Are _Conditions functions good or bad?

11-29-2008, 02:00 PM

I have several players who could all have the same hero and all use the same spell. If the spell kills a unit I need to do some stuff with that unit. So I have an array of units with each array element representing the corresponding player's hero. The unit in that array element is the current target of the spell (null if no current target).

I have a unit dies event. I need to determine if the unit was killed by the spell so I search the aforementioned array for the dying unit. If there's a match then I can do the trigger actions.

This is my _Conditions function:

JASS:

function Trig_KillWaveDeath_Conditions takes nothing returns boolean
    local unit uDying = GetDyingUnit()
    local integer iPlayer = 1
    if uDying != null then
        loop
            if uDying == udg_PlayerKillWaveTarget[iPlayer] then
                set uDying == null
                return true
            endif
            exitwhen iPlayer == 12
            set iPlayer = iPlayer + 1
        endloop
    endif
    set uDying = null
    return false
endfunction

Trouble is, when I get to the _Actions function, I have to do it all over again to determine the player ID that was casting the spell.

So my question is: would it not be more efficient to just put the _Conditions code at the start of the _Actions function and not bother with the _Conditions function?
If this is the case then why do we bother using _Conditions functions at all when it's just another superfluos function call and comparison? Is it merely just for ease of understanding more complex triggers? Or is there some tangible benefit to using _Conditions functions?

12-02-2008, 06:44 AM

Jazradel

It's actually better to use a Condition than to use an Action. Forgot why though. The benefits are tiny so mostly people seperate conditions and actions for ease of understanding.

In your case, using a single function would be a much better idea.

Also, its better to use GetTriggerUnit() instead of GetDyingUnit()

And I would highly recomend using a different method to detect if the spell has killed the unit.

12-02-2008, 07:30 AM	#3
Pyrogasm	TriggerConditions are preferable to TriggerActions because you can destroy a trigger with TriggerConditions without causing any severe problems, whereas there is some pretty horrific handle stack corruption that accompanies destroying a trigger with TriggerActions. But, considering that nowadays you shouldn't ever really destroy a trigger, the point is moot.

12-02-2008, 07:49 AM

marshall

Sounds like I still have a few things to learn.

Why GetTriggerUnit() vs GetDyingUnit()?

Why not destroy triggers from within trigger actions? I do this all over the place! Usually from triggers that don't have any conditions because they are called by other triggers.
Why not destroy triggers at all? I thought it wise to destroy a trigger that was no longer needed (all my init triggers for a start)?

Any thoughts on how else I would detect that the unit was killed by a particular spell?

12-02-2008, 08:49 AM

Captain Griffen

GetTriggerUnit() is slightly faster.

DestroyTrigger() is HORRIBLY bugged.

Condition functions don't need to start a proper thread, so are slightly faster, but you cannot wait in them (but waits are shite anyway for speed or accuracy intensive stuff).

In this case you could set the value after you find it to a global, and then access it from the actions function, as they'd run straight after the conditions.

12-02-2008, 08:52 AM

Pyrogasm

What do you gain by destroying a trigger? Nothing.
This talks about why you should use TriggerConditions. Basically, DestroyTrigger() called on a trigger with triggeractions sends the handle stack to hell and back, fucking stuff up massively.

Think of GetDyingUnit() as a wrapper:

JASS:

function GetDyingUnit takes nothing returns nothing
    return GetTriggerUnit()
endfunction

That, and it doesn't work after a TriggerSleepAction() call.

12-02-2008, 11:25 AM

Captain Griffen

Quote:

Originally Posted by Pyrogasm

Trigger Conditions can have the same problem if you run a thread from them.

Conditions are easier to clean though.

You should never destroy a trigger. The only possible expections are a couple of specific unit events to stop leaks, but if you need me to tell you this, you don't know enough, so just leak the events (which in 99% of cases is the most sensible approach).

12-02-2008, 04:11 PM	#8
chobibo	So the problems with Destroying a trigger is related to it's action and/or conditions? If you destroy a trigger which has no conditions nor actions, would it corrupt anything? I know that a trigger without actions or conditions are useless, I'm just curious about the DestroyTrigger bug.

12-02-2008, 04:59 PM	#9
Captain Griffen	If the trigger has never fired anything, then I highly doubt it could bug.