Merge pull request #10977 from godotengine/4.4

Update stable

.github/workflows/check_urls.yml

@@ -1,12 +1,10 @@
 name: 🌐 Check URLs
 on:
-  push:
-  pull_request:
   schedule:
-    # Every day at 18:00 UTC.
+    # Every Friday at 16:27 UTC.
     # URLs can decay over time. Setting up a schedule makes it possible to be warned
     # about dead links as soon as possible.
-    - cron: "0 18 * * *"
+    - cron: "27 16 * * FRI"
 
 jobs:
   check-urls:

.lycheeignore

@@ -12,6 +12,8 @@ tcp:\/\/.*
 .*asecuritysite\.com.*
 .*intel\.com.*
 .*reddit\.com.*
+.*inkscape.org.*
+.*computerhope.com*
 
 # Don't check URLs from these websites due to frequent rate limits (error 429) or timeouts.
 .*adobe\.com.*

about/release_policy.rst

@@ -209,9 +209,9 @@ When is the next release out?
 While Godot contributors aren't working under any deadlines, we strive to
 publish minor releases relatively frequently.
 
-In particular, after the very length release cycle for 4.0, we are pivoting to
-a faster paced development workflow, 4.1 released 4 months after 4.0, and 4.2
-released 4 months after 4.1
+In particular, after the very long release cycle for 4.0, we are pivoting to
+a faster-paced development workflow, 4.1 released 4 months after 4.0, and 4.2
+released 4 months after 4.1.
 
 Frequent minor releases will enable us to ship new features faster (possibly
 as experimental), get user feedback quickly, and iterate to improve those

community/tutorials.rst

@@ -33,6 +33,7 @@ Text tutorials
 - `GDScript website by Andrew Wilkes <https://gdscript.com>`__
 - `Godot Recipes by KidsCanCode <https://kidscancode.org/godot_recipes/4.x/>`__
 - `Godot Tutorials by SomethingLikeGames <https://www.somethinglikegames.de/en/tags/godot-engine/>`__
+- `GameDev Academy by Zenva <https://gamedevacademy.org/category/godot-tutorials/godot-4/>`__
 - `Game Dev Artisan website <https://gamedevartisan.com/>`__
 - `Night Quest Games Blog <https://www.nightquestgames.com/blog-articles/>`__
 

contributing/development/configuring_an_ide/visual_studio.rst

@@ -8,6 +8,12 @@ by `Microsoft <https://microsoft.com>`_ that's free for individual use or non-co
 It has many useful features, such as memory view, performance view, source
 control and more.
 
+.. note::
+
+    This documentation is for contributions to the game engine, and not using
+    Visual Studio as a C# editor. To code C# in an external editor, see
+    :ref:`the C# guide to configure an external editor <doc_c_sharp_setup_external_editor>`.
+
 Importing the project
 ---------------------
 

contributing/development/configuring_an_ide/visual_studio_code.rst

@@ -3,6 +3,12 @@
 Visual Studio Code
 ==================
 
+.. note::
+
+    This documentation is for contributions to the game engine, and not using
+    Visual Studio Code as a C# or GDScript editor. To code C# or GDScript in an external editor, see
+    :ref:`the C# guide to configure an external editor <doc_c_sharp_setup_external_editor>`.
+
 `Visual Studio Code <https://code.visualstudio.com>`_ is a free cross-platform code editor
 by `Microsoft <https://microsoft.com>`_ (not to be confused with :ref:`doc_configuring_an_ide_vs`).
 

contributing/development/core_and_modules/internal_rendering_architecture.rst

@@ -426,13 +426,7 @@ release.
 2D light rendering is performed in a single pass to allow for better performance
 with large amounts of lights.
 
-.. UPDATE: Planned feature. When Forward+ and Mobile feature 2D batching,
-.. update this.
-
-The Forward+ and Mobile rendering methods don't feature 2D batching yet, but
-it's planned for a future release.
-
-The Compatibility renderer features 2D batching to improve performance, which is
+All rendering methods feature 2D batching to improve performance, which is
 especially noticeable with lots of text on screen.
 
 MSAA can be enabled in 2D to provide "automatic" line and polygon antialiasing,
@@ -456,9 +450,10 @@ used to calculate particle collisions in 2D.
 Batching and instancing
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-In the Forward+ renderer, Vulkan instancing is used to group rendering
-of identical objects for performance. This is not as fast as static mesh
-merging, but it still allows instances to be culled individually.
+In the Forward+ renderer, Vulkan instancing is used to group rendering of
+identical opaque or alpha-tested objects for performance. (Alpha-blended objects
+are never instanced.) This is not as fast as static mesh merging, but it still
+allows instances to be culled individually.
 
 Light, decal and reflection probe rendering
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

contributing/development/core_and_modules/unit_testing.rst

@@ -4,7 +4,7 @@ Unit testing
 ============
 
 Godot Engine allows to write unit tests directly in C++. The engine integrates
-the `doctest <https://github.com/onqtam/doctest>`_ unit testing framework which
+the `doctest <https://github.com/doctest/doctest>`_ unit testing framework which
 gives ability to write test suites and test cases next to production code, but
 since the tests in Godot go through a different ``main`` entry point, the tests
 reside in a dedicated ``tests/`` directory instead, which is located at the root
@@ -208,7 +208,7 @@ for more complex ones if you think that it deserves a better explanation.
 
 .. seealso::
 
-    `doctest: Assertion macros <https://github.com/onqtam/doctest/blob/master/doc/markdown/assertions.md>`_.
+    `doctest: Assertion macros <https://github.com/doctest/doctest/blob/master/doc/markdown/assertions.md>`_.
 
 Logging
 ~~~~~~~
@@ -236,7 +236,7 @@ output can be redirected to an XML file:
 
 .. seealso::
 
-    `doctest: Logging macros <https://github.com/onqtam/doctest/blob/master/doc/markdown/logging.md>`_.
+    `doctest: Logging macros <https://github.com/doctest/doctest/blob/master/doc/markdown/logging.md>`_.
 
 Testing failure paths
 ~~~~~~~~~~~~~~~~~~~~~

contributing/development/editor/creating_icons.rst

@@ -38,7 +38,7 @@ Color conversion for light editor themes
 
 If the user has configured their editor to use a light theme, Godot will
 convert the icon's colors based on a
-`set of predefined color mappings <https://github.com/godotengine/godot/blob/4.0.2-stable/editor/editor_themes.cpp#L60-L160>`__.
+`set of predefined color mappings <https://github.com/godotengine/godot/blob/master/editor/themes/editor_color_map.cpp>`__.
 This is to ensure the icon always displays with a sufficient contrast rate.
 Try to restrict your icon's color palette to colors found in the list above.
 Otherwise, your icon may become difficult to read on a light background.

contributing/documentation/docs_contribution_checklist.rst

@@ -0,0 +1,71 @@
+.. _docs_contribution_checklist:
+
+Documentation contribution checklist
+====================================
+
+This page is a summary of the guidelines to follow when contributing to the
+documentation. Before you press that **Create pull request** button on GitHub,
+read over this list to double check if you missed anything.
+
+You don't need to read all the guidelines here in order to start contributing.
+If you do miss something, it will be pointed out during review. However,
+following the guidelines you are aware of as best you can will help speed up the
+review process.
+
+Writing style
+-------------
+
+:ref:`See here. <doc_docs_writing_guidelines_clear_english_rules>`
+
+- Use the active voice.
+- Use precise action verbs.
+- Avoid verbs that end in -ing.
+- Remove unnecessary adverbs and adjectives.
+- Ban these 8 words: obvious, simple, basic, easy, actual, just, clear, and however.
+- Use explicit references.
+- Use 's to show possession.
+- Use the Oxford comma.
+
+Code examples
+-------------
+
+- Use dynamic typing. :ref:`See here. <doc_docs_writing_guidelines_dynamic_typing>`
+- Use real, practical examples. Avoid ``foo`` / ``bar`` examples. :ref:`See here. <doc_docs_writing_guidelines_real_world_code_example>`
+
+Manual style and formatting
+---------------------------
+
+- Use common vocabulary for the editor interface. :ref:`See here. <doc_docs_writing_guidelines_common_vocabulary>`
+- Use ``:kbd:`` for keyboard shortcuts. :ref:`See here. <doc_docs_writing_guidelines_keyboard_shortcuts>`
+- Literals use ``code style``. :ref:`See here. <doc_docs_writing_guidelines_literals>`
+- Classes link to the class reference once, then use ``ClassName`` for the rest
+  of the page.
+  Methods and properties link to the class ref once, then use ``PropertyName``
+  for the rest of the page. :ref:`See here. <doc_docs_writing_guidelines_class_properties_methods>`
+- Editor UI, like menus, windows, and editor navigation paths, use
+  ``Bold Style``. :ref:`See here. <doc_docs_writing_guidelines_editor_ui>`
+- Link to project settings when referencing them. :ref:`See here. <doc_docs_writing_guidelines_project_settings>`
+- Text is manually wrapped to 80-100 characters. :ref:`See here. <doc_docs_writing_guidelines_manually_wrapping_lines>`
+- No trailing whitespace at the end of lines.
+- Most of the time, avoid mentioning a specific Godot version. :ref:`See here. <doc_docs_writing_guidelines_specific_version>`
+
+Images and videos
+-----------------
+
+- New (and updated) images are in WebP format. :ref:`See here. <doc_docs_image_guidelines_format_conversion>`
+- Editor screenshots are cropped. :ref:`See here. <doc_docs_image_guidelines_cropping>`
+- Images larger than 1080p or 300kb are scaled down. :ref:`See here. <doc_docs_image_guidelines_scaling_down>`
+- Outlines in images use ``fffb44`` yellow. :ref:`See here. <doc_docs_image_guidelines_outlines>`
+- Videos use the ``:autoplay:``, ``:loop:``, and ``:muted:`` tags. :ref:`See here. <doc_docs_image_guidelines_videos>`
+
+GitHub
+------
+
+- The PR title starts with a word like ``Fix``, ``Add``, ``Update``,
+  ``Clarify``, or ``Improve``.
+- If the PR closes an issue, link to the issue with one of GitHub's 
+  `keywords <https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests>`__:
+  ``closes``, ``fixes``, or ``resolves``, in the text of the PR.
+- Ideally, PR contains a single commit. However, multiple commits can be
+  :ref:`squashed <doc_pr_workflow_rebase>` later.
+

contributing/documentation/docs_image_guidelines.rst

@@ -36,6 +36,8 @@ dramatically increases file size. If you're taking screenshots on a higher
 resolution screen the screenshot should be scaled down. There are instructions
 on how to do this later on this page.
 
+.. _doc_docs_image_guidelines_format_conversion:
+
 Format conversion
 ~~~~~~~~~~~~~~~~~
 
@@ -59,6 +61,8 @@ it may have the ability to open an image then save it as a WebP file.
     GIFs should be avoided. Their compression is inefficient and they only support
     a 256-color palette with 1-bit transparency.
 
+.. _doc_docs_image_guidelines_cropping:
+
 Cropping
 ~~~~~~~~
 
@@ -94,6 +98,8 @@ If you make a mistake and overcrop don't worry, cropping is non-destructive in
 Krita and can be adjusted. Click on the image with your cropping tool still selected
 and the controls will return.
 
+.. _doc_docs_image_guidelines_scaling_down:
+
 Scaling down an image
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -119,6 +125,8 @@ If it's still over 300KB change to lossy compression and slowly increase the com
 300KB. If this results in noticeable compression artifacts using less compression is fine, even if the file
 size is bigger.
 
+.. _doc_docs_image_guidelines_outlines:
+
 Outlines, arrows and text
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -160,6 +168,8 @@ Where ``documentation_image.webp`` would be changed to the name of the image you
 created. Name your images in a way that makes their meaning clear, possibly with
 a prefix that makes their relationship to a documentation page explicit.
 
+.. _doc_docs_image_guidelines_videos:
+
 Videos
 ------
 

contributing/documentation/docs_writing_guidelines.rst

@@ -37,6 +37,8 @@ There are 3 rules to describe classes:
     See the :ref:`content guidelines <doc_content_guidelines>` for information
     on the types of documentation you can write in the official documentation.
 
+.. _doc_docs_writing_guidelines_clear_english_rules:
+
 7 rules for clear English
 -------------------------
 
@@ -283,6 +285,8 @@ element of a list with more than two elements.
 How to write methods and classes
 --------------------------------
 
+.. _doc_docs_writing_guidelines_dynamic_typing:
+
 Dynamic vs static typing
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -335,6 +339,8 @@ The exception is topics that explain static typing concepts to users.
         var choice = randi() % size
         return arguments[choice]
 
+.. _doc_docs_writing_guidelines_real_world_code_example:
+
 Use real-world code examples where appropriate
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -452,6 +458,7 @@ documentation and in Godot, it will display like ``this``. When you edit XML
 files in the Godot repository, replace existing arguments written like 'this' or
 \`this\` with ``[code]this[/code]``.
 
+.. _doc_docs_writing_guidelines_common_vocabulary:
 
 Common vocabulary to use in Godot's documentation
 -------------------------------------------------
@@ -487,6 +494,8 @@ class names, which you can't fold, are ``Classes`` e.g. the
 ``properties``. E.g. ``position`` or ``modulate color`` are both
 ``properties``.
 
+.. _doc_docs_writing_guidelines_keyboard_shortcuts:
+
 Keyboard shortcut guidelines
 ----------------------------
 
@@ -507,6 +516,7 @@ examples with the ``:kbd:`` tag left as-is for better visibility:
 - Press ``:kbd:`Space``` and hold the left mouse button to pan in the 2D editor.
 - Press ``:kbd:`Shift + Up Arrow``` to move the node upwards by 8 pixels.
 
+.. _doc_docs_writing_guidelines_manual_style:
 
 Manual style guidelines
 -----------------------
@@ -567,6 +577,8 @@ is fine too.
     - Godot uses *nodes* with *scripts* in a *scene tree*.
     - Godot uses **nodes** with **scripts** in a **scene tree**.
 
+.. _doc_docs_writing_guidelines_literals:
+
 Literals
 ~~~~~~~~
 
@@ -576,6 +588,8 @@ Use ``code style`` for literal values. Literals include:
     - Float literals like ``0.0``, ``0.5``, ``-2.0``, or ``100.0``
     - Vector literals like ``(0.0, 0.0)``, ``(0.5, -0.5, 0.5)``, or ``(1.0, 2.0, 3.0, 4.0)``.
 
+.. _doc_docs_writing_guidelines_class_properties_methods:
+
 Classes, properties, and methods
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -591,6 +605,8 @@ link.
 When discussing properties in the context of the inspector, use **bold style**
 instead.
 
+.. _doc_docs_writing_guidelines_editor_ui:
+
 Editor UI
 ~~~~~~~~~
 
@@ -613,6 +629,8 @@ reader must navigate. Use ``>`` as a separator. You can omit ellipses in menu na
 .. note:: Sometimes, ``->`` or ``→`` is used as a separator. This is nonstandard.
     Replace it with ``>`` if you are already making changes to a section.
 
+.. _doc_docs_writing_guidelines_project_settings:
+
 Project settings
 ~~~~~~~~~~~~~~~~
 
@@ -625,6 +643,8 @@ rendered, prefer splitting the setting name and the section when the link is lon
     - In the project settings under **Application > Run**, set :ref:`Max FPS<class_ProjectSettings_property_application/run/max_fps>` to ``60``.
     - In **Project Settings > Application > Run**, set :ref:`Max FPS<class_ProjectSettings_property_application/run/max_fps>` to ``60``.
 
+.. _doc_docs_writing_guidelines_manually_wrapping_lines:
+
 Manually wrapping lines
 ~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -710,6 +730,8 @@ See the `Sphinx documentation <https://www.sphinx-doc.org/en/master/usage/restru
 and the `reStructuredText documentation <https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#sections>`__
 for more information.
 
+.. _doc_docs_writing_guidelines_specific_version:
+
 When to refer to a specific Godot version
 -----------------------------------------
 

contributing/documentation/index.rst

@@ -25,6 +25,7 @@ documentation.
    content_guidelines
    docs_writing_guidelines
    docs_image_guidelines
+   docs_contribution_checklist
 
 Writing the manual
 ------------------

contributing/workflow/bug_triage_guidelines.rst

@@ -12,24 +12,33 @@ hesitate to propose modifications to the following guidelines.
 Issues management
 -----------------
 
-GitHub proposes various features to manage issues:
+For issue management, we use the following GitHub processes:
 
--  Set one or several labels from a predefined list
--  Set one milestone from a predefined list
--  Keep track of the issue in the project dashboard
--  Define one contributor as "assignee" among the Godot engine
-   organization members
+- Each issue and pull request (PR) is categorized with a set of *labels*,
+  sometimes called "tags".
+- Each PR is assigned to a *milestone*. Some issues can also be assigned to a
+  *milestone* (see below).
+- Issues can have an *assignee*, who is a contributor among Godot maintainers.
+- Issues can be put in one or more *projects*.
+- PRs can be *linked* to one or more issues which they "fix" or "close".
 
-As the Godot engine organization on GitHub currently has a restricted
-number of contributors, we do not use assignees extensively for now. All
-contributors are welcome to take on any issue, if relevant after mentioning
-it on the issue ticket and/or discussing the best way to resolve it with
-other developers.
+We don't yet extensively use or rely on some other GitHub processes:
 
-For the time being, we do not use the project dashboard feature either.
+- Issue close reasons (completed, not planned, duplicate). While we use these,
+  it is not consistent, and older issues are all closed as "completed", so the
+  issue close reason should not be relied on.
+- Issue *types* (Bug, Feature, Task).
+- Issue *relationships*.
 
-As far as possible, we try to assign labels (and milestones, when relevant)
-to both issues and pull requests.
+We only use the assignees feature for Godot maintainers who are members of the
+Godot Engine GitHub organization, and even then not in all cases. For other
+issues, we track who is working on an issue by comments on the issue and linked
+pull requests. Most issues are available for any contributor to take on, after
+discussing it with other contributors. If you would like to work on an issue,
+first check that no one else is working on it, by looking for a linked pull
+request, a comment "claiming" the issue, or an assignee. If no one else is
+working on the issue, leave a comment on the issue to "claim" it and start
+working on it.
 
 Labels
 ~~~~~~
@@ -37,10 +46,20 @@ Labels
 The following `labels <https://github.com/godotengine/godot/labels>`__ are
 currently defined in the Godot repository:
 
-**Categories:**
+Categories:
+^^^^^^^^^^^
 
--  *Archived*: either a duplicate of another issue, or invalid. Such an
-   issue would also be closed.
+-  *Archived*: used to filter issues closed with a resolution other than "fixed".
+
+   - For issues, added to all issues that are not resolved by engine or
+     documentation changes. This includes duplicate issues, user error, or
+     reports in the wrong repository.
+     Since we don't rely on GitHub's issue close reasons (``completed``, ``not
+     planned``, and ``duplicate``), it is possible for an issue to be closed as
+     ``completed`` with the *Archived* label.
+   - For PRs, added to all closed PRs that are not merged. This includes superseded
+     or duplicate PRs, Git or GitHub mistakes, and valid PRs that end up not merged. 
+   
 -  *Breaks compat*: describes something that can only be fixed by breaking
    compatibility with existing projects.
 -  *Bug*: describes something that is not working properly.
@@ -66,12 +85,11 @@ currently defined in the Godot repository:
    should be filed on the `godot-docs <https://github.com/godotengine/godot-docs>`_ repository.
 -  *Enhancement*: describes a proposed enhancement to an existing
    functionality.
--  *Feature proposal*: describes a wish for a new feature to be
-   implemented. Note that the main Godot repository no longer accepts
-   feature requests. Please use
-   `godot-proposals <https://github.com/godotengine/godot-proposals>`__ instead.
-   PRs which add new features but do not have a corresponding proposal use this
-   label.
+-  *Feature proposal*: used for PRs adding new features which do not have a
+   corresponding proposal use this label. The label is removed when a feature
+   proposal is created and linked. The main Godot repository no longer accepts
+   feature requests as issues. Please use the `godot-proposals
+   <https://github.com/godotengine/godot-proposals>`__ repository instead.
 -  *For PR meeting*: the issue needs to be discussed in a pull request meeting.
    These meetings are public and are held on the `Godot Contributors Chat <https://chat.godotengine.org/>`_.
 -  *Good first issue*: the issue is *assumed* to be an easy one to fix, which makes
@@ -89,29 +107,33 @@ currently defined in the Godot repository:
 -  *Performance*: issues that directly impact engine or editor performance.
    Can also be used for pull requests that improve performance or add low-end-friendly options.
    Should not be coupled with *Usability*.
--  *Production*: Relates to the production team.
 -  *Regression*: the bug appeared after a stable release not exhibiting
    the bug was released.
 -  *Salvageable*: the pull request can't be merged due to design issues or
    merge conflicts and its author is not active anymore. However, it can still
-   be picked up by an external contributor to bring it to a mergeable state.
+   be picked up by another contributor to bring it to a mergeable state.
    To do so, you need to open a new pull request based on the original pull request.
+-  *Spam*: intentional spam issues, and extremely low-effort PRs. Used
+   sparingly, since we give contributors and users the benefit of the doubt. In
+   most cases, *Needs work* or *Archived* is more appropriate.
 -  *Tracker*: issue used to track other issues (like all issues related to
    the plugin system).
 -  *Usability*: issues that directly impact user usability. Should not be coupled with *Performance*.
 
-The categories are used for general triage of the issues. They can be
-combined in some way when relevant, e.g. an issue can be labelled
-*Enhancement* and *Usability* at the same time if it's an issue to improve
-usability. Or *Feature proposal* and *Discussion* if it's a non-consensual
-feature request, or one that is not precise enough to be worked on.
-At least one of the categories *Bug*, *Enhancement* or *Discussion* is used to
-describe an issue or pull request.
+The categories are used for general triage of the issues. They can be combined
+in some way when relevant, e.g. an issue can be labeled *Bug* and *Usability*
+at the same time if it's a bug that affects usability. Or *Enhancement* and
+*Discussion* if it's an improvement that requires discussion of the best
+approach. At least one of the categories *Bug*, *Enhancement*, or *Discussion*
+are used to describe an issue or pull request.
 
-**Topics:**
+Topics:
+^^^^^^^
 
--  *2D*: relates to 2D-specific issues. Should be coupled with one of the labels below, and should not be coupled with *3D*.
--  *3D*: relates to 3D-specific issues. Should be coupled with one of the labels below, and should not be coupled with *2D*.
+-  *2D*: relates to 2D nodes. Should be coupled with one of the labels
+   below, and should not be coupled with *3D*.
+-  *3D*: relates to 3D nodes. Should be coupled with one of the labels
+   below, and should not be coupled with *2D*.
 -  *Animation*: relates to the Animation system, editors and importers.
 -  *Assetlib*: relates to issues with the asset library.
 -  *Audio*: relates to the audio features (low- and high-level).
@@ -119,7 +141,7 @@ describe an issue or pull request.
    buildsystem or to compiler peculiarities.
 -  *Codestyle*: relates to the programming style used within the codebase.
 -  *Core*: anything related to the core engine. Specific topics are split off separately as they crop up.
--  *Dotnet*: relates to the C# / Dotnet bindings.
+-  *Dotnet*: relates to the C# / .NET bindings.
 -  *Editor*: relates to issues in the editor (mainly UI).
 -  *Export*: relates to the export system and templates.
 -  *GDExtension*: relates to the GDExtension system for native extensions.
@@ -146,9 +168,10 @@ unthinkable to see issues that fit two bills. The general idea is that
 there will be specialized contributors teams behind all topics, so they
 can focus on the issues labelled with their team's topic.
 
-**Platforms:**
+Platforms:
+^^^^^^^^^^
 
-*Android*, *iOS*, *Linux*, *macOS*, *Web*, *Windows*
+*Android*, *iOS*, *LinuxBSD*, *macOS*, *Web*, *Windows*
 
 By default, it is assumed that a given issue applies to all platforms.
 If one of the platform labels is used, it is then exclusive and the
@@ -176,6 +199,12 @@ use the following `labels <https://github.com/godotengine/godot-docs/labels>`__:
    it a great fit for new contributors who want to become familiar with
    the code base. It should be removed while an active PR is available, that
    resolves this issue.
+-  *Linked demo PR*: the PR has a corresponding PR to the
+   `Godot Demo Projects <https://github.com/godotengine/godot-demo-projects>`__
+   repository which must be merged at the same time. Any changes to code in
+   tutorials that have a corresponding demo, such as :ref:`doc_your_first_2d_game`,
+   need to update both repositories so that the tutorial code stays in sync with
+   the completed demo.
 -  *Needs work*: the pull request needs additional work before it can be merged.
 -  *Python*: Pull requests that update Python code.
 -  *Salvageable*: the pull request can't be merged due to design issues or
@@ -184,8 +213,11 @@ use the following `labels <https://github.com/godotengine/godot-docs/labels>`__:
    To do so, you need to open a new pull request based on the original pull request.
 -  *Tracker*: issue used to track other issues (like all issues related to
    the plugin system).
+-  *Waiting on PR merge*: the PR documents an engine PR that has not been merged
+   yet.
 
-**Area:**
+Area:
+^^^^^
 
 -  *About*: Issues and PRs related to the About section of the documentation and other general articles.
 -  *Class reference*: the issue is about the class reference, not a documentation page.
@@ -194,7 +226,8 @@ use the following `labels <https://github.com/godotengine/godot-docs/labels>`__:
 -  *Getting started*: Issues and PRs related to the Getting Started section of the documentation.
 -  *Manual*: Issues and PRs related to the Manual/Tutorials section of the documentation.
 
-**Content:**
+Content:
+^^^^^^^^
 
 -  *Images*: Issues and PRs involving outdated or incorrect images in articles.
 -  *Example code*: Issues and PRs involving writing or updating code examples.
@@ -204,7 +237,8 @@ use the following `labels <https://github.com/godotengine/godot-docs/labels>`__:
 -  *Redirect*: Issues and PRs involving moving content and adding a redirect rule on the backend.
 -  *Website*: Issues related to adding website features and fixing bugs, whether on the front or back-end,
 
-**Topic:**
+Topic:
+^^^^^^
 
 The available topics describe the same content as the topics in the main
 repository.
@@ -212,15 +246,42 @@ repository.
 Milestones
 ~~~~~~~~~~
 
-`Milestones <https://github.com/godotengine/godot/milestones>`_ correspond to
-planned future versions of Godot for which there is an existing roadmap. Issues
-that fit in the said roadmap should be filed under the corresponding milestone;
-if they don't correspond to any current roadmap, they should be left without
-milestone. As a rule of thumb, an issue corresponds to a given milestone if it
-concerns a feature that is new in the milestone, or a critical bug that can't be
-accepted in any future stable release, or anything that Juan wants to work on
-right now. :)
+`Milestones <https://github.com/godotengine/godot/milestones>`_ are used for
+some issues and all PRs.
 
-Contributors are free to pick issues regardless of their assigned milestone;
-if a fix is proposed for a bug that was not deemed urgent and thus without
-milestone, it would likely still be very welcome.
+We have milestones for specific minor engine versions, like ``4.5`` and ``4.6``,
+as well as general milestones for major engine versions, like ``3.x`` and
+``4.x``. In the ``godot-proposals`` repo, we also have a ``5.0`` milestone for
+compatibility-breaking changes that will be considered for Godot 5.0, in many
+years.
+
+Issues are assigned to the current development milestone, such as ``4.5``, if
+they are related to features introduced in that engine version, or are bugs
+(regressions) in that version. Additionally, all issues completed during the
+development of that engine version are added to the milestone, so that users can
+see at a glance in which minor version an issue was first fixed. We don't always
+use the ``4.x`` milestone for issues, since by default all issues are related to
+Godot 4.x. However, we do use the ``3.x`` milestone to mark issues that are
+specific to Godot 3.x.
+
+All pull requests are assigned to a milestone. By default, enhancement and
+feature PRs are assigned to the ``4.x`` milestone, and bugs are assigned to the
+current development milestone, such as ``4.5``. Towards the end of the minor
+version's development, PRs currently in that milestone are reassessed. If
+a PR is no longer being considered for that version, it is reassigned to either the
+major version milestone (``4.x``), or the next minor version milestone (such as
+``4.6``).
+
+Pull requests in the ``4.x`` milestone are reassigned to the current minor
+engine version, such as ``4.5``, when the review process is complete, and the
+production team decides that the PR is ready to be merged soon. Note that
+this usually requires more than one approving review.
+
+The milestone assigned to a PR is a goal, not a guarantee. New features and
+enhancements are merged when they are ready. While reviewers and maintainers do
+their best to review PRs in time for the current version, at some point we reach
+the beta, feature freeze, and then release; and existing PRs are reassigned to
+the next minor version, or to ``4.x``. As a rule, we assign new features to the
+``4.x`` milestone initially to avoid continually reassigning a PR from version
+to version. However, a PR being in ``4.x`` does not mean it won't be merged;
+it's just the default for new features.

getting_started/first_2d_game/04.creating_the_enemy.rst

@@ -87,6 +87,7 @@ and randomly choose one of the three animation types:
     func _ready():
         var mob_types = Array($AnimatedSprite2D.sprite_frames.get_animation_names())
         $AnimatedSprite2D.animation = mob_types.pick_random()
+        $AnimatedSprite2D.play()
 
  .. code-tab:: csharp
 
@@ -106,6 +107,8 @@ to select one of these animation names at random. Meanwhile, in the C# code, we
 between ``0`` and ``2`` to select one of these names from the list (array indices start at ``0``). The 
 expression ``GD.Randi() % n`` selects a random integer between ``0`` and ``n-1``.
 
+Finally, we call ``play()`` to start playing the chosen animation.
+
 The last piece is to make the mobs delete themselves when they leave the screen.
 Connect the ``screen_exited()`` signal of the ``VisibleOnScreenNotifier2D`` node
 to the ``Mob`` and add this code:

getting_started/first_2d_game/06.heads_up_display.rst

@@ -160,10 +160,6 @@ We also need to process what happens when the player loses. The code below will
         GetNode<Button>("StartButton").Show();
     }
 
-This function is called when the player loses. It will show "Game Over" for 2
-seconds, then return to the title screen and, after a brief pause, show the
-"Start" button.
-
 .. note:: When you need to pause for a brief time, an alternative to using a
           Timer node is to use the SceneTree's ``create_timer()`` function. This
           can be very useful to add delays such as in the above code, where we

getting_started/first_3d_game/01.game_setup.rst

@@ -8,8 +8,7 @@ importing the start assets and setting up the game scene.
 
 We've prepared a Godot project with the 3D models and sounds we'll use for this
 tutorial, linked in the index page. If you haven't done so yet, you can download
-the archive here: `Squash the Creeps assets
-<https://github.com/godotengine/godot-3d-dodge-the-creeps/releases/tag/1.1.0>`__.
+the archive here: `Squash the Creeps assets <https://github.com/godotengine/godot-docs-project-starters/releases/download/latest-4.x/3d_squash_the_creeps_starter.zip>`_.
 
 Once you downloaded it, extract the .zip archive on your computer. Open the
 Godot Project Manager and click the *Import* button.
@@ -17,7 +16,7 @@ Godot Project Manager and click the *Import* button.
 .. image:: img/01.game_setup/01.import_button.webp
 
 In the import popup, enter the full path to the freshly created directory
-``squash_the_creeps_start/``. You can click the *Browse* button on the right to
+``3d_squash_the_creeps_starter/``. You can click the *Browse* button on the right to
 open a file browser and navigate to the ``project.godot`` file the folder
 contains.
 
@@ -108,7 +107,7 @@ 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.
 The first is by pressing the *Use Snap* button (or pressing the :kbd:`Y` key).
-The second is by selecting a node, dragging a handle on the gizmo **then** holding :kbd:`Ctrl` while still clicking to enable snapping as long as :kbd:`Ctrl` is held. 
+The second is by selecting a node, dragging a handle on the gizmo **then** holding :kbd:`Ctrl` while still clicking to enable snapping as long as :kbd:`Ctrl` is held.
 
 .. image:: img/01.game_setup/use_snap.webp
 

getting_started/first_3d_game/02.player_input.rst

@@ -7,19 +7,17 @@ In the next two lessons, we will design the player scene, register custom input
 actions, and code player movement. By the end, you'll have a playable character
 that moves in eight directions.
 
-.. TODO: add player animated gif?
-.. player_movement.gif
+Create a new scene by going to the **Scene** menu in the top-left
+and clicking **New Scene**.
 
-Create a new scene by going to the Scene menu in the top-left and clicking *New
-Scene*.
+.. image:: img/02.player_input/new_scene.webp
 
-|image0|
-
- Create a :ref:`CharacterBody3D <class_CharacterBody3D>` node as the root
+Click the **Other Node** button and select the ``CharacterBody3D`` node type
+to create a :ref:`CharacterBody3D <class_CharacterBody3D>` as the root node.
 
 .. image:: img/02.player_input/add_character_body3D.webp
 
-Name the :ref:`CharacterBody3D <class_CharacterBody3D>` to ``Player``.
+Rename the :ref:`CharacterBody3D <class_CharacterBody3D>` to ``Player``.
 Character bodies are complementary to the area and rigid bodies used in the 2D
 game tutorial. Like rigid bodies, they can move and collide with the
 environment, but instead of being controlled by the physics engine, **you** dictate
@@ -34,7 +32,9 @@ the jump and squash mechanics.
 For now, we're going to create a basic rig for our character's 3D model. This
 will allow us to rotate the model later via code while it plays an animation.
 
-Add a :ref:`Node3D <class_Node3D>` node as a child of ``Player`` and name it ``Pivot``
+Add a :ref:`Node3D <class_Node3D>` node as a child of ``Player``.
+Select the ``Player`` node in the **Scene** tree and click the "**+**" button to add a child node.
+Rename it to ``Pivot``.
 
 .. image:: img/02.player_input/adding_node3D.webp
 
@@ -42,12 +42,12 @@ Then, in the FileSystem dock, expand the ``art/`` folder
 by double-clicking it and drag and
 drop ``player.glb`` onto ``Pivot``.
 
-|image1|
+.. image:: img/02.player_input/instantiating_the_model.webp
 
 This should instantiate the model as a child of ``Pivot``.
 You can rename it to ``Character``.
 
-|image2|
+.. image:: img/02.player_input/scene_structure.webp
 
 .. note::
 
@@ -58,13 +58,14 @@ You can rename it to ``Character``.
 
 As with all kinds of physics nodes, we need a collision shape for our character
 to collide with the environment. Select the ``Player`` node again and add a child node
-:ref:`CollisionShape3D <class_CollisionShape3D>`. In the *Inspector*, on the *Shape* property, add a new :ref:`SphereShape3D <class_SphereShape3D>`.
+:ref:`CollisionShape3D <class_CollisionShape3D>`. In the **Inspector**, on the **Shape** property,
+add a new :ref:`SphereShape3D <class_SphereShape3D>`.
 
 .. image:: img/02.player_input/add_capsuleshape3d.webp
 
 The sphere's wireframe appears below the character.
 
-|image3|
+.. image:: img/02.player_input/sphere_shape.png
 
 It will be the shape the physics engine uses to collide with the environment, so
 we want it to better fit the 3D model. Make it a bit larger by dragging the orange
@@ -72,14 +73,14 @@ dot in the viewport. My sphere has a radius of about ``0.8`` meters.
 
 Then, move the collision shape up so its bottom roughly aligns with the grid's plane.
 
-|image4|
+.. image:: img/02.player_input/moving_the_sphere_up.png
 
 To make moving the shape easier, you can toggle the model's visibility by clicking
-the eye icon next to the ``Character`` or the ``Pivot`` nodes.
+the **eye icon** next to the ``Character`` or the ``Pivot`` nodes.
 
-|image5|
+.. image:: img/02.player_input/toggling_visibility.webp
 
-Save the scene as ``player.tscn``
+Save the scene as ``player.tscn``.
 
 With the nodes ready, we can almost get coding. But first, we need to define
 some input actions.
@@ -94,52 +95,49 @@ arrow keys. In Godot, while we could write all the key bindings in code, there's
 a powerful system that allows you to assign a label to a set of keys and
 buttons. This simplifies our scripts and makes them more readable.
 
-This system is the Input Map. To access its editor, head to the *Project* menu
-and select *Project Settings*.
+This system is the Input Map. To access its editor, head to the **Project** menu
+and select **Project Settings...**.
 
-|image6|
+.. image:: img/02.player_input/project_settings.webp
 
-At the top, there are multiple tabs. Click on *Input Map*. This window allows
+At the top, there are multiple tabs. Click on **Input Map**. This window allows
 you to add new actions at the top; they are your labels. In the bottom part, you
 can bind keys to these actions.
 
-|image7|
+.. image:: img/02.player_input/input_map_tab.webp
 
 Godot projects come with some predefined actions designed for user interface
 design (see above screenshot). These will become visible if you enable the
-*Show Built-in Actions* toggle. We could use these here, but instead we're
-defining our own to support gamepads. Leave *Show Built-in Actions* disabled.
+**Show Built-in Actions** toggle. We could use these here, but instead we're
+defining our own to support gamepads. Leave **Show Built-in Actions** disabled.
 
 We're going to name our actions ``move_left``, ``move_right``, ``move_forward``,
 ``move_back``, and ``jump``.
 
-To add an action, write its name in the bar at the top and press Enter.
+To add an action, write its name in the bar at the top and press Enter or click the **Add** button.
 
-|image8|
+.. image:: img/02.player_input/adding_action.webp
 
 Create the following five actions:
 
-|image9|
+.. image:: img/02.player_input/actions_list_empty.webp
 
-To bind a key or button to an action, click the "+" button to its right. Do this
-for ``move_left``. Press the left arrow key and click *OK*.
+To bind a key or button to an action, click the "**+**" button to its right. Do this
+for ``move_left``. Press the left arrow key and click **OK**.
 
 .. image:: img/02.player_input/left_inputmap.webp
 
 Bind also the :kbd:`A` key, onto the action ``move_left``.
 
-|image12|
+.. image:: img/02.player_input/keyboard_keys.webp
 
-Let's now add support for a gamepad's left joystick. Click the "+" button again
-but this time, select *Manual Selection -> Joypad Axes*.
+Let's now add support for a gamepad's left joystick. Click the "**+**" button again
+but this time, select the input within the input tree yourself.
+Select the negative X axis of the left joystick under **Joypad Axes**.
 
 .. image:: img/02.player_input/joystick_axis_input.webp
 
-Select the negative X axis of the left joystick.
-
-.. image:: img/02.player_input/left_joystick_select.webp
-
-Leave the other values as default and press *OK*
+Leave the other values as default and press **OK**.
 
 .. note::
 
@@ -149,35 +147,18 @@ Do the same for the other input actions. For example, bind the right arrow, D,
 and the left joystick's positive axis to ``move_right``. After binding all keys,
 your interface should look like this.
 
-|image15|
+.. image:: img/02.player_input/move_inputs_mapped.webp
 
 The final action to set up is the ``jump`` action. Bind the Space key and the gamepad's
-A button.
+A button located under **Joypad Buttons**.
 
-|image16|
+.. image:: img/02.player_input/joy_button_option.webp
 
 Your jump input action should look like this.
 
-|image18|
+.. image:: img/02.player_input/jump_input_action.webp
 
 That's all the actions we need for this game. You can use this menu to label any
 groups of keys and buttons in your projects.
 
 In the next part, we'll code and test the player's movement.
-
-.. |image0| image:: img/02.player_input/01.new_scene.png
-.. |image1| image:: img/02.player_input/02.instantiating_the_model.webp
-.. |image2| image:: img/02.player_input/03.scene_structure.png
-.. |image3| image:: img/02.player_input/04.sphere_shape.png
-.. |image4| image:: img/02.player_input/05.moving_the_sphere_up.png
-.. |image5| image:: img/02.player_input/06.toggling_visibility.webp
-.. |image6| image:: img/02.player_input/07.project_settings.png
-.. |image7| image:: img/02.player_input/07.input_map_tab.png
-.. |image8| image:: img/02.player_input/07.adding_action.webp
-.. |image9| image:: img/02.player_input/08.actions_list_empty.png
-.. |image11| image:: img/02.player_input/09.keyboard_key_popup.png
-.. |image12| image:: img/02.player_input/09.keyboard_keys.png
-.. |image15| image:: img/02.player_input/12.move_inputs_mapped.webp
-.. |image16| image:: img/02.player_input/13.joy_button_option.webp
-.. |image17| image:: img/02.player_input/14.add_jump_button.png
-.. |image18| image:: img/02.player_input/14.jump_input_action.webp

getting_started/first_3d_game/03.player_movement_code.rst

@@ -143,7 +143,7 @@ call its ``normalized()`` method.
 .. tabs::
  .. code-tab:: gdscript GDScript
 
-   #func _physics_process(delta):
+   func _physics_process(delta):
        #...
 
        if direction != Vector3.ZERO:
@@ -274,6 +274,7 @@ Here is the complete ``player.gd`` code for reference.
 
         if direction != Vector3.ZERO:
             direction = direction.normalized()
+            # Setting the basis property will affect the rotation of the node.
             $Pivot.basis = Basis.looking_at(direction)
 
         # Ground Velocity
@@ -327,6 +328,7 @@ Here is the complete ``player.gd`` code for reference.
             if (direction != Vector3.Zero)
             {
                 direction = direction.Normalized();
+                // Setting the basis property will affect the rotation of the node.
                 GetNode<Node3D>("Pivot").Basis = Basis.LookingAt(direction);
             }
 

getting_started/first_3d_game/07.killing_player.rst

@@ -349,7 +349,8 @@ Finally, the longest script, ``player.gd``:
         # Prevent diagonal moving fast af
         if direction != Vector3.ZERO:
             direction = direction.normalized()
-            $Pivot.look_at(position + direction, Vector3.UP)
+            # Setting the basis property will affect the rotation of the node.
+            $Pivot.basis = Basis.looking_at(direction)
 
         # Ground Velocity
         target_velocity.x = direction.x * speed
@@ -450,7 +451,8 @@ Finally, the longest script, ``player.gd``:
             if (direction != Vector3.Zero)
             {
                 direction = direction.Normalized();
-                GetNode<Node3D>("Pivot").LookAt(Position + direction, Vector3.Up);
+                // Setting the basis property will affect the rotation of the node.
+                GetNode<Node3D>("Pivot").Basis = Basis.LookingAt(direction);
             }
 
             // Ground Velocity

getting_started/first_3d_game/09.adding_animations.rst

@@ -266,7 +266,7 @@ Open the *Player* scene, select the AnimationPlayer node and then click on
 (two small squares) alongside the *float* animation. Click OK to close the window.
 
 Then open ``mob.tscn``, create an :ref:`AnimationPlayer <class_AnimationPlayer>` child
-node and select it. Click **Animation > Manage Animations**, then **Add Library**. You
+node and select it. Click **Animation > Manage Animations**, then **New Library**. You
 should see the message "Global library will be created." Leave the text field blank and
 click OK. Click the *Paste* icon (clipboard) and it should appear in the window. Click OK
 to close the window.
@@ -342,7 +342,8 @@ Here's the *Player* script.
         # Prevent diagonal movement being very fast
         if direction != Vector3.ZERO:
             direction = direction.normalized()
-            $Pivot.look_at(position + direction,Vector3.UP)
+            # Setting the basis property will affect the rotation of the node.
+            $Pivot.basis = Basis.looking_at(direction)
             $AnimationPlayer.speed_scale = 4
         else:
             $AnimationPlayer.speed_scale = 1
@@ -448,7 +449,8 @@ Here's the *Player* script.
             if (direction != Vector3.Zero)
             {
                 direction = direction.Normalized();
-                GetNode<Node3D>("Pivot").LookAt(Position + direction, Vector3.Up);
+                // Setting the basis property will affect the rotation of the node.
+                GetNode<Node3D>("Pivot").Basis = Basis.LookingAt(direction);
                 GetNode<AnimationPlayer>("AnimationPlayer").PlaybackSpeed = 4;
             }
             else

getting_started/first_3d_game/index.rst

@@ -33,7 +33,7 @@ This tutorial is for beginners who followed the complete getting started series.
 We'll start slow with detailed instructions and shorten them as we do similar
 steps. If you're an experienced programmer, you can browse the complete demo's
 source code here: `Squash the Creep source code
-<https://github.com/godotengine/godot-3d-dodge-the-creeps>`__.
+<https://github.com/godotengine/godot-demo-projects/tree/master/3d/squash_the_creeps>`__.
 
 .. note::
 
@@ -44,7 +44,7 @@ source code here: `Squash the Creep source code
 
 We prepared some game assets so we can jump straight to the code. You can
 download them here: `Squash the Creeps assets
-<https://github.com/godotengine/godot-3d-dodge-the-creeps/releases/tag/1.1.0>`__.
+<https://github.com/godotengine/godot-docs-project-starters/releases/download/latest-4.x/3d_squash_the_creeps_starter.zip>`__.
 
 We will first work on a basic prototype for the player's movement. We will then
 add the monsters that we'll spawn randomly around the screen. After that, we'll

getting_started/introduction/godot_design_philosophy.rst

@@ -99,9 +99,12 @@ Open source
 -----------
 
 Godot offers a fully open source codebase under the **MIT license**.
-This means all the technologies that ship with it have to be Free
-(as in freedom) as well.
-For the most part, they're developed from the ground up by contributors.
+This means that the codebase is free for anyone to download, use,
+modify, or share, as long as its license file is kept intact.
+
+All technologies that ship with Godot, including third-party libraries, must
+be legally compatible with this open source license. Therefore, most parts
+of Godot are developed from the ground up by community contributors.
 
 Anyone can plug in proprietary tools for the needs of their projects —
 they just won't ship with the engine. This may include Google AdMob,
@@ -142,11 +145,12 @@ and scenes for your games, or **build plugins and extend the editor.**
 This leads to a reliable and flexible UI system, as it powers the editor
 itself. With the ``@tool`` annotation, you can run any game code in the editor.
 
-|image5|
+.. figure:: img/introduction_rpg_in_a_box.webp
+   :align: center
 
-*RPG in a Box is a voxel RPG editor made with Godot 2. It uses Godot's
-UI tools for its node-based programming system and for the rest of the
-interface.*
+   RPG in a Box is a voxel RPG editor made with Godot. It uses Godot's
+   UI tools for its node-based programming system and for the rest of the
+   interface.
 
 Put the ``@tool`` annotation at the top of any GDScript file and it will run
 in the editor. This lets you import and export plugins, create plugins
@@ -170,4 +174,3 @@ interfaces over your 3D world.
 .. |image0| image:: img/engine_design_01.png
 .. |image1| image:: img/engine_design_02.png
 .. |image2| image:: img/engine_design_03.png
-.. |image5| image:: img/engine_design_rpg_in_a_box.png

getting_started/introduction/introduction_to_godot.rst

@@ -33,18 +33,31 @@ Godot was initially developed in-house by an Argentinian game studio. Its
 development started in 2001, and the engine was rewritten and improved
 tremendously since its open source release in 2014.
 
-Some examples of games created with Godot include Ex-Zodiac and Helms of Fury.
+Some examples of games created with Godot include Cassette Beasts, PVKK, and
+Usagi Shima. As for applications, the open source pixel art drawing program
+Pixelorama is powered by Godot, and so is the voxel RPG creator RPG in a Box.
+You can find many more examples in the `Official Showcase
+<https://godotengine.org/showcase/>`_.
 
-.. image:: img/introduction_ex_zodiac.png
+.. figure:: img/introduction_usagi_shima.webp
+   :align: center
 
-.. image:: img/introduction_helms_of_fury.jpg
+   Usagi Shima
 
-As for applications, the open source pixel art drawing program Pixelorama is
-powered by Godot, and so is the voxel RPG creator RPG in a box.
+.. figure:: img/introduction_cassette_beasts.webp
+   :align: center
 
-.. image:: img/introduction_rpg_in_a_box.png
+   Cassette Beasts
 
-You can find many more examples in the `official showcase videos`_.
+.. figure:: img/introduction_pvkk.webp
+   :align: center
+
+   PVKK: Planetenverteidigungskanonenkommandant
+
+.. figure:: img/introduction_rpg_in_a_box.webp
+   :align: center
+
+   RPG in a Box
 
 How does it work and look?
 --------------------------

getting_started/step_by_step/instancing.rst

@@ -195,7 +195,7 @@ For example, you could break down a shooter game like so:
 
 You can come up with a diagram like this for almost any type of game. Each
 rectangle represents an entity that's visible in the game from the player's
-perspective. The arrows point towards the insantiator of each scene.
+perspective. The arrows point towards the instantiator of each scene.
 
 Once you have a diagram, we recommend creating a scene for each element listed
 in it to develop your game. You'll use instancing, either by code or directly in

requirements.txt

@@ -18,7 +18,7 @@ sphinx-copybutton==0.5.2
 # Custom 404 error page (more useful than the default).
 sphinx-notfound-page==1.1.0
 # Adds Open Graph tags in the HTML `<head>` tag.
-sphinxext-opengraph==0.9.1
+sphinxext-opengraph==0.10.0
 
 # `.. video::` directive support to embed videos in documentation pages.
 sphinxcontrib-video==0.4.1

tutorials/3d/environment_and_post_processing.rst

@@ -646,6 +646,17 @@ There are 2 main use cases for a glow map texture:
 
 .. image:: img/environment_glow_map.webp
 
+By default, glow uses a bicubic scaling filter on desktop platforms and a
+bilinear scaling filter on mobile platforms. The bicubic scaling filter results
+in higher quality with a less blocky appearance, but it has a performance cost
+on the GPU which can be significant on integrated graphics.
+The scale mode can be controlled using the
+**Rendering > Environment > Glow > Upscale Mode** project setting.
+This setting is only effective when using the Forward+ or Mobile renderers,
+as Compatibility uses a different glow implementation.
+
+.. image:: img/environment_and_post_processing_glow_scale_mode.webp
+
 .. _doc_environment_and_post_processing_using_glow_in_2d:
 
 Using glow in 2D

tutorials/3d/global_illumination/reflection_probes.rst

@@ -3,11 +3,6 @@
 Reflection probes
 =================
 
-.. note::
-
-    Reflection probes are only supported in the Forward+ and Mobile renderers,
-    not the Compatibility renderer.
-
 As stated in the :ref:`doc_standard_material_3d`, objects can show reflected and/or
 diffuse light. Reflection probes are used as a source of reflected *and* ambient
 light for objects inside their area of influence. They can be used to provide

tutorials/3d/using_transforms.rst

@@ -13,7 +13,7 @@ At first, this seems easy. For simple games, this way of thinking may even be en
 
 Angles in three dimensions are most commonly referred to as "Euler Angles".
 
-.. image:: img/transforms_euler.png
+.. image:: img/transforms_euler.webp
 
 Euler angles were introduced by mathematician Leonhard Euler in the early 1700s.
 
@@ -383,8 +383,8 @@ Converting a rotation to quaternion is straightforward.
  .. code-tab:: csharp
 
     // Convert basis to quaternion, keep in mind scale is lost
-    var a = transform.Basis.GetQuaternion();
-    var b = transform2.Basis.GetQuaternion();
+    var a = new Quaternion(transform.Basis);
+    var b = new Quaternion(transform2.Basis);
     // Interpolate using spherical-linear interpolation (SLERP).
     var c = a.Slerp(b, 0.5f); // find halfway point between a and b
     // Apply back

tutorials/animation/playing_videos.rst

@@ -182,9 +182,8 @@ you should use a lossless or uncompressed format as an intermediate format to
 maximize the quality of the output Ogg Theora video, but this can require a lot
 of disk space.
 
-`HandBrake <https://handbrake.fr/>`__
-(GUI) and `FFmpeg <https://ffmpeg.org/>`__ (CLI) are popular open source tools
-for this purpose. FFmpeg has a steeper learning curve, but it's more powerful.
+`FFmpeg <https://ffmpeg.org/>`__ (CLI) is a popular open source tool
+for this purpose. FFmpeg has a steep learning curve, but it's powerful tool.
 
 Here are example FFmpeg commands to convert an MP4 video to Ogg Theora. Since
 FFmpeg supports a lot of input formats, you should be able to use the commands

tutorials/assets_pipeline/importing_audio_samples.rst

@@ -10,9 +10,10 @@ Godot provides 3 options to import your audio data: WAV, Ogg Vorbis and MP3.
 
 Each format has different advantages:
 
-- WAV files use raw data or light compression (IMA-ADPCM or QOA). They are 
-  lightweight to play back on the CPU (hundreds of simultaneous voices in this
-  format are fine). The downside is that they take up a lot of disk space.
+- WAV files use raw data or light compression (IMA-ADPCM or QOA). Currently
+  they can only be imported in raw format, but Godot allows compression after
+  import. They are lightweight to play back on the CPU (hundreds of simultaneous
+  voices in this format are fine). The downside is that they take up a lot of disk space.
 - Ogg Vorbis files use a stronger compression that results in much
   smaller file size, but require significantly more processing power to
   play back.

tutorials/best_practices/data_preferences.rst

@@ -105,11 +105,11 @@ Contiguous memory stores imply the following operation performance:
       though. Done by re-sorting the Array after every edit and writing an
       ordered-aware search algorithm.
 
-Godot implements Dictionary as an ``OrderedHashMap<Variant, Variant>``. The engine
+Godot implements Dictionary as an ``HashMap<Variant, Variant, VariantHasher, StringLikeVariantComparator>``. The engine
 stores a small array (initialized to 2^3 or 8 records) of key-value pairs. When
 one attempts to access a value, they provide it a key. It then *hashes* the
 key, i.e. converts it into a number. The "hash" is used to calculate the index
-into the array. As an array, the OHM then has a quick lookup within the "table"
+into the array. As an array, the HM then has a quick lookup within the "table"
 of keys mapped to values. When the HashMap becomes too full, it increases to
 the next power of 2 (so, 16 records, then 32, etc.) and rebuilds the structure.
 

tutorials/export/exporting_for_android.rst

@@ -39,7 +39,7 @@ Download and install the Android SDK.
     - Android SDK Command-line Tools (latest)
 
   - Ensure that the `NDK and CMake are installed and configured <https://developer.android.com/studio/projects/install-ndk>`__.
-  
+
     - CMake version 3.10.2.4988404
     - NDK version r23c (23.2.8568313)
 
@@ -61,8 +61,8 @@ Download and install the Android SDK.
 Setting it up in Godot
 ----------------------
 
-Enter the Editor Settings screen (under the Godot tab for macOS, or the Editor tab 
-for other platforms). This screen contains the editor settings for the user 
+Enter the Editor Settings screen (under the Godot tab for macOS, or the Editor tab
+for other platforms). This screen contains the editor settings for the user
 account in the computer (it's independent of the project).
 
 .. image:: img/editorsettings.png
@@ -186,3 +186,9 @@ the export menu.
      - ``GODOT_ANDROID_KEYSTORE_RELEASE_USER``
    * - Options / Keystore / Release Password
      - ``GODOT_ANDROID_KEYSTORE_RELEASE_PASSWORD``
+
+Export options
+--------------
+
+You can find a full list of export options available in the
+:ref:`class_EditorExportPlatformAndroid` class reference.

tutorials/export/exporting_for_ios.rst

@@ -136,8 +136,8 @@ xcode-select points at wrong SDK location
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 xcode-select is a tool that comes with Xcode and among other things points at iOS SDKs on your Mac.
-If you have Xcode installed, opened it, agreed to the license agreement, and installed the command line tools, 
-xcode-select should point at the right location for the iPhone SDK. 
+If you have Xcode installed, opened it, agreed to the license agreement, and installed the command line tools,
+xcode-select should point at the right location for the iPhone SDK.
 If it somehow doesn't, Godot will fail exporting to iOS with an error that may look like this:
 
 ::
@@ -145,9 +145,9 @@ If it somehow doesn't, Godot will fail exporting to iOS with an error that may l
     MSB3073: The command ""clang" <LOTS OF PATHS AND COMMAND LINE ARGUMENTS HERE>
     "/Library/Developer/CommandLineTools/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk"" exited with code 1.
 
-In this case, Godot is trying to find the ``Platforms`` folder containing the iPhone SDK inside the 
-``/Library/Developer/CommandLineTools/`` folder, but the ``Platforms`` folder with the iPhone SDK is 
-actually located under ``/Applications/Xcode.app/Contents/Developer``. To verify this, you can open 
+In this case, Godot is trying to find the ``Platforms`` folder containing the iPhone SDK inside the
+``/Library/Developer/CommandLineTools/`` folder, but the ``Platforms`` folder with the iPhone SDK is
+actually located under ``/Applications/Xcode.app/Contents/Developer``. To verify this, you can open
 up Terminal and run the following command to see what xcode-select points at:
 
 ::
@@ -161,3 +161,9 @@ To fix xcode-select pointing at a wrong location, enter this command in Terminal
     sudo xcode-select -switch /Applications/Xcode.app
 
 After running this command, Godot should be able to successfully export to iOS.
+
+Export options
+--------------
+
+You can find a full list of export options available in the
+:ref:`class_EditorExportPlatformIOS` class reference.

tutorials/export/exporting_for_linux.rst

@@ -32,3 +32,9 @@ the export menu.
      - Environment variable
    * - Encryption / Encryption Key
      - ``GODOT_SCRIPT_ENCRYPTION_KEY``
+
+Export options
+--------------
+
+You can find a full list of export options available in the
+:ref:`class_EditorExportPlatformLinuxBSD` class reference.

tutorials/export/exporting_for_macos.rst

@@ -10,13 +10,18 @@ Exporting for macOS
     read :ref:`doc_compiling_for_macos`.
 
 macOS apps exported with the official export templates are exported as a single "Universal 2" binary ``.app`` bundle, a folder with a specific structure which stores the executable, libraries and all the project files.
-This bundle can be exported as is, packed in a ZIP archive or DMG disk image (only supported when exporting from a computer running macOS).
+This bundle can be exported as is, packed in a ZIP archive, or packed in a DMG disk image (only supported when exporting from macOS).
 `Universal binaries for macOS support both Intel x86_64 and ARM64 (Apple Silicon) architectures <https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary>`__.
 
 .. warning::
-    Due to file system limitations, raw ``.app`` bundles exported from Windows lack ``executable`` flag and won't run on macOS.
-    To fix it, use the ``chmod +x {executable_name}`` command after transferring the exported ``.app`` to macOS or Linux. Projects exported as ``.zip`` aren't affected by this issue.
-    The main executable located in the ``Contents/MacOS/`` subfolder, as well as optional helper executables in the ``Contents/Helpers/`` subfolder, should have ``executable`` permission for the ``.app`` bundle to be valid.
+    Due to file system limitations, ``.app`` bundles exported from Windows lack the 
+    ``executable`` flag and won't run on macOS. Projects exported as ``.zip`` are not 
+    affected by this issue. To run ``.app`` bundles exported from Windows on macOS,
+    transfer the ``.app`` to a device running macOS or Linux and use the
+    ``chmod +x {executable_name}`` terminal command to add the ``executable`` permission.
+    The main executable located in the ``Contents/MacOS/`` subfolder, as well
+    as optional helper executables in the ``Contents/Helpers/`` subfolder, should have
+    the ``executable`` permission for the ``.app`` bundle to be valid.
 
 Requirements
 ------------
@@ -251,3 +256,9 @@ the export menu.
      - ``GODOT_MACOS_NOTARIZATION_APPLE_ID_NAME``
    * - Options / Notarization / Apple ID Password
      - ``GODOT_MACOS_NOTARIZATION_APPLE_ID_PASSWORD``
+
+Export options
+--------------
+
+You can find a full list of export options available in the
+:ref:`class_EditorExportPlatformMacOS` class reference.

tutorials/export/exporting_for_web.rst

@@ -41,7 +41,7 @@ in the user's browser.
     Since Godot 4.3, Godot supports exporting your game on a single thread, which
     solves this issue. While it has some drawbacks on its own (it cannot use threads, and is
     not as performant as the multi-threaded export), it doesn't require as much overhead to install.
-    It is also more compatible overall with stores like `itch.io <https://itch.io/>` or Web publishers like
+    It is also more compatible overall with stores like `itch.io <https://itch.io/>`__ or Web publishers like
     `Poki <https://poki.com/>`__ or `CrazyGames <https://crazygames.com/>`__. The single-threaded export
     works very well on macOS and iOS too, where it always had compatibility issues with multiple threads
     exports.
@@ -445,3 +445,9 @@ the export menu.
      - Environment variable
    * - Encryption / Encryption Key
      - ``GODOT_SCRIPT_ENCRYPTION_KEY``
+
+Export options
+--------------
+
+You can find a full list of export options available in the
+:ref:`class_EditorExportPlatformWeb` class reference.

tutorials/export/exporting_for_windows.rst

@@ -76,3 +76,9 @@ the export menu.
      - ``GODOT_WINDOWS_CODESIGN_IDENTITY``
    * - Options / Codesign / Password
      - ``GODOT_WINDOWS_CODESIGN_PASSWORD``
+
+Export options
+--------------
+
+You can find a full list of export options available in the
+:ref:`class_EditorExportPlatformWindows` class reference.

tutorials/export/exporting_projects.rst

@@ -193,8 +193,7 @@ The output path is *relative to the project path* or *absolute*;
 The output file extension should match the one used by the Godot export process:
 
 - Windows: ``.exe``
-- macOS: ``.zip`` (from all platforms) or ``.dmg`` (only when exporting *from* macOS).
-  ``.app`` is not supported directly, although the generated ZIP archive contains an ``.app`` bundle.
+- macOS: ``.app`` or ``.zip`` (or ``.dmg`` when exporting *from* macOS)
 - Linux: Any extension (including none). ``.x86_64`` is typically used for 64-bit x86 binaries.
 - HTML5: ``.zip``
 - Android: ``.apk``

tutorials/export/feature_tags.rst

@@ -37,91 +37,95 @@ Default features
 
 Here is a list of most feature tags in Godot. Keep in mind they are **case-sensitive**:
 
-+-----------------+----------------------------------------------------------+
-| **Feature tag** | **Description**                                          |
-+=================+==========================================================+
-| **android**     | Running on Android (but not within a Web browser)        |
-+-----------------+----------------------------------------------------------+
-| **bsd**         | Running on \*BSD (but not within a Web browser)          |
-+-----------------+----------------------------------------------------------+
-| **linux**       | Running on Linux (but not within a Web browser)          |
-+-----------------+----------------------------------------------------------+
-| **macos**       | Running on macOS (but not within a Web browser)          |
-+-----------------+----------------------------------------------------------+
-| **ios**         | Running on iOS (but not within a Web browser)            |
-+-----------------+----------------------------------------------------------+
-| **windows**     | Running on Windows                                       |
-+-----------------+----------------------------------------------------------+
-| **linuxbsd**    | Running on Linux or \*BSD                                |
-+-----------------+----------------------------------------------------------+
-| **debug**       | Running on a debug build (including the editor)          |
-+-----------------+----------------------------------------------------------+
-| **release**     | Running on a release build                               |
-+-----------------+----------------------------------------------------------+
-| **editor**      | Running on an editor build                               |
-+-----------------+----------------------------------------------------------+
-| **template**    | Running on a non-editor (export template) build          |
-+-----------------+----------------------------------------------------------+
-| **double**      | Running on a double-precision build                      |
-+-----------------+----------------------------------------------------------+
-| **single**      | Running on a single-precision build                      |
-+-----------------+----------------------------------------------------------+
-| **64**          | Running on a 64-bit build (any architecture)             |
-+-----------------+----------------------------------------------------------+
-| **32**          | Running on a 32-bit build (any architecture)             |
-+-----------------+----------------------------------------------------------+
-| **x86_64**      | Running on a 64-bit x86 build                            |
-+-----------------+----------------------------------------------------------+
-| **x86_32**      | Running on a 32-bit x86 build                            |
-+-----------------+----------------------------------------------------------+
-| **x86**         | Running on an x86 build (any bitness)                    |
-+-----------------+----------------------------------------------------------+
-| **arm64**       | Running on a 64-bit ARM build                            |
-+-----------------+----------------------------------------------------------+
-| **arm32**       | Running on a 32-bit ARM build                            |
-+-----------------+----------------------------------------------------------+
-| **arm**         | Running on an ARM build (any bitness)                    |
-+-----------------+----------------------------------------------------------+
-| **rv64**        | Running on a 64-bit RISC-V build                         |
-+-----------------+----------------------------------------------------------+
-| **riscv**       | Running on a RISC-V build (any bitness)                  |
-+-----------------+----------------------------------------------------------+
-| **ppc64**       | Running on a 64-bit PowerPC build                        |
-+-----------------+----------------------------------------------------------+
-| **ppc32**       | Running on a 32-bit PowerPC build                        |
-+-----------------+----------------------------------------------------------+
-| **ppc**         | Running on a PowerPC build (any bitness)                 |
-+-----------------+----------------------------------------------------------+
-| **wasm64**      | Running on a 64-bit WebAssembly build (not yet possible) |
-+-----------------+----------------------------------------------------------+
-| **wasm32**      | Running on a 32-bit WebAssembly build                    |
-+-----------------+----------------------------------------------------------+
-| **wasm**        | Running on a WebAssembly build (any bitness)             |
-+-----------------+----------------------------------------------------------+
-| **mobile**      | Host OS is a mobile platform                             |
-+-----------------+----------------------------------------------------------+
-| **pc**          | Host OS is a PC platform (desktop/laptop)                |
-+-----------------+----------------------------------------------------------+
-| **web**         | Host OS is a Web browser                                 |
-+-----------------+----------------------------------------------------------+
-| **web_android** | Host OS is a Web browser running on Android              |
-+-----------------+----------------------------------------------------------+
-| **web_ios**     | Host OS is a Web browser running on iOS                  |
-+-----------------+----------------------------------------------------------+
-| **web_linuxbsd**| Host OS is a Web browser running on Linux or \*BSD       |
-+-----------------+----------------------------------------------------------+
-| **web_macos**   | Host OS is a Web browser running on macOS                |
-+-----------------+----------------------------------------------------------+
-| **web_windows** | Host OS is a Web browser running on Windows              |
-+-----------------+----------------------------------------------------------+
-| **etc**         | Textures using ETC1 compression are supported            |
-+-----------------+----------------------------------------------------------+
-| **etc2**        | Textures using ETC2 compression are supported            |
-+-----------------+----------------------------------------------------------+
-| **s3tc**        | Textures using S3TC (DXT/BC) compression are supported   |
-+-----------------+----------------------------------------------------------+
-| **movie**       | :ref:`Movie Maker mode <doc_creating_movies>` is active  |
-+-----------------+----------------------------------------------------------+
++--------------------+----------------------------------------------------------+
+| **Feature tag**    | **Description**                                          |
++====================+==========================================================+
+| **android**        | Running on Android (but not within a Web browser)        |
++--------------------+----------------------------------------------------------+
+| **bsd**            | Running on \*BSD (but not within a Web browser)          |
++--------------------+----------------------------------------------------------+
+| **linux**          | Running on Linux (but not within a Web browser)          |
++--------------------+----------------------------------------------------------+
+| **macos**          | Running on macOS (but not within a Web browser)          |
++--------------------+----------------------------------------------------------+
+| **ios**            | Running on iOS (but not within a Web browser)            |
++--------------------+----------------------------------------------------------+
+| **windows**        | Running on Windows                                       |
++--------------------+----------------------------------------------------------+
+| **linuxbsd**       | Running on Linux or \*BSD                                |
++--------------------+----------------------------------------------------------+
+| **debug**          | Running on a debug build (including the editor)          |
++--------------------+----------------------------------------------------------+
+| **release**        | Running on a release build                               |
++--------------------+----------------------------------------------------------+
+| **editor**         | Running on an editor build                               |
++--------------------+----------------------------------------------------------+
+| **editor_hint**    | Running on an editor build, and inside the editor        |
++--------------------+----------------------------------------------------------+
+| **editor_runtime** | Running on an editor build, and running the project      |
++--------------------+----------------------------------------------------------+
+| **template**       | Running on a non-editor (export template) build          |
++--------------------+----------------------------------------------------------+
+| **double**         | Running on a double-precision build                      |
++--------------------+----------------------------------------------------------+
+| **single**         | Running on a single-precision build                      |
++--------------------+----------------------------------------------------------+
+| **64**             | Running on a 64-bit build (any architecture)             |
++--------------------+----------------------------------------------------------+
+| **32**             | Running on a 32-bit build (any architecture)             |
++--------------------+----------------------------------------------------------+
+| **x86_64**         | Running on a 64-bit x86 build                            |
++--------------------+----------------------------------------------------------+
+| **x86_32**         | Running on a 32-bit x86 build                            |
++--------------------+----------------------------------------------------------+
+| **x86**            | Running on an x86 build (any bitness)                    |
++--------------------+----------------------------------------------------------+
+| **arm64**          | Running on a 64-bit ARM build                            |
++--------------------+----------------------------------------------------------+
+| **arm32**          | Running on a 32-bit ARM build                            |
++--------------------+----------------------------------------------------------+
+| **arm**            | Running on an ARM build (any bitness)                    |
++--------------------+----------------------------------------------------------+
+| **rv64**           | Running on a 64-bit RISC-V build                         |
++--------------------+----------------------------------------------------------+
+| **riscv**          | Running on a RISC-V build (any bitness)                  |
++--------------------+----------------------------------------------------------+
+| **ppc64**          | Running on a 64-bit PowerPC build                        |
++--------------------+----------------------------------------------------------+
+| **ppc32**          | Running on a 32-bit PowerPC build                        |
++--------------------+----------------------------------------------------------+
+| **ppc**            | Running on a PowerPC build (any bitness)                 |
++--------------------+----------------------------------------------------------+
+| **wasm64**         | Running on a 64-bit WebAssembly build (not yet possible) |
++--------------------+----------------------------------------------------------+
+| **wasm32**         | Running on a 32-bit WebAssembly build                    |
++--------------------+----------------------------------------------------------+
+| **wasm**           | Running on a WebAssembly build (any bitness)             |
++--------------------+----------------------------------------------------------+
+| **mobile**         | Host OS is a mobile platform                             |
++--------------------+----------------------------------------------------------+
+| **pc**             | Host OS is a PC platform (desktop/laptop)                |
++--------------------+----------------------------------------------------------+
+| **web**            | Host OS is a Web browser                                 |
++--------------------+----------------------------------------------------------+
+| **web_android**    | Host OS is a Web browser running on Android              |
++--------------------+----------------------------------------------------------+
+| **web_ios**        | Host OS is a Web browser running on iOS                  |
++--------------------+----------------------------------------------------------+
+| **web_linuxbsd**   | Host OS is a Web browser running on Linux or \*BSD       |
++--------------------+----------------------------------------------------------+
+| **web_macos**      | Host OS is a Web browser running on macOS                |
++--------------------+----------------------------------------------------------+
+| **web_windows**    | Host OS is a Web browser running on Windows              |
++--------------------+----------------------------------------------------------+
+| **etc**            | Textures using ETC1 compression are supported            |
++--------------------+----------------------------------------------------------+
+| **etc2**           | Textures using ETC2 compression are supported            |
++--------------------+----------------------------------------------------------+
+| **s3tc**           | Textures using S3TC (DXT/BC) compression are supported   |
++--------------------+----------------------------------------------------------+
+| **movie**          | :ref:`Movie Maker mode <doc_creating_movies>` is active  |
++--------------------+----------------------------------------------------------+
 
 .. warning::
 
@@ -184,6 +188,28 @@ in many sections of the project settings.
 
 .. image:: img/feature_tags4.webp
 
+Taking feature tags into account when reading project settings
+--------------------------------------------------------------
+
+By default, feature tags are **not** taken into account when reading project settings
+using the typical approaches (:ref:`ProjectSettings.get_setting<class_ProjectSettings_method_get_setting>`
+or :ref:`ProjectSettings.get <class_Object_private_method__get>`).
+Instead, you must use :ref:`ProjectSettings.get_setting_with_override <class_ProjectSettings_method_get_setting>`.
+
+For example, with the following project settings:
+
+::
+
+    [section]
+
+    subsection/example = "Release"
+    subsection/example.debug = "Debug"
+
+Using ``ProjectSettings.get_setting("section/subsection/example")`` will return
+``"Release"`` regardless of whether a debug build is currently running. On the
+other hand, ``ProjectSettings.get_setting_with_override("section/subsection/example")``
+will obey feature tags and will return ``"Debug"`` if using a debug build.
+
 Customizing the build
 ---------------------
 

tutorials/math/vectors_advanced.rst

@@ -590,5 +590,5 @@ For more information on using vector math in Godot, see the following article:
 - :ref:`doc_matrices_and_transforms`
 
 If you would like additional explanation, you should check out
-3Blue1Brown's excellent video series "Essence of Linear Algebra":
-https://www.youtube.com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab
+3Blue1Brown's excellent video series 
+`Essence of Linear Algebra <https://www.youtube.com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab>`_.

tutorials/migrating/upgrading_to_godot_4.4.rst

@@ -45,7 +45,7 @@ Method ``store_string`` changes return type from ``void`` to ``bool``
 Method ``store_var`` changes return type from ``void`` to ``bool``                                                        |✔️|                 |❌|                  |✔️|                  `GH-78289`_
 **OS**
 Method ``execute_with_pipe`` adds a new ``blocking`` optional parameter                                                   |✔️|                 |✔️ with compat|      |✔️ with compat|      `GH-94434`_
-Method ``read_string_from_stdin`` adds a new ``buffer_size`` optional parameter                                           |✔️|                 |✔️ with compat|      |✔️ with compat|      `GH-91201`_
+Method ``read_string_from_stdin`` adds a new ``buffer_size`` parameter [#f1]_                                             |❌|                 |✔️ with compat|      |✔️ with compat|      `GH-91201`_
 **RegEx**
 Method ``compile`` adds a new ``show_error`` optional parameter                                                           |✔️|                 |✔️ with compat|      |✔️ with compat|      `GH-95212`_
 Method ``create_from_string`` adds a new ``show_error`` optional parameter                                                |✔️|                 |✔️ with compat|      |✔️ with compat|      `GH-95212`_
@@ -55,6 +55,8 @@ Method ``post`` adds a new ``count`` optional parameter
 Method ``standardize_locale`` adds a new ``add_defaults`` optional parameter                                              |✔️|                 |✔️ with compat|      |✔️ with compat|      `GH-98972`_
 ========================================================================================================================  ===================  ====================  ====================  ============
 
+.. [#f1] Default buffer size in 4.3 is ``1024``.
+
 GUI nodes
 ~~~~~~~~~
 

tutorials/navigation/navigation_using_navigationagents.rst

@@ -40,7 +40,7 @@ NavigationAgent Pathfollowing
 After a ``target_position`` has been set for the agent, the next position to follow in the path
 can be retrieved with the ``get_next_path_position()`` function.
 
-Once the next path position is received move the parent actor node of the agent
+Once the next path position is received, move the parent actor node of the agent
 towards this path position with your own movement code.
 
 .. note::

tutorials/networking/high_level_multiplayer.rst

@@ -205,6 +205,8 @@ To check whether the peer is server or client:
 
     Multiplayer.IsServer();
 
+.. _doc_high_level_multiplayer_rpcs:
+
 Remote procedure calls
 ----------------------
 

tutorials/performance/optimizing_3d_performance.rst

@@ -104,8 +104,22 @@ the viewer a considerable distance for the angle of view to change
 significantly. This can be complex to get working, but may be worth it depending
 on the type of project you are making.
 
-Use instancing (MultiMesh)
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+Use automatic instancing
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+*This is only implemented in the Forward+ renderer, not Mobile or Compatibility.*
+
+If you have many identical objects in your scene, you can use automatic
+instancing to reduce the number of draw calls. This automatically happens for
+MeshInstance3D nodes that use the same mesh and material: no manual setup is required.
+
+For automatic instancing to be effective, the material must be opaque or
+alpha-tested (alpha scissor or alpha hash). Alpha-blended or depth pre-pass
+materials are never instanced this way. Instead, you must use MultiMesh as
+described below.
+
+Use manual instancing (MultiMesh)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If several identical objects have to be drawn in the same place or nearby, try
 using :ref:`MultiMesh <class_MultiMesh>` instead. MultiMesh allows the drawing

tutorials/platform/consoles.rst

@@ -13,13 +13,9 @@ yourself or someone hired to do it, or provided by a third-party company.
 Currently, the only console Godot officially supports is Steam Deck (through the
 official Linux export templates).
 
-The reason other consoles are not officially supported are:
-
-- To develop for consoles, one must be licensed as a company.
-  As an open source project, Godot has no legal structure to provide console ports.
-- Console SDKs are secret and covered by non-disclosure agreements.
-  Even if we could get access to them, we could not publish the platform-specific
-  code under an open source license.
+The reasons other consoles are not officially supported are the risks of legal
+liability, disproportionate cost, and open source licensing issues. The reasons
+are explained in more detail in this article `About Official Console Ports <https://godotengine.org/article/about-official-console-ports/>`__
 
 As explained, however, it is possible to port your games to consoles thanks to
 services provided by third-party companies.
@@ -46,7 +42,7 @@ to a console platform is as follows:
   be more accepting of smaller developers, but this is not guaranteed.
 - Get access to developer tools and order a console specially made for
   developers (*devkit*). The cost of those devkits is confidential.
-- Port the engine to the console platform or pay a company to do it.
+- Port your game to the console platform or pay a company to do it.
 - To be published, your game needs to be rated in the regions you'd like to sell
   it in. For example, game ratings are handled by `ESRB <https://www.esrb.org/>`__
   in North America, and `PEGI <https://pegi.info/>`__ in Europe. Indie developers
@@ -62,10 +58,10 @@ Third-party support
 -------------------
 
 Console ports of Godot are offered by third-party companies (which have
-ported Godot on their own). These companies also offer publishing of
+ported Godot on their own). Some of these companies also offer publishing of
 your games to various consoles.
 
-Following is the list of providers:
+The following is a list of some of the providers:
 
 - `Lone Wolf Technology <https://www.lonewolftechnology.com/>`_ offers
   Switch and Playstation 4 porting and publishing of Godot games.
@@ -81,10 +77,23 @@ Following is the list of providers:
   Switch porting and publishing of Godot games.
 - `Seaven Studio <https://www.seaven-studio.com/>`_ offers
   Switch, Xbox One, Xbox Series, PlayStation 4 & PlayStation 5 porting of Godot games.
-- `Sickhead Games <https://www.sickhead.com>`_ offers console porting to Nintendo Switch, PlayStation 4, PlayStation 5, Xbox One, and Xbox Series X/S for Godot games.
-- `W4 Games <https://www.w4games.com/>`_ offers console ports for Nintendo Switch, Xbox Series X/S, and Playstation 5 for you to port your game yourself.
+- `Sickhead Games <https://www.sickhead.com>`_ offers 
+  console porting to Nintendo Switch, PlayStation 4, PlayStation 5, Xbox One, and Xbox Series X/S for Godot games.
 
 If your company offers porting, or porting *and* publishing services for Godot games,
 feel free to
 `contact the Godot Foundation <https://godot.foundation/#contact>`_
 to add your company to the list above.
+
+Middleware
+----------
+
+Middleware ports are available through the console vendor's website. They
+provide you with a version of Godot that can natively run on the console.
+Typically, you do the actual work of adapting your game to the various consoles
+yourself. In other words, the middleware provided has ported *Godot* to the
+console, you just need to port your game, which is significantly less work in
+most cases.
+
+- `W4 Games <https://www.w4games.com/>`_ offers official 
+  middleware ports for Nintendo Switch, Xbox Series X/S, and Playstation 5.

tutorials/plugins/editor/making_main_screen_plugins.rst

@@ -10,7 +10,7 @@ What this tutorial covers
 
 Main screen plugins allow you to create
 new UIs in the central part of the editor, which appear next to the
-"2D", "3D", "Script", and "AssetLib" buttons. Such editor plugins are
+"2D", "3D", "Script", "Game", and "AssetLib" buttons. Such editor plugins are
 referred as "Main screen plugins".
 
 This tutorial leads you through the creation of a basic main screen plugin.

tutorials/scripting/c_sharp/c_sharp_basics.rst

@@ -60,7 +60,7 @@ Configuring an external editor
 
 C# support in Godot's built-in script editor is minimal. Consider using an
 external IDE or editor, such as  `Visual Studio Code <https://code.visualstudio.com/>`__
-or MonoDevelop. These provide autocompletion, debugging, and other
+or `Visual Studio <https://visualstudio.microsoft.com/>`__. These provide autocompletion, debugging, and other
 useful features for C#. To select an external editor in Godot,
 click on **Editor → Editor Settings** and scroll down to
 **Dotnet**. Under **Dotnet**, click on **Editor**, and select your

tutorials/scripting/c_sharp/c_sharp_exports.rst

@@ -455,7 +455,7 @@ following as "Thing 1", "Thing 2", "Another Thing". The value will be stored as
     }
 
     [Export]
-    public MyEnum MyEnum { get; set; }
+    public MyEnum MyEnumCurrent { get; set; }
 
 Integer and string members can also be limited to a specific list of values using the
 ``[Export]`` annotation with the ``PropertyHint.Enum`` hint.

tutorials/scripting/c_sharp/c_sharp_features.rst

@@ -111,7 +111,7 @@ For example, you can change code based on the platform:
 
         public override void _Ready()
         {
-    #if (GODOT_32 || GODOT_MOBILE || GODOT_WEB)
+    #if (GODOT_MOBILE || GODOT_WEB)
             // Use simple objects when running on less powerful systems.
             SpawnSimpleObjects();
     #else
@@ -157,8 +157,6 @@ Full list of defines
 
 * ``GODOT_REAL_T_IS_DOUBLE`` is defined when the ``GodotFloat64`` property is set to ``true``.
 
-* One of ``GODOT_64`` or ``GODOT_32`` is defined depending on if the architecture is 64-bit or 32-bit.
-
 * One of ``GODOT_LINUXBSD``, ``GODOT_WINDOWS``, ``GODOT_OSX``,
   ``GODOT_ANDROID``, ``GODOT_IOS``, ``GODOT_WEB``
   depending on the OS. These names may change in the future.

tutorials/scripting/gdextension/gdextension_c_example.rst

@@ -760,7 +760,7 @@ the destructor.
 
     ...
 
-In the ``gdexample.cpp`` file, we will initialize these values in the constructor
+In the ``gdexample.c`` file, we will initialize these values in the constructor
 and add the implementations for those new functions, which are quite trivial:
 
 .. code-block:: c

tutorials/scripting/gdextension/what_is_gdextension.rst

@@ -93,6 +93,7 @@ The bindings below are developed and maintained by the community:
 - `Nim <https://github.com/godot-nim/gdext-nim>`__
 - `Rust <https://github.com/godot-rust/gdext>`__
 - `Swift <https://github.com/migueldeicaza/SwiftGodot>`__
+- `Odin <https://github.com/dresswithpockets/odin-godot>`__
 
 .. note::
 

tutorials/scripting/gdscript/gdscript_exports.rst

@@ -5,8 +5,9 @@ GDScript exported properties
 
 In Godot, class members can be exported. This means their value gets saved along
 with the resource (such as the :ref:`scene <class_PackedScene>`) they're
-attached to. They will also be available for editing in the property editor.
-Exporting is done by using the ``@export`` annotation.
+attached to, and get transferred over when using :ref:`RPCs <doc_high_level_multiplayer_rpcs>`.
+They will also be available for editing in the property editor. Exporting is done by using
+the ``@export`` annotation.
 
 ::
 
@@ -475,7 +476,7 @@ For example, this exposes the ``altitude`` property with no range limits but a
 
 ::
 
-    @export_custom(PROPERTY_HINT_NONE, "altitude:m") var altitude: Vector3
+    @export_custom(PROPERTY_HINT_NONE, "suffix:m") var altitude: float
 
 The above is normally not feasible with the standard ``@export_range`` syntax,
 since it requires defining a range.

tutorials/scripting/gdscript/gdscript_format_string.rst

@@ -6,7 +6,7 @@ GDScript format strings
 Godot offers multiple ways to dynamically change the contents of strings:
 
 - Format strings: ``var string = "I have %s cats." % "3"``
-- The ``String.format()`` method: ``var string = "I have {} cats.".format([3])``
+- The ``String.format()`` method: ``var string = "I have {0} cats.".format([3])``
 - String concatenation: ``var string = "I have " + str(3) + " cats."``
 
 This page explains how to use format strings, and briefly explains the ``format()``