Merge pull request #10222 from tetrapod00/run-time-runtime

mhilbrunner · web-flow · commit 47455be55a86 · 2024-11-08T00:14:11.000+01:00
Change all usages of "run-time" to "runtime"
diff --git a/about/faq.rst b/about/faq.rst
@@ -567,7 +567,7 @@ resulted in better usability while still being fast enough for most use cases.
 
 That said, nothing prevents you from making use of composition in your project
 by creating child Nodes with individual scripts. These nodes can then be added and
-removed at run-time to dynamically add and remove behaviors.
+removed at runtime to dynamically add and remove behaviors.
 
 More information about Godot's design choices can be found in
 `this article <https://godotengine.org/article/why-isnt-godot-ecs-based-game-engine>`__.
diff --git a/about/list_of_features.rst b/about/list_of_features.rst
@@ -239,7 +239,7 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
 
 **Global illumination with indirect lighting:**
 
-- :ref:`Baked lightmaps <doc_using_lightmap_gi>` (fast, but can't be updated at run-time).
+- :ref:`Baked lightmaps <doc_using_lightmap_gi>` (fast, but can't be updated at runtime).
 
    - Supports baking indirect light only or baking both direct and indirect lighting.
      The bake mode can be adjusted on a per-light basis to allow for hybrid light
@@ -256,7 +256,7 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
 - :ref:`Voxel-based GI probes <doc_using_voxel_gi>`. Supports
   dynamic lights *and* dynamic occluders, while also supporting reflections.
   Requires a fast baking step which can be performed in the editor or at
-  run-time (including from an exported project).
+  runtime (including from an exported project).
 - :ref:`Signed-distance field GI <doc_using_sdfgi>` designed for large open worlds.
   Supports dynamic lights, but not dynamic occluders. Supports reflections.
   No baking required.
@@ -290,7 +290,7 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods.
 - Texture channels are smoothly overlaid on top of the underlying material,
   with support for normal/ORM-only decals.
 - Support for normal fade to fade the decal depending on its incidence angle.
-- Does not rely on run-time mesh generation. This means decals can be used on
+- Does not rely on runtime mesh generation. This means decals can be used on
   complex skinned meshes with no performance penalty, even if the decal moves every frame.
 - Support for nearest, bilinear, trilinear or anisotropic texture filtering (configured globally).
 - Optional distance fade system to fade distant decals, improving performance.
@@ -407,7 +407,7 @@ improve quality. This can be helpful when
 
 - :ref:`3D geometry helper class <class_Geometry3D>`.
 - Support for exporting the current scene as a glTF 2.0 file, both from the editor
-  and at run-time from an exported project.
+  and at runtime from an exported project.
 
 3D physics
 ----------
@@ -544,7 +544,7 @@ Import
    - Collada (.dae).
    - Wavefront OBJ (static scenes only, can be loaded directly as a mesh or imported as a 3D scene).
 
-- Support for loading glTF 2.0 scenes at run-time, including from an exported project.
+- Support for loading glTF 2.0 scenes at runtime, including from an exported project.
 - 3D meshes use `Mikktspace <http://www.mikktspace.com/>`__ to generate tangents
   on import, which ensures consistency with other 3D applications such as Blender.
 
@@ -576,7 +576,7 @@ Navigation
 - A* algorithm in :ref:`2D <class_AStar2D>` and :ref:`3D <class_AStar3D>`.
 - Navigation meshes with dynamic obstacle avoidance in
   :ref:`2D <doc_navigation_overview_2d>` and :ref:`3D <doc_navigation_overview_3d>`.
-- Generate navigation meshes from the editor or at run-time (including from an exported project).
+- Generate navigation meshes from the editor or at runtime (including from an exported project).
 
 Networking
 ----------
diff --git a/contributing/development/core_and_modules/common_engine_methods_and_macros.rst b/contributing/development/core_and_modules/common_engine_methods_and_macros.rst
@@ -85,7 +85,7 @@ There are two types of internationalization in Godot's codebase:
   editor. If a user uses the same text in one of their projects, it won't be
   translated if they provide a translation for it. When contributing to the
   engine, this is generally the macro you should use for localizable strings.
-- ``RTR()``: **Run-time translations** will be automatically localized in
+- ``RTR()``: **Runtime translations** will be automatically localized in
   projects if they provide a translation for the given string. This kind of
   translation shouldn't be used in editor-only code.
 
diff --git a/contributing/development/core_and_modules/custom_modules_in_cpp.rst b/contributing/development/core_and_modules/custom_modules_in_cpp.rst
@@ -339,7 +339,7 @@ type registration methods:
     ScriptServer::init_languages();
 
 Our ``Summator`` class is initialized during the ``register_module_types()``
-call. Imagine that we need to satisfy some common module run-time dependency
+call. Imagine that we need to satisfy some common module runtime dependency
 (like singletons), or allow us to override existing engine method callbacks
 before they can be assigned by the engine itself. In that case, we want to
 ensure that our module classes are registered *before* any other built-in type.
diff --git a/contributing/development/core_and_modules/custom_platform_ports.rst b/contributing/development/core_and_modules/custom_platform_ports.rst
@@ -161,9 +161,9 @@ games.
 If the target platform doesn't support running Vulkan, Direct3D 12, OpenGL 3.3,
 or OpenGL ES 3.0, you have two options:
 
-- Use a library at run-time to translate Vulkan or OpenGL calls to another graphics API.
+- Use a library at runtime to translate Vulkan or OpenGL calls to another graphics API.
   For example, `MoltenVK <https://moltengl.com/moltenvk/>`__ is used on macOS
-  to translate Vulkan to Metal at run-time.
+  to translate Vulkan to Metal at runtime.
 - Create a new renderer from scratch. This is a large undertaking, especially if
   you want to support both 2D and 3D rendering with advanced features.
 
diff --git a/contributing/development/core_and_modules/internal_rendering_architecture.rst b/contributing/development/core_and_modules/internal_rendering_architecture.rst
@@ -744,15 +744,15 @@ This is done by rasterizing a low-resolution buffer on the CPU using
 `Embree <https://github.com/embree/embree>`__. The buffer's resolution depends
 on the number of CPU threads on the system, as this is done in parallel.
 This buffer includes occluder shapes that were baked in the editor or created at
-run-time.
+runtime.
 
 As complex occluders can introduce a lot of strain on the CPU, baked occluders
 can be simplified automatically when generated in the editor.
 
 Godot's occlusion culling doesn't support dynamic occluders yet, but
 OccluderInstance3D nodes can still have their visibility toggled or be moved.
 However, this will be slow when updating complex occluders this way. Therefore,
-updating occluders at run-time is best done only on simple occluder shapes such
+updating occluders at runtime is best done only on simple occluder shapes such
 as quads or cuboids.
 
 This CPU-based approach has a few advantages over other solutions, such as
diff --git a/contributing/development/core_and_modules/unit_testing.rst b/contributing/development/core_and_modules/unit_testing.rst
@@ -147,7 +147,7 @@ writing test cases themselves.
 
 Test cases are created using ``TEST_CASE`` function-like macro. Each test case
 must have a brief description written in parentheses, optionally including
-custom tags which allow to filter the tests at run-time, such as ``[String]``,
+custom tags which allow to filter the tests at runtime, such as ``[String]``,
 ``[Stress]`` etc.
 
 Test cases are written in a dedicated namespace. This is not required, but
@@ -227,7 +227,7 @@ macros which allow to log test output in a format written by doctest.
 | ``FAIL``       | Fails the test immediately. Can be wrapped in conditionals for complex checks.                            |
 +----------------+-----------------------------------------------------------------------------------------------------------+
 
-Different reporters can be chosen at run-time. For instance, here's how the
+Different reporters can be chosen at runtime. For instance, here's how the
 output can be redirected to an XML file:
 
 .. code-block:: shell
diff --git a/getting_started/first_3d_game/index.rst b/getting_started/first_3d_game/index.rst
@@ -24,7 +24,7 @@ You will learn to:
 - Use physics layers and a group to detect interactions with specific entities.
 - Code basic procedural gameplay by instancing monsters at regular time
   intervals.
-- Design a movement animation and change its speed at run-time.
+- Design a movement animation and change its speed at runtime.
 - Draw a user interface on a 3D game.
 
 And more.
diff --git a/tutorials/3d/global_illumination/introduction_to_global_illumination.rst b/tutorials/3d/global_illumination/introduction_to_global_illumination.rst
@@ -272,7 +272,7 @@ Real-time ability
 - **LightmapGI:** |bad| Baked, and therefore not real-time.
 
   - Both indirect lighting and SH reflections are baked and can't be changed at
-    run-time. Real-time GI must be
+    runtime. Real-time GI must be
     :ref:`simulated via other means <doc_faking_global_illumination>`,
     such as real-time positional lights. Dynamic objects receive indirect lighting
     via light probes, which can be placed automatically or manually by the user
@@ -286,7 +286,7 @@ Real-time ability
     is set to **Always** (which is expensive).
 
   - Indirect lighting must be configured manually by the user, but can be changed
-    at run-time without causing an expensive computation to happen behind the scenes.
+    at runtime without causing an expensive computation to happen behind the scenes.
     This makes ReflectionProbes viable for procedurally generated levels.
 
 User work needed
diff --git a/tutorials/3d/global_illumination/using_lightmap_gi.rst b/tutorials/3d/global_illumination/using_lightmap_gi.rst
@@ -6,7 +6,7 @@ Using Lightmap global illumination
 Baked lightmaps are a workflow for adding indirect (or fully baked)
 lighting to a scene. Unlike the :ref:`VoxelGI <doc_using_voxel_gi>` and
 :ref:`SDFGI <doc_using_sdfgi>` approaches, baked lightmaps work fine on low-end PCs
-and mobile devices, as they consume almost no resources at run-time. Also unlike
+and mobile devices, as they consume almost no resources at runtime. Also unlike
 VoxelGI and SDFGI, baked lightmaps can optionally be used to store direct
 lighting, which provides even further performance gains.
 
diff --git a/tutorials/3d/global_illumination/using_voxel_gi.rst b/tutorials/3d/global_illumination/using_voxel_gi.rst
@@ -81,7 +81,7 @@ contained within a VoxelGI node after it has been baked:
   If in doubt, leave this unchanged.
 - **Energy:** The indirect lighting's overall energy. This also effects the energy
   of direct lighting emitted by meshes with emissive materials.
-- **Bias:** Optional bias added to lookups into the voxel buffer at run time.
+- **Bias:** Optional bias added to lookups into the voxel buffer at runtime.
   This helps avoid self-occlusion artifacts.
 - **Normal Bias:** Similar to **Bias**, but offsets the lookup into the voxel buffer
   by the surface normal. This also helps avoid self-occlusion artifacts. Higher
diff --git a/tutorials/3d/lights_and_shadows.rst b/tutorials/3d/lights_and_shadows.rst
@@ -431,10 +431,10 @@ Balancing performance and quality
 Shadow rendering is a critical topic in 3D rendering performance. It's important
 to make the right choices here to avoid creating bottlenecks.
 
-Directional shadow quality settings can be changed at run-time by calling the
+Directional shadow quality settings can be changed at runtime by calling the
 appropriate :ref:`class_RenderingServer` methods.
 
-Positional (omni/spot) shadow quality settings can be changed at run-time on the
+Positional (omni/spot) shadow quality settings can be changed at runtime on the
 root :ref:`class_Viewport`.
 
 Shadow map size
diff --git a/tutorials/3d/mesh_lod.rst b/tutorials/3d/mesh_lod.rst
@@ -135,7 +135,7 @@ Configuring mesh LOD performance and quality
 
 You can adjust how aggressive mesh LOD transitions should be in the root viewport
 by changing the **Rendering > Mesh LOD > LOD Change > Threshold Pixels** project
-setting. To change this value at run-time, set ``mesh_lod_threshold`` on the
+setting. To change this value at runtime, set ``mesh_lod_threshold`` on the
 root viewport as follows:
 
 .. tabs::
diff --git a/tutorials/3d/occlusion_culling.rst b/tutorials/3d/occlusion_culling.rst
@@ -192,7 +192,7 @@ your scene. Note that the performance benefit highly depends on the 3D editor
 camera's view angle, as occlusion culling is only effective if there are
 occluders in front of the camera.
 
-To toggle occlusion culling at run-time, set ``use_occlusion_culling`` on the
+To toggle occlusion culling at runtime, set ``use_occlusion_culling`` on the
 root viewport as follows:
 
 .. tabs::
@@ -205,7 +205,7 @@ root viewport as follows:
     GetTree().Root.UseOcclusionCulling = true;
 
 
-Toggling occlusion culling at run-time is useful to compare performance on a
+Toggling occlusion culling at runtime is useful to compare performance on a
 running project.
 
 Performance considerations
diff --git a/tutorials/3d/resolution_scaling.rst b/tutorials/3d/resolution_scaling.rst
@@ -93,7 +93,7 @@ The **Rendering > Scaling 3D > Scale** setting adjusts the resolution scale.
 matching the 2D rendering resolution. Resolution scales *below* ``1.0`` can be
 used to speed up rendering, at the cost of a blurrier final image and more aliasing.
 
-The rendering scale can be adjusted at run-time by changing the ``scaling_3d_scale``
+The rendering scale can be adjusted at runtime by changing the ``scaling_3d_scale``
 property on a :ref:`class_Viewport` node.
 
 Resolution scales *above* ``1.0`` can be used for supersample antialiasing
@@ -234,7 +234,7 @@ not change depending on resolution scale.
 
 The texture LOD bias can manually be changed by adjusting the **Rendering >
 Textures > Default Filters > Texture Mipmap Bias** advanced project setting. It
-can also be changed at run-time on :ref:`Viewports <class_Viewport>` by
+can also be changed at runtime on :ref:`Viewports <class_Viewport>` by
 adjusting the ``texture_mipmap_bias`` property.
 
 .. warning::
diff --git a/tutorials/assets_pipeline/importing_audio_samples.rst b/tutorials/assets_pipeline/importing_audio_samples.rst
@@ -286,7 +286,7 @@ sample rate and number of channels for your audio:
 - There's no *audible* benefit to using 24-bit audio, especially in a game
   where several sounds are often playing at the same time (which makes it
   harder to appreciate individual sounds).
-- Unless you are slowing down the audio at run-time, there's no *audible*
+- Unless you are slowing down the audio at runtime, there's no *audible*
   benefit to using a sample rate greater than 48 kHz. If you wish to keep a
   source with a higher sample rate for editing, use the **Force > Max Rate**
   import option to limit the sample rate of the imported sound (only available
diff --git a/tutorials/export/feature_tags.rst b/tutorials/export/feature_tags.rst
@@ -17,7 +17,7 @@ Each *feature* is represented as a string, which can refer to many of the follow
 * Whether the project is running from the editor or a "standalone" binary.
 * Many more things.
 
-Features can be queried at run-time from the singleton API by calling:
+Features can be queried at runtime from the singleton API by calling:
 
 .. tabs::
  .. code-tab:: gdscript
@@ -127,7 +127,7 @@ Here is a list of most feature tags in Godot. Keep in mind they are **case-sensi
 
     With the exception of texture compression, ``web_<platform>`` and
     ``movie`` feature tags, default feature tags are **immutable**.
-    This means that they will *not* change depending on run-time conditions.
+    This means that they will *not* change depending on runtime conditions.
     For example, ``OS.has_feature("mobile")`` will return ``false``
     when running a project exported to Web on a mobile device.
 
diff --git a/tutorials/i18n/internationalizing_games.rst b/tutorials/i18n/internationalizing_games.rst
@@ -233,8 +233,8 @@ TranslationServer
 
 Godot has a server handling low-level translation management
 called the :ref:`TranslationServer <class_TranslationServer>`.
-Translations can be added or removed during run-time;
-the current language can also be changed at run-time.
+Translations can be added or removed during runtime;
+the current language can also be changed at runtime.
 
 .. _doc_internationalizing_games_bidi:
 
diff --git a/tutorials/inputs/inputevent.rst b/tutorials/inputs/inputevent.rst
@@ -206,8 +206,8 @@ This allows for:
 
 -  The same code to work on different devices with different inputs (e.g.,
    keyboard on PC, Joypad on console).
--  Input to be reconfigured at run-time.
--  Actions to be triggered programmatically at run-time.
+-  Input to be reconfigured at runtime.
+-  Actions to be triggered programmatically at runtime.
 
 Actions can be created from the Project Settings menu in the **Input Map**
 tab and assigned input events.
@@ -250,7 +250,7 @@ InputMap
 
 Customizing and re-mapping input from code is often desired. If your
 whole workflow depends on actions, the :ref:`InputMap <class_InputMap>` singleton is
-ideal for reassigning or creating different actions at run-time. This
+ideal for reassigning or creating different actions at runtime. This
 singleton is not saved (must be modified manually) and its state is run
 from the project settings (project.godot). So any dynamic system of this
 type needs to store settings in the way the programmer best sees fit.
diff --git a/tutorials/migrating/upgrading_to_godot_4.1.rst b/tutorials/migrating/upgrading_to_godot_4.1.rst
@@ -23,7 +23,7 @@ This article indicates whether each breaking change affects GDScript and whether
 the C# breaking change is *binary compatible* or *source compatible*:
 
 - **Binary compatible** - Existing binaries will load and execute successfully without
-  recompilation, and the run-time behavior won't change.
+  recompilation, and the runtime behavior won't change.
 - **Source compatible** - Source code will compile successfully without changes when
   upgrading Godot.
 
diff --git a/tutorials/migrating/upgrading_to_godot_4.2.rst b/tutorials/migrating/upgrading_to_godot_4.2.rst
@@ -44,7 +44,7 @@ This article indicates whether each breaking change affects GDScript and whether
 the C# breaking change is *binary compatible* or *source compatible*:
 
 - **Binary compatible** - Existing binaries will load and execute successfully without
-  recompilation, and the run-time behavior won't change.
+  recompilation, and the runtime behavior won't change.
 - **Source compatible** - Source code will compile successfully without changes when
   upgrading Godot.
 
diff --git a/tutorials/migrating/upgrading_to_godot_4.3.rst b/tutorials/migrating/upgrading_to_godot_4.3.rst
@@ -17,7 +17,7 @@ This article indicates whether each breaking change affects GDScript and whether
 the C# breaking change is *binary compatible* or *source compatible*:
 
 - **Binary compatible** - Existing binaries will load and execute successfully without
-  recompilation, and the run-time behavior won't change.
+  recompilation, and the runtime behavior won't change.
 - **Source compatible** - Source code will compile successfully without changes when
   upgrading Godot.
 
diff --git a/tutorials/migrating/upgrading_to_godot_4.rst b/tutorials/migrating/upgrading_to_godot_4.rst
@@ -494,7 +494,7 @@ Checking Environment settings
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Graphics quality settings were moved from Environment properties to project
-settings. This was done to make run-time quality adjustments easier, without
+settings. This was done to make runtime quality adjustments easier, without
 having to access the currently active Environment resource then modify its
 properties.
 
@@ -569,7 +569,7 @@ The most notable examples of this are:
   The conversion tool will use the string-based syntax which is still present in
   Godot 4, but it's recommended to switch to the :ref:`class_Signal`-based syntax
   described on the linked page. This way, strings are no longer involved,
-  which avoids issues with signal name errors that can only be discovered at run-time.
+  which avoids issues with signal name errors that can only be discovered at runtime.
 - Built-in scripts that are :ref:`tool scripts <doc_running_code_in_the_editor>`
   do not get the ``tool`` keyword converted to the ``@tool`` annotation.
 - The Tween node was removed in favor of Tweeners, which are also available in
diff --git a/tutorials/performance/using_multiple_threads.rst b/tutorials/performance/using_multiple_threads.rst
@@ -54,7 +54,7 @@ wait until the thread is done (if not done yet), then properly dispose of it.
 
 .. warning::
 
-    Creating threads at run-time is slow on Windows and should be avoided to
+    Creating threads at runtime is slow on Windows and should be avoided to
     prevent stuttering. Semaphores, explained later on this page, should be used
     instead.
 
diff --git a/tutorials/rendering/jitter_stutter.rst b/tutorials/rendering/jitter_stutter.rst
@@ -174,7 +174,7 @@ Increasing the number of physics iterations per second can also reduce
 physics-induced input latency. This is especially noticeable when using physics
 interpolation (which improves smoothness but increases latency). To do so, set
 **Physics > Common > Physics Ticks Per Second** to a value higher than the
-default ``60``, or set ``Engine.physics_ticks_per_second`` at run-time in a
+default ``60``, or set ``Engine.physics_ticks_per_second`` at runtime in a
 script. Values that are a multiple of the monitor refresh rate (typically
 ``60``) work best when physics interpolation is disabled, as they will avoid
 jitter. This means values such as ``120``, ``180`` and ``240`` are good starting
@@ -220,7 +220,7 @@ the same framerate cap (usually less than 1 ms greater), but without any
 tearing.
 
 This can be done by changing the **Application > Run > Max FPS** project
-setting or assigning ``Engine.max_fps`` at run-time in a script.
+setting or assigning ``Engine.max_fps`` at runtime in a script.
 
 On some platforms, you can also opt into a low-latency mode in the graphics
 driver options (such as the NVIDIA Control Panel on Windows). The **Ultra**
diff --git a/tutorials/rendering/multiple_resolutions.rst b/tutorials/rendering/multiple_resolutions.rst
@@ -247,7 +247,7 @@ to the region outside the blue frame you see in the 2D editor.
     landscape mode, use 720×720 as the project's base window size in the
     Project Settings.
 
-    To allow the user to choose their preferred screen orientation at run-time,
+    To allow the user to choose their preferred screen orientation at runtime,
     remember to set **Display > Window > Handheld > Orientation** to ``sensor``.
 
 To configure the stretch aspect at runtime from a script, use the
diff --git a/tutorials/scripting/gdextension/what_is_gdextension.rst b/tutorials/scripting/gdextension/what_is_gdextension.rst
diff --git a/tutorials/scripting/gdscript/gdscript_advanced.rst b/tutorials/scripting/gdscript/gdscript_advanced.rst
diff --git a/tutorials/shaders/shader_reference/shader_preprocessor.rst b/tutorials/shaders/shader_reference/shader_preprocessor.rst
diff --git a/tutorials/shaders/shader_reference/shading_language.rst b/tutorials/shaders/shader_reference/shading_language.rst
diff --git a/tutorials/ui/bbcode_in_richtextlabel.rst b/tutorials/ui/bbcode_in_richtextlabel.rst
diff --git a/tutorials/ui/gui_using_fonts.rst b/tutorials/ui/gui_using_fonts.rst
