[System] StructuredDD (Structured Damage Detection)

[Cokemonkey11]

Originally Posted by Troll-Brain

That's exactly the opposite.
There is a reason why we use set ... = null for locals.
When the local variable "dies" (end of the function), its value should be flushed, but it is not, and then when the associated handle is destroyed, its id is not recycled.
Function arguments are not concerned by this bug though (takes ...)

So how can I fix the issue? How can I null a unit when it finishes decaying?

Maybe instead I should just remove the "DEAD_UNITS_ARE_NULL" system and simply make the loop check for dead units.

I should also be using the native UnitAlive (right?)

[Troll-Brain]

"Modern" unit indexers can detect when an unit is removed of the game on event, exploiting a bug.

With a removed unit, or any other invalid one, GetUnitTypeId should return 0.

Jass:

        static if ENABLE_PERIODIC_CLEANUP then
                set perCleanup=CreateTrigger()
                call TriggerRegisterTimerEvent(perCleanup,PER_CLEANUP_TIMEOUT,true)
                call TriggerAddCondition(perCleanup,Condition(function ddBucket.perCleanupC))
            endif

You could directly use a timer instead.

[Cokemonkey11]

Originally Posted by Troll-Brain

"Modern" unit indexers can detect when an unit is removed of the game on event, exploiting a bug.

With a removed unit, or any other invalid one, GetUnitTypeId should return 0.

That seems quite useful. I think with my script, if the client uses RemoveUnit(), the associated bucket and trigger will never be destroyed, which is a big problem.

Can you show me how to use this exploit?

Jass:

        static if ENABLE_PERIODIC_CLEANUP then
                set perCleanup=CreateTrigger()
                call TriggerRegisterTimerEvent(perCleanup,PER_CLEANUP_TIMEOUT,true)
                call TriggerAddCondition(perCleanup,Condition(function ddBucket.perCleanupC))
            endif

You could directly use a timer instead.

That would be more efficient, right? Because the callback function in a timer is faster than checking the conditions of a trigger?

[Troll-Brain]

Originally Posted by Cokemonkey11

Can you show me how to use this exploit?

Unit indexers provide a custom event for that, such as UnitIndexer, AutoIndex, AIDS.
If you want a sample, check my UnitLL resource.

That would be more efficient, right? Because the callback function in a timer is faster than checking the conditions of a trigger?

That should be yes, but anyway you just don't need a trigger.

[Cokemonkey11]

Originally Posted by Troll-Brain

Unit indexers provide a custom event for that, such as UnitIndexer, AutoIndex, AIDS.
If you want a sample, check my UnitLL resource.

I looked through nes' non-lua version of UnitIndexer and couldn't find anything useful. If I can't figure it out and there's no way to explain it to me I'll just make a "safeRemoveUnit" method.

That should be yes, but anyway you just don't need a trigger.

Thanks. I've updated the script to use a timer.

[Nestharus]

rather than comparing to null, compare GetUnitTypeId to 0.

UnitIndexer is in a rather optimized state atm, rendering it nigh unreadable ;p.

Whenever a unit decays or is removed, 'Adef' fires two times. The second time it fires, the ability level of 'Adef' is 0. You register a trigger to fire whenever 'Adef' is used and check to see if the ability level is 0. If the ability level is 0, the unit went out of scope via decay or remove =). That is how UnitIndexer works = p. It also has a bit of other code for event registration, but that is the bug itself ; ). Things like AIDS and wc3c don't take advantage of 'Adef' being 0 on the second fire, so AIDS uses a stupid timer to check to see if the unit is gone and wc3c hooks RemoveUnit and : |.

I do not recommend building an entire unit indexer into the code. The fastest it will ever be is UnitIndexer, so if you are going to do indexing, you might as well just use UnitIndexer >.<.


One thing... I don't think hexed units are ever deindexed when they are removed via RemoveUnit as all abilities on a Hexed unit are disabled. Same with silenced unit ;o.

[Cokemonkey11]

Originally Posted by Nestharus

rather than comparing to null, compare GetUnitTypeId to 0

Oh perfect. I've updated the script (And added you and Troll-Brain in my credits :P )

Thanks for explaining this.

UnitIndexer is in a rather optimized state atm, rendering it nigh unreadable ;p.

Whenever a unit decays or is removed, 'Adef' fires two times. The second time it fires, the ability level of 'Adef' is 0. You register a trigger to fire whenever 'Adef' is used and check to see if the ability level is 0. If the ability level is 0, the unit went out of scope via decay or remove =). That is how UnitIndexer works = p. It also has a bit of other code for event registration, but that is the bug itself ; ).

Interesting. Why don't you also use GetUnitTypeId()? Is UnitAddAbility() faster?

Things like AIDS and wc3c don't take advantage of 'Adef' being 0 on the second fire, so AIDS uses a stupid timer to check to see if the unit is gone and wc3c hooks RemoveUnit and : |.

*cringe* what a nightmare.

One thing... I don't think hexed units are ever deindexed when they are removed via RemoveUnit as all abilities on a Hexed unit are disabled. Same with silenced unit ;o.

But I'm sure you've documented that into UnitIndexer. Anyway, GetUnitTypeId() will not have to worry about that so I've used it.

One more thing, I've also updated the script to use the UnitAlive() native. I assume that's better. Anyone recommend reverting it to the way it was for some reason?

[Nestharus]

One more thing, I've also updated the script to use the UnitAlive() native. I assume that's better. Anyone recommend reverting it to the way it was for some reason?

Use that

Interesting. Why don't you also use GetUnitTypeId()? Is UnitAddAbility() faster?

??

The ability is added to all units as the units are created and it is never removed ;p

[Cokemonkey11]

Originally Posted by Nestharus

The ability is added to all units as the units are created and it is never removed ;p

Gotcha. Carry on.

I'm pretty happy with this system in its current state. Anyone have any questions or requests?

I'm thinking about writing a tutorial on how to use it for GUI users. Perhaps that's a waste of time.

[Troll-Brain]

About UnitAlive, i personnaly used IsUnitType(...UNIT_TYPE_DEAD), but i guess that the UnitAlive native have a different behavior about dead units but being under the process of resurrection.
In fact a custom function IsUnitAlive which have an extra boolean argument to consider ressurecting units alives ot not should be the best way.

[Cokemonkey11]

Originally Posted by Troll-Brain

About UnitAlive, i personnaly used IsUnitType(...UNIT_TYPE_DEAD), but i guess that the UnitAlive native have a different behavior about dead units but being under the process of resurrection.
In fact a custom function IsUnitAlive which have an extra boolean argument to consider ressurecting units alives ot not should be the best way.

Under the process of resurrection means they're not alive or dead? Seems like a really specific bug to consider.

Also, since I'm declaring "native UnitAlive ...", will everything be handled correctly if another library declares the same native or will that cause a problem?

[Troll-Brain]

Jasshelper handle multiple native functions declaration (only consider the first and ignore the other ones).

I'm just saying i'm not sure how IsUnitType(...UNIT_TYPE_DEAD) and IsUnitAlive handle units which are being resurected, you should test it.

[Cokemonkey11]

I'm not worried about such a tiny case. The client won't know the difference between ressurecting units being considered live or dead anyway, I just want to use the native which is faster.

[Cokemonkey11]

Bumping this thread too.

Any questions? What exactly has to happen before a thread becomes accepted or graveyarded?

[Bribe]

To get it approved? Someone has to move the thread to the JASS Resources forum.

To get it reviewed is something different. I could approve this but it is still "another damage detection system" to join the ranks of far too many to keep track of.

Also, to respond to the Unitalive/IsUnitType thing, they both return the same when a unit is resurrecting.