Attack detect system (again)

Okay for the current stage, we know that for most of the damage detect system out there, we have:
- one trigger per unit (as we cant use only ONE trigger due to event leak here)
- destroying the trigger free the event somehow, prevent leaking
- removed unit (or decayed unit) will be removed in a group automatically

----

So, I'm thinking of something by using the things above:
- an attack detect system that using one DAMAGE_EVENT trigger, one group
- upon creating a new unit, register the unit into the trigger and the group
- and every 30 seconds (or 2 minutes, depends on map), destroy the trigger and by using the group, re-register the units that are still in the map into the new DAMAGE_EVENT trigger

so what we get is a DAMAGE_EVENT trigger that doesn't increase the handle count over time.

Question : will this work?

It really isn't noticeable enough to matter. I use a system that uses a single trigger with multiple events, and I don't notice anything when having thousands of units killed and created.

Well, doing it the "bad" way with 1 trigger in a map of Szythe's caused it to lag to hell and back again... so I really don't know how "bad" it is, to be honest.

nobody is answering the question....

I would assume it would work, but depending on the number of units in the map, it might cause a bit of lag every refresh. Do some tests with creating a trigger and adding 300 events to it.

He said he was gonna use a single event for multiple units?

single trigger for multiple units and then every x seconds destroy and create a trigger, refreshing all the events which units don't exist for.

It will not work.

One trigger = one unit
is the only way.

I tried that before and I think it had problems.

I was a nub triggerer back then, though.

yeah really interesting... YES if you will make it correct it will work + don't use a loop to destroy and recreate triggers etc.
use a periodical timer with 0.025 event. SO you will rework 40 units per second == no noticeables lag. and yes do it for example every minute.

nice idea +1 ^^
// the problems at first look are attachings BUT they can be also grouped and checking for "special unit is existing"...
zen87 if you will do it wise so it will be fine =)
you also could include in this a "global cleaner" (to deallocate attached data from units)

or you could do it permo... for example every 0.1 second check 1 unit in a group (or array is better) and do needed actions. (somekind infinite cycle)
so in 1 minute you can check 600 units. (well more than that)
imho a wise mangment... you have inspired me but i will do nothing xD

Do events register to the actual unit or to the handle?

What if a unit is registered the damage event and then is removed. The next unit created gets the same handle id the previous one had. Does it now work for the event or is there some internal check which prevents this?

It does not fire.

My test map is attached; in-game attack the footman to make the damaged message appear, then press escape to start removing it and creating new ones until the handle ids match. The message does not fire when the new footman with the same handle id is attacked.

In the map list, the name of the map is "Damage Event".

I would make 10 triggers and equally divide the events amongst them to solve the lag problem.

@Toadcop
You cant remove events from a trigger. So checking units 1 at a time would mean that you have to have 1 trigger for each unit, which isn't exactly what the discussion is about.

Damage events are registered to the unit object, not unit handle.
I discovered this while tracking a bug created by mixing 2 systems that used damage detection.

It turns out that if you register 2 unit damage events to the same unit the first one overrides the second.

My guess is that all specific unit events are registered on the unit object.

Toadcop: thank you! I think i have a rough idea of doing the things now +rep~

I'll post it in the resources after I finished it :)

cohadar: so... multiple damage event on the same unit don't work... that might be something useful...