Limiting the FPS can be useful to reduce the host machine's power consumption, which reduces heat, noise emissions, and improves battery life.
If [member ProjectSettings.display/window/vsync/vsync_mode] is Enabled or Adaptive, the setting takes precedence and the max FPS number cannot exceed the monitor's refresh rate.
If [member ProjectSettings.display/window/vsync/vsync_mode] is Enabled, on monitors with variable refresh rate enabled (G-Sync/FreeSync), using an FPS limit a few frames lower than the monitor's refresh rate will [url=https://blurbusters.com/howto-low-lag-vsync-on/]reduce input lag while avoiding tearing[/url].
See also physics_ticks_per_second and [member ProjectSettings.application/run/max_fps].
Note: The actual number of frames per second may still be below this value if the CPU or GPU cannot keep up with the project's logic and rendering.
Note: If [member ProjectSettings.display/window/vsync/vsync_mode] is Disabled, limiting the FPS to a high value that can be consistently reached on the system can reduce input lag compared to an uncapped framerate. Since this works by ensuring the GPU load is lower than 100%, this latency reduction is only effective in GPU-bottlenecked scenarios, not CPU-bottlenecked scenarios.

Note: The default value is tuned to prevent expensive physics simulations from triggering even more expensive simulations indefinitely. However, the game will appear to slow down if the rendering FPS is less than 1 / max_physics_steps_per_frame of physics_ticks_per_second. This occurs even if delta is consistently used in physics calculations. To avoid this, increase max_physics_steps_per_frame if you have increased physics_ticks_per_second significantly above its default value.

Note: The default value of 0.5 should be good enough for most cases; values above 2 could cause the game to react to dropped frames with a noticeable delay and are not recommended.
Note: When using a custom physics interpolation solution, or within a network game, it's recommended to disable the physics jitter fix by setting this property to 0.

Note: Only max_physics_steps_per_frame physics ticks may be simulated per rendered frame at most. If more physics ticks have to be simulated per rendered frame to keep up with rendering, the project will appear to slow down (even if delta is used consistently in physics calculations). Therefore, it is recommended to also increase max_physics_steps_per_frame if increasing physics_ticks_per_second significantly above its default value.

Note: This property does not impact the editor's Errors tab when running a project from the editor.
Warning: If set to false anywhere in the project, important error messages may be hidden even if they are emitted from other scripts. In a @tool script, this will also impact the editor itself. Do not report bugs before ensuring error messages are enabled (as they are by default).

Note: This does not stop printing errors or warnings produced by scripts to the console or log files, for more details see print_error_messages.

This value affects Timer, SceneTreeTimer, and all other simulations that make use of delta time (such as [method Node._process] and [method Node._physics_process]).
Note: It's recommended to keep this property above 0.0, as the game may behave unexpectedly otherwise.
Note: This does not affect audio playback speed. Use [member AudioServer.playback_speed_scale] to adjust audio playback speed independently of [member Engine.time_scale].
Note: This does not automatically adjust physics_ticks_per_second. With values above 1.0 physics simulation may become less precise, as each physics tick will stretch over a larger period of engine time. If you're modifying [member Engine.time_scale] to speed up simulation by a large factor, consider also increasing physics_ticks_per_second to make the simulation more reliable.

By default, the returned ScriptBacktrace will only contain stack frames in editor builds and debug builds. To enable them for release builds as well, you need to enable [member ProjectSettings.debug/settings/gdscript/always_track_call_stacks].
If include_variables is true, the backtrace will also include the names and values of any global variables (e.g. autoload singletons) at the point of the capture, as well as local variables and class member variables at each stack frame. This will however will only be respected when running the game with a debugger attached, like when running the game from the editor. To enable it for export builds as well, you need to enable [member ProjectSettings.debug/settings/gdscript/always_track_local_variables].
Warning: When include_variables is true, any captured variables can potentially (e.g. with GDScript backtraces) be their actual values, including any object references. This means that storing such a ScriptBacktrace will prevent those objects from being deallocated, so it's generally recommended not to do so.

To detect whether the current build is 64-bit, or the type of architecture, don't use the architecture name. Instead, use [method OS.has_feature] to check for the "64" feature tag, or tags such as "x86" or "arm". See the [url=$DOCS_URL/tutorials/export/feature_tags.html]Feature Tags[/url] documentation for more details.
Note: This method does not return the name of the system's CPU architecture (like [method OS.get_processor_name]). For example, when running an x86_32 Godot binary on an x86_64 system, the returned value will still be "x86_32".

Every Dictionary contains a name identifier, and a parts array of dictionaries. It describes the component in detail with the following entries:
- files - Array of file paths from the source code affected by this component;
- copyright - Array of owners of this component;
- license - The license applied to this component (such as "[url=https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants]Expat[/url]" or "[url=https://creativecommons.org/licenses/by/4.0/]CC-BY-4.0[/url]").

{platinum_sponsors, gold_sponsors, silver_sponsors, bronze_sponsors, mini_sponsors, gold_donors, silver_donors, bronze_donors}

Note: On headless platforms, or if rendering is disabled with --disable-render-loop via command line, this method always returns 0. See also get_process_frames.

Note: The type instantiated as the main loop can changed with [member ProjectSettings.application/run/main_loop_type].

This method can be used to run expensive logic less often without relying on a Timer:

func _physics_process(_delta): if Engine.get_physics_frames() % 2 == 0: pass # Run expensive logic only once every 2 physics frames here.

public override void _PhysicsProcess(double delta) { base._PhysicsProcess(delta); if (Engine.GetPhysicsFrames() % 2 == 0) { // Run expensive logic only once every 2 physics frames here. } }

This method can be used to run expensive logic less often without relying on a Timer:

func _process(_delta): if Engine.get_process_frames() % 5 == 0: pass # Run expensive logic only once every 5 process (render) frames here.

public override void _Process(double delta) { base._Process(delta); if (Engine.GetProcessFrames() % 5 == 0) { // Run expensive logic only once every 5 process (render) frames here. } }

Note: Global singletons are not the same as autoloaded nodes, which are configurable in the project settings.

- major - Major version number as an int;
- minor - Minor version number as an int;
- patch - Patch version number as an int;
- hex - Full version encoded as a hexadecimal int with one byte (2 hex digits) per number (see example below);
- status - Status (such as "beta", "rc1", "rc2", "stable", etc.) as a String;
- build - Build name (e.g. "custom_build") as a String;
- hash - Full Git commit hash as a String;
- timestamp - Holds the Git commit date UNIX timestamp in seconds as an int, or 0 if unavailable;
- string - major, minor, patch, status, and build in a single String.
The hex value is encoded as follows, from left to right: one byte for the major, one byte for the minor, one byte for the patch version. For example, "3.1.12" would be 0x03010C.
Note: The hex value is still an int internally, and printing it will give you its decimal representation, which is not particularly meaningful. Use hexadecimal literals for quick version comparisons from code:

if Engine.get_version_info().hex >= 0x040100: pass # Do things specific to version 4.1 or later. else: pass # Do things specific to versions before 4.1.

if ((int)Engine.GetVersionInfo()["hex"] >= 0x040100) { // Do things specific to version 4.1 or later. } else { // Do things specific to versions before 4.1. }

print(Engine.has_singleton("OS")) # Prints true print(Engine.has_singleton("Engine")) # Prints true print(Engine.has_singleton("AudioServer")) # Prints true print(Engine.has_singleton("Unknown")) # Prints false

GD.Print(Engine.HasSingleton("OS")); // Prints True GD.Print(Engine.HasSingleton("Engine")); // Prints True GD.Print(Engine.HasSingleton("AudioServer")); // Prints True GD.Print(Engine.HasSingleton("Unknown")); // Prints False

Note: Global singletons are not the same as autoloaded nodes, which are configurable in the project settings.

if Engine.is_editor_hint(): draw_gizmos() else: simulate_physics()

if (Engine.IsEditorHint()) DrawGizmos(); else SimulatePhysics();

See [url=$DOCS_URL/tutorials/plugins/running_code_in_the_editor.html]Running code in the editor[/url] in the documentation for more information.
Note: To detect whether the script is running on an editor build (such as when pressing kbdF5[/kbd]), use [method OS.has_feature] with the "editor" argument instead. OS.has_feature("editor") evaluate to true both when the script is running in the editor and when running the project from the editor, but returns false when run from an exported project.

func _enter_tree(): # Depending on when the node is added to the tree, # prints either "true" or "false". print(Engine.is_in_physics_frame()) func _process(delta): print(Engine.is_in_physics_frame()) # Prints false func _physics_process(delta): print(Engine.is_in_physics_frame()) # Prints true

Returns:
- OK on success;
- ERR_UNAVAILABLE if ScriptServer has reached the limit and cannot register any new language;
- ERR_ALREADY_EXISTS if ScriptServer already contains a language with similar extension/name/type.

Returns:
- OK on success;
- ERR_DOES_NOT_EXIST if the language is not registered in ScriptServer.