[JASS] "Simon Says" Issue Order, Infinite Loop

[Titanhex]

Alright, this is my code. Basically what the "Master" unit does the "Slave" unit should do the same order. Unfortunately it infinite loops (without crash) and I'm not sure why.

globals
    trigger array SimonPoint
    trigger array SimonImmediate
    trigger array SimonTarget
endglobals

function Trig_SimonPoint_Actions takes nothing returns nothing
    if GetTriggerUnit() == Master[GetUnitId(GetTriggerUnit())] then
        call IssuePointOrderById( Slave[GetUnitId(GetTriggerUnit())], GetIssuedOrderId(), GetOrderPointX(), GetOrderPointY() )
    endif
endfunction

function Trig_SimonImmediate_Actions takes nothing returns nothing
    if GetTriggerUnit() == Master[GetUnitId(GetTriggerUnit())] then
        call IssueImmediateOrderById( Slave[GetUnitId(GetTriggerUnit())], GetIssuedOrderId() )
    endif
endfunction

function Trig_SimonTarget_Actions takes nothing returns nothing
    if GetTriggerUnit() == Master[GetUnitId(GetTriggerUnit())] then
        call IssueTargetOrderById( Slave[GetUnitId(GetTriggerUnit())], GetIssuedOrderId(), GetOrderTarget() )
    endif
endfunction

//===========================================================================
function InitTrig_SimonSays takes nothing returns nothing
 local integer i = 0
    loop
     exitwhen i > 9
     set SimonPoint[i] = CreateTrigger(  )
        call TriggerRegisterPlayerUnitEvent( SimonPoint[i], Player(i), EVENT_PLAYER_UNIT_ISSUED_POINT_ORDER, null)
        call TriggerAddAction( SimonPoint[i], function Trig_SimonPoint_Actions )
     set SimonImmediate[i] = CreateTrigger(  )
        call TriggerRegisterPlayerUnitEvent( SimonImmediate[i], Player(i), EVENT_PLAYER_UNIT_ISSUED_ORDER, null)
        call TriggerAddAction( SimonImmediate[i], function Trig_SimonImmediate_Actions )
     set SimonTarget[i] = CreateTrigger(  )
        call TriggerRegisterPlayerUnitEvent( SimonTarget[i], Player(i), EVENT_PLAYER_UNIT_ISSUED_TARGET_ORDER, null)
        call TriggerAddAction( SimonTarget[i], function Trig_SimonTarget_Actions )
    endloop
endfunction

 

[Cokemonkey11]

How do you know it infinite loops? Did you put a debug message within the "if then" block of each action function?

 

[Titanhex]

Well, "infinite" may not be accurate. It actually creates a lot of looping, enough to slow down the game until it completes, if not freeze it completely.

I'd like to know how to make it so this action doesn't repeat. So far, inside the trigger, I've tried disabling and enabling it and creating a local integer that increases when the trigger is executed. Neither work.

 

[Troll-Brain]

You've forgotten to increase "i" inside your init loop, so you have many triggers related the the Player(0).
It's probably something like several thousands triggers, indeed since the exitwhen is never true the loop still fire until the limit op is reached.
That totally explains the freez when the events occur.

Also it would be still better to disable the trigger, issue the order, enable the trigger, just because a trigger evaluation is heavier than this process.

 

[Titanhex]

Thanks. That makes sense.

I don't understand the disabling the trigger, issuing the order, and enabling it again though. Except to prevent a chance of endlessly looping events.

 

[Troll-Brain]

Then the trigger will not be evaluated when you issue the order for the slave unit.
A trigger evaluation is heavier than these simple 2 lines of code to disable and enable the trigger.

 

[Cokemonkey11]

He's saying that if you don't call the "disable trigger" before this line runs:

        call IssueTargetOrderById( Slave[GetUnitId(GetTriggerUnit())], GetIssuedOrderId(), GetOrderTarget() )

Then that same line will trigger the event in the parent:

EVENT_PLAYER_UNIT_ISSUED_POINT_ORDER

Which will then run the conditions in the action functions:

if GetTriggerUnit() == Master[GetUnitId(GetTriggerUnit())] then

So what Troll-Brain is saying is that, the processing time it takes to call disable trigger, and then later enable trigger, is less than the processing time it would take to run through that condition.

 

[Troll-Brain]

Ofc, it's not going to does matter in real cases, but it's a good practice anyway (to avoid trigger event recursion)

 

[PurplePoot]

You guys are way too obsessed with efficiency. Optimization is great when it's easy and/or necessary, but in cases like this it's just annoying and frivolous.

 

[Troll-Brain]

actually you are the one which is obseded by that
that is not like i have not gave a valid reason to do it beyond efficiency