Invulnerability Detector

[moyack]

I've changed the name to avoid confusion (Inv could be interpreted as Inventory... :P)

[ToukoAozaki]

Originally Posted by moyack

I've changed the name to avoid confusion (Inv could be interpreted as Inventory... :P)

I was also concerned, but I didn't have enough motive to change. Thanks.

[DioD]

this is madness...

JASS:

library InvulnerabilityDetector
//THIS IS SPARTAAAAAAAAA

    function IsUnitInvulnerable takes unit whichUnit returns boolean
        local boolean result = false // default false
        local real HPSTATE = GetWidgetLife(whichUnit)
        
        call UnitDamageTarget(whichUnit,whichUnit,0.01,false,true,null,null,null)
        
        if GetWidgetLife(whichUnit) == HPSTATE then
        return true
        else
        return false
        endif
        return false
    endfunction
endlibrary

looks like "null ownage" still works.

ever if banish ruin all fun, there is check for ethereal state, on this check we can use other attacktype.

well, there is banish+spell immune no problem proof.
result by modded function ofc.

[Troll-Brain]

And in this unlucky case :
The unit has just a little more than 0.405 hp and she is vulnerable, she will die for no reason.
And there is a constant witch allow to hit invulnerable units, no ?
Hmm finally i will make my own function which checking if the unit has one of the invulnerable buff.
Credit to Rising_Dusk :p

[ToukoAozaki]

Originally Posted by DioD

this is madness...

JASS:

library InvulnerabilityDetector
//THIS IS SPARTAAAAAAAAA

    function IsUnitInvulnerable takes unit whichUnit returns boolean
        local boolean result = false // default false
        local real HPSTATE = GetWidgetLife(whichUnit)
        
        call UnitDamageTarget(whichUnit,whichUnit,0.01,false,true,null,null,null)
        
        if GetWidgetLife(whichUnit) == HPSTATE then
        return true
        else
        return false
        endif
        return false
    endfunction
endlibrary

looks like "null ownage" still works.

ever if banish ruin all fun, there is check for ethereal state, on this check we can use other attacktype.

well, there is banish+spell immune no problem proof.
result by modded function ofc.

Your method indeed functions, but there is a flaw. No matter which parameter you change or not, UnitDamageTarget will trigger EVENT_UNIT_DAMAGED every time called with vulnerable units: which is undesirable. Please consider why I did all sort of extra stuff; a function that works with anything and anytime.

[emjlr3]

if someone has a DDS, they can easily omit any damage they want - such as in this case

[Rising_Dusk]

Yeah, a 0. damage event is easy to ignore in every DDS out there.

[DioD]

You can use damage dummy, if not able to set up filters yourself.
There is no problem with events.

JASS:

    function IsUnitInvulnerable takes unit whichUnit returns boolean
        local boolean result = false // default false
        local real HPSTATE = GetWidgetLife(whichUnit)
        call SetWidgetLife(whichUnit,HPSTATE + 0.01)
        call UnitDamageTarget(whichUnit,whichUnit,0.01,false,true,null,null,null)
        
        if GetWidgetLife(whichUnit) == HPSTATE then
        return true
        else
        return false
        endif
        return false
    endfunction

There is no more problem with 0.405 hp, since unit will get hp before taking damage.

[ToukoAozaki]

Originally Posted by Rising_Dusk

Yeah, a 0. damage event is easy to ignore in every DDS out there.

That would impose limitation that one should use DDS or configure it additionally. This makes extra (indirect) dependency. Suppose you are making an AoS and decide to implement a takeover feature. In this case, you don't necessarily have to use DDS; detecting damages on a few major buildings would work fine without DDS. However, if I need to force doing such configuration, it is overcomplicating things on the user's side. I think unnecessary dependencies should be avoided in the modules (whether it is Jass, C, C#, or whatever), and I wrote them to be independent as possible. It is user's choice anyway, to choose simpler implementation but more work on the user's side, or a bit complex implementation but simple and handy on the user's side. (I think performance difference in this particular case is trivial, though)

[Rising_Dusk]

Any AoS without a DDS is going to be limited in the scope of its design anyways, so as far as we're concerned your example falters. Anyways, this is not a discussion of game design, so please don't use silly, mis-representative examples.

Anyways, you have still failed to address why using the boolean return of a UnitDamageTarget() call won't work. Technically, your current library will set off false positives for systems that intercept unit orders, so it imposes just as much a user-side dilemma as the UnitDamageTarget() boolean return. As far as I am concerned, with regards to actual maps, the overhead to ignore 0.00 damage events is obvious, whereas ignoring random orders in order-related systems may not be.

Regardless, I stand by what we decided on earlier. If you can prove via testmap that a custom FoD ability is the only way to do this library effectively, then I'll buy into it.

[DioD]

UnitDamageTarget()

return true, always, no matter what params, tested on paladin.

DDS system - if you can not add filters - dont use jass its overcomplicated for you.

[Rising_Dusk]

Originally Posted by DioD

return true, always, no matter what params, tested on paladin.

Did you test it against ethereal + invulnerable units as well as spell immune + invulnerable units? If it works for those two cases, it's a far better solution than the FoD ability order.

[ToukoAozaki]

Originally Posted by Rising_Dusk

Any AoS without a DDS is going to be limited in the scope of its design anyways, so as far as we're concerned your example falters. Anyways, this is not a discussion of game design, so please don't use silly, mis-representative examples.

I just wanted to be more specific. My argument is that this library doesn't interfere with trigger events.

Originally Posted by Rising_Dusk

Anyways, you have still failed to address why using the boolean return of a UnitDamageTarget() call won't work. Technically, your current library will set off false positives for systems that intercept unit orders, so it imposes just as much a user-side dilemma as the UnitDamageTarget() boolean return. As far as I am concerned, with regards to actual maps, the overhead to ignore 0.00 damage events is obvious, whereas ignoring random orders in order-related systems may not be.

This does not fire any order events. I am well aware of that issue and worked in many ways to make that not happen. When I first wrote this library, there was my another library called OrderLib, which reports any order events in debug mode. When I got a report of a FoD order, I made changes until I didn't get false positives.
Please read what I wrote.

Originally Posted by Touko-Aozaki

This is an invulnerability detector library. Uses finger of death as a dummy ability, and won't fire any order events.

Originally Posted by Rising_Dusk

Regardless, I stand by what we decided on earlier. If you can prove via testmap that a custom FoD ability is the only way to do this library effectively, then I'll buy into it.

Would a proof that there is no event fired be enough, then?

[DioD]

Rising_Dusk
Read my posts, just a time, more - better.

I posted proof screen.

There is proof map.

[ToukoAozaki]

I have updated the testmap. You can now see every issued order on the screen. :)

You can test it yourself, or see attached screenshot. If checking invulnerability against vulnerable units causes an order to fire, it should be displayed on the screen. You can also compare the result by commenting out PauseUnit calls (doing so will cause the event to fire.).