Scene Timers: No longer automatically initialized since 5.0.126

[AtomicCrocStudios]

Describe the bug

I was working on a project today and noticed the new timers were not firing for me. Thinking I may have somehow screwed up something simple I tried creating a test project to just update a text object with the current timestamp every second, once again it didn't work.

After looking at the RAW mode of the scene debugged, I could see that the timer wasn't even being initialized.

I tried initializing the timer manually at the start of the scene and it worked.

I am hoping this is not the intended behaviour of this update as I believe it has the ability to break existing projects once they're updated to the latest version with users assuming that timers still automatically initialize.

I understand it's bad practice to not manually initialize them, however it always felt unnecessary to run an action that was already handled by the engine on startup.

Happy to hear any feedback and thanks for expanding upon the functionality D8H :)

[4ian]

Timer are indeed not initialised automatically anymore, you need to call the "reset the timer" whenever you want to start it.

But this should not break any project because the old condition is still working as before.
This being said, should we add a parameter to "start the timer if it was not started" or should be just adapt the documentation and our habits to start a timer explicitly? In theory, being explicit is better than implicit here.

cc @D8H :)

[AtomicCrocStudios]

Timer are indeed not initialised automatically anymore, you need to call the "reset the timer" whenever you want to start it.

But this should not break any project because the old condition is still working as before. This being said, should we add a parameter to "start the timer if it was not started" or should be just adapt the documentation and our habits to start a timer explicitly? In theory, being explicit is better than implicit here.

cc @D8H :)

Thanks for the reply 4ian. I think having people manually create the timers is perfectly fine and gives more control to the user in the long run (they may not want to initialize at the beginning of the scene).

Rather then adding the new option, maybe just some info text on the condition?

[Silver-Streak]

I still think a parameter on timer conditions (or actions) could be very useful, have it default to "initialize at start of scene: yes" for backwards compatibility, and then users still have the option to not do so if they don't want to.

[Bouh]

I still think a parameter on timer conditions (or actions) could be very useful, have it default to "initialize at start of scene: yes" for backwards compatibility, and then users still have the option to not do so if they don't want to.

I did not see that change in the changelog, maybe it deserves a warning for the ancient users?
I agree it could be more friendly to have a boolean button on the timer condition/action to "initialize at start of scene: yes/no"

[4ian]

Agree, I will make a warning on the changelog (my bad, this change was added just before the release and I did not think enough it could be confusing).

I'll also add a warning on the conditions:

I agree it could be more friendly to have a boolean button on the timer condition/action to "initialize at start of scene: yes/no"

Well that was the problem of the previous version: it did not initialize the timer at the start of the scene. Instead, it started the timer the first time a condition referring to the timer was executed. So this created confusion (everyone thinks the timer was started at the start of the scene, but no, it was just when the condition was executed).
This being said, we could do again this behavior with a toggle "Automatically start the timer if was never started", so that we would both have the previous behavior (not sure if it should be the default or not), and the new operators.

[Bouh]

"Automatically start the timer if was never started"

It's more confusing. Since we don't know when it starts, you said it yourself before it was on execution (I didn't know that before you said it here). And now it's not even automatic anymore, we have to set the action ourselves to start a timer.

Or I didn't understand anything and in this case, it's more worrying :')

What should be explained is in the boolean field in the description is:
"True = Automatically started the timer when the scene start / False = The timer start when the condition is checked"
And False is set by default to keep the compatibility like before ever.

With this boolean, we don't need to add an action manually at the beginning of the scene to start a timer, which is very wordy.
It's for me a bad and terrible choice made here to force the user to make it manually, and it could broke all the older projects.

[D8H]

This being said, we could do again this behavior with a toggle "Automatically start the timer if was never started", so that we would both have the previous behavior (not sure if it should be the default or not), and the new operators.

I'm utterly against it.

• In every language I know, a condition with a side effect is an anti-pattern.
• With the <= operator, starting the timer means that if the condition is checked again right below it will be true. <= is useful to check if something happens in less than N seconds, so it makes no senses to start it in this configuration.
• Why kill the cat?

[Silver-Streak]

This being said, we could do again this behavior with a toggle "Automatically start the timer if was never started", so that we would both have the previous behavior (not sure if it should be the default or not), and the new operators.

I'm utterly against it.

• In every language I know, a condition with a side effect is an anti-pattern.
• With the <= operator, starting the timer means that if the condition is checked again right below it will be true. <= is useful to check if something happens in less than N seconds, so it makes no senses to start it in this configuration.
• Why kill the cat?

@D8H Did you mean to reply to a different part of the text? Your bullets don't seem to match up to the text you're replying to, or I can't quite parse it within the context.

[4ian]

No I think D8H answer is right. Just to make things clear:

1. This is not breaking older games.
   This is a new condition, and the old one still works but is hidden.

2. The old condition was confusing. Timers were started when the first condition referring to them was executed (and NOT at the beginning of the scene).

3. This being said, with this condition, we now have to always use the action to start a timer. It's not the end of the world. BUT it can take time for people to adapt to this. So the question is :

• Is this ok?
• If not, do we want to:
  • Reproduce the old behavior (D8H is against this).
  • Do something were we analyze the timers used and start them at the beginning of the scene (but it's unlikely we can do that, because timers name are expressions and can be anything).

[Silver-Streak]

Thanks for the clarification!

• Is this ok?

It could be, but we have seen a decent amount of feedback from users who are very confused as this wasn't listed in any release notes they (or I) can find.

• If not, do we want to:

  • Reproduce the old behavior (D8H is against this).
  • Do something were we analyze the timers used and start them at the beginning of the scene (but it's unlikely we can do that, because timers name are expressions and can be anything).

I still think a toggle is probably the right way for compatibility and user flexibility going forward, explicitly because it can help users reduce the amount of extra events in their event sheet to reproduce behavior they are used to for years now.

[ClementPasteau]

I've updated the release notes to highlight the change of behavior for the Timers. I agree that we should have planned this better!

[D8H]

Let's think of this with game theory:

New condition

Case A: users are used to the old way

• users don't see the warning
• their game doesn't work
• they come back to the action editor see the warning
• add the start action

Dangerousness: 1/4 hour loss
Risk: 75% at release and probably 25% on newcomers

Case B: user have to add a start timer action to start a timer

• users start all the timers they need at the start of the scene

Dangerousness: 1 minute loss
Risk: 100%

Old condition (or switch)

Case C: users hut a bug caused by a timer starting at the condition check

• users check the timer in a sub condition
• the timer condition is started very far in the game
• after investigations, users realize that the timer has a value lower than expected
• users don't understand why, they ask for help
• someone with a good knowledge of the engine answer them
• they add a start action at the beginning of the scene

Dangerousness: 1 day + support time + might discourage users + games released with bugs
Risk: 10% (those 10% are likely to be working on a big games that make GDevelop shines which make the dangerousness even more dangerous)

[Bouh]

It's certainly easier to add a warning message to tell the user to add a timer himself but it's an avoidable warning...

By adding a boolean on the new condition (enable automatically the timer or not at the beginning of the scene) we let him know that something has changed because he has never seen the new button True/False on a timer in the past, this way the new condition becomes easier to use and to understand.

I can't imagine saying to people with lot of timers in their games, now you've to add a new action for all your timers.
I agree it give more controls but for the user who use this new timers it's a new thing to do more.
And to finish, the toggle would give more freedom, is I enable the timers by myself where I want in the eventsheet, or the engine do it for me at the beginning.

[D8H]

It's certainly easier to add a warning message to tell the user to add a timer himself but it's an avoidable warning...

By adding a boolean on the new condition (enable automatically the timer or not at the beginning of the scene) we let him know that something has changed because he has never seen the new button True/False on a timer in the past, this way the new condition becomes easier to use and to understand.

By adding a boolean on the new condition, we let users doing something they don't understand and will backfire at them later just to save few clicks and we allow some configuration that can't work < and Yes.
Last week, I wouldn't be able to help a user with a timer that doesn't start at the beginning because I didn't know this could happen and I've being using GDevelop for 1 year.
Why bother trying to explain something very complicated and error prone when we can just let users create an action when they want things to be done. I mean this is the core concept of GDevelop.

It seems this is short term vs long term.
This is a new condition, let's make it right, clean slate.

Users have bad habits, habits can change and imho for the best.