I think it just means that if there are multiple conditions within ONE event then trigger once should be last. In fact, I think there was even something introduced a while back that automatically put the TO at the end when pasted in or moved or something. Not sure what it was as I don’t think it always works.
Yes, that part is pretty common.
Now part of that problem has been fixed…considering the new “just pressed” conditions… and I guess for clicks it’s no longer needed.
But what about the sub-events? Or maybe the main events themselves… does it mean they get executed at the end, or am I interpreting this the wrong way?
EDIT:
Ok, I get what you mean… that in a group of conditions, the “t.o” one is always executed last in the list.If that’s the meaning, then I can relax.
I don’t think it’s a problem or a bug… because sometimes you want something like a keypress, with a Trigger Once right under it, and then maybe an `animation frame > 1 as the next condition where you don’t want Trigger Once. At least for me, ever since I’ve been using GD, it has always worked this way…
but ofc what described in the TO feels strange.
Each event is evaluated in order. With the trigger once event only being triggered once. The last event isn’t a subevent of the trigger once, so it gets processed.
The first event will rotate NewSprite1 once everytime the mouse is down and the cursor is on the object. But, because the trigger once is last, you can hold the mouse and swipe back and forth over the object and it will spin a little each time. All of the conditions are factored into the trigger state. So, moving the cursor back and forth causes the cursor is on object condition state to repeatedly changes between true to false which resets or removes and adds a trigger once state.
The 2nd event does the same but bc the trigger once condition only monitors the mouse is down condition when you press and hold the mouse, it will only rotate NewSprite2 once. Plus, because the mouse is checked first, it will only rotate if the cursor is over the object when the mouse is pressed. It only gets one chance per press. So, nothing else will be process after the first time.
The last event is the same as the 2nd event. It’s my preferred way. It’s more structured. Easier for me to understand.
Yeah, it’s like I replied to Snowy above… I think.
So why does the description say “the condition is executed last in the list”? **I guess in the end it was just an interpretation of a very specific situation, without taking all the other cases into account.
Well actually it says ‘This condition is always last in the list’. And for years I believed that because that’s what it said. So maybe it could be worded better.
That definitely seems contrary to the description, which seems to say that Trigger Once will always be evaluated last for the condition block it is in.
Have you tested this recently? I wonder if the evaluation order was changed and they just forgot to update the description?
The description is confusing. Since, it’s neither always last or evaluated last. The app does try to keep it last. If you already have a trigger once and click the add a condition text, it will add the new condition before the trigger once.
Maybe, in the past things worked differently. Or maybe, they believe that it’s easier to understand the logic when the trigger once is last.
There’s nothing to prevent you from using multiple trigger once conditions in the same event but that would be extremely confusing looking. I think they prefer breaking the logic into subevents.
The trigger once conditions would all be evaluated the first time but on the following frames only the first trigger once would be evaluated.
Think of it like having a hallway full of doors and locking each door behind you. The first time, you could walk through the entire hallway. The next person would be stopped by the 1st door.
You could put a condition in between each trigger once. That would be confusing and probably unnecessary since the first trigger once would control the process. Resetting the first would reset them all.
Mh… how I had understood this was, that the trigger once state will always be checked last in terms of order of operation. So it is useful to know, that using this will not make your events more performant, since all previous conditions will be checked, before the trigger-once-state is checked.
I don‘t believe, that it will be checked after following conditions, because those are not relevant to the „trigger once“.
I also don’t think that it (the statement we are talking about) has any implications on where to put it. You need to always put it below all events that you want to apply it to. The conditions, which are not trigger once dependend, need to go below this condition.
I actually don’t use this condition anymore. It seems to always be better to use your own states.
