Brute51 wrote:
Good one about the floating point thing. In Supcom it happens quite often that it is "almost" a round number, especially in the UI code. I'll try to remember it for future things. Its not straight forward when you have to use it because variable types are implicitely defined.
Good one about the floating point thing. In Supcom it happens quite often that it is "almost" a round number, especially in the UI code. I'll try to remember it for future things. Its not straight forward when you have to use it because variable types are implicitely defined.
Yeah, there are probably a few subtle bugs around this elsewhere in the codebase
It's a tricky thing to remember when you don't have the types right there.Brute51 wrote:
The registering thing does not always return false. It actually seems to work ok in most cases. But given that there's a floating point comparison like you mentioned it is partially "luck" that it returns true.
The absorbion is used to take advantage of the shield absorbtion logic in the game and because we only want to spill over the actual damage done to the shield, not the projectile damage. For example when the shield has less HP than the damage the projectile deals you still want to spill over the damage to the shield, not the projectile damage. You're right that in the current code this could damage the shield twice for the same projectile, but changing "absorbed" to "projectile damage" is not the way to fix it. It may work in many layered shield situations but it is more complex than that.
True, but we need to pass on the absorbed damage along with the actual damage given. This way, we can check whether we took the original damage, or spillover from it, and still apply proper absorbed damage from the first shield.
It's still not perfect, since whichever shield has its OnDamage function called first, gets to decide how much damage is spilled over. This is an implementation detail of the DamageArea C-function defined in Projectile, so there's going to be a bit of 'randomness' when multiple, different-hp shields are hit by the same projectile.
The only way I see around this is to rework the DamageArea function in lua, but I'm not too keen on that, and don't think a little randomness like this is a big deal.
I suppose you could wait an extra tick and have all the shields propagate spillover values without applying, and then finally just applying the smallest one. This seems like a bad idea though, especially with many shields.
Brute51 wrote:
Adding a GetAdjacentShields function seems like a good change.
We both have a fix, nice. I'll have a look at your code but what do we do now?
IceDreamer uploaded a new version of the spillover mod. Take a look at that, perhaps post your own code -- and we can discuss here what needs to be done?
I definitely think this fix is top priority.
Statistics: Posted by Sheeo — 14 Jun 2014, 15:48
]]>
