onDamage issue
by Howard Dortch · in Torque 3D Professional · 02/19/2011 (1:46 pm) · 9 replies
I was having speed issues with the engine and discovered it was hammering the player::onDamage function with a %delta of -0.014 (number is not important) seems the negative value will cause it to call the onDamage every update causing 1000's of hits. Discovered this by putting echo statement in there and quickly ran up 500k of spam. Bug? Any reason I shouldn't put a test in the engine function like if(delta < 0) dont do the con::executef ?? thoughts?
#2
speedDamageScale = "1";
Seems it might be caused by setRepairRate but that doesn't make sense
02/19/2011 (5:51 pm)
minImpactSpeed = 9;speedDamageScale = "1";
Seems it might be caused by setRepairRate but that doesn't make sense
#3
The script is in health.cs
02/19/2011 (6:09 pm)
Ah yes, the healing script. It should only be working whilst the player is injured and then should stop, it's scripted to be an incremental increase until either damageLevel is fixed or health of the object (healthpack) is used up.The script is in health.cs
#4
echo("ON DAMAGE CALLED "@%obj SPC %delta);
run the game and from the console:
==>6149.setRepairRate(0.01);
ON DAMAGE CALLED 6149 -0.00999832
ON DAMAGE CALLED 6149 -0.00999832
ON DAMAGE CALLED 6149 -0.00999832
ON DAMAGE CALLED 6149 -0.00999832
ETC forever..
I altered the code in the engine to prevent this call but not sure thats the proper way to "fix" it...
02/21/2011 (5:44 am)
Well here is what happens. I put an echo in Armor::onDamageecho("ON DAMAGE CALLED "@%obj SPC %delta);
run the game and from the console:
==>6149.setRepairRate(0.01);
ON DAMAGE CALLED 6149 -0.00999832
ON DAMAGE CALLED 6149 -0.00999832
ON DAMAGE CALLED 6149 -0.00999832
ON DAMAGE CALLED 6149 -0.00999832
ETC forever..
I altered the code in the engine to prevent this call but not sure thats the proper way to "fix" it...
#5
Is it possible that floating point inaccuracies (if really large) are just throwing that delta away (such that health + delta == health)?
What are the before / after healths in onDamage?
02/21/2011 (9:43 am)
What's the health set to on the object being repaired?Is it possible that floating point inaccuracies (if really large) are just throwing that delta away (such that health + delta == health)?
What are the before / after healths in onDamage?
#6
02/21/2011 (2:20 pm)
The health values may vary. The above post I had the health at 50 via setDamageLevel(50); Then the player took some "medicine" via the setRepairRate(0.01) and blam.... I tried other values like 25 and 75 and got the same result. Are you suggesting a larger repair value like 0.1 ?
#7
I'd still throw in a print-out in the onDamage callback that shows the before and after health - make sure that
1) It is increasing the health
and
2) It's capping at some point?
If it's capping and continuing on, then that's a bug in the code
If it's never hitting a cap then the maxHealth or whatever the variable is may be set too high.
Also try tweaking your repair rate
(a repair rate of 0.01, healing from 50 to 100, will take 5000 frames...or 166 seconds... a little under 3 minutes of spamming your logs)
02/21/2011 (2:59 pm)
Ok those are pretty low healths...you have to be in the 10s of thousands (or dealing with very small numbers, like 0.000001) before floating point inaccuracies will really cause issues...I'd still throw in a print-out in the onDamage callback that shows the before and after health - make sure that
1) It is increasing the health
and
2) It's capping at some point?
If it's capping and continuing on, then that's a bug in the code
If it's never hitting a cap then the maxHealth or whatever the variable is may be set too high.
Also try tweaking your repair rate
(a repair rate of 0.01, healing from 50 to 100, will take 5000 frames...or 166 seconds... a little under 3 minutes of spamming your logs)
#8
02/21/2011 (3:48 pm)
Try looking at the number of bits used when it is pack/unpackUpdate-ed, may be getting clamped there.
#9
@Jameson looks like 6 bits for DamageLevelBits so I suppose a sign,exponent and mantissa could be compressed into that and x.xx would be about the limit.
I did add this to the engine to shut it up on small deltas
if(mFabs(mDamage - store) > 1.0f) << PREVENT SPAM
Con::executef(mDataBlock, "onDamage",scriptThis(),delta);
Seems to work ok for now but it's a bandaid not a fix.
Thanks for the response....
02/21/2011 (6:12 pm)
@Bryan onDamage callback ? you mean in the script code? That callback only checks for death and sets flash levels. I suppose I can put an echo in the player check loop and see what changes are there, will report after I check it out.@Jameson looks like 6 bits for DamageLevelBits so I suppose a sign,exponent and mantissa could be compressed into that and x.xx would be about the limit.
I did add this to the engine to shut it up on small deltas
if(mFabs(mDamage - store) > 1.0f) << PREVENT SPAM
Con::executef(mDataBlock, "onDamage",scriptThis(),delta);
Seems to work ok for now but it's a bandaid not a fix.
Thanks for the response....
Associate Steve Acaster
[YorkshireRifles.com]