[JASS] Dynamic Triggers - just how bad are they?

[Molekyle]

I've been coding most of the spells in my maps using dynamic triggers, recently I saw a post on wc3c claiming that dynamic triggers leak ever so slightly no matter how you go about cleaning them up... naturally this made me piss my pants as I would have to recode tons of spells if it happened to be true.

So just how bad are dynamic triggers?

Additionally, I have posted a sketch of how I go about cleaning up the dynamic triggers in my map:

function ability_periodic takes nothing returns nothing
    local trigger trig = GetTriggeringTrigger()
    local integer trigid = GetHandleId(trig)

    call TriggerRemoveAction(trig, LoadTriggerActionHandle(udg_hashtable, trigid, 0))
    call FlushChildHashtable(udg_hashtable, trigid)
    call DisableTrigger(trig)
    set trig = null
    call DestroyTrigger(GetTriggeringTrigger())
endfunction

function ability_conditions takes nothing returns boolean
    local trigger trig
    local integer trigid

    if GetSpellAbilityId() == 'xxxx' then
        set trig = CreateTrigger()
        set trigid = GetHandleId(trig)
        call TriggerRegisterTimerEvent(trig, 0.03125, true)
        call SaveTriggerActionHandle(udg_hashtable , trigid, 0, TriggerAddAction(trig, function ability_periodic))
        set trig = null
    endif

return false
endfunction

 

[WaterKnight]

What do you need dynamic triggers for? The example you showed here involves a periodic event. You could do this as well/better via a timer object.

triggerconditions should at least be better than triggeractions corcerning leaks.

 

[Molekyle]

Yes, Im using dynamic triggers for MUI periodic spell events. I realise now that the same thing could have been achieved with a timer, but this is an old map and as such most of the spells were made before I was that familiar with JASS.

I guess that kinda brings me back to the question: Just how bad are dynamic triggers? Are they so horribly bad that I should recode all spells that I've already finished - because I'd rather not put that much work into redoing them all unless it poses significant problem.

You mention replacing triggeraction with triggercondition, I've seen that suggestion before, just out of curiosity - what is the improvement here?

 

[WaterKnight]

triggerconditions are faster, they are checked first. Blizzard did not screw them up as much. I think the TriggerClearActions function does not remove the triggeractions properly, only deactivates them. At least the id does not get released. TriggerEvaluate is fast and you can return a boolean value, which can be used to determine if the thread wrongly terminated. triggerconditions or at least TriggerEvaluate does not suffer from init inflation.

A con is that you cannot have TriggerSleepAction within triggercondition-threads but there is few (senseful) application for TSA anyway. Also you may already use a triggercondition to skip the triggeractions in case it returns false.

So have you really everywhere spelled the framework in full like above? I do not know why people do this, use functions, it is neater and you can somewhat change the implementation later on.

@initial question: Test the map, if you see the performance breaking in, it's bad, else it's tolerable. Most likely you won't cast your abilities a million times and won't even notice it.

 

[Molekyle]

So have you really everywhere spelled the framework in full like above? I do not know why people do this, use functions, it is neater and you can somewhat change the implementation later on.

Yep, sadly that is the case.. /sadface.

Anyways, thanks for the help waterknight, much appreciated!