mirror of
https://github.com/godotengine/godot-docs.git
synced 2025-12-31 17:49:03 +03:00
Fix various minor typos
This commit is contained in:
@@ -44,7 +44,7 @@ Here are some quick links to the areas you might be interested in:
|
||||
|
||||
## License
|
||||
|
||||
At the exception of the `classes/` folder, all the content of this repository is licensed under the Creative Commons Attribution 3.0 Unported license ([CC BY 3.0](https://creativecommons.org/licenses/by/3.0/)) and is to be attributed to "Juan Linietsky, Ariel Manzur and the Godot community".
|
||||
With the exception of the `classes/` folder, all the content of this repository is licensed under the Creative Commons Attribution 3.0 Unported license ([CC BY 3.0](https://creativecommons.org/licenses/by/3.0/)) and is to be attributed to "Juan Linietsky, Ariel Manzur and the Godot community".
|
||||
See [LICENSE.txt](/LICENSE.txt) for details.
|
||||
|
||||
The files in the `classes/` folder are derived from [Godot's main source repository](https://github.com/godotengine/godot) and are distributed under the MIT license, with the same authors as above.
|
||||
|
||||
@@ -17,21 +17,21 @@ For more information on the scripts themselves, see their help output.
|
||||
To install requirements: `pip3 install -r requirements.txt`.
|
||||
Git is also required and needs to be available in the `PATH`.
|
||||
To interact with the Read the Docs API, a valid API key must be set as
|
||||
`RTD_AUTH_TOKEN` (either as a environment variable or in a [.env file](https://pypi.org/project/python-dotenv/)).
|
||||
`RTD_AUTH_TOKEN` (either as an environment variable or in a [.env file](https://pypi.org/project/python-dotenv/)).
|
||||
|
||||
## Usage
|
||||
|
||||
Lets say we recently renamed some files in the Git branch `3.4` (compared to the `stable` branch), and now we want to create redirects for these.
|
||||
Let's say we recently renamed some files in the Git branch `3.4` (compared to the `stable` branch), and now we want to create redirects for these.
|
||||
For this, we would (after setting up the API token and requirements, see Setup above):
|
||||
|
||||
> python convert_git_renames_to_csv.py stable 3.4
|
||||
|
||||
This should output a list of the redirects to create. Lets append these to the redirects file:
|
||||
This should output a list of the redirects to create. Let's append these to the redirects file:
|
||||
|
||||
> python convert_git_renames_to_csv.py stable 3.4 >> redirects.csv
|
||||
|
||||
After this, redirects for renamed files should have been appended to `redirects.csv`. You may want to double check that!
|
||||
Now lets submit these to ReadTheDocs and create redirects there:
|
||||
After this, redirects for renamed files should have been appended to `redirects.csv`. You may want to double-check that!
|
||||
Now let's submit these to ReadTheDocs and create redirects there:
|
||||
|
||||
> python create_redirects.py
|
||||
|
||||
|
||||
@@ -141,5 +141,5 @@ effects of each of them.
|
||||
- **SubViewportContainer shrink transform**
|
||||
:ref:`stretch <class_SubViewportContainer_property_stretch>` together with
|
||||
:ref:`stretch_shrink <class_SubViewportContainer_property_stretch_shrink>` declare for a
|
||||
*SubViewportContaner* if and by what integer factor the contained *SubViewport* should be
|
||||
*SubViewportContainer* if and by what integer factor the contained *SubViewport* should be
|
||||
scaled in comparison to the container's size.
|
||||
|
||||
@@ -139,7 +139,7 @@ Write your titles like plain sentences, without capitalizing each word:
|
||||
- **Good:** Understanding signals in Godot
|
||||
- **Bad:** Understanding Signals In Godot
|
||||
|
||||
Only propers nouns, projects, people, and node class names should have their
|
||||
Only proper nouns, projects, people, and node class names should have their
|
||||
first letter capitalized.
|
||||
|
||||
Sphinx and reStructuredText syntax
|
||||
|
||||
@@ -47,7 +47,7 @@ editing, such as precise cropping or adding outlines, Squoosh can be used.
|
||||
source, and doesn't give Google any image rights by using it. When choosing
|
||||
compression if you can get an image that's under 300KB in size use lossless
|
||||
compression. If it's over 300KB, use just enough lossy compression to get it
|
||||
under that size. If this results in noticable compression artifacts using less
|
||||
under that size. If this results in noticeable compression artifacts using less
|
||||
compression is fine, even if the file size is bigger.
|
||||
|
||||
If you already have an image editor such as GIMP, Krita or Photoshop installed
|
||||
@@ -110,7 +110,7 @@ means the image will not lose detail and will be as small as possible.
|
||||
|
||||
If the image is over 300KB in size try compressing it losslessly using `Squoosh <https://squoosh.app/>`_.
|
||||
If it's still over 300KB change to lossy compression and slowly increase the compression until it's under
|
||||
300KB. If this results in noticable compression artifacts using less compression is fine, even if the file
|
||||
300KB. If this results in noticeable compression artifacts using less compression is fine, even if the file
|
||||
size is bigger.
|
||||
|
||||
Outlines, arrows and text
|
||||
|
||||
@@ -165,7 +165,7 @@ use the following labels:
|
||||
- *Discussion*: the issue is not consensual and needs further
|
||||
discussion to define what exactly should be done to address the
|
||||
topic.
|
||||
- *Enhancememnt*: new information to be added in an existing page.
|
||||
- *Enhancement*: new information to be added in an existing page.
|
||||
- *Good first issue*: the issue is *assumed* to be an easy one to fix, which makes
|
||||
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
|
||||
|
||||
@@ -61,7 +61,7 @@ to generate a universal download link.
|
||||
.. image:: img/testing_pull_requests_access_fork.png
|
||||
|
||||
- Now that you are on the fork's branch page, click the ``.github`` folder at the top of the file list.
|
||||
Then, click on the ``workflows`` folder (whicb is inside the ``.github`` folder).
|
||||
Then, click on the ``workflows`` folder (which is inside the ``.github`` folder).
|
||||
Click the workflow file for the platform you wish to download artifacts for.
|
||||
*After* clicking on the file (which opens the file view), copy the page URL from your browser's address bar.
|
||||
|
||||
|
||||
@@ -85,7 +85,7 @@ In Godot, occlusion culling works by rasterizing the scene's occluder geometry
|
||||
to a low-resolution buffer on the CPU. This is done using
|
||||
the software raytracing library `Embree <https://github.com/embree/embree>`__.
|
||||
|
||||
The engine then uses this low-resolution buffer to test occludees'
|
||||
The engine then uses this low-resolution buffer to test the occludee's
|
||||
:abbr:`AABB (Axis-Aligned Bounding Box)` against the occluder shapes.
|
||||
The occludee's :abbr:`AABB (Axis-Aligned Bounding Box)` must be *fully occluded*
|
||||
by the occluder shape to be culled.
|
||||
|
||||
@@ -19,7 +19,7 @@ value to spawn more particles at the cost of performance.
|
||||
The ``Amount Ratio`` property is the ratio of particles compared to the amount that will be emitted.
|
||||
If it's less than ``1.0``, the amount of particles emitted through the lifetime will be the ``Amount`` *
|
||||
``Amount Ratio``. Changing this value while emitted doesn't affect already created particles and doesn't
|
||||
cause the particle system to restart. It's useful for making effects where the number of emitted particels
|
||||
cause the particle system to restart. It's useful for making effects where the number of emitted particles
|
||||
varies over time.
|
||||
|
||||
You can set another particle node as a ``Sub Emitter``, which will be spawned as a child of each
|
||||
|
||||
@@ -111,7 +111,7 @@ choose from:
|
||||
- **Disabled:** Uses hysteresis to switch between LOD levels instantly. This
|
||||
prevents situations where LOD levels are switched back and forth quickly when
|
||||
the player moves forward and then backward at the LOD transition point. The
|
||||
hystereis distance is determined by **Visibility Range > Begin Margin** and
|
||||
hysteresis distance is determined by **Visibility Range > Begin Margin** and
|
||||
**Visibility Range > End Margin**. This mode provides the best performance as
|
||||
it doesn't force rendering to become transparent during the fade transition.
|
||||
- **Self:** Uses alpha blending to smoothly fade between LOD levels. The node
|
||||
|
||||
@@ -62,7 +62,7 @@ Animation Mode
|
||||
---------------------------
|
||||
Godot and Blender have different structure to store animation data.
|
||||
In Godot animation data is stored in an AnimationPlayer node, instead
|
||||
of in each animated node. In order to fix this inconsistence and still
|
||||
of in each animated node. In order to fix this inconsistency and still
|
||||
make the animation play versatile, this add-on has three animation exporting
|
||||
modes.
|
||||
|
||||
|
||||
@@ -231,7 +231,7 @@ in another context without any extra changes to its API.
|
||||
satisfied? Other programmers, and especially designers and writers, will need
|
||||
clear instructions in the messages telling them what to do to configure it.
|
||||
|
||||
So, why does all this complex switcharoo work? Well, because scenes operate
|
||||
So, why does all this complex switcheroo work? Well, because scenes operate
|
||||
best when they operate alone. If unable to work alone, then working with
|
||||
others anonymously (with minimal hard dependencies, i.e. loose coupling)
|
||||
is the next best thing. Inevitably, changes may need to be made to a class and
|
||||
|
||||
@@ -51,7 +51,7 @@ Supported platforms
|
||||
the project should be exported to.
|
||||
|
||||
- **Desktop platforms:** Exports the project with debugging enabled and runs it
|
||||
on the remove computer via SSH.
|
||||
on the remote computer via SSH.
|
||||
|
||||
- **Web:** Starts a local web server and runs the exported project by opening
|
||||
the default web browser. This is only accessible on ``localhost`` by default.
|
||||
|
||||
@@ -14,8 +14,8 @@ or crawling actors so they can find paths through those narrow sections in your
|
||||
When an actor changes locomotion state, e.g. stands up, starts
|
||||
crouching or crawling, query the appropriate map for a path.
|
||||
|
||||
If the avoidance behavior should also change with the locomotion e.g. only avoid while standing or only avoid
|
||||
other agents in the same locomotion state, switch the actors's avoidance agent to another avoidance map with each locomotion change.
|
||||
If the avoidance behavior should also change with the locomotion e.g. only avoid while standing or only avoid
|
||||
other agents in the same locomotion state, switch the actor's avoidance agent to another avoidance map with each locomotion change.
|
||||
|
||||
.. tabs::
|
||||
.. code-tab:: gdscript GDScript
|
||||
|
||||
@@ -94,7 +94,7 @@ It uses the NavigationServer2D and a NavigationAgent2D for path movement.
|
||||
|
||||
.. image:: img/nav_2d_min_setup_step1.png
|
||||
|
||||
#. Define the moveable navigation area with the NavigationPolygon draw tool. Then click
|
||||
#. Define the movable navigation area with the NavigationPolygon draw tool. Then click
|
||||
the `Bake NavigationPolygon`` button on the toolbar.
|
||||
|
||||
.. image:: img/nav_2d_min_setup_step2.png
|
||||
|
||||
@@ -49,8 +49,8 @@ Ideally when an obstacle is moving the static vertices are removed and instead t
|
||||
Similar to agents the obstacles can make use of the ``avoidance_layers`` bitmask.
|
||||
All agents with a matching bit on their own avoidance mask will avoid the obstacle.
|
||||
|
||||
Procedual obstacles
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
Procedural obstacles
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
New obstacles can be created without a Node directly on the NavigationServer.
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ for the query and a ``NavigationPathQueryResult`` that receives (regular) update
|
||||
:ref:`NavigationPathQueryParameters3D<class_NavigationPathQueryParameters3D>` respectively.
|
||||
|
||||
2D and 3D versions of ``NavigationPathQueryResult`` are available as
|
||||
:ref:`NavigationPathQuerResult2D<class_NavigationPathQueryResult2D>` and
|
||||
:ref:`NavigationPathQueryResult2D<class_NavigationPathQueryResult2D>` and
|
||||
:ref:`NavigationPathQueryResult3D<class_NavigationPathQueryResult3D>` respectively.
|
||||
|
||||
Both parameters and result are used as a pair with the ``NavigationServer.query_path()`` function.
|
||||
|
||||
@@ -51,7 +51,7 @@ This is the range where individual integer values can be represented in a
|
||||
floating-point number:
|
||||
|
||||
- **Single-precision float range (represent all integers):** Between -16,777,216 and 16,777,216
|
||||
- **Double-precision float range (represent all integers):** Between -9 quadrillon and 9 quadrillon
|
||||
- **Double-precision float range (represent all integers):** Between -9 quadrillion and 9 quadrillion
|
||||
|
||||
+----------------------+-----------------------+-----------------------+-----------------------------------------------------------------------------+
|
||||
| Range | Single step | Double step | Comment |
|
||||
|
||||
@@ -312,7 +312,7 @@ Using a v2 Android plugin as an Android library
|
||||
|
||||
Since they are also Android libraries, Godot v2 Android plugins can be stripped from their ``EditorExportPlugin`` packaging and provided as raw ``AAR`` binaries for use as libraries alongside the :ref:`Godot Android library <doc_android_library>` by Android apps.
|
||||
|
||||
If targetting this use-case, make sure to include additional instructions for how the ``AAR`` binaries should be included (e.g: custom additions to the Android app's manifest).
|
||||
If targeting this use-case, make sure to include additional instructions for how the ``AAR`` binaries should be included (e.g: custom additions to the Android app's manifest).
|
||||
|
||||
Reference implementations
|
||||
-------------------------
|
||||
|
||||
@@ -167,7 +167,7 @@ default ``60``, or set ``Engine.physics_ticks_per_second`` at run-time in a
|
||||
script. Values that are a multiple of the monitor refresh rate (typically
|
||||
``60``) work best when physics interpolation is disabled, as they will avoid
|
||||
jitter. This means values such as ``120``, ``180`` and ``240`` are good starting
|
||||
points. As a bonus, higher physics FPSes make tunneling and physics unstability
|
||||
points. As a bonus, higher physics FPSes make tunneling and physics instability
|
||||
issues less likely to occur.
|
||||
|
||||
The downside of increasing physics FPS is that CPU usage will increase, which
|
||||
|
||||
@@ -203,12 +203,12 @@ The XR runtime can use this for improved reprojection.
|
||||
Startup Alert
|
||||
-------------
|
||||
|
||||
If enabled this will result in an alert message presented to the user if OpenXR fails to start.
|
||||
We don't always receive feedback from the XR system as to why starting fails. If we do we log this to the console.
|
||||
If enabled, this will result in an alert message presented to the user if OpenXR fails to start.
|
||||
We don't always receive feedback from the XR system as to why starting fails. If we do, we log this to the console.
|
||||
Common failure reasons are:
|
||||
|
||||
- No OpenXR runtime is installed on the host system.
|
||||
- Microsofts WMR OpenXR runtime is currently active, this only supports DirectX and will fail if OpenGL or Vulkan is used.
|
||||
- Microsoft's WMR OpenXR runtime is currently active, this only supports DirectX and will fail if OpenGL or Vulkan is used.
|
||||
- SteamVR is used but no headset is connected/turned on.
|
||||
|
||||
Disable this if you support a fallback mode in your game so it can be played in desktop mode when no VR headset is connected,
|
||||
|
||||
@@ -201,7 +201,7 @@ OpenXR defines a number of bindable input poses that are commonly available for
|
||||
There are no rules for which poses are supported for different controllers.
|
||||
The poses OpenXR currently defines are:
|
||||
|
||||
* The aim pose on most controllers is positioned slightly infront of the controller and aims forward.
|
||||
* The aim pose on most controllers is positioned slightly in front of the controller and aims forward.
|
||||
This is a great pose to use for laser pointers or to align the muzzle of a weapon with.
|
||||
* The grip pose on most controllers is positioned where the grip button is placed on the controller.
|
||||
The orientation of this pose differs between controllers and can differ for the same controller on different XR runtimes.
|
||||
|
||||
Reference in New Issue
Block a user