From d79cb5b0a41780da5912a46a546f9fb39e826254 Mon Sep 17 00:00:00 2001 From: Micky <66727710+Mickeon@users.noreply.github.com> Date: Sun, 2 Aug 2026 15:09:54 +0200 Subject: [PATCH] Update codespell to include many more checks --- .pre-commit-config.yaml | 2 +- _tools/codespell-dict.txt | 1 + _tools/codespell-ignore.txt | 7 ---- about/complying_with_licenses.rst | 4 +- about/list_of_features.rst | 2 +- .../first_3d_game/01.game_setup.rst | 6 +-- .../first_3d_game/05.spawning_mobs.rst | 2 +- getting_started/step_by_step/instancing.rst | 2 +- pyproject.toml | 20 +++++++++- tutorials/2d/custom_drawing_in_2d.rst | 40 +++++++++---------- .../3d/physical_light_and_camera_units.rst | 6 +-- tutorials/i18n/internationalizing_games.rst | 4 ++ .../migrating/upgrading_to_godot_4.5.rst | 6 +-- .../navigation_using_navigationagents.rst | 2 +- tutorials/networking/http_request_class.rst | 7 ++-- tutorials/performance/cpu_optimization.rst | 6 +-- .../performance/optimizing_3d_performance.rst | 8 ++-- .../performance/pipeline_compilations.rst | 4 +- .../physics_interpolation_introduction.rst | 11 ++--- .../using_physics_interpolation.rst | 2 +- tutorials/rendering/renderers.rst | 2 +- .../scripting/gdscript/gdscript_basics.rst | 2 +- .../shaders/using_viewport_as_texture.rst | 4 +- tutorials/ui/gui_using_theme_editor.rst | 2 +- tutorials/xr/a_better_xr_start_script.rst | 4 +- tutorials/xr/openxr_settings.rst | 6 +-- tutorials/xr/openxr_spatial_entities.rst | 2 +- tutorials/xr/setting_up_xr.rst | 2 +- tutorials/xr/xr_action_map.rst | 11 ++--- 29 files changed, 99 insertions(+), 78 deletions(-) delete mode 100644 _tools/codespell-ignore.txt diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index db7b8eae0a0..5f53061fae8 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -3,7 +3,7 @@ default_language_version: repos: - repo: https://github.com/codespell-project/codespell - rev: v2.3.0 + rev: v2.4.3 hooks: - id: codespell additional_dependencies: [tomli] diff --git a/_tools/codespell-dict.txt b/_tools/codespell-dict.txt index f8e93f339d9..8cf631d1b9e 100644 --- a/_tools/codespell-dict.txt +++ b/_tools/codespell-dict.txt @@ -1 +1,2 @@ anti-aliasing->antialiasing +sub-surface->subsurface \ No newline at end of file diff --git a/_tools/codespell-ignore.txt b/_tools/codespell-ignore.txt deleted file mode 100644 index 176af77a403..00000000000 --- a/_tools/codespell-ignore.txt +++ /dev/null @@ -1,7 +0,0 @@ -doubleclick -lod -uint -implementors -thirdparty -inout -findn diff --git a/about/complying_with_licenses.rst b/about/complying_with_licenses.rst index 6ba70db555f..c3018652c19 100644 --- a/about/complying_with_licenses.rst +++ b/about/complying_with_licenses.rst @@ -26,8 +26,8 @@ with the original one. .. note:: This section covers compliance with licenses from a user perspective. - If you are interested in licence compliance as a contributor, you can find - guidelines `here `__. + If you are interested in license compliance as a contributor, you can find + guidelines in the `Best practices `__ page. .. tip:: diff --git a/about/list_of_features.rst b/about/list_of_features.rst index 011ad7d14ee..47c609bd8aa 100644 --- a/about/list_of_features.rst +++ b/about/list_of_features.rst @@ -246,7 +246,7 @@ Godot 4 includes three renderers: - Normal mapping. - Parallax/relief mapping with automatic level of detail based on distance. - Detail mapping for the albedo and normal maps. -- Sub-surface scattering and transmittance. +- Subsurface scattering and transmittance. - Screen-space refraction with support for material roughness (resulting in blurry refraction). - Proximity fade (soft particles) and distance fade. - Distance fade can use alpha blending or dithering to avoid going through diff --git a/getting_started/first_3d_game/01.game_setup.rst b/getting_started/first_3d_game/01.game_setup.rst index 199b91ca22d..15e268aa94a 100644 --- a/getting_started/first_3d_game/01.game_setup.rst +++ b/getting_started/first_3d_game/01.game_setup.rst @@ -101,8 +101,8 @@ resource and set its *Size* to ``60``, ``2``, and ``60``. .. image:: img/01.game_setup/12.cube_resized.webp -You should see a wide grey slab that covers the grid and blue and red axes in -the viewport. +You should see a wide gray slab that covers the grid, +as well as blue and red axes in the viewport. We're going to move the ground down so we can see the floor grid. To do this, the grid snapping feature can be used. Grid snapping can be activated 2 ways in the 3D editor. @@ -137,7 +137,7 @@ Ultimately, ``Ground``'s Y position should be ``-1``. .. image:: img/01.game_setup/ground_down1meter.webp -Let's add a directional light so our scene isn't all grey. Select the ``Main`` +Let's add a directional light so our scene isn't all gray. Select the ``Main`` node and add a child node :ref:`DirectionalLight3D `. .. image:: img/01.game_setup/create_directional_light3d.webp diff --git a/getting_started/first_3d_game/05.spawning_mobs.rst b/getting_started/first_3d_game/05.spawning_mobs.rst index d31f89d260f..c2e0b5dc54d 100644 --- a/getting_started/first_3d_game/05.spawning_mobs.rst +++ b/getting_started/first_3d_game/05.spawning_mobs.rst @@ -120,7 +120,7 @@ the background, like a bright orange. |image14| We can now use the cylinders as guides. Fold them in the *Scene* dock by -clicking the grey arrow next to them. Moving forward, you can also toggle their +clicking the gray arrow next to them. Moving forward, you can also toggle their visibility by clicking the eye icon next to *Cylinders*. |image15| diff --git a/getting_started/step_by_step/instancing.rst b/getting_started/step_by_step/instancing.rst index 8a0de1c288f..f1923686e72 100644 --- a/getting_started/step_by_step/instancing.rst +++ b/getting_started/step_by_step/instancing.rst @@ -155,7 +155,7 @@ Select one of the instanced Ball nodes and, in the :ui:`Inspector`, set its .. image:: img/instancing_property_gravity_scale.webp -A grey "revert" button appears next to the adjusted property. +A gray "revert" button appears next to the adjusted property. .. image:: img/instancing_property_revert_icon.webp diff --git a/pyproject.toml b/pyproject.toml index bd4031e5090..a5241c89df6 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -2,8 +2,12 @@ line-length = 120 [tool.codespell] +enable-colors = true +write-changes = true +check-hidden = true +quiet-level = 3 dictionary = ["_tools/codespell-dict.txt", "-"] -ignore-words = "_tools/codespell-ignore.txt" +builtin = ["clear", "rare", "en-GB_to_en-US"] skip = [ "_build/*", "_static/*", @@ -14,3 +18,17 @@ skip = [ "AUTHORS.md", "LICENSE.txt", ] +ignore-words-list = [ + "dialogue", # Common even in US spelling. + "doubleclick", + "findn", # Our case-insensitive `find` function. + "implementors", + "inout", # Shader attribute. + "lod", # "Level of Detail". + "marshalled", # Common spelling in IT. + "marshalling", # Common spelling in IT. + "thirdparty", # Prefer as one word. + "uint", # "Unsigned integer". + "writeable", # Part of a Python error message. +] +ignore-multiline-regex = "codespell:ignore-begin.*?codespell:ignore-end" diff --git a/tutorials/2d/custom_drawing_in_2d.rst b/tutorials/2d/custom_drawing_in_2d.rst index bf76d3f5a14..9b7dc38da3e 100644 --- a/tutorials/2d/custom_drawing_in_2d.rst +++ b/tutorials/2d/custom_drawing_in_2d.rst @@ -515,16 +515,16 @@ its radius, and the third is its color: func _draw(): var white : Color = Color.WHITE var godot_blue : Color = Color("478cbf") - var grey : Color = Color("414042") + var gray : Color = Color("414042") draw_polygon(head, [ godot_blue ]) draw_polyline(mouth, white, _mouth_width) - # Four circles for the 2 eyes: 2 white, 2 grey. + # Four circles for the 2 eyes: 2 white, 2 gray. draw_circle(Vector2(42.479, 65.4825), 9.3905, white) draw_circle(Vector2(85.524, 65.4825), 9.3905, white) - draw_circle(Vector2(43.423, 65.92), 6.246, grey) - draw_circle(Vector2(84.626, 66.008), 6.246, grey) + draw_circle(Vector2(43.423, 65.92), 6.246, gray) + draw_circle(Vector2(84.626, 66.008), 6.246, gray) .. code-tab:: csharp @@ -533,16 +533,16 @@ its radius, and the third is its color: { Color white = Colors.White; Color godotBlue = new Color("478cbf"); - Color grey = new Color("414042"); + Color gray = new Color("414042"); DrawPolygon(_head, [godotBlue]); DrawPolyline(_mouth, white, _mouthWidth); - // Four circles for the 2 eyes: 2 white, 2 grey. + // Four circles for the 2 eyes: 2 white, 2 gray. DrawCircle(new Vector2(42.479f, 65.4825f), 9.3905f, white); DrawCircle(new Vector2(85.524f, 65.4825f), 9.3905f, white); - DrawCircle(new Vector2(43.423f, 65.92f), 6.246f, grey); - DrawCircle(new Vector2(84.626f, 66.008f), 6.246f, grey); + DrawCircle(new Vector2(43.423f, 65.92f), 6.246f, gray); + DrawCircle(new Vector2(84.626f, 66.008f), 6.246f, gray); } When executing it, you should have something like this: @@ -569,14 +569,14 @@ like this: func _draw(): var white : Color = Color.WHITE var godot_blue : Color = Color("478cbf") - var grey : Color = Color("414042") + var gray : Color = Color("414042") draw_polygon(head, [ godot_blue ]) draw_polyline(mouth, white, _mouth_width) draw_circle(Vector2(42.479, 65.4825), 9.3905, white) draw_circle(Vector2(85.524, 65.4825), 9.3905, white) - draw_circle(Vector2(43.423, 65.92), 6.246, grey) - draw_circle(Vector2(84.626, 66.008), 6.246, grey) + draw_circle(Vector2(43.423, 65.92), 6.246, gray) + draw_circle(Vector2(84.626, 66.008), 6.246, gray) # Draw a short but thick white vertical line for the nose. draw_line(Vector2(64.273, 60.564), Vector2(64.273, 74.349), white, 5.8) @@ -587,14 +587,14 @@ like this: { Color white = Colors.White; Color godotBlue = new Color("478cbf"); - Color grey = new Color("414042"); + Color gray = new Color("414042"); DrawPolygon(_head, [godotBlue]); DrawPolyline(_mouth, white, _mouthWidth); DrawCircle(new Vector2(42.479f, 65.4825f), 9.3905f, white); DrawCircle(new Vector2(85.524f, 65.4825f), 9.3905f, white); - DrawCircle(new Vector2(43.423f, 65.92f), 6.246f, grey); - DrawCircle(new Vector2(84.626f, 66.008f), 6.246f, grey); + DrawCircle(new Vector2(43.423f, 65.92f), 6.246f, gray); + DrawCircle(new Vector2(84.626f, 66.008f), 6.246f, gray); // Draw a short but thick white vertical line for the nose. DrawLine(new Vector2(64.273f, 60.564f), new Vector2(64.273f, 74.349f), @@ -628,14 +628,14 @@ to do it, like this: func _draw(): var white : Color = Color.WHITE var godot_blue : Color = Color("478cbf") - var grey : Color = Color("414042") + var gray : Color = Color("414042") draw_polygon(head, [ godot_blue ]) draw_polyline(mouth, white, _mouth_width) draw_circle(Vector2(42.479, 65.4825), 9.3905, white) draw_circle(Vector2(85.524, 65.4825), 9.3905, white) - draw_circle(Vector2(43.423, 65.92), 6.246, grey) - draw_circle(Vector2(84.626, 66.008), 6.246, grey) + draw_circle(Vector2(43.423, 65.92), 6.246, gray) + draw_circle(Vector2(84.626, 66.008), 6.246, gray) draw_line(Vector2(64.273, 60.564), Vector2(64.273, 74.349), white, 5.8) # Draw GODOT text below the logo with the default font, size 22. @@ -650,14 +650,14 @@ to do it, like this: { Color white = Colors.White; Color godotBlue = new Color("478cbf"); - Color grey = new Color("414042"); + Color gray = new Color("414042"); DrawPolygon(_head, [godotBlue]); DrawPolyline(_mouth, white, _mouthWidth); DrawCircle(new Vector2(42.479f, 65.4825f), 9.3905f, white); DrawCircle(new Vector2(85.524f, 65.4825f), 9.3905f, white); - DrawCircle(new Vector2(43.423f, 65.92f), 6.246f, grey); - DrawCircle(new Vector2(84.626f, 66.008f), 6.246f, grey); + DrawCircle(new Vector2(43.423f, 65.92f), 6.246f, gray); + DrawCircle(new Vector2(84.626f, 66.008f), 6.246f, gray); DrawLine(new Vector2(64.273f, 60.564f), new Vector2(64.273f, 74.349f), white, 5.8f); diff --git a/tutorials/3d/physical_light_and_camera_units.rst b/tutorials/3d/physical_light_and_camera_units.rst index 1d590d4919a..f4f7ffffd3e 100644 --- a/tutorials/3d/physical_light_and_camera_units.rst +++ b/tutorials/3d/physical_light_and_camera_units.rst @@ -185,9 +185,9 @@ A candle is about 13 lumens, while a streetlight can be approximately 60000 lume **DirectionalLight3D intensity** -Lux is a measure pf luminous flux per unit area, it is equal to one lumen per -square metre. Lux is the measure of how much light hits a surface at a given -time. +Lux is a measure pf luminous flux per unit area +and it is the measure of how much light hits a surface at a given time. +It is equal to one lumen per square meter. With DirectionalLight3D, on a clear sunny day, a surface in direct sunlight may receive approximately 100000 lux. A typical room in a home may receive diff --git a/tutorials/i18n/internationalizing_games.rst b/tutorials/i18n/internationalizing_games.rst index 774bdc52dc5..9bb6e5abe44 100644 --- a/tutorials/i18n/internationalizing_games.rst +++ b/tutorials/i18n/internationalizing_games.rst @@ -100,10 +100,14 @@ information. Why locales exist can be illustrated through the USA and Great Britain. Both speak the same language (English), yet differ in many aspects: +.. codespell:ignore-begin grey metres + - Spelling: e.g. gray (USA), grey (GB) - Use of words: e.g. eggplant (USA), aubergine (GB) - Units or currencies: e.g. feet/inches (USA), metres/cm (GB) +.. codespell:ignore-end + It can get more complex however. Imagine you offer different content in Europe and in China (e.g. in an MMO). You will need to translate each of those content variations into many languages and store and load them accordingly. diff --git a/tutorials/migrating/upgrading_to_godot_4.5.rst b/tutorials/migrating/upgrading_to_godot_4.5.rst index 824fb46608b..97e8aa61d52 100644 --- a/tutorials/migrating/upgrading_to_godot_4.5.rst +++ b/tutorials/migrating/upgrading_to_godot_4.5.rst @@ -258,14 +258,14 @@ Navigation .. note:: - By default, the regions in a NavigationServer map now update asynchronously using threads to improve performance. - This can cause additional delay in the update due to thread synchronisation. + By default, the regions in a NavigationServer map update asynchronously using threads to improve performance. + This can cause additional delay in the update due to thread synchronization. The asynchronous region update can be toggled with the ``navigation/world/region_use_async_iterations`` project setting. .. note:: The merging of navmeshes in the NavigationServer has changed processing order. Regions now merge and cache internal navmeshes first, then the remaining free edges are merged by the navigation map. - If a project had navigation map synchronisation errors before, it might now have shifted + If a project had navigation map synchronization errors before, it might now have shifted affected edges, making already existing errors in a layout more noticeable in the pathfinding. The ``navigation/2d_or_3d/merge_rasterizer_cell_scale`` project setting can be set to a lower value to increase the detail of the rasterization grid (with `0.01` being the smallest cell size possible). diff --git a/tutorials/navigation/navigation_using_navigationagents.rst b/tutorials/navigation/navigation_using_navigationagents.rst index 248a03ac4ba..5257b7d6da2 100644 --- a/tutorials/navigation/navigation_using_navigationagents.rst +++ b/tutorials/navigation/navigation_using_navigationagents.rst @@ -79,7 +79,7 @@ Pathfollowing common problems There are some common user problems and important caveats to consider when writing agent movement scripts. - The path is returned empty - If an agent queries a path before the navigation map synchronisation, e.g. in a ``_ready()`` function, the path might return empty. In this case the ``get_next_path_position()`` function will return the same position as the agent parent node and the agent will consider the path end reached. This is fixed by making a deferred call or using a callback e.g. waiting for the navigation map changed signal. + If an agent queries a path before the navigation map synchronization, e.g. in a ``_ready()`` function, the path might return empty. In this case the ``get_next_path_position()`` function will return the same position as the agent parent node and the agent will consider the path end reached. This is fixed by making a deferred call or using a callback e.g. waiting for the navigation map changed signal. - The agent is stuck dancing between two positions This is usually caused by very frequent path updates every single frame, either deliberate or by accident (e.g. max path distance set too short). The pathfinding needs to find the closest position that are valid on navigation mesh. If a new path is requested every single frame the first path positions might end up switching constantly in front and behind the agent's current position, causing it to dance between the two positions. diff --git a/tutorials/networking/http_request_class.rst b/tutorials/networking/http_request_class.rst index 4bbc2854d55..5fbdebd3803 100644 --- a/tutorials/networking/http_request_class.rst +++ b/tutorials/networking/http_request_class.rst @@ -145,7 +145,8 @@ For example, to set a custom user agent (the HTTP ``User-Agent`` header) you cou .. danger:: - Be aware that someone might analyse and decompile your released application and - thus may gain access to any embedded authorization information like tokens, usernames or passwords. + Be aware that someone might analyze and decompile your released application and + thus may gain access to any embedded authorization information like tokens, usernames, or passwords. That means it is usually not a good idea to embed things such as database - access credentials inside your game. Avoid providing information useful to an attacker whenever possible. + access credentials inside your game. + Avoid providing information useful to an attacker whenever possible. diff --git a/tutorials/performance/cpu_optimization.rst b/tutorials/performance/cpu_optimization.rst index 4852472208e..8309d38e9db 100644 --- a/tutorials/performance/cpu_optimization.rst +++ b/tutorials/performance/cpu_optimization.rst @@ -147,9 +147,9 @@ Understanding caching is also crucial to CPU optimization. If you have an algorithm (routine) that loads small bits of data from randomly spread out areas of main memory, this can result in a lot of cache misses, a lot of the time, the CPU will be waiting around for data instead of doing any work. Instead, if you -can make your data accesses localised, or even better, access memory in a linear -fashion (like a continuous list), then the cache will work optimally and the CPU -will be able to work as fast as possible. +can make your data accesses localized, or even better, access memory in a linear +fashion (like a continuous list), then the cache, and therefore the CPU, +will be able to work as efficiently as possible. Godot usually takes care of such low-level details for you. For example, the Server APIs make sure data is optimized for caching already for things like diff --git a/tutorials/performance/optimizing_3d_performance.rst b/tutorials/performance/optimizing_3d_performance.rst index 11a4485e775..223ecf43bfa 100644 --- a/tutorials/performance/optimizing_3d_performance.rst +++ b/tutorials/performance/optimizing_3d_performance.rst @@ -175,9 +175,9 @@ Large worlds may need to be built in tiles that can be loaded on demand as you move around the world. This can prevent memory use from getting out of hand, and also limit the processing needed to the local area. -There may also be rendering and physics glitches due to floating point error in +There may also be rendering and physics bugs due to floating-point errors in large worlds. This can be resolved using :ref:`doc_large_world_coordinates`. -If using large world coordinates is not an option, you may be able to use techniques -such as orienting the world around the player (rather than the other way -around), or shifting the origin periodically to keep things centred around +If using large world coordinates is not an option, other common techniques include +orienting the world around the player (rather than the other way +around), or shifting the origin periodically to keep things centered around ``Vector3(0, 0, 0)``. diff --git a/tutorials/performance/pipeline_compilations.rst b/tutorials/performance/pipeline_compilations.rst index f80d265f1c6..5b29dbf5b3a 100644 --- a/tutorials/performance/pipeline_compilations.rst +++ b/tutorials/performance/pipeline_compilations.rst @@ -165,8 +165,8 @@ the changes are applied. a time to perform precompilation. - **Reflection Probes**: Enabled when a ReflectionProbe node is placed on the scene. -- **Separate Specular**: Enabled when using effects like sub-surface scattering - or a compositor effect that relies on sampling the specularity directly off +- **Separate Specular**: Enabled when using effects like subsurface scattering + or a compositor effect that relies on sampling the specularity directly from the screen. - **Motion Vectors**: Enabled when using effects such as TAA, FSR2 or a compositor effect that requires motion vectors (such as motion blur). diff --git a/tutorials/physics/interpolation/physics_interpolation_introduction.rst b/tutorials/physics/interpolation/physics_interpolation_introduction.rst index 5a9d6c2811c..001c971651f 100644 --- a/tutorials/physics/interpolation/physics_interpolation_introduction.rst +++ b/tutorials/physics/interpolation/physics_interpolation_introduction.rst @@ -113,10 +113,11 @@ Let us consider only the position, and a situation where we know that the previo physics tick X coordinate was 10 units, and the current physics tick X coordinate is 30 units. -.. note:: Although the maths is explained here, you do not have to worry about the - details, as this step will be performed for you. Under the hood, Godot - may use more complex forms of interpolation, but linear interpolation is - the easiest in terms of explanation. +.. note:: + + Do not worry too much about the math, as the engine can mostly take care of it. + Although linear interpolation is described here for simplicity, + Godot itself may use different, more complex forms of interpolation. The physics interpolation fraction ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -200,7 +201,7 @@ Why look into the past? Why not predict the future? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is an alternative to this scheme, which is: instead of interpolating between -the previous and current tick, we use maths to *extrapolate* into the future. We +the previous and current tick, we use math to *extrapolate* into the future. We try to predict where the object *will be*, rather than show it where it was. This can be done and may be offered as an option in future, but there are some significant downsides: diff --git a/tutorials/physics/interpolation/using_physics_interpolation.rst b/tutorials/physics/interpolation/using_physics_interpolation.rst index ac3cdff9316..bfe6e4adf90 100644 --- a/tutorials/physics/interpolation/using_physics_interpolation.rst +++ b/tutorials/physics/interpolation/using_physics_interpolation.rst @@ -87,7 +87,7 @@ As a rough guide: "Better CPU performance","Good physics behavior in complex scenes","Good with fast physics" "Add some delay to input","Good for first person games","Good for racing games" - "Simple physics behaviour" + "Simple physics behavior" .. note:: You can always change the tick rate as you develop, it is as simple as changing the project setting. diff --git a/tutorials/rendering/renderers.rst b/tutorials/rendering/renderers.rst index b0deb1c1998..7258beef634 100644 --- a/tutorials/rendering/renderers.rst +++ b/tutorials/rendering/renderers.rst @@ -319,7 +319,7 @@ See :ref:`doc_standard_material_3d` for more information. +-------------------------+--------------------------+--------------------------+--------------------------+ | Feature | Compatibility | Mobile | Forward+ | +=========================+==========================+==========================+==========================+ -| Sub-surface scattering | ❌ Not supported. | ❌ Not supported. | ✔️ Supported. | +| Subsurface scattering | ❌ Not supported. | ❌ Not supported. | ✔️ Supported. | | | | | | +-------------------------+--------------------------+--------------------------+--------------------------+ diff --git a/tutorials/scripting/gdscript/gdscript_basics.rst b/tutorials/scripting/gdscript/gdscript_basics.rst index e6ad7396376..b46a0a0e1ae 100644 --- a/tutorials/scripting/gdscript/gdscript_basics.rst +++ b/tutorials/scripting/gdscript/gdscript_basics.rst @@ -2844,7 +2844,7 @@ In this case, the ``wait_confirmation`` becomes a coroutine, which means that th if confirmed: print("User confirmed") else: - print("User cancelled") + print("User canceled") Note that requesting a coroutine's return value without ``await`` will trigger an error: diff --git a/tutorials/shaders/using_viewport_as_texture.rst b/tutorials/shaders/using_viewport_as_texture.rst index 0d53bff1bdd..342c189bf3c 100644 --- a/tutorials/shaders/using_viewport_as_texture.rst +++ b/tutorials/shaders/using_viewport_as_texture.rst @@ -186,7 +186,9 @@ to make the planet. We will be using this noise function directly from a `Shader dot(hash(i + vec3(1.0, 1.0, 1.0)), f - vec3(1.0, 1.0, 1.0)), u.x), u.y), u.z ); } -.. note:: All credit goes to the author, Inigo Quilez. It is published under the ``MIT`` licence. +.. note:: + + All credit goes to the author, Inigo Quilez. It is published under the ``MIT`` license. Now to use ``noise``, add the following to the ``fragment`` function: diff --git a/tutorials/ui/gui_using_theme_editor.rst b/tutorials/ui/gui_using_theme_editor.rst index 1695b22ab5e..dab5a9d2975 100644 --- a/tutorials/ui/gui_using_theme_editor.rst +++ b/tutorials/ui/gui_using_theme_editor.rst @@ -88,7 +88,7 @@ The right-hand side of the theme editor provides a list of theme types available in the edited theme resource, and the contents of the selected type. The list of type's items is divided into several tabs, corresponding to each data type available in the theme (colors, constants, styles, etc.). If the **Show Default** option is -enabled, then for each built-in type its default theme values are displayed, greyed +enabled, then for each built-in type its default theme values are displayed, grayed out. If the option is disabled, only the items available in the edited theme itself are displayed. diff --git a/tutorials/xr/a_better_xr_start_script.rst b/tutorials/xr/a_better_xr_start_script.rst index 22d9051b3ae..62991ea675d 100644 --- a/tutorials/xr/a_better_xr_start_script.rst +++ b/tutorials/xr/a_better_xr_start_script.rst @@ -3,7 +3,7 @@ A better XR start script ======================== -In :ref:`doc_setting_up_xr` we introduced a startup script that initialises our setup which we used as our script on our main node. +In :ref:`doc_setting_up_xr` we introduced a startup script that initializes our setup which we used as our script on our main node. This script performs the minimum steps required for any given interface. When using OpenXR there are a number of improvements we should do here. @@ -103,7 +103,7 @@ See :ref:`OpenXR Settings ` for further details. We hook up a number of signals that will be emitted by the :ref:`XRInterface `. We'll provide more detail about these signals as we implement them. -We also quit our application if we couldn't successfully initialise OpenXR. +We also quit our application if we couldn't successfully initialize OpenXR. Now this can be a choice. If you are making a mixed mode game you setup the VR mode of your game on success, and setup the non-VR mode of your game on failure. diff --git a/tutorials/xr/openxr_settings.rst b/tutorials/xr/openxr_settings.rst index db6e1a2b91f..8834a6531a6 100644 --- a/tutorials/xr/openxr_settings.rst +++ b/tutorials/xr/openxr_settings.rst @@ -36,7 +36,7 @@ This specifies whether your game is designed for: - ``Head Mounted`` devices such as a Meta Quest, Valve Index, or Magic Leap, - ``Handheld`` devices such as phones. -If the device on which you run your game does not match the selection here, OpenXR will fail to initialise. +If the device on which you run your game does not match the selection here, OpenXR will fail to initialize. View Configuration ~~~~~~~~~~~~~~~~~~ @@ -46,7 +46,7 @@ This specifies the view configuration your game is designed for: - ``Mono``, your game provides a single image output. E.g. phone based AR; - ``Stereo``, your game provides stereo image output. E.g. head mounted devices. -If the device on which you run your game does not match the selection here, OpenXR will fail to initialise. +If the device on which you run your game does not match the selection here, OpenXR will fail to initialize. .. note:: OpenXR has additional view configurations for very specific devices that Godot doesn't support yet. @@ -252,7 +252,7 @@ Hand Tracking ~~~~~~~~~~~~~ This enables the hand tracking extension when supported by the device used. This is on by default for legacy reasons. -The hand tracking extension provides access to data that allows you to visualise the user's hands with correct finger positions. +The hand tracking extension provides access to data that allows you to visualize the user's hands with correct finger positions. Depending on platform capabilities the hand tracking data can be inferred from controller inputs, come from data gloves, come from optical hand tracking sensors or any other applicable source. diff --git a/tutorials/xr/openxr_spatial_entities.rst b/tutorials/xr/openxr_spatial_entities.rst index 30eebca7125..620aa73fe2a 100644 --- a/tutorials/xr/openxr_spatial_entities.rst +++ b/tutorials/xr/openxr_spatial_entities.rst @@ -611,7 +611,7 @@ Spatial entity core The core spatial entity functionality is exposed through the :ref:`OpenXRSpatialEntityExtension` singleton. -Specific logic is exposed through capabilities that introduce specialised component types, +Specific logic is exposed through capabilities that introduce specialized component types, and give access to specific types of entities, however they all use the same mechanisms for accessing the entity data managed by the spatial entity system. diff --git a/tutorials/xr/setting_up_xr.rst b/tutorials/xr/setting_up_xr.rst index 3e204f593f6..d83ee6b8542 100644 --- a/tutorials/xr/setting_up_xr.rst +++ b/tutorials/xr/setting_up_xr.rst @@ -153,7 +153,7 @@ Next we need to add a script to our root node. Add the following code into this If you run your project at this point in time, everything will work but you will be in a dark world. So to finish off our starting point add a :ref:`DirectionalLight3D ` and a :ref:`WorldEnvironment ` node to your scene. -You may wish to also add a mesh instance as a child to each controller node just to temporarily visualise them. +You may wish to also add a mesh instance as a child to each controller node just to temporarily visualize them. Make sure you configure a sky in your world environment. Now run your project, you should be floating somewhere in space and be able to look around. diff --git a/tutorials/xr/xr_action_map.rst b/tutorials/xr/xr_action_map.rst index ef1cc0bec95..757fbc60920 100644 --- a/tutorials/xr/xr_action_map.rst +++ b/tutorials/xr/xr_action_map.rst @@ -171,7 +171,7 @@ Actions can be used for both input and output and each action has a type that de its behavior. * The ``Bool`` type is used for discrete input like buttons. -* The ``Float`` type is used for analogue input like triggers. +* The ``Float`` type is used for analog input like triggers. These two are special as they are the only ones that are interchangeable. OpenXR will handle conversions between ``Bool`` and ``Float`` inputs and actions. @@ -180,7 +180,8 @@ your :ref:`XRController3D ` node. It emits the ``input_float_changed`` signal when changed. .. note:: - Where analogue inputs are queried as buttons a threshold is applied. + + Where analog inputs are queried as buttons a threshold is applied. This threshold is currently managed exclusively by the XR runtime. There are plans to extend Godot to provide some level of control over these thresholds in the future. @@ -282,13 +283,13 @@ The appropriate :ref:`XRController3D ` node will emit the .. warning:: For both grab and shoot we've used the ``Bool`` type. - As mentioned before, OpenXR does automatic conversions from an analogue controls + As mentioned before, OpenXR does automatic conversions from an analog control however not all XR Runtimes currently apply sensible thresholds. We recommend as a workaround to use the ``Float`` type when interacting with triggers and grip buttons and apply your own threshold. - For buttons like A/B/X/Y and similar where there is no analogue option, the ``Bool`` + For buttons like A/B/X/Y and similar where there is no analog option, the ``Bool`` type works fine. .. note:: @@ -383,7 +384,7 @@ If all else fails, it will check the generic :ref:`"Simple controller"