wait until the event(s) had waited and then proceed to the next event
Thanks for reading Have a nice day.
Thanks for reading Have a nice day.
3 Likes
Hello potato-coder.
Thank you for your message!
As mentioned on the message Welcome to the User Feedback channel! each of your bullet points need to be a separate topic so it can be classified and followed (ideally, each feature request have a what, a why, and if possible images and videos).
Most of the features that you have requested already have an existing topic (for exemple, Support for animating sprites on 3D cubes), so please find them and vote for them by liking the original, first message.
You can edit this topic to have one of the features that you are requesting, but for the rest you’ll have to make separated topics.
Thank you for your cooperation!
4 Likes
Thanks, I’ll look forward to it.
Can you give more detail on what you actually want with this one?
What you are describing in your opening post is exactly what conditions do.
1 Like
It will be an action, not a condition
It’s like this scratch cat block where it’ll wait for the player to press space and then wait until it’s not pressed:
it’s like a “Wait X seconds”(action) but it doesn’t linger a specific amount of time instead it waits until the conditions are met
thanks
The problem I have with wait actions is it makes it harder to debug. The wait is less noticable. I also don’t like how waits aren’t visible once set or cancelable. They’re not as transparent. It would be nice to be able to see a wait list but that’s a different matter.
Where would wait actions get checked? Where they’re added? In realtime? Between frames?
I personally am ok with using conditions, timers “has finished” type conditions and such.
Yes, but you haven’t explained why this should be added
What does this get you over just adding a condition? Or adding a subevent with just the condition needed?
Everything in you mentioned in the above post only seems to make your workflow much more complicated, and much harder to debug if something goes wrong.
well normal subevents just trigger when the base event is triggering but this will wait until the conditions are true regardless of the original event
What you’re describing is not how waits work(They still require the previous conditions to have been true at one point) and what you’re describing is still how conditions and subevents work today.
Keep in mind I have no input/decision rights on any of this, but I’m still not seeing anything from your description on how this would have any benefits over a subevent with a new condition, or just a new parent condition, or a subevent with a timer.
1 Like
I don’t understand what you mean…
how can a timer check for conditions? timers are used for waiting for a set amount of time Ex: 10
but the wait until action will wait until the conditions have actually occurred (Ex: PlayerHp=0),
the problem with the subevents is that it will wait until it occurs it just checks it one time (a condition with trigger once for example)
As with all conditions and actions, timer conditions and actions are impacted by whatever other conditions are in the same event.
Event 1:
Conditions blah > all of your other actions, then Start/reset timer “Waituntilblah”
Event 2:
Conditions
Variable A of objectA is = B
Blah is in condition with Blah2
Timer “Waituntilblah” >= 5 seconds
Actions: Your actions here to do whatever you want.
That said, you don’t need a timer for what you’re asking. Again, what you’re describing is literally what conditions are.
“I only want action X to happen after Y occurs” Is
Event:
Condition:
Y has occurred
Action:
Do X.
That is the basis of the event system as it exists today. Moving that to a “wait until condition” action makes no sense to me, doesn’t save any time in your actual event flow, and causes issues from a debugging standpoint (because then you have conditions in your action box, among other things). So I’m still not seeing any use case that this solves.
2 Likes
I’m not sure if I get you, or you’re not getting me,
either way, thanks for your time
That is already possible, use the extension builder to make your own asynchronous event: Asynchronous events - GDevelop documentation
Asynchronous events are special actions that will not execute when called. Instead, they’ll do a bit of work between each frame, and once it is done, will allow the actions and subevents following it to run. Just after being called, the actions and subevents following it will be skipped, as they’ll only run when the asynchronous action has finished its work, and the event sheet will continue executing the rest normally.
I think that’s what I’m looking for, thank you so much