IsUnitDead

[Dr Super Good]

Generally the standard death detection method using life is fine as no one is stupid enough to heal a dead unit. If it does cause a problem people would fix it using your system but by default its easier and faster to do life detection.

[Berbanog]

I have never had an issue with detecting whether or not a unit is dead, seriously.

[azlier]

Triggers are not the only method through which life can be added to dead units. Stone Form is an example.

[Berbanog]

I don't understand what you mean by that, azlier. A dead unit cannot cast an ability (in this case, Stone Form).

[azlier]

Try killing a unit that has Stone Form active?

[Berbanog]

It dies?

[azlier]

Try checking its health a short time after death?

I forget the exact bug myself, but Stone Form causes increased health after death sometimes. I think.

[Berbanog]

When the unit died I checked its health immediately at death (to which it responded 0.00) and then again 3 seconds later (to which it also responded 0.00). Then I checked its health in the thread after the unit dies (a 0.00-second timer) and got the same results.

[azlier]

As I said before, I forget the exact bug myself.

But there is a bug, and it's better to be safe than sorry.

Who knows? Maybe UnitAlive is faster than a native and a real comparison.

[Berbanog]

Originally Posted by azlier

Maybe UnitAlive is faster than a native and a real comparison.

I still wouldn't use it lol. I tend to make everything I need myself anyway but if I were going to submit a system I wouldn't have it require something like this just to speed up one function call. I use structs that represent units for most of my code construction anyway so I simply have a method method isDead. If I were looking to speed it up (I would first need proof that its faster) then I wouldn't use this library, instead I would probably just change my method so that it uses the faster native.

[Troll-Brain]

Originally Posted by Berbanog

When the unit died I checked its health immediately at death (to which it responded 0.00) and then again 3 seconds later (to which it also responded 0.00). Then I checked its health in the thread after the unit dies (a 0.00-second timer) and got the same results.

Try with a TriggerSleepAction(0) and you will see a dead unit with more than 0.405 hp.

Btw i don't consider myself using some common.ai native inside a trigger as a "safer" way.
Blizzard don't officially support it and we all know how supported things are lame/bugged sometimes.
IsUnitType(<unit>,UNIT_TYPE_DEAD) and GetUnitTypeId(<unit>) != 0 is perfect for me, even if it should be "much slower" than the native GetWidgetLife or UnitAlive.

I've already explained my reasons few post before, plz read them before comment it.

[Mooglefrooglian]

I disagree. Just because it isnt supported means little. The actual function which is within the wc3 exe is probably just a simple if check of some internal boolean, which makes it close to impossible to screw up.

[Justify]

Lmao. JNGP isn' supportet by Blizzard either...

[Troll-Brain]

Originally Posted by Justify

Lmao. JNGP isn' supportet by Blizzard either...

Sorry, but it's a lame comment.
Mooglefrooglian is probably right though.

[Justify]

Na, it's not. Someone here mentioned before some days, that he doesn't want to use the JNGP because it's not 100% stable. Barnebog showed him, that the WE isn't stable too. It's just like this quite often, that people don't want to use something for some reason (like an unsupported native) while they use stuff that could be rejected for just the same reason (JNGP). However, GetWidgetLife is still a perfect check IF you code properly. UnitAlive if not, the same with all the TimerUtils safety stuff, you could improve performance a lot if you keep sure not to make mistakes (and no, I can't say this all the time)