IsUnitDead

[YourNameHere]

function UnitDead takes unit u returns boolean
    return not UnitAlive(u)
endfunction

That doesn't need to be in there if it's just returning a native call : |. It'd be like a BJ ><

I have quarrels with DoesUnitExist as well, but I suppose that would be fine. It's like a BJ too, : o.

Since it get's inlined by JassHelper, I don't see any problem with it.

 

[Nestharus]

True that, I'm just saying writing-

UnitAlive(u)

Is just as easy, lol.

 

[yatyfornetreg]

What will happen if I
call SetUnitState(MyUnit, UNIT_STATE_LIFE, 0.2)?
0.2 < 0.405
So, I just want to ask. Why 0.405 can be a flag that judges whether a unit is dead or not?

 

[Berb]

So basically, this is an IsUnitType( unit, UNIT_TYPE_DEAD ) that returns true when unit == null. I would find it much easier to just add another boolean expression to the if-statement. If someone is going to be typing out a system/spell, being saved 10 seconds of typing for slower performance is never worth it. There is no way I would make any of my vJass libraries require your little "death" library, no way.

To be honest I don't think this is very useful, but I suppose there isn't much standard when it comes to script submissions here.

 

[azlier]

These days it uses a more accurate (and probably faster) native to tell whether a unit is alive or not, you know.

 

[Justify]

UnitAlive is still bugged, at least people say so
Didn't tested it, but it seems not to recognize removed
units as dead in the moment when it gets removed.
On thehelper someone fixed it with RemoveUnit hooks,
using KillUnit.
However, this will trigger unit-death events :/

 

[Berb]

Sorry my mention of standards in script submissions was rude.

I'll let you guys discuss this one I've already given my two bits.

 

[azlier]

>Didn't tested it, but it seems not to recognize removed
units as dead in the moment when it gets removed.

Nothing can.

 

[Berb]

How are you detecting when the unit is removed?

 

[azlier]

hook RemoveUnit UnitRemovedHook

This bug only happens when RemoveUnit is called.

 

[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.

 

[Berb]

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.

 

[Berb]

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?

 

[Berb]

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.

 

[Berb]

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.

 

[Berb]

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]

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]

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)

 

[Troll-Brain]

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)

I'm not that sort of guy, since JNGP is able to make correct map files.
I was focusing about an other "hack" abuse in jass2, but like i've said Mooglefrooglian is probably right.
About the GetWidgetLife then you have to recode all the regeneration abilities including the fountains, not that hard, but i don't consider using them as "coding badly" (depends how you use them, and what you want to do ofc)

 

[Bribe]

>Didn't tested it, but it seems not to recognize removed
units as dead in the moment when it gets removed.

Nothing can.

Nestharus found a way to detect it: abilities get removed from the unit the instant it gets removed/decays, but its unittypeid will still be above 0

I think the UnitEvent library Nestharus developed kills this, because its "IsUnitDead" function is the fastest possible return in this case.

It should be mentioned for future readers of this thread, that native declarations do not work with Vexorian's Map Optimizer. I suggest UNIT_TYPE_DEAD if you want to use the optimizer.