Ok, here’s the issue. Normally when you have the “Trigger Once” condition. It’s suppose to do what it says on the tin. And most of the time it does. HOWEVER. There is one edge case that I have found where it leads to it triggering multiple times despite it’s function. What it is is when you have dynamic variables, the function will trigger once as you asked it. But the second the condition changes, the “Trigger Once” function releases. And if the variable changes back quick enough, it can trigger it again which can lead to some undesired behavior. Not a typical bug, but certainly an issue.
Now that being said, there is an easy fix to this. All that is needed, is to add a “Delay” to when the “Trigger Once” condition is allowed to be released, which would solve the rapid re-trigger issue this flaw is causing. Granted someone could add a separate timer in the logic to fix this issue, but this won’t scale well when you have lots of dynamic variables to deal with. Especially when some logic needs different delays than others.
This is the basic setup. But like I said. the issue is when variables need to change quickly for certain gameplay related features. the “Trigger Once” condition doesn’t work very well. The exact structure doesn’t matter as much as when variables of any kind change rapidly
Does the trigger once work as designed? It sounds like it’s working. Do you want it to have a timer or cooldown period?
There are 3 conditions. The trigger once is tied to the final state. All 3 conditions decide the fate of the trigger once. Is the animation being changed?
As I said, It works as advertised. But the issue is how it’s programmed. when you need a variable to change quickly for gameplay purposes. This breaks the feature by repeatedly re-triggering the condition. And yes a delay we can set is all it really needs to prevent this from happening. Which I don’t imagine to be too hard to implement.
The problem has nothing to do with order of events. Rather what happens when ANY variable in the condition branch changes. Which causes the “Trigger Once” condition to release immediately. So when the variable changes again to make all the conditions true. It allows the event to re-trigger, which depending on how fast this happens, might cause unintended behavior. As I said, it’s not a “Bug” in the sense that it was incorrectly programmed, but an oversight on how it functions.
What you are describing is exactly how trigger once is supposed to work, and is part of the design how it functions.
The trigger once captures the current condition state and only counts them as true once, by confirming if they were previously met on a prior frame and not allowing the actions to trigger again. If your conditions change in any form (including variable conditions changing) it is explicitly intended to allow for retriggering since those conditions were no longer previously met. Otherwise there would be no way to allow for it to trigger again.
There is no flaw in the design, at least not how you are describing it above.
If you are changing variables around rapidly, you don’t need trigger once, you need some form of boolean state variable that you can set back manually whenever you want it to be triggerable again. Edit: You could even set up your own function for it in an extension if you really need it as a single condition. But I don’t see it likely for any of the devs to modify the trigger once beyond its designed function as it is today.
What exactly do you mean by “variables need to change quickly”? What do you mean by quickly? A couple of times per game frame? Every game frame? Either case, GDevelop handles it. I suspect it’s more likely the issue is with your events or game logic.
That only works when the project is simple. When you have dozens of variables that operate very different parts of your game, this can blow the complexity of the game up VERY fast. Something I mentioned in the OP
There’s nothing wrong with asking. IMO, it just sounds more like a feature request than a bug reoort. Either way. Feel free to ask whatever you want to.
That’s not going to get you an answer. We’re just trying to point out your reasoning and assumptions may not be correct.
WRT the screen shot you provided, can you also include screen shots for ALL the events that modify Varable_1, and the events that allow those actions to occur?
Nowhere i mentioned ANTYHING about order of events
But only about value of your variable
In short of it
If you have condition
Space key pressed
Trigger once
Action
Play sound
Then you will hear only sound ONCE when you press space
And if you release space you won’t hear it again
BUT if you press space again then you gonna hear sound again
CAUSE your condition became true 1st so it executed action once
If it would stay true or false by that point it would not kick in again
BUT since it went by true > false > true AGAIN
That false state allowed it to trigger when it become true again
Same with variables if your variables become anything else than what you check in condition then back what you are checking in condition then it will kick in actios
That is why i told you to show how you are changing your variables
From my personal experience, I don’t think the issue is with your Trigger Once condition, even though it really looks like that’s the culprit when you first look at it.
I believe the problem is actually with the Lifebar extension, which runs after the events and isn’t triggered just once. I’m saying this because I ran into a very similar issue myself, and that’s how I ended up fixing it.
As the others mentioned above, Trigger Once does exactly what it’s supposed to do, but the extension doesn’t follow its rule.(bcs lifebar have sort of previous value conservation for smooth transitions). That’s why it looks like it doesn’t have enough “time” to work properly.
