Love this functionality! But the UX of this needs work – because if the user wants to slow down a lot to see a specific thing in slow motion and then resume normally, it needs a LOT of clicks with this interface.

Perhaps a dropdown (probably), a small slider, or a small field where one can enter a percentage.

Perhaps a dropdown (probably)

Cool! Without the << and >> buttons, I think the UX is a lot better.

Cool! Without the << and >> buttons, I think the UX is a lot better.

Do you think the speed reset button is needed?

Arguably it would be great to be able to reset to 1.0x using a little reset button (like the one used to reset variables to their default in the inspector!), but we wouldn’t want the bar to grow or shrink in width. maybe there’s a clean solution to this?

maybe there’s a clean solution to this?

I have two solutions, the first is to reset the value by right-clicking on the menu button, the second is to add a button to reset it, when the value is one, the button is not hidden and only disabled.

as right clicking is hidden, the button is probably a better idea?

The current implementation changes several values directly. Instead, they should override those temporarily (and add up to those that have been changed in the game itself) and go back to their original values once done.

Let me give you a example:

• The user's game overrides the game speed (set_time_scale()) manually for some gameplay reason. Lets say a value of 1.2.
• With the current implementation of your PR, the current value set by the user is erased in favor of the one chosen in the UI.
• The correct implementation would be to temporally override it, and to also add up to it. So if the user picks 0.5 in the UI, it will still remember that the original ingame value was 1.2, and change the speed internally to 0.6. And setting it in the UI back to 1, will set it back to 1.2.

This is how it's done for the mouse mode behavior as well.

Cool! Without the << and >> buttons, I think the UX is a lot better.

The reason I wanted those buttons is to have keyboard shortcuts for them, but we can replace it with a toggle that enables the speed override instead. This means you could toggle between slow motion and full speed, or full speed and fast-forward. It would use remember the last selected speed to toggle back to every time you press the shortcut (on startup, it'd default to 2×).

Emulators generally have a key you can press (or hold, like in Dolphin) to enable turbo mode. They sometimes have a separate slow motion key though (as well as frame advance).

Let me give you a example:

• The user's game overrides the game speed (set_time_scale()) manually for some gameplay reason. Lets say a value of 1.2.
• With the current implementation of your PR, the current value set by the user is erased in favor of the one chosen in the UI.
• The correct implementation would be to temporally override it, and to also add up to it. So if the user picks 0.5 in the UI, it will still remember that the original ingame value was 1.2, and change the speed internally to 0.6. And setting it in the UI back to 1, will set it back to 1.2.

This is how it's done for the mouse mode behavior as well.

I updated the code so that time_scale can be changed both by code and the UI at the same time.
Should I do this for physics_ticks_per_second and max_physics_steps_per_frame as well?

Should I do this for physics_ticks_per_second and max_physics_steps_per_frame as well?

They can also be changed by the user, so yes.

There's a problem, don't I?

Could you rebase it? It's still on Godot 4.5.

Could you rebase it? It's still on Godot 4.5.

@YeldhamDev Done.

Opening the editor spits this warning:

scene/gui/control.cpp:3090 - Attempting to access theme items too early in GameView; prefer NOTIFICATION_POSTINITIALIZE and NOTIFICATION_THEME_CHANGED

Opening the editor spits this warning:

scene/gui/control.cpp:3090 - Attempting to access theme items too early in GameView; prefer NOTIFICATION_POSTINITIALIZE and NOTIFICATION_THEME_CHANGED

@YeldhamDev fixed. (I think)

I can still reproduce it.

I can still reproduce it.

@YeldhamDev now fixed

@syntaxerror247 Done

Thanks! Congratulations on your first merged contribution! 🎉