Does destroying a trigger leak events?

If not, then can't we make leak-free damage engines by recreating the trigger periodically?

event is destroyed together with trigger. (if trigger is destroyed) xD

Events and conditions are destroyed automatically but actions are not. You need to keep track of the actions a trigger has and manually remove them with TriggerRemoveAction.

But not TriggerClearActions, since that leaks.

and since you should use only Conditions =)

Ah, I always assumed that Conditions had to be removed as well (since there is also a TriggerRemoveCondition-function).

So, back to the point. Most onDamage engines create a single trigger to which all units are added. The problem is that units are eventually killed, but the events are not removed => leak. If I would destroy the onDamage trigger and instantly create it again, say once every minute, the damage system would actually be leak free?

Most? I don't think I've ever seen a non-GUI system that does.

Resources -> Systems -> Intuitive Damage System - Rising Dusk

I don't think I've ever seen an onDamage-system which uses 1 trigger/unit (seems like a waste of triggers).

I have proof of it in AotZ if I could isolate it, but there is so much shit breaking in Wc3 in that map that it's tough to gauge. I know it causes natives to break though, because calls to SetUnitPosition among others just don't respond at all even if all of the arguments exist and are properly defined. It's really bizarre, but in my personal experience the obvious solution is to just never destroy the bloody triggers. As soon as I stopped destroying triggers, the problems vanished entirely. That's about the best I can say on the topic.

You should see some of the crazy shit UnitAddAbility has done in AotZ... It started messing up the raw codes and adding A006 when I would tell it to add A002. (Just an example) Things like IssueTargetOrder were breaking too, issuing orders that I wouldn't tell it to use. Seriously, if someone could decipher exactly what is breaking in AotZ, you'd discover a wealth of knowledge pertaining to problems with I2H and trigger safety among other things. It probably has a lot to do with me failing at coding, though, but still -- There's a bunch of other stuff going on there too.
Conditions don't have to be removed because they apparently share similar properties to boolexprs, as proven by some tests Vexorian has posted somewhere in this forum.

You use I2H?

Dynamic triggers are not a problem. I2H just causes other things to break.

So, destroying and recreating the onDamage trigger in the purpose of eliminating the leak is not a problem?

I2H is unsafe... wouldn't that mean that the classic game cache attaching which was used for like years is... :P

Used to, anyways.
Very much so.
I think more testing might be in order, though I presume not.

I think I can remember Vex saying that once he got rid of I2H and destroying timers, there wasn't a problem anymore (timers can be recycled, unlike triggers).

There are sometimes decisions to make, when you talk about DestroyTrigger, specially in such systems as Dusk's in which you don't really got any control on what the trigger will do, since you got an array of user created triggers called later. You would have to ask yourself if fixing the memory leak actually is worth it.

The fun part is that a dynamic trigger requires attaching and complications like that, including something verifying for dead units, not to mention that it allocates an extra handle per unit. I think at the end of the day, at least if not optimally implemented, dynamic triggers end up causing as much of a performance loss as leaking events.

There's Strilanc's crazy system in which he has generations of triggers, the problem is that there are always more events than units, and it still uses DestroyTrigger, you may call it the hybrid.

Exactly, the classic game cache-H2I-I2H hybrid is unsafe. That was one of the main reasons we invented structs...

--
I am not really sure if DestroyTrigger causes issues by itself. What we do know is that DestroyTrigger + waits in the trigger do, if you have no control whatsoever on what the trigger is going to do, it is better not to destroy it.

I have empirically observed that the removal of I2H takes maps to a new level of safety, I am not sure if I2H is the direct cause or the detonator, either way, It is best to remove it.

Whether removing I2H is all what's necessary, I am not sure. BTW, I got to say that damage stuff is the only place in which dynamic triggers are useful at all (This could change), not to mention the only use for the dynamic triggers in this case is to avoid an event leak. Everything else can be replaced with things that don't do dynamic triggers and don't leak. And timers can be recycled.

--
What we need is a test that leaks tons of events so we get to see its actual consequences on performance.

So this will cause a crash too?


Yeah.