Leak test

[--Thanatos--]

Will this leak?

function TestingTheLeak_TrgAct takes nothing returns nothing

    local trigger trig = GetTriggeringTrigger ()

    call UnitDamageTarget (GetHandleUnit(trig,"target"),GetTriggerUnit(),GetHandleReal(trig,"damage"),false,false,ATTACK_TYPE_CHAOS,DAMAGE_TYPE_FIRE,null)

    call DestroyTrigger (trig)
    set trig = null

endfunction

I'm pushing to efficiency and leak for now so that I only use one local. With the hope this doesn't leak.

 

[Squll2]

i believe.. but im only a begineer that

GetTriggerUnit()

will leak.

 

[--Thanatos--]

Okay I think I got the answer.

Units don't leak (at least we cannot do any to remove the leak, I've read that somewhere).
But still +rep for Squll2 for that...

Then another question:
Is it Efficient enough?

 

[TheDamien]

Use DisableTrigger() and TriggerRemoveAction() before destroying.

Edit: Unfortunately, you can only get a triggeraction when you first register a trigger, so it's best to not use actions entirely and instead put your "actions" in the trigger condition (put return false at the end). This is according to Vexorian.

i believe.. but im only a begineer that

GetTriggerUnit()

will leak.

Not a "leak" you would want to get rid of though.

 

[substance]

apparently you shouldnt destroy triggers.

 

[--Thanatos--]

Please destroy triggers.

> Use DisableTrigger() and TriggerRemoveAction() before destroying.

DisableTrigger() is unnecessary (heard from SFilip, if I'm not mistaken).

TriggerRemoveAction? I think TriggerClearActions will do the job?

> Edit: Unfortunately, you can only get a triggeraction when you first register a trigger, so it's best to not use actions entirely and instead put your "actions" in the trigger condition (put return false at the end). This is according to Vexorian.

Oh yeah. I remember that there's the trick.

BTW, this is just a test, so don't care about handle stacks. -.-

 

[TheDamien]

Please destroy triggers.

> Use DisableTrigger() and TriggerRemoveAction() before destroying.

DisableTrigger() is unnecessary (heard from SFilip, if I'm not mistaken).

TriggerRemoveAction? I think TriggerClearActions will do the job?

> Edit: Unfortunately, you can only get a triggeraction when you first register a trigger, so it's best to not use actions entirely and instead put your "actions" in the trigger condition (put return false at the end). This is according to Vexorian.

Oh yeah. I remember that there's the trick.

BTW, this is just a test, so don't care about handle stacks. -.-

If there is a TriggerClearActions then it will probably work just as well as TriggerRemoveAction.

 

[Rheias]

No leaks here.

You should know that when destroying trigger (although it appears that it shouldn't be done) you need to disable the trigger before destroying it.

 

[Tom Jones]

As someone mentioned, you'll have to remove the triggeraction from the trigger before destroying it to avoid leaks. DestroyTrigger() doesn't clean triggeractions from a trigger.

 

[emjlr3]

add a condition as opposed to a triggeraction, and use that in its place. Then destroying the trigger is all that is needed.

As far as efficieny goes, structs would still blow this away

 

[Arkan]

No leaks here.

You should know that when destroying trigger (although it appears that it shouldn't be done) you need to disable the trigger before destroying it.

Source on this?

 

[Rheias]

> Source on this?

I'm unable to find the thread again, however I saw somewhere the removing triggers without disabling them is like removing timers without pausing them, what appears to cause few problems.

Maybe need wasn't the right word, but it certainly won't do harm!

> As someone mentioned, you'll have to remove the triggeraction from the trigger before destroying it to avoid leaks. DestroyTrigger() doesn't clean triggeractions from a trigger.

Or use condition as an action.

 

[Dimaspy]

Fact about leaks. Nobody likes them, they are in the way, they are irritating, some people has wrecked their computer because of them, and if you don't like the leaks here, never try out Worldcraft making counter-strike maps. :banghead:

( Totally out of topic!! )

 

[Doom-Angel]

u need to pause timer before destroying\removing it?

 

[PurgeandFire]

i believe.. but im only a begineer that

GetTriggerUnit()

will leak.

Units don't leak. Only local units leak, so they need to be set to null. Mapmakers just use variables for GetTriggerUnit() if it is being called a lot of times, so it is easier for them to write some variable name such as "caster" than "GetTriggerUnit()". It is just a time and amount of work efficiency, both will do the same and won't leak. (Except local units because they need to be nulled)

 

[Uberplayer]

>u need to pause timer before destroying\removing it?
You don't need to, it destroys anyways, but you really should.. I don't remember why >_>

It's also good not to destroy timer you use in spell, you should use same timer for all instances if you are able to.

 

[--Thanatos--]

I cannot use structs. (I don't have NewGen)

> You don't need to, it destroys anyways, but you really should.. I don't remember why >_>
Infinite run bug maybe?

> It's also good not to destroy timer you use in spell, you should use same timer for all instances if you are able to.
Freaking hard w/o globals. -.-

> You should know that when destroying trigger (although it appears that it shouldn't be done) you need to disable the trigger before destroying it.
I don't think so. I remember a mod told me. (forgotten, SFilip if I'm not mistaken)

 

[Tom Jones]

> You don't need to, it destroys anyways, but you really should.. I don't remember why >_>
Infinite run bug maybe?

Handle stack corruption.

 

[Doom-Angel]

Handle stack corruption.

could u elaborate this one?

 

[SFilip]

> at least we cannot do any to remove the leak, I've read that somewhere
Not true.
A leak only occurs when you create something and don't destroy. Units get destroyed about 90 seconds after death.
GetTriggerUnit does not create anything...and, well, why would someone want to create a unit every 0.1 seconds? Unless it's invisible (dummy) there should be nothing to worry about.

> could u elaborate this one?
Supposedly there is a cached "list" of all handles.
Now recently we figured that I2H based systems tend to corrupt it - warcraft can't understand when a handle simply appears out of nowhere.
When this happens handles you create afterwards might get the same id as some existing...very bad thing really.