I’m aware that it’s possible to use timers to make timed events in Gdevelop, but an action like “Wait [ ] seconds” could greatly improve the overall Gdevelop experience by making code more simple. I’d also like to see some sort of option to export for steam if that’s at all possible.
Yes, but when I do this it can be complicated with multiple timers running and a wait action would be much easier to manage.
Steam is just a launcher for PC games. Just compile for all the pc Platforms and upload to steam.
AFAIK every engine has to use a scheduling system like GDevelop. This is because a wait event would make the game wait, aka pause the game (event loop) for the time you entered. Sure it is possible to wrap the scheduler in a helper action that does stuff for you, but it is important to know how to use timers too. The may be a bit difficult to get but way more powerful than a wait action. I think such a function would make people lazy and never learn how to use the normal timer options Wich are way better.
I have often thought about this because I also had/have problems with triggers. And I think some laggs come from “wrong” used triggers.
All never created or started triggers are true…
Is it okay to delete no longer needed trigger or just pause it…
What happens to object trigger when the object is deleted…
Yes it is certainly possible to study the wiki, test the behavior and use it, but it is actually really too complicated if you just want execute actions with a little delay. It’s GD’s mission to make things user-friendly, and triggers really are not
(I’m not saying remove triggers and their advanced features)
I loved the Wait X Seconds feature in Construct, it would be a great addition. It works so well to program short sequences where you have to trigger couple of elements on/off like cutscenes and UI. Timers are great tool and learning to use them is a must but they are not the right tool to make a sequence.
Being able to cancel all Wait event would also be really handy to abort all current sequences. For example, when a player dies and you do need to do something else. This is missing from Construct and has been the source of many headaches.
+1
Yeah I feel the same way
Where is the difficulty with timer ?
Wait action is like the action “The timer “wait” is greater than X seconds”
Look how i’ve used timer for my cut scene, isn’t complicated right ?
it is not even necessary to set the timer at the beginning of the scene. GD knows that it is used in events so it will set it to 0 itself.
Wait really? I didn’t knew about that feature
I still understand that an action “Wait X seconds” will be very convenient. It might be something to look into - even if there are caveats and it must be done (and used) carefully.
I’ve made a card for it: Trello
I don’t see the difference
Jup
This also means, if you don’t want all timers to start from the beginning, you have to pause them at the beginning of the scene. (or use an object timer, I think)
And when you delete a timer, it’s true again and triggers old events. (if you don’t save it with a switch variable) Every 12.5 seconds your dialogues start over again, right @Bouh?
When the timer is deleted, this one doesn’t exist anymore, it’s like if the value was set on false.
Indeed, the an timer start when this one is create. If you don’t start the timer at the creation add the pause action.
The timer object are create when the object is create.
To me it looks like it is not possible to delete timers, they are automatically recreated and started.
(The rectangle flashes, it’s not from the gif repeat)
Maybe an object timer is “deleted” the same way when the object is deleted.
This can/will bring unexpected results. That’s why I don’t use an object timer if I’m not 100% sure that I will never delete or add the object.
I’d probably agree with Jack here. We really should have an option on Timer Conditions for “Create if doesn’t exist: yes/no” that shows up in the condition, something like “The timer “testTimer” of NewObject is greater than 1 seconds (Create if needed: No)”.
Otherwise it can lead to unexpected behavior.
I’ve also confirmed that deleting the timer at the start of the scene does not stop the timer from existing.
Here’s the platformer example with some quick code added:
The events below it still occur as if the timer was created after the scene starts.
Even if the above delete not working is a bug, while the engine works to simplify a lot of things for users, I don’t think automating the creation of timers is beneficial for most developers as it will lead to a lot of confusion or make extra work for people wanting to use timers as they’ll need to start tracking other variables rather than just starting a timer when they want it to.
i also noticed this error. I mean deleting a timer does not stop the timer from existing.
however, this is not a big deal, just we need to stop it before deleting.
nope. maybe it should happen, but it doesn’t.