1. Updated Resource Submission Rules: All model & skin resource submissions must now include an in-game screenshot. This is to help speed up the moderation process and to show how the model and/or texture looks like from the in-game camera.
    Dismiss Notice
  2. DID YOU KNOW - That you can unlock new rank icons by posting on the forums or winning contests? Click here to customize your rank or read our User Rank Policy to see a list of ranks that you can unlock. Have you won a contest and still haven't received your rank award? Then please contact the administration.
    Dismiss Notice
  3. Lead your forces to battle in the 15th Techtree Contest. The call is yours, commander!
    Dismiss Notice
  4. The reforging of the races is complete. Come see the 14th Techtree Contest Results.
    Dismiss Notice
  5. It's time to choose your horse in the race - the 32nd Modeling Contest Poll is up!
    Dismiss Notice
  6. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

Trigger Evaluation Behaviour Changed in Recent Patches

Discussion in 'The Lab' started by AGD, Apr 26, 2020.

  1. AGD

    AGD

    Joined:
    Mar 29, 2016
    Messages:
    457
    Resources:
    13
    Spells:
    7
    Tutorials:
    1
    JASS:
    5
    Resources:
    13
    I just wanna share this. It was known in the past that removing the currently evaluated triggercondition using
    TriggerRemoveCondition()
    /
    TriggerClearConditions()
    /
    DestroyTrigger()
    will prevent the next triggerconditions in the trigger from being evaluated.
    This means
    Code (vJASS):
        globals
            trigger array trig
            triggercondition array tc
        endglobals

        function A takes nothing returns nothing
            call BJDebugMsg("A")
        endfunction
        function B takes nothing returns nothing
            call BJDebugMsg("B")
            call TriggerRemoveCondition(trig[0], tc[2])
        endfunction
        function C takes nothing returns nothing
            call BJDebugMsg("C")
        endfunction
        function D takes nothing returns nothing
            call BJDebugMsg("D")
        endfunction

        function OnInit takes nothing returns nothing
            set trig[0] = CreateTrigger()
            set tc[1] = TriggerAddCondition(trig[0], Filter(function A))
            set tc[2] = TriggerAddCondition(trig[0], Filter(function B))
            set tc[3] = TriggerAddCondition(trig[0], Filter(function C))
            set tc[4] = TriggerAddCondition(trig[0], Filter(function D))

            call TriggerEvaluate(trig[0])
            /*Displays:
            A
            B
            */

        endfunction

    This is also true for patch 1.27.x

    But in patches past 1.30.4 (I actually only tested patches 1.30.4 and 1.31. Haven't also tested patches in between 1.27 and 1.30.4 so don't exactly know when the change happened), you can safety remove the currently evaluated triggercondition without stopping the next triggerconditions in the list. The same code above would display
    Code (vJASS):
    A
    B
    C
    D


    More Info

    It seems that in older patches, calling TriggerRemoveCondition() removes the links (A post by Nestharus says that TCs are structures as a linked-list, or that's how they behave atleast) of that TC immediately. While in the recent patches, calling TriggerRemoveCondition() inside an evaluated trigger removes the links of that TC after all TCs are the current TC is done being evaluated.

    Test Code
    Code (vJASS):
        globals
            trigger array trig
            triggercondition array tc
        endglobals

        function A takes nothing returns nothing
            call BJDebugMsg("A")
        endfunction
        function B takes nothing returns nothing
            call BJDebugMsg("B")
            call TriggerRemoveCondition(trig[0], tc[3]) // We remove the next TC
        endfunction
        function C takes nothing returns nothing
            call BJDebugMsg("C")
        endfunction
        function D takes nothing returns nothing
            call BJDebugMsg("D")
        endfunction

        function OnInit takes nothing returns nothing
            set trig[0] = CreateTrigger()
            set tc[1] = TriggerAddCondition(trig[0], Filter(function A))
            set tc[2] = TriggerAddCondition(trig[0], Filter(function B))
            set tc[3] = TriggerAddCondition(trig[0], Filter(function C))
            set tc[4] = TriggerAddCondition(trig[0], Filter(function D))

            call TriggerEvaluate(trig[0])
        endfunction

    In older patches, it displays
    Code (vJASS):
    A
    B
    D
     

    while in the recent ones
    Code (vJASS):
    A
    B
     

     
    Last edited: Apr 28, 2020
  2. IcemanBo

    IcemanBo

    Joined:
    Sep 6, 2013
    Messages:
    6,382
    Resources:
    22
    Maps:
    3
    Spells:
    11
    Template:
    1
    Tutorials:
    4
    JASS:
    3
    Resources:
    22
    Thanks for sharing! I tested it on patch 1.32.3.
    • Removing the currently evaluated condition still correctly evaluated the rest, like in your test.
    • Removing the next evaluated condition caused a Warcraft crash. Tested several times.
     
  3. AGD

    AGD

    Joined:
    Mar 29, 2016
    Messages:
    457
    Resources:
    13
    Spells:
    7
    Tutorials:
    1
    JASS:
    5
    Resources:
    13
    Thanks also for this test btw, IcemanBo, as I don't have Reforged myself. Does this mean calling
    TriggerClearConditions(GetTriggeringTrigger())
    crashes in reforged? It seems my system that has something like this causes problem for someone using it in reforged.
    I'm wondering if there are other ways for example to stop the execution of triggerconditions in a trigger midway in reforged. For example a trigger has 5 triggerconditions and I only want the trigger to execute until the 3rd triggercondition.
     
  4. IcemanBo

    IcemanBo

    Joined:
    Sep 6, 2013
    Messages:
    6,382
    Resources:
    22
    Maps:
    3
    Spells:
    11
    Template:
    1
    Tutorials:
    4
    JASS:
    3
    Resources:
    22
    Yes, correct. Calling
    TriggerClearConditions(GetTriggeringTrigger())
    does crash warcraft, when called from a middle-running condition. ( patch 1.32.5 meanwhile )

    It's definitely a bug from blizzard. Honestly, idk a good work around or hack for this. Maybe using single triggers... . Or have you tried looking on something like this from Nestharus Trigger v1.1.0.2 (it's huge, maybe there's a smaller alternative... but haven't found one atm)
     
  5. AGD

    AGD

    Joined:
    Mar 29, 2016
    Messages:
    457
    Resources:
    13
    Spells:
    7
    Tutorials:
    1
    JASS:
    5
    Resources:
    13
    Nes' Trigger doesn't have such option sadly. I think my only option left is to use multiple triggers.. or maybe to drop compatibility for reforged. It's difficult enough to debug something I can't personally test anyway xD.
     
  6. IcemanBo

    IcemanBo

    Joined:
    Sep 6, 2013
    Messages:
    6,382
    Resources:
    22
    Maps:
    3
    Spells:
    11
    Template:
    1
    Tutorials:
    4
    JASS:
    3
    Resources:
    22
    Nes explains a TriggerCondition in his code (jass native type is "triggercondition") is allowed to be removed at any point. Or maybe I mix something up?

    In cases, I could test out a code for you in reforged (discord IcemanBo#5874). I hope it gets fixed, it's really game-breaking actually. Good point, I saw your announce in the patch thread. :peasant-thumbs-up:
     
  7. AGD

    AGD

    Joined:
    Mar 29, 2016
    Messages:
    457
    Resources:
    13
    Spells:
    7
    Tutorials:
    1
    JASS:
    5
    Resources:
    13
    Yeah, but Nes' Triggers can only contain 1 TriggerCondition, which contains multiple boolexprs. So it doesn't allow stopping on a certain registered code. It runs all codes, which is actually one of the goals of Trigger - to allow removing the current code without breaking the traversal of the remaining codes. The removal only affects the next time the Trigger runs.

    I'll just pm you here instead if I'll ask some favor =).
     
  8. IcemanBo

    IcemanBo

    Joined:
    Sep 6, 2013
    Messages:
    6,382
    Resources:
    22
    Maps:
    3
    Spells:
    11
    Template:
    1
    Tutorials:
    4
    JASS:
    3
    Resources:
    22
    Idk if it makes sense to create a nasty workaround for a newly intruduced bug...
    Do you already have an idea how to approach it?
     
  9. AGD

    AGD

    Joined:
    Mar 29, 2016
    Messages:
    457
    Resources:
    13
    Spells:
    7
    Tutorials:
    1
    JASS:
    5
    Resources:
    13
    Yeah, using two triggers. But I didn't implement it as the code will be may more convoluted, and just dropped compatibility for reforged for such feature. I guess I'll just wait for bug fix (if ever).
     
  10. IcemanBo

    IcemanBo

    Joined:
    Sep 6, 2013
    Messages:
    6,382
    Resources:
    22
    Maps:
    3
    Spells:
    11
    Template:
    1
    Tutorials:
    4
    JASS:
    3
    Resources:
    22
    But two triggers could handle multiple revoments?
     
  11. AGD

    AGD

    Joined:
    Mar 29, 2016
    Messages:
    457
    Resources:
    13
    Spells:
    7
    Tutorials:
    1
    JASS:
    5
    Resources:
    13
    In my particular case, there is only one triggercondition (statically determined) wherein an evaluation break can happen, so two triggers as an alternative should suffice. Actually the purpose of the break is just to simulate something like
    Code (vJASS):
    call TriggerEvaluate(genericTrigger)
    if not this.blockEvent then
        call TriggerEvaluate(this.specificTrigger)
    endif

    As you can see, separating into two triggers is the reasonable choice here but because I insisted on having only 1 trigger evaluation that's why I forced myself into this complication :D.
     
  12. IcemanBo

    IcemanBo

    Joined:
    Sep 6, 2013
    Messages:
    6,382
    Resources:
    22
    Maps:
    3
    Spells:
    11
    Template:
    1
    Tutorials:
    4
    JASS:
    3
    Resources:
    22
    Hm, I don't really understand. But doesn't matter here. : ) Thanks anways.
     
  13. Macadamia

    Macadamia

    Joined:
    Jan 30, 2020
    Messages:
    686
    Resources:
    0
    Resources:
    0
    Wait guys. Reading a lot about TriggerConditions since my return in December, I came to believe, according to what was said, that you didn't need to remove conditions from triggers before destroying them !?

    ConditionalTriggerExecute vs TriggerEvaluate

    Would that have changed in the meantime ?
     
  14. IcemanBo

    IcemanBo

    Joined:
    Sep 6, 2013
    Messages:
    6,382
    Resources:
    22
    Maps:
    3
    Spells:
    11
    Template:
    1
    Tutorials:
    4
    JASS:
    3
    Resources:
    22
    AGD uses it for a system, where users can register code to run on certain events. Only one trigger is used, which is never destroyed. Only code or boolexpr gets registered/unregistered, that's why TriggerRemoveCondition is used.

    Btw, I tested with TriggerRemoveAction, and it doesn't crash. But the removed action would still run, if it's removed from a prior trigger action.
     
  15. Macadamia

    Macadamia

    Joined:
    Jan 30, 2020
    Messages:
    686
    Resources:
    0
    Resources:
    0
    Oh ok It makes sense then.

    Well I moved all my actions in my conditions a while back now so I never had any issue with destroying triggers, even when I was still using Jass ^^