From ff486f333d5ecbe7ab04ae42be3a682e1d6b3f1f Mon Sep 17 00:00:00 2001 From: Ninni Pipping Date: Sun, 23 Apr 2023 10:21:18 +0200 Subject: [PATCH] Add information about how `Engine.time_scale` affects Timers (cherry picked from commit 16a1465380df708edebffc53c77011cd771f6b91) --- doc/classes/Engine.xml | 2 +- doc/classes/Timer.xml | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/classes/Engine.xml b/doc/classes/Engine.xml index c9931dedeb1..9d05e270a3c 100644 --- a/doc/classes/Engine.xml +++ b/doc/classes/Engine.xml @@ -166,7 +166,7 @@ The desired frames per second. If the hardware cannot keep up, this setting may not be respected. A value of 0 means no limit. - Controls how fast or slow the in-game clock ticks versus the real life one. It defaults to 1.0. A value of 2.0 means the game moves twice as fast as real life, whilst a value of 0.5 means the game moves at half the regular speed. + Controls how fast or slow the in-game clock ticks versus the real life one. It defaults to 1.0. A value of 2.0 means the game moves twice as fast as real life, whilst a value of 0.5 means the game moves at half the regular speed. This also affects [Timer] and [SceneTreeTimer] (see [method SceneTree.create_timer] for how to control this). diff --git a/doc/classes/Timer.xml b/doc/classes/Timer.xml index af275267346..a2f2dafbc65 100644 --- a/doc/classes/Timer.xml +++ b/doc/classes/Timer.xml @@ -5,6 +5,7 @@ Counts down a specified interval and emits a signal on reaching 0. Can be set to repeat or "one-shot" mode. + [b]Note:[/b] Timers are affected by [member Engine.time_scale], a higher scale means quicker timeouts, and vice versa. [b]Note:[/b] To create a one-shot timer without instantiating a node, use [method SceneTree.create_timer]. @@ -52,7 +53,7 @@ The wait time in seconds. - [b]Note:[/b] Timers can only emit once per rendered frame at most (or once per physics frame if [member process_mode] is [constant TIMER_PROCESS_PHYSICS]). This means very low wait times (lower than 0.05 seconds) will behave in significantly different ways depending on the rendered framerate. For very low wait times, it is recommended to use a process loop in a script instead of using a Timer node. + [b]Note:[/b] Timers can only emit once per rendered frame at most (or once per physics frame if [member process_mode] is [constant TIMER_PROCESS_PHYSICS]). This means very low wait times (lower than 0.05 seconds) will behave in significantly different ways depending on the rendered framerate. For very low wait times, it is recommended to use a process loop in a script instead of using a Timer node. Timers are affected by [member Engine.time_scale], a higher scale means quicker timeouts, and vice versa.