Using an Object Variable in combination with “Repeat for each object” has a weird effect…
The events now multiply all action relating to that specific object referenced in the variable for every object that your repeating for.
Not the entire event, or better the actions, it picks only the action referencing that object, all the other action get the regular “Repeat for each object” interaction…
I made a short video showing what happens and explaining, its just odd.
So bug? or just really weird?
A few things. It’s easier to read screenshots instead of video. Just a tip.
It looks like it’s trying to set an object variable before the object is created. This will pick any existing objects. (I’ve had discussions about this) So, when you add an object, all of the objects are picked and any action is applied to all of the objects.
It wouldn’t matter with some actions but others like linking can only work on 1 instance at a time and will pick the earliest object instead of the just created object. This can throw everything off.
In your case IDKW, you’re setting a variable first. You can move it after the add object or add event above the current event and move it to that event. That way they wouldn’t share the same pick list. To be clear, separate even events not sub events.
You can verify it by adding a debug statement to display the number of picked instances. The number should grow with the boolean but remain at 1 without it.
1 Like
Just to mention here: trigger once is designed for “once per event block”, so using it in a for each event is not going to behave how you expect. You would likely need to replace that qith a boolean object variable that you toggle in your actions if you only want it to occur once per each instance.
1 Like
Ohhhh!!! Good catch mate!!!
I used the object variable to replace a “Play a sound”, the play a sound order didnt matter so when i replaced it, i completely forgot to check if i had already created the Lavaball before giving it a variable!
That makes perfect sense now! Facepalm
Thanks! Ill go switch it around and confirm that it works
1 Like
No, the trigger once was working as intended and doing the job, i just didnt explain myself right, what i ment was how it was multiplying the result.
But its cool, Keith cought the reason why… i completely forgot about the order of actions because i replacing something that didnt matter where it was.
Sorry for the confusion. I wasn’t saying that was the source of your current problem, I’m saying that using it that way may cause you other problems down the road.
Basically, only the first instance in the ‘for each’ will trigger once, all others will happen every frame, unless you alwaye only have one instance evaluating at any one time. It’s mentioned in the documentation here: Advanced conditions - GDevelop documentation
1 Like
Just tested it… and yup you were right, good eye mate!
Swapped the object variable in and everything works normally.
I feel so annoyed missing something like the order of actions… its bringing back PTSD of inversions when working with accounting and payrolls haha
The interaction was so odd i didnt even think of checking, usually when you set a variable before creating the object, as far as i recall, it does nothing because you havent created the object yet, so i didnt even consider it, honestly the first time i saw the weird interaction i just laughed couse it looked so silly and all i had done was change a sound file
1 Like
Ahh, well then matey, the documentation is wrong.
Its working as intended, all instances only trigger the event once.
In fact thats the reason why i was modifying the event in the first place.
Further proof of that, is the fact that the permanent forces are only being applied once, if it was triggering every frame they would shoot off a million miles a second.
The way i have it set up, whats happening is, at a specific frame, all the spawners are being triggered with repeat for each object, each object or spawner creates a “Lavaball” and applies the VFXs and Forces, each are treated as individuals and each trigger their own “Trigger Once”.
Iv been using it this way for a while in most things and it works just fine, maybe the documentation is referencing some other interaction?
Oh! I think because the event trigger is just “one specific action”.
Its the boss hitting the floor, or the “specific” frame thats the trigger and thats the thing thats being gated by “Trigger Once”.
It then Repeats for every spawner the creation of the Lavaball, but the spawners themselfs arent being affected by the “Trigger Once”, only the “Frame” condition.
1 Like
I gave up trying to understand trigger once inside loops. They don’t work as expected. It’s best to avoid them. As stated, if needed use an object variable. Same thing with wait inside or outside of a loop. I try to avoid it.
Most people want the loop to only trigger once. In that case, they should put the trigger outside of the loop.
2 Likes
Yeah. That condition is basically acting as your real “trigger once” so that makes sense on why you’re not seeing any oddities (which means you could likely remove the trigger once without any issues)
1 Like
Usually your on the money mate, but not this time.
The frame is the trigger, if i remove the “Trigger Once” while on that specific frame, then for as long as that frame is happening the actions would trigger non stop.
I could make a variable to stop it, but “Trigger Once” is doing the job.
“Trigger Once” is pretty useful for quick programming once you get the hang of it.
I’m not sure what you are pointing out in your above post.
Short answer: events only apply once per frame (including once per instance per frame with a for each), so you might be misinterpreting what you are experiencing
Way more detail answer:
To clarify every event occurs only once per rendered frame, with only the following exceptions:
- for each events - occure once per instance per frame,
- "for each child"events -only occure once per child variable of a structure variable per frame
- repeat block events - happen X times per frame, where X is the set repeat number
- “while” block events - repeats the event actions and stop frames from continuing/proceeding to the next frame until the whole conditions are no longer true
So the event sheet only proccesses your event conditions and actions once per frame outside of the above exceptions, and the for each event block only proccesses your conditions and actions once per instance per frame as mentioned above.
Trigger once only applies once per event block, so on a for each event, usually on the first instance where the condition is true. If you have something that is immediately making the conditions false (a scene boolean variable, a required object being deleted, etc) it would not apply to other instances.
This behavior is called out in the documentation because of the confusion it can cause, to the point where entire PRs were made to add a “trigger once per instance” condition. It didn’t get added because the devs preferred people use blocking conditions such as boolean variables instead. (You can read the entire exchange and details here, if you prefer: Add trigger once per instance by arthuro555 · Pull Request #5435 · 4ian/GDevelop · GitHub)
You said i could remove the “Trigger once” and probably be ok.
I answered, that your usually right about these things, but not about this one, the “Trigger once” is the condition keeping my actions from happening non stop.
When i mentioned “frame”, i ment from the object, as in the condition that was triggering the event
I didnt mean anything by it.
And what im experiencing isnt any of that… The short is…
- I have an event that tells spawners to spawn stuff
- I added Repeat for each “Spawner”
- …and its doing just that, its treating each spawner like its own thing and giving it its own set of actions, its all working proper
If thats not how its supose to work… well then i have no idea, but as far as i can tell, the logic behind it makes perfect sense.
The only weird thing was what happened when i told it to make a variable for an object that didnt exist, that was unexpected, everything else tho makes sense.
Yep, I totally wasn’t getting what you meant by frame, thought you meant rendered frame (as in fps) not animation frame, apologies.
If it’s working in your current state that’s totally fine, but if you do experience issues I would strongly recommend swapping from a trigger once to a boopean variable, as you will likely experience oddities for the reasons I mentioned above.
I get you, for the most part i use variables to gate my actions, its much nicer to have full control of whats happening.
But i still think trigger once is fine for stuff like this, but if it start causing issues ill change.
The whole thing with Trigger Once, is using it for a single event, or a “Master” event that triggers other stuff, like whats happening here with my Boss Character.
Hes the main thing triggering everything, while hes hitting the floor, trigger once happens and keeps things from repeating, the moment he switches frames, the even can be triggered again.
But yeah… im an ambassador of using “states” over “trigger once”