GetUnitState() bug

[Luorax]

I've just experienced a very, very weird bug: one of my heroes' spells deals damage based on the targets maximum health, any time the hero successfully lands a basic attack and heals him for the same amount. Its done like this:

    call Heal(caster,caster,MagicDamage(caster,target,GetUnitState(target,UNIT_STATE_MAX_LIFE)*.025,DAMAGE_DIRECT))

Now the problem is that GetUnitState returns really odd values: even 2.5% of their maximum health is usually over 12k. Does anyone have an idea what could possible be causing this weird thing?

At first I thought it was because of Cargo Hold (jungle creeps are given this ability so that they won't automatically aggro on heroes), but my heroes also die from one single hit, even though they don't have Cargo Hold. So I'm clueless.

 

[rulerofiron99]

Use debug messages:
display unit max health
display unit max health * 0.025

 

[edo494]

if you use things like DDS by bribe then its possible because it gives the unit 500k life when it takes damage, that actually returns the value you are experiencing

 

[Luorax]

Use debug messages:
display unit max health
display unit max health * 0.025

As I said it returns odd values, it wasn't just a random guess. The number returned by GetUnitState(target,UNIT_STATE_MAX_LIFE)*.025 was equal to the damage text that popped up.

@edo494:
I'm using J4L's "Damage", which is also based on adding extra life to the unit. You may be right and it might be the reason why this is happening - though I didn't mention it in the main post, but it only occours if that's the first damage the target receives from the hero - if, let's say I cast a spell on them or attack them without the buff activated, it works perfectly.

 

[Luorax]

Yea, it was the extra life ability from Damage. I don't want to go into details, let's just say that the timer that fired the on-attack-hit event and Damage's built in ability-removal timer was fired simultaneously, and the unit still had the ability when the event was fired and the damage was dealt. So the problem's SOLVED.

 

[Troll-Brain]

You know what, maybe this Timer(0) is not necessary in the damage system.
Remove an ability may be not instant. (pure theory, i could be 100 % wrong)
Or it could be also this "hacky" use about Pause/ResumeTimer instead of just start it.

 

[Luorax]

J4L is using ResumeTimer. I'm quite sure though it's necessary, otherwise they wouldn't have made it the way it is written now, because it'd be easier for sure to just remove it immediately. (To be honest I'm also lazy to test it, because tomorrow I'm moving to the youth hostel and the first semester of the university is starting soon, so I'm happy if I can just release the new version without this bug)

 

[Troll-Brain]

J4L is using ResumeTimer. I'm quite sure though it's necessary, otherwise they wouldn't have made it the way it is written now, because it'd be easier for sure to just remove it immediately. (To be honest I'm also lazy to test it, because tomorrow I'm moving to the youth hostel and the first semester of the university is starting soon, so I'm happy if I can just release the new version without this bug)

I don't believe in Jesus4Lyf or anyone else, including me.
We are all just a bunch of amateur, most of times we make assumptions without any tests, while jass is tricky and odd.
He could have tested if the timer was needed, ot not.

About the ResumeTimer, he exploits one bug, apparently resume a not paused timer make it expiring again.
But i consider it as an awfull speedfreak hacky way, here it's obvious that the proper way is to use TimerStart.

call TimerStart(RemoveBoostedTimer,0.0,false,function RemoveBoostedTimerFunc)

And then ofc remove this line from the onInit method.

I'm not saying that it will change something, but you deserve some bugs with such silly jass usages.

 

[baassee]

JASS != Logic.