mirror of
https://github.com/Relintai/pandemonium_engine_docs.git
synced 2025-01-06 15:00:03 +01:00
More cleanups.
This commit is contained in:
parent
322c693483
commit
73841919b6
@ -54,7 +54,7 @@ To add images, please put them in an `img/` folder next to the .rst file with a
|
||||
|
||||
Similarly, you can include attachments (like assets as support material for a tutorial) by placing them into a `files/` folder next to the .rst file, and using this inline markup:
|
||||
```rst
|
||||
:download:`myfilename.zip <files/myfilename.zip )`
|
||||
:download:`myfilename.zip ( files/myfilename.zip )`
|
||||
```
|
||||
|
||||
## Building with Sphinx
|
||||
|
@ -112,11 +112,11 @@ Godot uses `FreeType ( https://www.freetype.org/ )`_ to render fonts. Its licens
|
||||
requires attribution, so the following text must be included together with the
|
||||
Godot license:
|
||||
|
||||
Portions of this software are copyright © <year> The FreeType Project (www.freetype.org). All rights reserved.
|
||||
Portions of this software are copyright © ( year> The FreeType Project (www.freetype.org). All rights reserved.
|
||||
|
||||
.. note::
|
||||
|
||||
<year> should correspond to the value from the FreeType version used
|
||||
( year> should correspond to the value from the FreeType version used
|
||||
in your build. This information can be found in the editor by opening
|
||||
the **Help > About** dialog and going to the **Third-party Licenses**
|
||||
tab.
|
||||
@ -163,5 +163,5 @@ as the latest version of OpenSSL currently uses (as of April 2022).
|
||||
.. note::
|
||||
|
||||
If you exported your project using a
|
||||
`custom build with specific modules disabled <doc_optimizing_for_size )`,
|
||||
`custom build with specific modules disabled ( doc_optimizing_for_size )`,
|
||||
you don't need to list the disabled modules' licenses in your exported project.
|
||||
|
@ -5,7 +5,7 @@ Documentation changelog
|
||||
|
||||
The documentation is continually being improved. The release of version 3.2
|
||||
includes many new tutorials, many fixes and updates for old tutorials, and many updates
|
||||
to the `class reference <toc-class-ref )`. Below is a list of new tutorials
|
||||
to the `class reference ( toc-class-ref )`. Below is a list of new tutorials
|
||||
added since version 3.1.
|
||||
|
||||
.. note:: This document only contains new tutorials so not all changes are reflected,
|
||||
@ -83,7 +83,7 @@ Creating content
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Procedural geometry series:
|
||||
- `Procedural geometry <toc-procedural_geometry )`
|
||||
- `Procedural geometry ( toc-procedural_geometry )`
|
||||
- `doc_arraymesh`
|
||||
- `doc_surfacetool`
|
||||
- `doc_meshdatatool`
|
||||
|
22
about/faq.md
22
about/faq.md
@ -38,7 +38,7 @@ Which platforms are supported by Godot?
|
||||
* Windows
|
||||
* macOS
|
||||
* X11 (Linux, \*BSD)
|
||||
* `Web <doc_using_the_web_editor )`
|
||||
* `Web ( doc_using_the_web_editor )`
|
||||
* Android (experimental)
|
||||
|
||||
**For exporting your games:**
|
||||
@ -60,15 +60,15 @@ Additionally, there is some unofficial third-party work being done on building
|
||||
for some consoles. However, none of this is included in the default build
|
||||
scripts or export templates at this time.
|
||||
|
||||
For more on this, see the sections on `exporting <toc-learn-workflow-export )`
|
||||
and `compiling Godot yourself <toc-devel-compiling )`.
|
||||
For more on this, see the sections on `exporting ( toc-learn-workflow-export )`
|
||||
and `compiling Godot yourself ( toc-devel-compiling )`.
|
||||
|
||||
Which programming languages are supported in Godot?
|
||||
---------------------------------------------------
|
||||
|
||||
The officially supported languages for Godot are GDScript, Visual Scripting,
|
||||
C#, and C++. See the subcategories for each language in the
|
||||
`scripting <toc-learn-scripting )` section.
|
||||
`scripting ( toc-learn-scripting )` section.
|
||||
|
||||
If you are just starting out with either Godot or game development in general,
|
||||
GDScript is the recommended language to learn and use since it is native to Godot.
|
||||
@ -99,7 +99,7 @@ up to maximize Godot's potential in the least amount of code, affording both nov
|
||||
and expert developers alike to capitalize on Godot's strengths as fast as possible.
|
||||
If you've ever written anything in a language like Python before then you'll feel
|
||||
right at home. For examples, history, and a complete overview of the power GDScript
|
||||
offers you, check out the `GDScript scripting guide <doc_gdscript )`.
|
||||
offers you, check out the `GDScript scripting guide ( doc_gdscript )`.
|
||||
|
||||
There are several reasons to use GDScript--especially when you are prototyping, in
|
||||
alpha/beta stages of your project, or are not creating the next AAA title--but the
|
||||
@ -225,7 +225,7 @@ Linux
|
||||
This is typically `/usr/local/bin/godot` or `/usr/bin/godot`.
|
||||
Doing this requires administrator privileges,
|
||||
but this also allows you to
|
||||
`run the Godot editor from a terminal <doc_command_line_tutorial )` by entering `godot`.
|
||||
`run the Godot editor from a terminal ( doc_command_line_tutorial )` by entering `godot`.
|
||||
|
||||
- If you cannot move the Godot editor binary to a protected location, you can
|
||||
keep the binary somewhere in your home directory, and modify the `Path=`
|
||||
@ -309,7 +309,7 @@ functionality in Godot. This is why we are aiming to move some core
|
||||
functionality to officially supported add-ons in future versions of Godot. In
|
||||
terms of binary size, this also has the advantage of making you pay only for what
|
||||
you actually use in your project. (In the meantime, you can
|
||||
`compile custom export templates with unused features disabled <doc_optimizing_for_size )`
|
||||
`compile custom export templates with unused features disabled ( doc_optimizing_for_size )`
|
||||
to optimize the distribution size of your project.)
|
||||
|
||||
How should assets be created to handle multiple resolutions and aspect ratios?
|
||||
@ -344,7 +344,7 @@ This is mostly needed for 2D, as in 3D it's just a matter of Camera XFov or YFov
|
||||
if there is one aspect ratio and you want black bars to appear
|
||||
instead. This is also explained in `doc_multiple_resolutions`.
|
||||
|
||||
4. For user interfaces, use the `anchoring <doc_size_and_anchors )`
|
||||
4. For user interfaces, use the `anchoring ( doc_size_and_anchors )`
|
||||
to determine where controls should stay and move. If UIs are more
|
||||
complex, consider learning about Containers.
|
||||
|
||||
@ -359,7 +359,7 @@ How can I extend Godot?
|
||||
-----------------------
|
||||
|
||||
For extending Godot, like creating Godot Editor plugins or adding support
|
||||
for additional languages, take a look at `EditorPlugins <doc_making_plugins )`
|
||||
for additional languages, take a look at `EditorPlugins ( doc_making_plugins )`
|
||||
and tool scripts.
|
||||
|
||||
Also, see the official blog posts on these topics:
|
||||
@ -474,9 +474,9 @@ have to deal with the LGPL licensing caveats that come with GTK or Qt. Lastly,
|
||||
this means Godot is "eating its own dog food" since the editor itself is one of
|
||||
the most complex users of Godot's UI system.
|
||||
|
||||
This custom UI toolkit `can't be used as a library <doc_faq_use_godot_as_library )`,
|
||||
This custom UI toolkit `can't be used as a library ( doc_faq_use_godot_as_library )`,
|
||||
but you can still
|
||||
`use Godot to create non-game applications by using the editor <doc_faq_non_game_applications )`.
|
||||
`use Godot to create non-game applications by using the editor ( doc_faq_non_game_applications )`.
|
||||
|
||||
.. _doc_faq_why_not_stl:
|
||||
|
||||
|
@ -20,12 +20,12 @@ where to look if you need info on a specific feature.
|
||||
Before you start
|
||||
----------------
|
||||
|
||||
The `Tutorials and resources <doc_community_tutorials )` page lists
|
||||
The `Tutorials and resources ( doc_community_tutorials )` page lists
|
||||
video tutorials contributed by the community. If you prefer video to text,
|
||||
those may be worth a look.
|
||||
|
||||
In case you have trouble with one of the tutorials or your project,
|
||||
you can find help on the various `Community channels <doc_community_channels )`,
|
||||
you can find help on the various `Community channels ( doc_community_channels )`,
|
||||
especially the Godot Discord community, Q&A, and IRC.
|
||||
|
||||
About Godot Engine
|
||||
@ -51,7 +51,7 @@ if you need a quick writeup about Godot Engine.
|
||||
|
||||
For a more in-depth view of the engine, you are encouraged to read this
|
||||
documentation further, especially the `Step by step
|
||||
<toc-learn-step_by_step )` tutorial.
|
||||
( toc-learn-step_by_step )` tutorial.
|
||||
|
||||
About the documentation
|
||||
-----------------------
|
||||
@ -86,7 +86,7 @@ relatively intuitive:
|
||||
- The `sec-learn` section is the *raison d'être* of this
|
||||
documentation, as it contains all the necessary information on using the
|
||||
engine to make games. It starts with the `Step by step
|
||||
<toc-learn-step_by_step )` tutorial which should be the entry point for all
|
||||
( toc-learn-step_by_step )` tutorial which should be the entry point for all
|
||||
new users.
|
||||
- The `sec-tutorials` section can be read as needed,
|
||||
in any order. It contains feature-specific tutorials and documentation.
|
||||
|
@ -33,8 +33,8 @@ Platforms
|
||||
|
||||
- Android 4.4 and later.
|
||||
- iOS 10.0 and later.
|
||||
- `Consoles <doc_consoles )`.
|
||||
- `Headless Linux and macOS servers <doc_exporting_for_dedicated_servers )`.
|
||||
- `Consoles ( doc_consoles )`.
|
||||
- `Headless Linux and macOS servers ( doc_exporting_for_dedicated_servers )`.
|
||||
|
||||
Godot aims to be as platform-independent as possible and can be ported to new
|
||||
platforms with relative ease.
|
||||
@ -46,9 +46,9 @@ Editor
|
||||
|
||||
- Scene tree editor.
|
||||
- Built-in script editor.
|
||||
- Support for `external script editors <doc_external_editor )` such as
|
||||
- Support for `external script editors ( doc_external_editor )` such as
|
||||
Visual Studio Code or Vim.
|
||||
- GDScript `debugger <doc_debugger_panel )`.
|
||||
- GDScript `debugger ( doc_debugger_panel )`.
|
||||
|
||||
- No support for debugging in threads yet.
|
||||
- Performance monitoring tools.
|
||||
@ -71,10 +71,10 @@ Editor
|
||||
**Plugins:**
|
||||
|
||||
- Editor plugins can be downloaded from the
|
||||
`asset library <doc_what_is_assetlib )` to extend editor functionality.
|
||||
- `Create your own plugins <doc_making_plugins )` using GDScript to add new
|
||||
`asset library ( doc_what_is_assetlib )` to extend editor functionality.
|
||||
- `Create your own plugins ( doc_making_plugins )` using GDScript to add new
|
||||
features or speed up your workflow.
|
||||
- `Download projects from the asset library <doc_using_assetlib_editor )`
|
||||
- `Download projects from the asset library ( doc_using_assetlib_editor )`
|
||||
in the project manager and import them directly.
|
||||
|
||||
2D graphics
|
||||
@ -275,7 +275,7 @@ Editor
|
||||
|
||||
**Performance:**
|
||||
|
||||
- Occlusion culling with `rooms and portals <doc_rooms_and_portals )`.
|
||||
- Occlusion culling with `rooms and portals ( doc_rooms_and_portals )`.
|
||||
Supports gameplay notifications with primary and secondary visibility to
|
||||
disable AI/physics processing for nodes that don't need it.
|
||||
- Real-time occluder shapes (sphere and polygon). Not as effective as rooms and portals
|
||||
@ -291,8 +291,8 @@ Editor
|
||||
^^^^^^^^
|
||||
|
||||
- Built-in meshes: cube, cylinder/cone, (hemi)sphere, prism, plane, quad.
|
||||
- Tools for `procedural geometry generation <doc_procedural_geometry )`.
|
||||
- `Constructive solid geometry <doc_csg_tools )` (intended for prototyping).
|
||||
- Tools for `procedural geometry generation ( doc_procedural_geometry )`.
|
||||
- `Constructive solid geometry ( doc_csg_tools )` (intended for prototyping).
|
||||
- Path3D node to represent a path in 3D space.
|
||||
|
||||
- Can be drawn in the editor or generated procedurally.
|
||||
@ -326,7 +326,7 @@ Shaders
|
||||
|
||||
- *2D:* Custom vertex, fragment, and light shaders.
|
||||
- *3D:* Custom vertex, fragment, light, and sky shaders.
|
||||
- Text-based shaders using a `shader language inspired by GLSL <doc_shading_language )`.
|
||||
- Text-based shaders using a `shader language inspired by GLSL ( doc_shading_language )`.
|
||||
- Visual shader editor.
|
||||
|
||||
- Support for visual shader plugins.
|
||||
@ -338,19 +338,19 @@ Scripting
|
||||
|
||||
- Object-oriented design pattern with scripts extending nodes.
|
||||
- Signals and groups for communicating between scripts.
|
||||
- Support for `cross-language scripting <doc_cross_language_scripting )`.
|
||||
- Support for `cross-language scripting ( doc_cross_language_scripting )`.
|
||||
- Many 2D and 3D linear algebra data types such as vectors and transforms.
|
||||
|
||||
`GDScript: <toc-learn-scripting-gdscript )`
|
||||
`GDScript: ( toc-learn-scripting-gdscript )`
|
||||
|
||||
- `High-level interpreted language <doc_gdscript )` with
|
||||
`optional static typing <doc_gdscript_static_typing )`.
|
||||
- `High-level interpreted language ( doc_gdscript )` with
|
||||
`optional static typing ( doc_gdscript_static_typing )`.
|
||||
- Syntax inspired by Python.
|
||||
- Syntax highlighting is provided on GitHub.
|
||||
- `Use threads <doc_using_multiple_threads )` to perform asynchronous actions
|
||||
- `Use threads ( doc_using_multiple_threads )` to perform asynchronous actions
|
||||
or make use of multiple processor cores.
|
||||
|
||||
`C#: <toc-learn-scripting-C# )`
|
||||
`C#: ( toc-learn-scripting-C# )`
|
||||
|
||||
- Packaged in a separate binary to keep file sizes and dependencies down.
|
||||
- Uses Mono 6.x.
|
||||
@ -360,9 +360,9 @@ Scripting
|
||||
- Supports all platforms.
|
||||
- Using an external editor is recommended to benefit from IDE functionality.
|
||||
|
||||
`VisualScript: <toc-learn-scripting-visual_script )`
|
||||
`VisualScript: ( toc-learn-scripting-visual_script )`
|
||||
|
||||
- `Graph-based visual scripting language <doc_what_is_visual_script )`.
|
||||
- `Graph-based visual scripting language ( doc_what_is_visual_script )`.
|
||||
- Works best when used for specific purposes (such as level-specific logic)
|
||||
rather than as a language to create entire projects.
|
||||
|
||||
@ -386,7 +386,7 @@ Scripting
|
||||
Future Godot 4.x releases may have VisualScript reimplemented as an extension.
|
||||
|
||||
While Godot 3.x will keep VisualScript supported, we recommend
|
||||
`trying out GDScript <toc-learn-scripting-gdscript )` instead,
|
||||
`trying out GDScript ( toc-learn-scripting-gdscript )` instead,
|
||||
especially if you intend to migrate your project to Godot 4.
|
||||
|
||||
Audio
|
||||
@ -399,7 +399,7 @@ Audio
|
||||
|
||||
- Optional Doppler effect in 2D and 3D.
|
||||
|
||||
- Support for re-routable `audio buses <doc_audio_buses )` and effects
|
||||
- Support for re-routable `audio buses ( doc_audio_buses )` and effects
|
||||
with dozens of effects included.
|
||||
- Listener2D and Listener3D nodes to listen from a position different than the camera.
|
||||
- Audio input to record microphones with real-time access using the AudioEffectCapture class.
|
||||
@ -416,7 +416,7 @@ Audio
|
||||
Import
|
||||
^^^^^^
|
||||
|
||||
- Support for `custom import plugins <doc_import_plugins )`.
|
||||
- Support for `custom import plugins ( doc_import_plugins )`.
|
||||
|
||||
**Formats:**
|
||||
|
||||
@ -492,8 +492,8 @@ Internationalization
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Full support for Unicode including emoji.
|
||||
- Store localization strings using `CSV <doc_internationalizing_games )`
|
||||
or `gettext <doc_localization_using_gettext )`.
|
||||
- Store localization strings using `CSV ( doc_internationalizing_games )`
|
||||
or `gettext ( doc_localization_using_gettext )`.
|
||||
- Use localized strings in your project automatically in GUI elements or by
|
||||
using the `tr()` function.
|
||||
- Support for right-to-left typesetting and text shaping planned in Godot 4.0.
|
||||
@ -516,10 +516,10 @@ Windowing and OS integration
|
||||
- Execute commands in a blocking or non-blocking manner.
|
||||
- Open file paths and URLs using default or custom protocol handlers (if registered on the system).
|
||||
- Parse custom command line arguments.
|
||||
- `Headless/server binaries <doc_exporting_for_dedicated_servers )` can be
|
||||
downloaded for Linux and `compiled for macOS <doc_compiling_for_osx )`.
|
||||
- `Headless/server binaries ( doc_exporting_for_dedicated_servers )` can be
|
||||
downloaded for Linux and `compiled for macOS ( doc_compiling_for_osx )`.
|
||||
Any binary can be used without a window using the `--no-window`
|
||||
`command line argument <doc_command_line_tutorial )`.
|
||||
`command line argument ( doc_command_line_tutorial )`.
|
||||
|
||||
Mobile
|
||||
^^^^^^
|
||||
@ -552,7 +552,7 @@ The editor UI can easily be extended in many ways using add-ons.
|
||||
- Dropdown menus using PopupMenu and OptionButton.
|
||||
- Scrollbars.
|
||||
- Labels.
|
||||
- RichTextLabel for `text formatted using BBCode <doc_bbcode_in_richtextlabel )`.
|
||||
- RichTextLabel for `text formatted using BBCode ( doc_bbcode_in_richtextlabel )`.
|
||||
- Trees (can also be used to represent tables).
|
||||
- Color picker with RGB and HSV modes.
|
||||
- Containers (horizontal, vertical, grid, flow, center, margin, aspect ratio, draggable splitter, ...).
|
||||
@ -600,7 +600,7 @@ Animation
|
||||
File formats
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- Scenes and resources can be saved in `text-based <doc_tscn_file_format )` or binary formats.
|
||||
- Scenes and resources can be saved in `text-based ( doc_tscn_file_format )` or binary formats.
|
||||
|
||||
- Text-based formats are human-readable and more friendly to version control.
|
||||
- Binary formats are faster to save/load for large scenes/resources.
|
||||
@ -617,25 +617,25 @@ File formats
|
||||
- Read XML files using `XMLParser`.
|
||||
- Pack game data into a PCK file (custom format optimized for fast seeking),
|
||||
into a ZIP archive, or directly into the executable for single-file distribution.
|
||||
- `Export additional PCK files<doc_exporting_pcks )` that can be read
|
||||
- `Export additional PCK files( doc_exporting_pcks )` that can be read
|
||||
by the engine to support mods and DLCs.
|
||||
|
||||
Miscellaneous
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
- `Low-level access to servers <doc_using_servers )` which allows bypassing
|
||||
- `Low-level access to servers ( doc_using_servers )` which allows bypassing
|
||||
the scene tree's overhead when needed.
|
||||
- `Command line interface <doc_command_line_tutorial )` for automation.
|
||||
- `Command line interface ( doc_command_line_tutorial )` for automation.
|
||||
|
||||
- Export and deploy projects using continuous integration platforms.
|
||||
- `Shell completion scripts ( https://github.com/godotengine/godot/tree/master/misc/dist/shell )`
|
||||
are available for Bash, zsh and fish.
|
||||
|
||||
- Support for `C++ modules <doc_custom_modules_in_c++ )` statically linked
|
||||
- Support for `C++ modules ( doc_custom_modules_in_c++ )` statically linked
|
||||
into the engine binary.
|
||||
- Engine and editor written in C++03.
|
||||
|
||||
- Can be `compiled <doc_introduction_to_the_buildsystem )` using GCC,
|
||||
- Can be `compiled ( doc_introduction_to_the_buildsystem )` using GCC,
|
||||
Clang and MSVC. MinGW is also supported.
|
||||
- Friendly towards packagers. In most cases, system libraries can be used
|
||||
instead of the ones provided by Godot. The build system doesn't download anything.
|
||||
@ -644,7 +644,7 @@ Miscellaneous
|
||||
|
||||
- Licensed under the permissive MIT license.
|
||||
|
||||
- Open developement process with `contributions welcome <doc_ways_to_contribute )`.
|
||||
- Open developement process with `contributions welcome ( doc_ways_to_contribute )`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
@ -81,7 +81,7 @@ done to improve performance, especially on integrated graphics, where rendering
|
||||
|
||||
To resolve this, open **Project > Project Settings** and enable **Display >
|
||||
Window > Dpi > Allow Hidpi**. On top of that, make sure your project is
|
||||
configured to support `multiple resolutions <doc_multiple_resolutions )`.
|
||||
configured to support `multiple resolutions ( doc_multiple_resolutions )`.
|
||||
|
||||
The project window doesn't appear centered when I run the project.
|
||||
------------------------------------------------------------------
|
||||
@ -89,7 +89,7 @@ The project window doesn't appear centered when I run the project.
|
||||
This is a `known bug ( https://github.com/godotengine/godot/issues/13017 )`. To
|
||||
resolve this, open **Project > Project Settings** and enable **Display > Window
|
||||
> Dpi > Allow Hidpi**. On top of that, make sure your project is configured to
|
||||
support `multiple resolutions <doc_multiple_resolutions )`.
|
||||
support `multiple resolutions ( doc_multiple_resolutions )`.
|
||||
|
||||
The project works when run from the editor, but fails to load some files when running from an exported copy.
|
||||
------------------------------------------------------------------------------------------------------------
|
||||
@ -102,7 +102,7 @@ project, you need to specify `*.json` in the non-resource export filter. See
|
||||
`doc_exporting_projects_export_mode` for more information.
|
||||
|
||||
On Windows, this can also be due to `case sensitivity
|
||||
<doc_project_organization_case_sensitivity )` issues. If you reference a resource
|
||||
( doc_project_organization_case_sensitivity )` issues. If you reference a resource
|
||||
in your script with a different case than on the filesystem, loading will fail
|
||||
once you export the project. This is because the virtual PCK filesystem is
|
||||
case-sensitive, while Windows's filesystem is case-insensitive by default.
|
||||
|
@ -59,7 +59,7 @@ reproduce the bug.
|
||||
|
||||
Before bisecting a regression, you need to set up a build environment to
|
||||
compile Godot from source. To do so, read the
|
||||
`Compiling <toc-devel-compiling )` page for your target platform.
|
||||
`Compiling ( toc-devel-compiling )` page for your target platform.
|
||||
(Compiling Godot from source doesn't require C++ programming knowledge.)
|
||||
|
||||
Note that compiling Godot can take a while on slow hardware (up an hour for
|
||||
@ -88,7 +88,7 @@ following commit hashes depending on the version:
|
||||
To refer to the latest state of the master branch, you can use `master`
|
||||
instead of a commit hash.
|
||||
|
||||
`Get Godot's source code using Git <doc_getting_source )`. Once this
|
||||
`Get Godot's source code using Git ( doc_getting_source )`. Once this
|
||||
is done, in the terminal window, use `cd` to reach the Godot repository
|
||||
folder and enter the following command:
|
||||
|
||||
|
@ -80,7 +80,7 @@ their documentation by completing or improving the text in these tags:
|
||||
- `<constant )`
|
||||
|
||||
Write in a clear and simple language. Always follow the `writing guidelines
|
||||
<doc_docs_writing_guidelines )` to keep your descriptions short and easy to read.
|
||||
( doc_docs_writing_guidelines )` to keep your descriptions short and easy to read.
|
||||
**Do not leave empty lines** in the descriptions: each line in the XML file will
|
||||
result in a new paragraph, even if it is empty.
|
||||
|
||||
|
@ -149,7 +149,7 @@ ones, the following rules should be followed:
|
||||
separation.
|
||||
- Finally, third-party headers (either from `thirdparty` or from the system's
|
||||
include paths) come next and should be included with the < and > symbols, e.g.
|
||||
`#include <png.h )`. The block of third-party headers should also be followed
|
||||
`#include <png.h>`. The block of third-party headers should also be followed
|
||||
by an empty line for separation.
|
||||
- Godot and third-party headers should be included in the file that requires
|
||||
them, i.e. in the `.h` header if used in the declarative code or in the `.cpp`
|
||||
@ -344,7 +344,7 @@ Don't repeat what the code says in a comment. Explain the *why* rather than *how
|
||||
You can use Javadoc-style comments above function or macro definitions. It's
|
||||
recommended to use Javadoc-style comments *only* for methods which are not
|
||||
exposed to scripting. This is because exposed methods should be documented in
|
||||
the `class reference XML <doc_updating_the_class_reference )`
|
||||
the `class reference XML ( doc_updating_the_class_reference )`
|
||||
instead.
|
||||
|
||||
**Example:**
|
||||
|
@ -26,7 +26,7 @@ request triggers a rebuild of the online documentation upon merging.
|
||||
|
||||
.. warning:: The class reference's source files are in the `Godot engine
|
||||
repository ( https://github.com/godotengine/godot )`_. We generate
|
||||
the `Godot API <toc-class-ref )` section of this documentation
|
||||
the `Godot API ( toc-class-ref )` section of this documentation
|
||||
from them. If you want to update the description of a class, its
|
||||
methods, or properties, read
|
||||
`doc_updating_the_class_reference`.
|
||||
@ -173,7 +173,7 @@ using this inline markup:
|
||||
|
||||
.. code:: rst
|
||||
|
||||
:download:`myfilename.zip <files/myfilename.zip )`
|
||||
:download:`myfilename.zip ( files/myfilename.zip )`
|
||||
|
||||
|
||||
License
|
||||
|
@ -34,7 +34,7 @@ There are 3 rules to describe classes:
|
||||
|
||||
.. seealso::
|
||||
|
||||
See the `content guidelines <doc_content_guidelines )` for information
|
||||
See the `content guidelines ( doc_content_guidelines )` for information
|
||||
on the types of documentation you can write in the official documentation.
|
||||
|
||||
7 rules for clear English
|
||||
|
@ -27,7 +27,7 @@ documentation.
|
||||
|
||||
.. warning:: The class reference's source files are in the `Godot engine repository
|
||||
( https://github.com/godotengine/godot )`_. We generate the `Godot API
|
||||
<toc-class-ref )` section of this documentation from them. If you want to update the
|
||||
( toc-class-ref )` section of this documentation from them. If you want to update the
|
||||
description of a class, its methods, or properties, read
|
||||
`doc_updating_the_class_reference`.
|
||||
|
||||
|
@ -258,7 +258,7 @@ external links, etc. Here are some examples::
|
||||
# "Have a look here" is a link pointing to https://docs.godotengine.org/en/latest.
|
||||
# You should translate "Have a look here", but not the URL, unless there is
|
||||
# a matching URL for the same content in your language.
|
||||
# Note: The `, <, >, and _ characters all have a meaning in the hyperlink
|
||||
# Note: The `, ( , >, and _ characters all have a meaning in the hyperlink
|
||||
# syntax and should be preserved.
|
||||
|
||||
Looking for the documentation of the current **development** branch?
|
||||
@ -281,7 +281,7 @@ external links, etc. Here are some examples::
|
||||
|
||||
# Or it can be used with an optional custom title, which should thus be translated:
|
||||
|
||||
See `how to contribute <doc_ways_to_contribute )`.
|
||||
See `how to contribute ( doc_ways_to_contribute )`.
|
||||
|
||||
# You may encounter other Sphinx roles, such as :kbd: used for shortcut keys.
|
||||
# You can translate the content between backticks to match the usual key names,
|
||||
@ -328,7 +328,7 @@ breaks if they are not part of the original translation.
|
||||
.. seealso::
|
||||
|
||||
See our documentation for class reference writers for the `list of
|
||||
BBCode-like tags <doc_class_reference_writing_guidelines_bbcode )` which are used
|
||||
BBCode-like tags ( doc_class_reference_writing_guidelines_bbcode )` which are used
|
||||
throughout the class reference.
|
||||
|
||||
Offline translation and testing
|
||||
@ -357,9 +357,9 @@ upload mode.
|
||||
version.
|
||||
|
||||
If you want to test changes locally (especially for the editor translation), you
|
||||
can use the downloaded PO file and `compile Godot from source <toc-devel-compiling )`.
|
||||
can use the downloaded PO file and `compile Godot from source ( toc-devel-compiling )`.
|
||||
|
||||
Rename the editor translation PO file to `<lang>.po` (e.g. `eo.po` for
|
||||
Rename the editor translation PO file to `( lang>.po` (e.g. `eo.po` for
|
||||
Esperanto) and place it in the `editor/translations/` folder
|
||||
(`GitHub ( https://github.com/godotengine/godot/tree/master/editor/translations )`).
|
||||
|
||||
@ -413,4 +413,4 @@ original image in the `images` subfolder
|
||||
and place your translated image there. In our example, the end result should be
|
||||
`images/getting_started/step_by_step/img/project_manager_first_open.fr.png)`.
|
||||
|
||||
Repeat this for other images and `make a Pull Request <doc_pr_workflow )`.
|
||||
Repeat this for other images and `make a Pull Request ( doc_pr_workflow )`.
|
||||
|
@ -236,11 +236,11 @@ You will then be back to the original state of your branch before calling
|
||||
If you have already created a merge commit without using `rebase`, or
|
||||
have made any other changes that have resulted in undesired history, the best option
|
||||
is to use an *interactive rebase* on the upstream branch. See the `dedicated
|
||||
section <doc_pr_workflow_rebase )` for instructions.
|
||||
section ( doc_pr_workflow_rebase )` for instructions.
|
||||
|
||||
.. tip:: If at any time you want to *reset* a local branch to a given commit or branch,
|
||||
you can do so with `git reset --hard <commit ID )` or
|
||||
`git reset --hard <remote>/<branch )` (e.g. `git reset --hard upstream/master`).
|
||||
you can do so with `git reset --hard ( commit ID )` or
|
||||
`git reset --hard ( remote>/( branch )` (e.g. `git reset --hard upstream/master`).
|
||||
|
||||
Be warned that this will remove any changes that you might have committed in
|
||||
this branch. If you ever lose commits by mistake, use the `git reflog` command
|
||||
@ -266,12 +266,12 @@ before staging it, while it is staged, and after it has been committed.
|
||||
|
||||
- `git diff` will show you the current unstaged changes, i.e. the
|
||||
differences between your working directory and the staging area.
|
||||
- `git checkout -- <files )` will undo the unstaged changes to the given
|
||||
- `git checkout -- ( files )` will undo the unstaged changes to the given
|
||||
files.
|
||||
- `git add <files )` will *stage* the changes on the listed files.
|
||||
- `git add ( files )` will *stage* the changes on the listed files.
|
||||
- `git diff --staged` will show the current staged changes, i.e. the
|
||||
differences between the staging area and the last commit.
|
||||
- `git reset HEAD <files )` will *unstage* changes to the listed files.
|
||||
- `git reset HEAD ( files )` will *unstage* changes to the listed files.
|
||||
- `git status` will show you what are the currently staged and unstaged
|
||||
modifications.
|
||||
- `git commit` will commit the staged files. It will open a text editor
|
||||
@ -336,7 +336,7 @@ remote branch to share them with the world. The syntax for this is:
|
||||
|
||||
::
|
||||
|
||||
$ git push <remote> <local branch>[:<remote branch>]
|
||||
$ git push ( remote> ( local branch>[:( remote branch>]
|
||||
|
||||
The part about the remote branch can be omitted if you want it to have the
|
||||
same name as the local branch, which is our case in this example, so we will
|
||||
|
@ -23,7 +23,7 @@ depending on whether you have a GitHub account or not.
|
||||
Due to a GitHub Actions limitation, builds are only available for 90 days
|
||||
after the pull request was last updated. If you still wish to try a
|
||||
pull request locally, you can
|
||||
`compile the pull request branch from source <doc_testing_pull_requests_compile )`
|
||||
`compile the pull request branch from source ( doc_testing_pull_requests_compile )`
|
||||
instead.
|
||||
|
||||
If you have a GitHub account
|
||||
@ -100,5 +100,5 @@ by Godot's GitHub Actions setup.
|
||||
|
||||
![](img/testing_pull_requests_fork_zip.png)
|
||||
|
||||
- Extract the ZIP archive and follow the `compiling <toc-devel-compiling )` instructions
|
||||
- Extract the ZIP archive and follow the `compiling ( toc-devel-compiling )` instructions
|
||||
for your operating system.
|
||||
|
@ -4,7 +4,7 @@ Contributing to the class reference
|
||||
===================================
|
||||
|
||||
|
||||
The class reference is available online in the `classes <toc-class-ref )`
|
||||
The class reference is available online in the `classes ( toc-class-ref )`
|
||||
section of the documentation and in the Godot editor, from the help menu.
|
||||
|
||||
In the class reference, some methods, variables, and signals lack descriptions.
|
||||
@ -19,7 +19,7 @@ taking care of a given class.
|
||||
|
||||
.. seealso::
|
||||
|
||||
You can find the writing guidelines for the class reference `here <doc_class_reference_writing_guidelines )`.
|
||||
You can find the writing guidelines for the class reference `here ( doc_class_reference_writing_guidelines )`.
|
||||
|
||||
For details on Git usage and the pull request workflow, please
|
||||
refer to the `doc_pr_workflow` page.
|
||||
@ -40,11 +40,11 @@ repository: `doc/classes/
|
||||
( https://github.com/godotengine/godot/tree/master/doc/classes )`_.
|
||||
|
||||
.. note:: For some modules in the engine's source code, you'll find the XML
|
||||
files in the `modules/<module_name>/doc_classes/` directory instead.
|
||||
files in the `modules/( module_name>/doc_classes/` directory instead.
|
||||
|
||||
.. warning:: Always edit the API reference through these source XML files. Do
|
||||
not edit the generated `.rst` files `in the online documentation
|
||||
<toc-class-ref )`, hosted in the `godot-docs
|
||||
( toc-class-ref )`, hosted in the `godot-docs
|
||||
( https://github.com/godotengine/godot-docs )`_ repository.
|
||||
|
||||
.. warning::
|
||||
|
@ -125,7 +125,7 @@ Testing development versions
|
||||
To help with the testing, you have several possibilities:
|
||||
|
||||
- Compile the engine from source yourself, following the instructions of the
|
||||
`Compiling <toc-devel-compiling )` page for your platform.
|
||||
`Compiling ( toc-devel-compiling )` page for your platform.
|
||||
|
||||
- Test official pre-release binaries when they are announced (usually on the
|
||||
blog and other community platforms), such as alpha, beta and release candidate (RC) builds.
|
||||
@ -197,7 +197,7 @@ There are two separate resources referred to as "documentation" in Godot:
|
||||
- **The class reference.** This is the documentation for the complete Godot API
|
||||
as exposed to GDScript and the other scripting languages. It can be consulted
|
||||
offline, directly in Godot's code editor, or online at `Godot API
|
||||
<toc-class-ref )`. To contribute to the class reference, you have to edit the
|
||||
( toc-class-ref )`. To contribute to the class reference, you have to edit the
|
||||
XML file corresponding to the class and make a pull request.
|
||||
See `doc_updating_the_class_reference` and
|
||||
`doc_class_reference_writing_guidelines` for more details.
|
||||
|
@ -61,13 +61,13 @@ Setting up the buildsystem
|
||||
|
||||
::
|
||||
|
||||
tools/bin/sdkmanager --sdk_root=<android_sdk_path> --licenses
|
||||
tools/bin/sdkmanager --sdk_root=( android_sdk_path> --licenses
|
||||
|
||||
- Complete setup by running the following command where `android_sdk_path` is the path to the Android SDK.
|
||||
|
||||
::
|
||||
|
||||
tools/bin/sdkmanager --sdk_root=<android_sdk_path> "platform-tools" "build-tools;30.0.3" "platforms;android-29" "cmdline-tools;latest" "cmake;3.10.2.4988404"
|
||||
tools/bin/sdkmanager --sdk_root=( android_sdk_path> "platform-tools" "build-tools;30.0.3" "platforms;android-29" "cmdline-tools;latest" "cmake;3.10.2.4988404"
|
||||
|
||||
.. seealso:: To set the environment variable on Windows, press :kbd:`Windows + R`, type
|
||||
"control system", then click on **Advanced system settings** in the left
|
||||
@ -177,11 +177,11 @@ The newly-compiled templates (`android_debug.apk`
|
||||
and `android_release.apk`) must be copied to Godot's templates folder
|
||||
with their respective names. The templates folder can be located in:
|
||||
|
||||
- Windows: `%APPDATA%\Godot\templates\<version>\`
|
||||
- Linux: `$HOME/.local/share/godot/templates/<version>/`
|
||||
- macOS: `$HOME/Library/Application Support/Godot/templates/<version>/`
|
||||
- Windows: `%APPDATA%\Godot\templates\( version>\`
|
||||
- Linux: `$HOME/.local/share/godot/templates/( version>/`
|
||||
- macOS: `$HOME/Library/Application Support/Godot/templates/( version>/`
|
||||
|
||||
`<version )` is of the form `major.minor[.patch].status` using values from
|
||||
`( version )` is of the form `major.minor[.patch].status` using values from
|
||||
`version.py` in your Godot source repository (e.g. `3.0.5.stable` or `3.1.dev`).
|
||||
You also need to write this same version string to a `version.txt` file located
|
||||
next to your export templates.
|
||||
@ -208,7 +208,7 @@ Platform doesn't appear in SCons
|
||||
Double-check that you've set the `ANDROID_SDK_ROOT`
|
||||
environment variable. This is required for the platform to appear in SCons'
|
||||
list of detected platforms.
|
||||
See `Setting up the buildsystem <doc_android_setting_up_the_buildsystem )`
|
||||
See `Setting up the buildsystem ( doc_android_setting_up_the_buildsystem )`
|
||||
for more information.
|
||||
|
||||
Application not installed
|
||||
@ -238,8 +238,8 @@ one of the following reasons:
|
||||
|
||||
- Make sure to use export templates that match your editor version; if
|
||||
you use a new Godot version, you *have* to update the templates too.
|
||||
- `libgodot_android.so` is not in `libs/<android_arch>/`
|
||||
where `<android_arch )` is the device's architecture.
|
||||
- `libgodot_android.so` is not in `libs/( android_arch>/`
|
||||
where `( android_arch )` is the device's architecture.
|
||||
- The device's architecture does not match the exported one(s).
|
||||
Make sure your templates were built for that device's architecture,
|
||||
and that the export settings included support for that architecture.
|
||||
|
@ -85,7 +85,7 @@ projects in an automated manner, use::
|
||||
scons platform=server tools=yes target=release_debug --jobs=$(sysctl -n hw.logicalcpu)
|
||||
|
||||
To compile a debug *server* build which can be used with
|
||||
`remote debugging tools <doc_command_line_tutorial )`, use::
|
||||
`remote debugging tools ( doc_command_line_tutorial )`, use::
|
||||
|
||||
scons platform=server tools=no target=release_debug --jobs=$(sysctl -n hw.logicalcpu)
|
||||
|
||||
|
@ -38,7 +38,7 @@ either `release` for a release build or `release_debug` for a debug build::
|
||||
scons platform=javascript tools=no target=release
|
||||
scons platform=javascript tools=no target=release_debug
|
||||
|
||||
By default, the `JavaScript singleton <doc_javascript_eval )` will be built
|
||||
By default, the `JavaScript singleton ( doc_javascript_eval )` will be built
|
||||
into the engine. Official export templates also have the JavaScript singleton
|
||||
enabled. Since `eval()` calls can be a security concern, the
|
||||
`javascript_eval` option can be used to build without the singleton::
|
||||
@ -65,7 +65,7 @@ Threads and GDNative
|
||||
|
||||
The default export templates do not include threads and GDNative support for
|
||||
performance and compatibility reasons. See the
|
||||
`export page <doc_javascript_export_options )` for more info.
|
||||
`export page ( doc_javascript_export_options )` for more info.
|
||||
|
||||
You can build the export templates using the option `threads_enabled=yes` or
|
||||
`gdnative_enabled=yes` to enable threads or GDNative support::
|
||||
@ -104,5 +104,5 @@ Once finished, the resulting file will be placed in the `bin` subdirectory.
|
||||
Its name will be `godot.javascript.opt.tools.threads.zip`. You can upload the
|
||||
zip content to your web server and visit it with your browser to use the editor.
|
||||
|
||||
Refer to the `export page <doc_javascript_export_options )` for the web
|
||||
Refer to the `export page ( doc_javascript_export_options )` for the web
|
||||
server requirements.
|
||||
|
@ -273,7 +273,7 @@ with the following flags::
|
||||
C:\godot> scons platform=windows tools=no target=release bits=64
|
||||
|
||||
If you plan on replacing the standard export templates, copy these to the
|
||||
following location, replacing `<version )` with the version identifier
|
||||
following location, replacing `( version )` with the version identifier
|
||||
(such as `3.1.1.stable` or `3.2.dev`)::
|
||||
|
||||
%USERPROFILE%\AppData\Roaming\Godot\templates\<version>\
|
||||
|
@ -150,7 +150,7 @@ projects in an automated manner, use::
|
||||
scons -j8 platform=server tools=yes target=release_debug
|
||||
|
||||
To compile a debug *server* build which can be used with
|
||||
`remote debugging tools <doc_command_line_tutorial )`, use::
|
||||
`remote debugging tools ( doc_command_line_tutorial )`, use::
|
||||
|
||||
scons -j8 platform=server tools=no target=release_debug
|
||||
|
||||
@ -254,7 +254,7 @@ to get even faster builds.
|
||||
|
||||
ln -s ~/.local/opt/pyston/bin/scons ~/.local/bin/pyston-scons
|
||||
|
||||
- Instead of running `scons <build arguments )`, run `pyston-scons <build arguments )`
|
||||
- Instead of running `scons ( build arguments )`, run `pyston-scons ( build arguments )`
|
||||
to compile Godot.
|
||||
|
||||
If you can't run `pyston-scons` after creating the symbolic link,
|
||||
|
@ -248,7 +248,7 @@ to the Gradle project.
|
||||
|
||||
Once you've built Mono, you can proceed to build Godot with the instructions
|
||||
described in this page and the
|
||||
`Compiling for Android<doc_compiling_for_android )` page.
|
||||
`Compiling for Android( doc_compiling_for_android )` page.
|
||||
Make sure to let SCons know about the location of the Mono runtime you've just built, e.g.:
|
||||
`scons [...] mono_prefix="$HOME/mono-installs/android-armeabi-v7a-release"`
|
||||
(This path may be different on your system).
|
||||
@ -258,7 +258,7 @@ Targeting iOS
|
||||
|
||||
Once you've built Mono, you can proceed to build Godot with the instructions
|
||||
described in this page and the
|
||||
`Compiling for iOS<doc_compiling_for_ios )` page.
|
||||
`Compiling for iOS( doc_compiling_for_ios )` page.
|
||||
Make sure to let SCons know about the location of the Mono runtime you've just built, e.g.:
|
||||
`scons [...] mono_prefix="$HOME/mono-installs/ios-arm64-release"`
|
||||
(This path may be different on your system).
|
||||
@ -307,7 +307,7 @@ Building for WebAssembly currently involves the same process regardless of wheth
|
||||
|
||||
Once you've built Mono, you can proceed to build Godot with the instructions
|
||||
described in this page and the
|
||||
`Compiling for the Web<doc_compiling_for_web )` page.
|
||||
`Compiling for the Web( doc_compiling_for_web )` page.
|
||||
Make sure to let SCons know about the location of the Mono runtime you've just built, e.g.:
|
||||
`scons [...] mono_prefix="$HOME/mono-installs/wasm-runtime-release"`
|
||||
(This path may be different on your system).
|
||||
|
@ -7,7 +7,7 @@ Getting the source
|
||||
Downloading the Godot source code
|
||||
---------------------------------
|
||||
|
||||
Before `getting into the SCons build system <doc_introduction_to_the_buildsystem )`
|
||||
Before `getting into the SCons build system ( doc_introduction_to_the_buildsystem )`
|
||||
and compiling Godot, you need to actually download the Godot source code.
|
||||
|
||||
The source code is available on `GitHub ( https://github.com/godotengine/godot )`
|
||||
@ -15,7 +15,7 @@ and while you can manually download it via the website, in general you want to
|
||||
do it via the `git` version control system.
|
||||
|
||||
If you are compiling in order to make contributions or pull requests, you should
|
||||
follow the instructions from the `Pull Request workflow <doc_pr_workflow )`.
|
||||
follow the instructions from the `Pull Request workflow ( doc_pr_workflow )`.
|
||||
|
||||
If you don't know much about `git` yet, there are a great number of
|
||||
`tutorials ( https://git-scm.com/book )` available on various websites.
|
||||
@ -50,4 +50,4 @@ after the `--branch` (or just `-b`) argument::
|
||||
There are also generally branches besides `master` for each major version.
|
||||
|
||||
After downloading the Godot source code,
|
||||
you can `continue to compiling Godot <doc_introduction_to_the_buildsystem )`.
|
||||
you can `continue to compiling Godot ( doc_introduction_to_the_buildsystem )`.
|
||||
|
@ -39,7 +39,7 @@ On Windows, `strip.exe` is included in most MinGW toolchain setups.
|
||||
This will reduce the size of compiled binaries by a factor between 5× and 10×.
|
||||
The downside is that crash backtraces will no longer provide accurate information
|
||||
(which is useful for troubleshooting the cause of a crash).
|
||||
`C++ profilers <doc_using_cpp_profilers )` will also no longer be able to display
|
||||
`C++ profilers ( doc_using_cpp_profilers )` will also no longer be able to display
|
||||
function names (this does not affect the built-in GDScript profiler).
|
||||
|
||||
.. note::
|
||||
|
@ -11,7 +11,7 @@ Importing the project
|
||||
|
||||
CLion requires a `CMakeLists.txt` file as a project file, which is problematic
|
||||
for Godot because it uses the SCons buildsystem instead of CMake. However,
|
||||
there is a `CMakeLists.txt` configuration for `Android Studio <doc_configuring_an_ide_android_studio )`
|
||||
there is a `CMakeLists.txt` configuration for `Android Studio ( doc_configuring_an_ide_android_studio )`
|
||||
which can also be used by CLion.
|
||||
|
||||
- From the CLion's welcome window choose the option to import an existing
|
||||
|
@ -85,12 +85,12 @@ Debugging the project
|
||||
:align: center
|
||||
|
||||
To learn more about command line arguments, refer to the
|
||||
`command line tutorial <doc_command_line_tutorial )`.
|
||||
`command line tutorial ( doc_command_line_tutorial )`.
|
||||
|
||||
Code style configuration
|
||||
------------------------
|
||||
|
||||
Developers must follow the project's `code style <doc_code_style_guidelines )`
|
||||
Developers must follow the project's `code style ( doc_code_style_guidelines )`
|
||||
and the IDE should help them follow it. By default, Qt Creator uses spaces
|
||||
for indentation which doesn't match the Godot code style guidelines. You can
|
||||
change this behavior by changing the **Code Style** in **Tools > Options > C++**.
|
||||
|
@ -53,7 +53,7 @@ project manager opens a project, the initial process is terminated and the debug
|
||||
:align: center
|
||||
|
||||
To learn more about command line arguments, refer to the
|
||||
`command line tutorial <doc_command_line_tutorial )`.
|
||||
`command line tutorial ( doc_command_line_tutorial )`.
|
||||
|
||||
Even if you start the project without a debugger attached it can still be connected to the running
|
||||
process using **Debug > Attach to Process...** menu.
|
||||
|
@ -315,7 +315,7 @@ object-oriented C code.
|
||||
References
|
||||
~~~~~~~~~~~
|
||||
|
||||
- `RID<class_rid )`
|
||||
- `RID( rid )`
|
||||
- `core/rid.h ( https://github.com/godotengine/godot/blob/3.x/core/rid.h )`
|
||||
|
||||
Registering the class in GDScript
|
||||
|
@ -303,7 +303,7 @@ and compile them accordingly, including our "summator" module.
|
||||
|
||||
.. seealso::
|
||||
|
||||
`Introduction to the buildsystem - Custom modules build option <doc_buildsystem_custom_modules )`.
|
||||
`Introduction to the buildsystem - Custom modules build option ( doc_buildsystem_custom_modules )`.
|
||||
|
||||
Improving the build system for development
|
||||
------------------------------------------
|
||||
@ -312,7 +312,7 @@ Improving the build system for development
|
||||
|
||||
This shared library support is not designed to support distributing a module
|
||||
to other users without recompiling the engine. For that purpose, use
|
||||
`GDNative <doc_what_is_gdnative )` instead.
|
||||
`GDNative ( doc_what_is_gdnative )` instead.
|
||||
|
||||
So far, we defined a clean SCsub that allows us to add the sources
|
||||
of our new module as part of the Godot binary.
|
||||
|
@ -17,7 +17,7 @@ data types. If not, refer to this guide `doc_custom_modules_in_c++`.
|
||||
References
|
||||
~~~~~~~~~~
|
||||
|
||||
- `ResourceLoader<class_resourceloader )`
|
||||
- `ResourceLoader( resourceloader )`
|
||||
- `core/io/resource_loader.cpp ( https://github.com/godotengine/godot/blob/master/core/io/resource_loader.cpp )`_
|
||||
|
||||
What for?
|
||||
|
@ -86,7 +86,7 @@ make a separate pull request for your icons to be available within the editor
|
||||
as they can be self-contained.
|
||||
|
||||
For specific instructions on how to create module icons, refer to
|
||||
`Creating custom module icons<doc_custom_module_icons )`.
|
||||
`Creating custom module icons( doc_custom_module_icons )`.
|
||||
|
||||
Troubleshooting
|
||||
~~~~~~~~~~~~~~~
|
||||
|
@ -37,7 +37,7 @@ The editor's code is fully self-contained in the
|
||||
of the Godot source repository.
|
||||
|
||||
Some editor functionality is also implemented via
|
||||
`modules <doc_custom_modules_in_c++ )`. Some of these are only enabled in
|
||||
`modules ( doc_custom_modules_in_c++ )`. Some of these are only enabled in
|
||||
editor builds to decrease the binary size of export templates. See the
|
||||
`modules/ ( https://github.com/godotengine/godot/tree/master/modules )` folder
|
||||
in the Godot source repository.
|
||||
@ -83,6 +83,6 @@ Development tips
|
||||
----------------
|
||||
|
||||
To iterate quickly on the editor, we recommend to set up a test project and
|
||||
`open it from the command line <doc_command_line_tutorial )` after compiling
|
||||
`open it from the command line ( doc_command_line_tutorial )` after compiling
|
||||
the editor. This way, you don't have to go through the project manager every
|
||||
time you start Godot.
|
||||
|
@ -16,7 +16,7 @@ Node structure
|
||||
To begin, we need to choose a root node for the player object. As a general
|
||||
rule, a scene's root node should reflect the object's desired functionality -
|
||||
what the object *is*. Click the "Other Node" button and add an `Area2D
|
||||
<class_Area2D )` node to the scene.
|
||||
( Area2D )` node to the scene.
|
||||
|
||||
![](img/add_node.png)
|
||||
|
||||
@ -54,10 +54,10 @@ Sprite animation
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Click on the `Player` node and add an `AnimatedSprite
|
||||
<class_AnimatedSprite )` node as a child. The `AnimatedSprite` will handle the
|
||||
( AnimatedSprite )` node as a child. The `AnimatedSprite` will handle the
|
||||
appearance and animations for our player. Notice that there is a warning symbol
|
||||
next to the node. An `AnimatedSprite` requires a `SpriteFrames
|
||||
<class_SpriteFrames )` resource, which is a list of the animations it can
|
||||
( SpriteFrames )` resource, which is a list of the animations it can
|
||||
display. To create one, find the `Frames` property in the Inspector and click
|
||||
"[empty]" -> "New SpriteFrames". Click again to open the "SpriteFrames" panel:
|
||||
|
||||
|
@ -22,7 +22,7 @@ The HUD needs to display the following information:
|
||||
|
||||
The basic node for UI elements is `Control`. To create our
|
||||
UI, we'll use two types of `Control` nodes: `Label
|
||||
<class_Label )` and `Button`.
|
||||
( Label )` and `Button`.
|
||||
|
||||
Create the following as children of the `HUD` node:
|
||||
|
||||
|
@ -8,7 +8,7 @@ lesson, we'll make the player die when a monster hits them on the ground.
|
||||
|
||||
First, we have to change a few settings related to physics interactions. Enter
|
||||
the world of `physics layers
|
||||
<doc_physics_introduction_collision_layers_and_masks )`.
|
||||
( doc_physics_introduction_collision_layers_and_masks )`.
|
||||
|
||||
Controlling physics interactions
|
||||
--------------------------------
|
||||
@ -156,7 +156,7 @@ over monsters and kill them at the same time.
|
||||
|
||||
We need to detect collisions with a monster and to differentiate them from
|
||||
collisions with the floor. To do so, we can use Godot's `group
|
||||
<doc_groups )` tagging feature.
|
||||
( doc_groups )` tagging feature.
|
||||
|
||||
Open the scene `Mob.tscn` again and select the *Mob* node. Go to the *Node*
|
||||
dock on the right to see a list of signals. The *Node* dock has two tabs:
|
||||
@ -224,18 +224,18 @@ gdscript GDScript
|
||||
That's a lot of new functions. Here's some more information about them.
|
||||
|
||||
The functions `get_slide_count()` and `get_slide_collision()` both come from
|
||||
the `KinematicBody<class_KinematicBody )` class and are related to
|
||||
the `KinematicBody( KinematicBody )` class and are related to
|
||||
`move_and_slide()`.
|
||||
|
||||
`get_slide_collision()` returns a
|
||||
`KinematicCollision<class_KinematicCollision )` object that holds
|
||||
`KinematicCollision( KinematicCollision )` object that holds
|
||||
information about where and how the collision occurred. For example, we use its
|
||||
`collider` property to check if we collided with a "mob" by calling
|
||||
`is_in_group()` on it: `collision.collider.is_in_group("mob")`.
|
||||
|
||||
.. note::
|
||||
|
||||
The method `is_in_group()` is available on every `Node<class_Node )`.
|
||||
The method `is_in_group()` is available on every `Node( Node )`.
|
||||
|
||||
To check that we are landing on the monster, we use the vector dot product:
|
||||
`Vector3.UP.dot(collision.normal) > 0.1`. The collision normal is a 3D vector
|
||||
|
@ -262,14 +262,14 @@ gdscript GDScript
|
||||
```
|
||||
|
||||
The function `get_tree()` gives us access to the global `SceneTree
|
||||
<class_SceneTree )` object, which allows us to reload and restart the current
|
||||
( SceneTree )` object, which allows us to reload and restart the current
|
||||
scene.
|
||||
|
||||
Adding music
|
||||
------------
|
||||
|
||||
To add music that plays continuously in the background, we're going to use
|
||||
another feature in Godot: `autoloads <doc_singletons_autoload )`.
|
||||
another feature in Godot: `autoloads ( doc_singletons_autoload )`.
|
||||
|
||||
To play audio, all you need to do is add an *AudioStreamPlayer* node to your
|
||||
scene and attach an audio file to it. When you start the scene, it can play
|
||||
|
@ -29,11 +29,11 @@ information about 2D, 3D, physics, rendering and performance, and much more.
|
||||
|
||||
Here are the sections we recommend you to explore next:
|
||||
|
||||
1. Read the `Scripting section <toc-scripting-core-features )` to learn essential programming features you’ll use
|
||||
1. Read the `Scripting section ( toc-scripting-core-features )` to learn essential programming features you’ll use
|
||||
in every project.
|
||||
2. The `3D <toc-learn-features-3d )` and `Physics <toc-learn-features-physics )` sections will teach you more about 3D game creation in the
|
||||
2. The `3D ( toc-learn-features-3d )` and `Physics ( toc-learn-features-physics )` sections will teach you more about 3D game creation in the
|
||||
engine.
|
||||
3. `Inputs <toc-learn-features-inputs )` is another important one for any game project.
|
||||
3. `Inputs ( toc-learn-features-inputs )` is another important one for any game project.
|
||||
|
||||
You can start with these or, if you prefer, look at the sidebar menu on the left
|
||||
and pick your options.
|
||||
|
@ -13,7 +13,7 @@ This page will give you a brief overview of Godot's interface. We're going to
|
||||
look at the different main screens and docks to help you situate yourself.
|
||||
|
||||
.. seealso:: For a comprehensive breakdown of the editor's interface and how to
|
||||
use it, see the `Editor manual <toc-learn-editor )`.
|
||||
use it, see the `Editor manual ( toc-learn-editor )`.
|
||||
|
||||
The Project manager
|
||||
-------------------
|
||||
|
@ -90,7 +90,7 @@ completely free and open-source.
|
||||
.. seealso:: These are the five officially supported programming languages. The
|
||||
community maintains support for many more. For more information,
|
||||
see `GDNative third-party bindings
|
||||
<doc_what_is_gdnative_third_party_bindings )`.
|
||||
( doc_what_is_gdnative_third_party_bindings )`.
|
||||
|
||||
What do I need to know to use Godot?
|
||||
------------------------------------
|
||||
|
@ -14,7 +14,7 @@ the previous lesson was an example. We call those files "Packed Scenes" as they
|
||||
pack information about your scene's content.
|
||||
|
||||
Here's an example of a ball. It's composed of a `RigidBody2D
|
||||
<class_RigidBody2D )` node as its root named Ball, which allows the ball to fall
|
||||
( RigidBody2D )` node as its root named Ball, which allows the ball to fall
|
||||
and bounce on walls, a `Sprite` node, and a
|
||||
`CollisionShape2D`.
|
||||
|
||||
|
@ -26,9 +26,9 @@ The equivalent C# code has been included in another tab for convenience.
|
||||
![](img/scripting_first_script_rotating_godot.gif)
|
||||
|
||||
.. seealso:: To learn more about GDScript, its keywords, and its syntax, head to
|
||||
the `GDScript reference<doc_gdscript )`.
|
||||
the `GDScript reference( doc_gdscript )`.
|
||||
|
||||
.. seealso:: To learn more about C#, head to the `C# basics <doc_c_sharp )` page.
|
||||
.. seealso:: To learn more about C#, head to the `C# basics ( doc_c_sharp )` page.
|
||||
|
||||
Project setup
|
||||
-------------
|
||||
|
@ -25,7 +25,7 @@ Available scripting languages
|
||||
|
||||
Godot offers **five gameplay programming languages**: GDScript, C#,
|
||||
VisualScript, and, via its GDNative technology, C and C++. There are more
|
||||
`community-supported languages <doc_what_is_gdnative_third_party_bindings )`,
|
||||
`community-supported languages ( doc_what_is_gdnative_third_party_bindings )`,
|
||||
but these are the official ones.
|
||||
|
||||
You can use multiple languages in a single project. For instance, in a team, you
|
||||
@ -68,7 +68,7 @@ Let's look at each language's features, as well as its pros and cons.
|
||||
GDScript
|
||||
~~~~~~~~
|
||||
|
||||
`GDScript<doc_gdscript )` is an
|
||||
`GDScript( doc_gdscript )` is an
|
||||
`object-oriented ( https://en.wikipedia.org/wiki/Object-oriented_programming )`_ and
|
||||
`imperative ( https://en.wikipedia.org/wiki/Imperative_programming )`_
|
||||
programming language built for Godot. It's made by and for game developers
|
||||
@ -149,7 +149,7 @@ VisualScript
|
||||
`trying out GDScript <toc-learn-scripting-gdscript )` instead,
|
||||
especially if you intend to migrate your project to Godot 4.
|
||||
|
||||
`Visual Scripting<doc_what_is_visual_script )` is a graph-based visual
|
||||
`Visual Scripting( doc_what_is_visual_script )` is a graph-based visual
|
||||
programming language where you connect blocks. It can be a great tool for
|
||||
non-programmers like game designers and artists.
|
||||
|
||||
@ -166,7 +166,7 @@ is slow compared to using other programming languages.
|
||||
.. seealso::
|
||||
|
||||
For more information, see
|
||||
`Getting started with VisualScript <doc_getting_started_visual_script )`.
|
||||
`Getting started with VisualScript ( doc_getting_started_visual_script )`.
|
||||
|
||||
C and C++ via GDNative
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -142,7 +142,7 @@ node's motion.
|
||||
|
||||
Our Sprite moves thanks to code in the `_process()` function. Godot provides a
|
||||
method to toggle processing on and off: `Node.set_process()
|
||||
<class_Node_method_set_process )`. Another method of the Node class,
|
||||
( Node_method_set_process )`. Another method of the Node class,
|
||||
`is_processing()`, returns `true` if idle processing is active. We can use
|
||||
the `not` keyword to invert the value.
|
||||
|
||||
|
2
index.md
2
index.md
@ -31,7 +31,7 @@ Godot Docs – *3.5* branch
|
||||
Welcome to the official documentation of `Godot Engine ( https://godotengine.org )`,
|
||||
the free and open source community-driven 2D and 3D game engine! If you are new
|
||||
to this documentation, we recommend that you read the
|
||||
`introduction page <doc_about_intro )` to get an overview of what this
|
||||
`introduction page ( doc_about_intro )` to get an overview of what this
|
||||
documentation has to offer.
|
||||
|
||||
The table of contents below and in the sidebar should let you easily access the
|
||||
|
@ -51,7 +51,7 @@ The demo uses four different nodes:
|
||||
* `Light2D`
|
||||
* `LightOccluder2D`
|
||||
|
||||
`CanvasModulate<class_CanvasModulate )` is used to darken the scene.
|
||||
`CanvasModulate( CanvasModulate )` is used to darken the scene.
|
||||
|
||||
`Sprites` are used to display the textures for the light blobs, the
|
||||
background, and for the shadow casters.
|
||||
|
@ -23,7 +23,7 @@ children: `Sprite` and `CollisionShape2D`. You can use the Godot icon ("icon.png
|
||||
for the Sprite's texture or use any other 2D image you have.
|
||||
|
||||
Open `Project -> Project Settings` and select the "Input Map" tab. Add the following
|
||||
input actions (see `InputEvent <doc_inputevent )` for details):
|
||||
input actions (see `InputEvent ( doc_inputevent )` for details):
|
||||
|
||||
![](img/movement_inputs.png)
|
||||
|
||||
|
@ -40,7 +40,7 @@ with the following nodes:
|
||||
`RigidBody2D`. The animation will still be
|
||||
made in the same way. Once the animation is completed, you can
|
||||
assign a shape to the CollisionShape2D. See
|
||||
`Physics Introduction <doc_physics_introduction )` for more
|
||||
`Physics Introduction ( doc_physics_introduction )` for more
|
||||
information.
|
||||
|
||||
Now select the `AnimatedSprite` and in its *SpriteFrames* property, select
|
||||
@ -147,7 +147,7 @@ setting up your scene tree:
|
||||
`RigidBody2D`. The animation will still be
|
||||
made in the same way. Once the animation is completed, you can
|
||||
assign a shape to the CollisionShape2D. See
|
||||
`Physics Introduction <doc_physics_introduction )` for more
|
||||
`Physics Introduction ( doc_physics_introduction )` for more
|
||||
information.
|
||||
|
||||
Drag the spritesheet into the Sprite's *Texture* property, and you'll see the
|
||||
|
@ -21,7 +21,7 @@ can be accessed as a `Transform2D`.
|
||||
|
||||
Also covered in the previous tutorial, nodes are drawn by default in Layer 0,
|
||||
in the built-in canvas. To put nodes in a different layer, a `CanvasLayer
|
||||
<class_CanvasLayer )` node can be used.
|
||||
( CanvasLayer )` node can be used.
|
||||
|
||||
Global canvas transform
|
||||
-----------------------
|
||||
|
@ -308,11 +308,11 @@ Let's run again! This time, the rotation displays fine!
|
||||
Antialiased drawing
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Godot offers method parameters in `draw_line<class_CanvasItem_method_draw_line )`
|
||||
Godot offers method parameters in `draw_line( CanvasItem_method_draw_line )`
|
||||
to enable antialiasing, but it doesn't work reliably in all situations
|
||||
(for instance, on mobile/web platforms, or when HDR is enabled).
|
||||
There is also no `antialiased` parameter available in
|
||||
`draw_polygon<class_CanvasItem_method_draw_polygon )`.
|
||||
`draw_polygon( CanvasItem_method_draw_polygon )`.
|
||||
|
||||
As a workaround, install and use the
|
||||
`Antialiased Line2D add-on ( https://github.com/godot-extended-libraries/godot-antialiased-line2d )`
|
||||
|
@ -30,7 +30,7 @@ up and shaded by light sources if the shaded flag is enabled, but it
|
||||
will not cast a shadow, even with cast shadow turned on under the nodes
|
||||
GeometryInstance3D settings. This is because the node is a quad mesh
|
||||
(one glyph per quad) with transparent textures and has the same limitations
|
||||
as Sprite3D. See `this page <doc_3d_rendering_limitations_transparency_sorting )`
|
||||
as Sprite3D. See `this page ( doc_3d_rendering_limitations_transparency_sorting )`
|
||||
for more information.
|
||||
|
||||
Text mesh
|
||||
|
@ -333,7 +333,7 @@ Capture
|
||||
- **Quality:** The lightmap probe generation quality. Higher values result in
|
||||
more accurate lighting, but take longer to bake. This setting does not affect
|
||||
the *density* of the lightmap probes, only their quality.
|
||||
- **Propagation:** Similar to `GIProbe <doc_gi_probes )`'s Propagation property.
|
||||
- **Propagation:** Similar to `GIProbe ( doc_gi_probes )`'s Propagation property.
|
||||
Higher values result in brighter and more diffuse indirect lighting for
|
||||
dynamic objects. Adjust this value depending on your scene to make dynamic
|
||||
objects better fit with static baked lighting.
|
||||
|
@ -17,7 +17,7 @@ This works because if a monster is in an area that is completely out of view for
|
||||
How does a monster know whether it is within the gameplay area?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This problem is solved because the portal system contains a subsystem called the **Gameplay Monitor** that can be turned on and off from the `RoomManager<class_RoomManager )`. When switched on, any roaming objects that move inside or outside the gameplay area (whether by moving themselves, or the camera moving) will receive callbacks to let them know of this change.
|
||||
This problem is solved because the portal system contains a subsystem called the **Gameplay Monitor** that can be turned on and off from the `RoomManager( RoomManager )`. When switched on, any roaming objects that move inside or outside the gameplay area (whether by moving themselves, or the camera moving) will receive callbacks to let them know of this change.
|
||||
|
||||
You can choose to either receive these callbacks as `signals`, or as `notifications`.
|
||||
|
||||
@ -41,7 +41,7 @@ VisbilityNotifiers / VisibilityEnablers
|
||||
|
||||
Gameplay callbacks have one more useful function. By default in Godot, animation and physics are still processed regardless of whether an object is within view. This can sap performance, especially when using software skinning.
|
||||
|
||||
The engine's solution to this problem is the `VisibilityNotifier<class_VisibilityNotifier )` node, and its slightly easier to use variation, the `VisibilityEnabler<class_VisibilityEnabler )` node. VisibilityEnabler can be used to switch off animation and sleep physics when an object is outside the view frustum. You do this by simply placing a VisibilityEnabler node in your subscene (for e.g. a monster). It will do the rest. Consult the `VisibilityEnabler<class_VisibilityEnabler )` documentation for full details.
|
||||
The engine's solution to this problem is the `VisibilityNotifier( VisibilityNotifier )` node, and its slightly easier to use variation, the `VisibilityEnabler( VisibilityEnabler )` node. VisibilityEnabler can be used to switch off animation and sleep physics when an object is outside the view frustum. You do this by simply placing a VisibilityEnabler node in your subscene (for e.g. a monster). It will do the rest. Consult the `VisibilityEnabler( VisibilityEnabler )` documentation for full details.
|
||||
|
||||
![](img/visibility_enabler.png)
|
||||
|
||||
@ -52,11 +52,11 @@ What if the VisibilityEnabler could turn off objects when they were occlusion cu
|
||||
RoomGroups
|
||||
~~~~~~~~~~
|
||||
|
||||
A `RoomGroup<class_RoomGroup )` is a special node which allows you to deal with a group of rooms at once, instead of having write code for them individually. This is especially useful in conjunction with gameplay callbacks. The most important use for RoomGroups is to delineate between "inside" and "outside" areas.
|
||||
A `RoomGroup( RoomGroup )` is a special node which allows you to deal with a group of rooms at once, instead of having write code for them individually. This is especially useful in conjunction with gameplay callbacks. The most important use for RoomGroups is to delineate between "inside" and "outside" areas.
|
||||
|
||||
![](img/roomgroups.png)
|
||||
|
||||
For instance, when outside you may wish to use a `DirectionalLight<class_DirectionalLight )` to represent the sun. When the outside RoomGroup receives an `enter gameplay` callback, you can turn the light on, and you can turn it off when the RoomGroup exits gameplay. With the light off, performance will increase as there is no need to render it indoors.
|
||||
For instance, when outside you may wish to use a `DirectionalLight( DirectionalLight )` to represent the sun. When the outside RoomGroup receives an `enter gameplay` callback, you can turn the light on, and you can turn it off when the RoomGroup exits gameplay. With the light off, performance will increase as there is no need to render it indoors.
|
||||
|
||||
This is an example of a simple RoomGroup script to turn on and off a DirectionalLight. Note that you can also use signals for callbacks (the choice is up to you):
|
||||
|
||||
|
@ -8,9 +8,9 @@ Putting all the ideas together, here is an example scene tree:
|
||||
|
||||
![](img/example_scenetree.png)
|
||||
|
||||
- We have used a `RoomGroup<class_RoomGroup )` to denote an outside area.
|
||||
- The `MeshInstance<class_MeshInstance )`\ s inside the `Room<class_Room )`\ s are either `STATIC` or `DYNAMIC`.
|
||||
- We have created a `Spatial<class_Spatial )` (I decided to call it 'Freeform', but you could use any name) under which to place `STATIC` and `DYNAMIC` objects that will be autoplaced in rooms
|
||||
- We have used a `RoomGroup( RoomGroup )` to denote an outside area.
|
||||
- The `MeshInstance( MeshInstance )`\ s inside the `Room( Room )`\ s are either `STATIC` or `DYNAMIC`.
|
||||
- We have created a `Spatial( Spatial )` (I decided to call it 'Freeform', but you could use any name) under which to place `STATIC` and `DYNAMIC` objects that will be autoplaced in rooms
|
||||
(Freeform is inside the `roomlist`, but *not* inside a room.)
|
||||
- The player and the monsters are on branches *OUTSIDE* the `roomlist`.
|
||||
- The player and monster meshes have portal mode `ROAMING` so they can be in any room.
|
||||
@ -26,9 +26,9 @@ Although you can create your room system entirely within the editor, you can als
|
||||
Postfix convention
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- `-room` becomes a `Room<class_Room )`.
|
||||
- `-roomgroup` becomes a `RoomGroup<class_RoomGroup )`.
|
||||
- `-portal` becomes a `Portal<class_Portal )`.
|
||||
- `-room` becomes a `Room( Room )`.
|
||||
- `-roomgroup` becomes a `RoomGroup( RoomGroup )`.
|
||||
- `-portal` becomes a `Portal( Portal )`.
|
||||
- `-bound` becomes a manual bound.
|
||||
|
||||
Rooms and RoomGroups should be created as Empties within Blender. Any mesh children of the `-room` Empty will thus be placed in the Room during conversion in Godot.
|
||||
@ -44,7 +44,7 @@ Portals
|
||||
|
||||
Portals are different from Rooms. In Portals, we need to specify the geometry of the Portal in our modelling tool, in addition to just the name. To do this your "portal-to-be" should be created as a Mesh.
|
||||
|
||||
Portal meshes have some restrictions to work properly. They must be convex, and the polygon points should be in the same plane. The accuracy to the plane does not have to be exact, as Godot will automatically average the direction of the portal plane. Once converted to a `Portal<class_Portal )` node, the snapping to the portal plane is enforced, and the vertices are specified (and editable) as 2D coordinates in the inspector, rather than 3D points.
|
||||
Portal meshes have some restrictions to work properly. They must be convex, and the polygon points should be in the same plane. The accuracy to the plane does not have to be exact, as Godot will automatically average the direction of the portal plane. Once converted to a `Portal( Portal )` node, the snapping to the portal plane is enforced, and the vertices are specified (and editable) as 2D coordinates in the inspector, rather than 3D points.
|
||||
|
||||
The portal's naming is quite important. You can either name the portal `-portal` which will attempt to autolink the Portal in Godot, or you can use the name of the Room you wish to link the Portal to as a prefix.
|
||||
|
||||
|
@ -4,7 +4,7 @@ First steps with Rooms and Portals
|
||||
The RoomManager
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Anytime you want to use the portal system, you need to include a special node in your scene tree, called the `RoomManager<class_RoomManager )`. The RoomManager is responsible for the runtime maintenance of the system, especially converting the objects in your rooms into a *room graph* which is used at runtime to perform occlusion culling and other tasks.
|
||||
Anytime you want to use the portal system, you need to include a special node in your scene tree, called the `RoomManager( RoomManager )`. The RoomManager is responsible for the runtime maintenance of the system, especially converting the objects in your rooms into a *room graph* which is used at runtime to perform occlusion culling and other tasks.
|
||||
|
||||
Room Conversion
|
||||
^^^^^^^^^^^^^^^
|
||||
@ -40,7 +40,7 @@ Rooms
|
||||
What is a room?
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
`Room<class_Room )`\ s are a way of spatially partitioning your level into areas that make sense in terms of level design. Rooms often quite literally *are* rooms (like in a building). Ultimately though, as far as the engine is concerned, a room represents a **non-overlapping** convex volume in which you typically place most of your objects that fall within that area.
|
||||
`Room( Room )`\ s are a way of spatially partitioning your level into areas that make sense in terms of level design. Rooms often quite literally *are* rooms (like in a building). Ultimately though, as far as the engine is concerned, a room represents a **non-overlapping** convex volume in which you typically place most of your objects that fall within that area.
|
||||
|
||||
A room doesn't need to correspond to a literal room. It could, for example, also be a canyon in an outdoor area or a smaller part of a concave room. With a little imagination, you can use the system in almost any scenario.
|
||||
|
||||
@ -64,12 +64,12 @@ If you accidentally create overlapping rooms, the editor will warn you when you
|
||||
|
||||
The system does attempt to cope with overlapping rooms as best as possible by making the current room *"sticky"*. Each object remembers which room it was in during the previous frame and stays within it as long as it does not move outside the convex hull room bound. This can result in some hysteresis in these overlapping zones.
|
||||
|
||||
There is one exception, however, for `internal rooms<doc_rooms_and_portals_internal_rooms )`. You do not have to worry about these to start with.
|
||||
There is one exception, however, for `internal rooms( doc_rooms_and_portals_internal_rooms )`. You do not have to worry about these to start with.
|
||||
|
||||
How do I create a room?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
A `Room<class_Room )` is a node type that can be added to the scene tree like any other. You can place objects within the room by making them children and grand-children of the Room node.
|
||||
A `Room( Room )` is a node type that can be added to the scene tree like any other. You can place objects within the room by making them children and grand-children of the Room node.
|
||||
|
||||
How do I define the shape and position of my room convex hull?
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -93,7 +93,7 @@ Portals
|
||||
|
||||
If you create some rooms, place objects within them, then convert the level in the editor, you will see the objects in the rooms appearing and showing as you move between rooms. There is one problem, however! Although you can see the objects within the room that the camera is in, you can't see to any neighbouring rooms! For that we need portals.
|
||||
|
||||
`Portal<class_Portal )`\ s are special convex polygons that you position over the openings between rooms in order to allow the system to see between them. You can create a portal node directly in the editor. The default portal has 4 points and behaves much like a `plane` `MeshInstance<class_MeshInstance )`. You can add or remove points using the inspector. A portal requires at least 3 points to work - this is because it needs to form a polygon rather than a point or line.
|
||||
`Portal( Portal )`\ s are special convex polygons that you position over the openings between rooms in order to allow the system to see between them. You can create a portal node directly in the editor. The default portal has 4 points and behaves much like a `plane` `MeshInstance( MeshInstance )`. You can add or remove points using the inspector. A portal requires at least 3 points to work - this is because it needs to form a polygon rather than a point or line.
|
||||
|
||||
To save editing effort, **only one Portal is required between each pair of Rooms**. You *do not need* to (and indeed should not) create two Portals that overlap in opposite directions. Portals default to being two-way, but you can make them one-way in the Portal inspector.
|
||||
|
||||
|
@ -3,7 +3,7 @@
|
||||
Introduction to Rooms and Portals
|
||||
=================================
|
||||
|
||||
The rooms and portals system is an optional component of Godot that allows you to partition your 3D game levels into a series of `Room<class_Room )` s (*aka cells*), and `Portal<class_Portal )` s. Portals are openings between the rooms that the `Camera<class_Camera )` (and lights) can see through.
|
||||
The rooms and portals system is an optional component of Godot that allows you to partition your 3D game levels into a series of `Room( Room )` s (*aka cells*), and `Portal( Portal )` s. Portals are openings between the rooms that the `Camera( Camera )` (and lights) can see through.
|
||||
|
||||
This allows several features:
|
||||
|
||||
|
@ -16,13 +16,13 @@ Step 1
|
||||
![](tutorial_simple/img/tutorial_simple_1.png)
|
||||
|
||||
- Create a new project.
|
||||
- Add a `Spatial<class_Spatial )` as the scene root (on the screenshot, it's called "Root").
|
||||
- Next add a `RoomManager<class_RoomManager )` node. We will need this later to process the room system.
|
||||
- Add a `Spatial( Spatial )` as the scene root (on the screenshot, it's called "Root").
|
||||
- Next add a `RoomManager( RoomManager )` node. We will need this later to process the room system.
|
||||
- Next we need to start defining our rooms. We create all our rooms under another Spatial we have called 'RoomList'.
|
||||
- Add a new `Room<class_Room )` node as a child of the roomlist.
|
||||
- Add a new `Room( Room )` node as a child of the roomlist.
|
||||
- We have named the room `Kitchen`.
|
||||
- We will now create the geometry of our room. The names you give to the geometry is up to you.
|
||||
- Create a `MeshInstance<class_MeshInstance )` for the floor. Create a box by adding a CubeMesh resource to the MeshInstance. Scale and position it to form a floor.
|
||||
- Create a `MeshInstance( MeshInstance )` for the floor. Create a box by adding a CubeMesh resource to the MeshInstance. Scale and position it to form a floor.
|
||||
- Create MeshInstances for the walls. Create more box meshes for this, then scale and position them. Be sure to leave an opening on one side. You will need to create two wall segments to do this on that side.
|
||||
|
||||
Step 2
|
||||
@ -41,7 +41,7 @@ Step 3
|
||||
![](tutorial_simple/img/tutorial_simple_3.png)
|
||||
|
||||
- Next, we will add a portal between the two rooms.
|
||||
- Create a new `Portal<class_Portal )` in the kitchen.
|
||||
- Create a new `Portal( Portal )` in the kitchen.
|
||||
- Scale and position the portal using the node `Transform` in the inspector, so it fits within the opening between the two rooms.
|
||||
- The portal plane should face *outward* from the source room, i.e. towards the lounge. This direction is indicated by the arrow in the editor gizmo, and portal gizmo's color.
|
||||
|
||||
@ -54,7 +54,7 @@ Step 4
|
||||
- Placing these boxes as children or grandchildren of the room nodes explicitly tells the system which room the objects should be in. However, we can also create these objects *outside* the rooms. Provided they are in the RoomList branch, the system will attempt to automatically place them in the correct room at runtime.
|
||||
- On the screenshot, the boxes were places as children of a Spatial I have called `Freeform` to keep things tidy.
|
||||
- Boxes also have a green SpatialMaterial assigned to them to make them stand out more from the rest of the room.
|
||||
- Let's also create an `OmniLight<class_OmniLight )` so it will be autoplaced in one of the rooms.
|
||||
- Let's also create an `OmniLight( OmniLight )` so it will be autoplaced in one of the rooms.
|
||||
|
||||
Step 5
|
||||
~~~~~~
|
||||
|
@ -1,12 +1,12 @@
|
||||
Using objects in Rooms and Portals
|
||||
==================================
|
||||
|
||||
Normally, when you use Godot, all objects that you can see (`VisualInstance<class_VisualInstance )`\ s) are treated in the same way by the engine. The portal renderer is slightly different, in that it makes a distinction between the different roles objects will have in your game. It makes this distinction to define the `Room<class_Room )`\ s, and to render and process everything in the most efficient way.
|
||||
Normally, when you use Godot, all objects that you can see (`VisualInstance( VisualInstance )`\ s) are treated in the same way by the engine. The portal renderer is slightly different, in that it makes a distinction between the different roles objects will have in your game. It makes this distinction to define the `Room( Room )`\ s, and to render and process everything in the most efficient way.
|
||||
|
||||
Portal mode
|
||||
~~~~~~~~~~~
|
||||
|
||||
If you look in the inspector, every VisualInstance in Godot is derived from a `CullInstance<class_CullInstance )`, where you can set a `PortalMode`. This determines how objects will behave in the portal system.
|
||||
If you look in the inspector, every VisualInstance in Godot is derived from a `CullInstance( CullInstance )`, where you can set a `PortalMode`. This determines how objects will behave in the portal system.
|
||||
|
||||
![](img/cull_instance.png)
|
||||
|
||||
@ -90,6 +90,6 @@ While sprawling works great for large moving objects, it also gives you a lot mo
|
||||
Lighting
|
||||
~~~~~~~~
|
||||
|
||||
In general lights are handled like any other visual instance. They can be placed in rooms, and they will sprawl to affect neighbouring rooms, following the dimensions and direction of the light. The exception to this is `DirectionalLight<class_DirectionalLight )`\ s. DirectionalLights have no source room as they affect *everywhere*. They should therefore not be placed in a room. As DirectionalLights can be expensive, it is a good idea to turn them off when inside, see the later `doc_rooms_and_portals_roomgroups` section for details on how to do this.
|
||||
In general lights are handled like any other visual instance. They can be placed in rooms, and they will sprawl to affect neighbouring rooms, following the dimensions and direction of the light. The exception to this is `DirectionalLight( DirectionalLight )`\ s. DirectionalLights have no source room as they affect *everywhere*. They should therefore not be placed in a room. As DirectionalLights can be expensive, it is a good idea to turn them off when inside, see the later `doc_rooms_and_portals_roomgroups` section for details on how to do this.
|
||||
|
||||
Congratulations! You have now mastered the intermediate techniques required to use rooms and portals. You can use these to make games already, but there are many more features.
|
||||
|
@ -84,7 +84,7 @@ ArrayMesh
|
||||
The ArrayMesh resource extends Mesh to add a few different quality of life functions and, most
|
||||
importantly, the ability to construct a Mesh surface through scripting.
|
||||
|
||||
For more information about the ArrayMesh, please see the `ArrayMesh tutorial <doc_arraymesh )`.
|
||||
For more information about the ArrayMesh, please see the `ArrayMesh tutorial ( doc_arraymesh )`.
|
||||
|
||||
MeshDataTool
|
||||
^^^^^^^^^^^^
|
||||
@ -92,14 +92,14 @@ MeshDataTool
|
||||
The MeshDataTool is a resource that converts Mesh data into arrays of vertices, faces, and edges that can
|
||||
be modified at runtime.
|
||||
|
||||
For more information about the MeshDataTool, please see the `MeshDataTool tutorial <doc_meshdatatool )`.
|
||||
For more information about the MeshDataTool, please see the `MeshDataTool tutorial ( doc_meshdatatool )`.
|
||||
|
||||
SurfaceTool
|
||||
^^^^^^^^^^^
|
||||
|
||||
The SurfaceTool allows the creation of Meshes using an OpenGL 1.x immediate mode style interface.
|
||||
|
||||
For more information about the SurfaceTool, please see the `SurfaceTool tutorial <doc_surfacetool )`.
|
||||
For more information about the SurfaceTool, please see the `SurfaceTool tutorial ( doc_surfacetool )`.
|
||||
|
||||
ImmediateGeometry
|
||||
^^^^^^^^^^^^^^^^^
|
||||
@ -113,7 +113,7 @@ ImmediateGeometry is useful for prototyping because of its straightforward API,
|
||||
is rebuilt every frame. It is most useful for adding simple geometry for visual debugging (e.g. by drawing lines to
|
||||
visualize physics raycasts etc.).
|
||||
|
||||
For more information about ImmediateGeometry, please see the `ImmediateGeometry tutorial <doc_immediategeometry )`.
|
||||
For more information about ImmediateGeometry, please see the `ImmediateGeometry tutorial ( doc_immediategeometry )`.
|
||||
|
||||
Which one should I use?
|
||||
-----------------------
|
||||
|
@ -16,7 +16,7 @@ for certain mesh algorithms. If you do not need this extra information then it m
|
||||
We initialize the MeshDataTool from an ArrayMesh by calling `create_from_surface()`. If there is already data initialized in the MeshDataTool,
|
||||
calling `create_from_surface()` will clear it for you. Alternatively, you can call `clear()` yourself before re-using the MeshDataTool.
|
||||
|
||||
In the examples below, assume an ArrayMesh called `mesh` has already been created. See `ArrayMesh tutorial <doc_arraymesh )` for an example of mesh generation.
|
||||
In the examples below, assume an ArrayMesh called `mesh` has already been created. See `ArrayMesh tutorial ( doc_arraymesh )` for an example of mesh generation.
|
||||
|
||||
gdscript GDScript
|
||||
|
||||
@ -71,7 +71,7 @@ gdscript GDScript
|
||||
```
|
||||
|
||||
Below is a complete example that turns a spherical mesh called `mesh` into a randomly deformed blob complete with updated normals and vertex colors.
|
||||
See `ArrayMesh tutorial <doc_arraymesh )` for how to generate the base mesh.
|
||||
See `ArrayMesh tutorial ( doc_arraymesh )` for how to generate the base mesh.
|
||||
|
||||
gdscript GDScript
|
||||
|
||||
|
@ -7,7 +7,7 @@ Introduction
|
||||
------------
|
||||
|
||||
`Gridmaps` are a tool for creating 3D
|
||||
game levels, similar to the way `TileMap <doc_using_tilemaps )`
|
||||
game levels, similar to the way `TileMap ( doc_using_tilemaps )`
|
||||
works in 2D. You start with a predefined collection of 3D meshes (a
|
||||
`MeshLibrary`) that can be placed on a grid,
|
||||
as if you were building a level with an unlimited amount of Lego blocks.
|
||||
@ -19,7 +19,7 @@ Example project
|
||||
---------------
|
||||
|
||||
To learn how GridMaps work, start by downloading the sample project:
|
||||
:download:`gridmap_demo.zip <files/gridmap_demo.zip )`.
|
||||
:download:`gridmap_demo.zip ( files/gridmap_demo.zip )`.
|
||||
|
||||
Unzip this project and add it to the Project Manager using the "Import"
|
||||
button.
|
||||
|
@ -368,4 +368,4 @@ To apply the same easing curve to multiple keyframes at once:
|
||||
Skeletal deform can be used to augment a cutout rig, allowing single pieces to
|
||||
deform organically (e.g. antennae that wobble as an insect character walks).
|
||||
|
||||
This process is described in a `separate tutorial <doc_2d_skeletons )`.
|
||||
This process is described in a `separate tutorial ( doc_2d_skeletons )`.
|
||||
|
@ -142,7 +142,7 @@ There are several limitations with the current implementation of video playback
|
||||
|
||||
- Seeking a video to a certain point is not supported.
|
||||
- Changing playback speed is not supported. VideoPlayer also won't follow
|
||||
`Engine.time_scale<class_Engine_property_time_scale )`.
|
||||
`Engine.time_scale( Engine_property_time_scale )`.
|
||||
- Looping is not supported, but you can connect a VideoPlayer's
|
||||
`finished` signal to a function
|
||||
that plays the video again. However, this will cause a black frame to be
|
||||
|
@ -18,12 +18,12 @@ Godot will automatically import these files internally
|
||||
and keep the imported resources hidden in a `res://.import` folder.
|
||||
|
||||
This means that when trying to access imported assets through code you
|
||||
need to use the `Resource Loader<class_ResourceLoader )` as it will
|
||||
need to use the `Resource Loader( ResourceLoader )` as it will
|
||||
automatically take into account where the internal files are saved. If you
|
||||
try and access an imported asset using the `File` class
|
||||
it will work in the editor, but break in the exported project.
|
||||
|
||||
However, the `Resource Loader<class_ResourceLoader )` cannot access
|
||||
However, the `Resource Loader( ResourceLoader )` cannot access
|
||||
non imported files, only the `File` class can.
|
||||
|
||||
Changing import parameters
|
||||
|
@ -49,7 +49,7 @@ for music, speech, and long sound effects.
|
||||
Best practices
|
||||
--------------
|
||||
|
||||
Godot has an `extensive bus system <doc_audio_buses )` with built-in effects.
|
||||
Godot has an `extensive bus system ( doc_audio_buses )` with built-in effects.
|
||||
This saves SFX artists the need to add reverb to the sound effects,
|
||||
reducing their size greatly and ensuring correct trimming. Say no to SFX
|
||||
with baked reverb!
|
||||
|
@ -64,7 +64,7 @@ CSV files must be formatted as follows:
|
||||
+--------+----------+----------+----------+
|
||||
|
||||
The "lang" tags must represent a language, which must be one of the `valid
|
||||
locales <doc_locales )` supported by the engine. The "KEY" tags must be
|
||||
locales ( doc_locales )` supported by the engine. The "KEY" tags must be
|
||||
unique and represent a string universally (they are usually in
|
||||
uppercase, to differentiate from other strings). These keys will be replaced at
|
||||
runtime by the matching translated string. Note that the case is important,
|
||||
|
@ -151,7 +151,7 @@ The compressor has many uses. For example:
|
||||
|
||||
If your goal is to prevent a signal from exceeding a given amplitude
|
||||
altogether, rather than to reduce the dynamic range of the signal,
|
||||
a `limiter <doc_audio_buses_limiter )` is likely a better choice
|
||||
a `limiter ( doc_audio_buses_limiter )` is likely a better choice
|
||||
than a compressor.
|
||||
|
||||
|
||||
@ -259,7 +259,7 @@ Reverb
|
||||
Reverb simulates rooms of different sizes. It has adjustable parameters that can
|
||||
be tweaked to obtain the sound of a specific room. Reverb is commonly outputted
|
||||
from `Areas`
|
||||
(see `Reverb buses <doc_audio_streams_reverb_buses )`), or to apply
|
||||
(see `Reverb buses ( doc_audio_streams_reverb_buses )`), or to apply
|
||||
a "chamber" feel to all sounds.
|
||||
|
||||
SpectrumAnalyzer
|
||||
|
@ -26,11 +26,11 @@ The problem, in the end, is not this slight delay but synchronizing graphics and
|
||||
Using the system clock to sync
|
||||
------------------------------
|
||||
|
||||
As mentioned before, If you call `AudioStreamPlayer.play()<class_AudioStreamPlayer_method_play )`, sound will not begin immediately, but when the audio thread processes the next chunk.
|
||||
As mentioned before, If you call `AudioStreamPlayer.play()( AudioStreamPlayer_method_play )`, sound will not begin immediately, but when the audio thread processes the next chunk.
|
||||
|
||||
This delay can't be avoided but it can be estimated by calling `AudioServer.get_time_to_next_mix()<class_AudioServer_method_get_time_to_next_mix )`.
|
||||
This delay can't be avoided but it can be estimated by calling `AudioServer.get_time_to_next_mix()( AudioServer_method_get_time_to_next_mix )`.
|
||||
|
||||
The output latency (what happens after the mix) can also be estimated by calling `AudioServer.get_output_latency()<class_AudioServer_method_get_output_latency )`.
|
||||
The output latency (what happens after the mix) can also be estimated by calling `AudioServer.get_output_latency()( AudioServer_method_get_output_latency )`.
|
||||
|
||||
Add these two and it's possible to guess almost exactly when sound or music will begin playing in the speakers during *_process()*:
|
||||
|
||||
@ -65,9 +65,9 @@ For a rhythm game where a song begins and ends after a few minutes, this approac
|
||||
Using the sound hardware clock to sync
|
||||
--------------------------------------
|
||||
|
||||
Using `AudioStreamPlayer.get_playback_position()<class_AudioStreamPlayer_method_get_playback_position )` to obtain the current position for the song sounds ideal, but it's not that useful as-is. This value will increment in chunks (every time the audio callback mixed a block of sound), so many calls can return the same value. Added to this, the value will be out of sync with the speakers too because of the previously mentioned reasons.
|
||||
Using `AudioStreamPlayer.get_playback_position()( AudioStreamPlayer_method_get_playback_position )` to obtain the current position for the song sounds ideal, but it's not that useful as-is. This value will increment in chunks (every time the audio callback mixed a block of sound), so many calls can return the same value. Added to this, the value will be out of sync with the speakers too because of the previously mentioned reasons.
|
||||
|
||||
To compensate for the "chunked" output, there is a function that can help: `AudioServer.get_time_since_last_mix()<class_AudioServer_method_get_time_since_last_mix )`.
|
||||
To compensate for the "chunked" output, there is a function that can help: `AudioServer.get_time_since_last_mix()( AudioServer_method_get_time_since_last_mix )`.
|
||||
|
||||
|
||||
Adding the return value from this function to *get_playback_position()* increases precision:
|
||||
|
@ -20,7 +20,7 @@ many ways to avoid global state thanks to the node tree and signals.
|
||||
|
||||
For example, let's say we are building a platformer and want to collect coins
|
||||
that play a sound effect. There's a node for that: the `AudioStreamPlayer
|
||||
<class_AudioStreamPlayer )`. But if we call the `AudioStreamPlayer` while it is
|
||||
( AudioStreamPlayer )`. But if we call the `AudioStreamPlayer` while it is
|
||||
already playing a sound, the new sound interrupts the first.
|
||||
|
||||
A solution is to code a global, auto-loaded sound manager class. It generates a
|
||||
@ -68,7 +68,7 @@ or data across many scenes.
|
||||
|
||||
In the case of functions, you can create a new type of `Node` that provides
|
||||
that feature for an individual scene using the `name
|
||||
<doc_gdscript_basics_class_name )` keyword in GDScript.
|
||||
( doc_gdscript_basics_class_name )` keyword in GDScript.
|
||||
|
||||
When it comes to data, you can either:
|
||||
|
||||
|
@ -334,4 +334,4 @@ for blending, i.e. enabling smooth transitions between these animations. There
|
||||
may also be a hierarchical structure between animations that one plans out for
|
||||
their object. These are the cases where the `AnimationTree`
|
||||
shines. One can find an in-depth guide on using the AnimationTree
|
||||
`here <doc_animation_tree )`.
|
||||
`here ( doc_animation_tree )`.
|
||||
|
@ -155,7 +155,7 @@ following checks, in order:
|
||||
the ClassDB for the "visible" property against the CanvasItem class and all
|
||||
of its inherited types. If found, it will call the bound setter or getter.
|
||||
For more information about HashMaps, see the
|
||||
`data preferences <doc_data_preferences )` docs.
|
||||
`data preferences ( doc_data_preferences )` docs.
|
||||
|
||||
- If not found, it does an explicit check to see if the user wants to access
|
||||
the "script" or "meta" properties.
|
||||
|
@ -140,5 +140,5 @@ As such, the best options would be...
|
||||
into a plugin.
|
||||
|
||||
For an example of the various ways one can swap scenes around at runtime,
|
||||
please see the `"Change scenes manually" <doc_change_scenes_manually )`
|
||||
please see the `"Change scenes manually" ( doc_change_scenes_manually )`
|
||||
documentation.
|
||||
|
@ -52,7 +52,7 @@ your project's features.
|
||||
can be save and loaded, therefore they extend from Resource.
|
||||
|
||||
- **Advantages:** Much has
|
||||
`already been said <doc_resources )`
|
||||
`already been said ( doc_resources )`
|
||||
on `Resource`'s advantages over traditional data
|
||||
storage methods. In the context of using Resources over Nodes though,
|
||||
their main advantage is in Inspector-compatibility. While nearly as
|
||||
|
@ -218,7 +218,7 @@ the various menus and widgets the project needs.
|
||||
- Control "GUI" (gui.gd)
|
||||
|
||||
When changing levels, one can then swap out the children of the "World" node.
|
||||
`Changing scenes manually <doc_change_scenes_manually )` gives users full
|
||||
`Changing scenes manually ( doc_change_scenes_manually )` gives users full
|
||||
control over how their game world transitions.
|
||||
|
||||
The next step is to consider what gameplay systems one's project requires.
|
||||
@ -228,7 +228,7 @@ If one has a system that...
|
||||
2. should be globally accessible
|
||||
3. should exist in isolation
|
||||
|
||||
... then one should create an `autoload 'singleton' node <doc_singletons_autoload )`.
|
||||
... then one should create an `autoload 'singleton' node ( doc_singletons_autoload )`.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -246,7 +246,7 @@ If one has a system that...
|
||||
If one has systems that modify other systems' data, one should define those as
|
||||
their own scripts or scenes rather than autoloads. For more information on the
|
||||
reasons, please see the
|
||||
`Autoloads versus regular nodes <doc_autoloads_versus_internal_nodes )`
|
||||
`Autoloads versus regular nodes ( doc_autoloads_versus_internal_nodes )`
|
||||
documentation.
|
||||
|
||||
Each subsystem within one's game should have its own section within the
|
||||
|
@ -73,7 +73,7 @@ name.
|
||||
|
||||
There are two systems for registering types...
|
||||
|
||||
- `Custom Types <doc_making_plugins )`
|
||||
- `Custom Types ( doc_making_plugins )`
|
||||
|
||||
- Editor-only. Typenames are not accessible at runtime.
|
||||
|
||||
@ -90,7 +90,7 @@ There are two systems for registering types...
|
||||
|
||||
- Set up using `EditorPlugin.add_custom_type`.
|
||||
|
||||
- `Script Classes <doc_gdscript_basics_class_name )`
|
||||
- `Script Classes ( doc_gdscript_basics_class_name )`
|
||||
|
||||
- Editor and runtime accessible.
|
||||
|
||||
@ -157,7 +157,7 @@ makes a call to the scripting API which leads to many "lookups" on the back-end
|
||||
to find the logic to execute.
|
||||
|
||||
Scenes help to avoid this performance issue. `PackedScene
|
||||
<class_PackedScene )`, the base type that scenes inherit from, defines resources
|
||||
( PackedScene )`, the base type that scenes inherit from, defines resources
|
||||
that use serialized data to create objects. The engine can process scenes in
|
||||
batches on the back-end and provide much better performance than scripts.
|
||||
|
||||
|
@ -23,7 +23,7 @@ These scripts are not technically classes. Instead, they are resources that tell
|
||||
sequence of initializations to perform on one of the engine's built-in classes.
|
||||
|
||||
Godot's internal classes have methods that register a class's data with a `ClassDB
|
||||
<class_ClassDB )`. This database provides runtime access to class information. `ClassDB` contains
|
||||
( ClassDB )`. This database provides runtime access to class information. `ClassDB` contains
|
||||
information about classes like:
|
||||
|
||||
- Properties.
|
||||
|
@ -45,9 +45,9 @@ Command line reference
|
||||
+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| Command | Description |
|
||||
+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `-e`, `--editor` | Start the editor instead of running the scene (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `-e`, `--editor` | Start the editor instead of running the scene (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `-p`, `--project-manager` | Start the project manager, even if a project is auto-detected (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `-p`, `--project-manager` | Start the project manager, even if a project is auto-detected (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `-q`, `--quit` | Quit after the first iteration. |
|
||||
+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
@ -135,22 +135,22 @@ Command line reference
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--check-only` | Only parse for errors and quit (use with `--script`). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--export <target )` | Export the project using the given export target. Export only main pack if path ends with .pck or .zip (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `--export <target )` | Export the project using the given export target. Export only main pack if path ends with .pck or .zip (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--export-debug <target )` | Like `--export`, but use debug template (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `--export-debug <target )` | Like `--export`, but use debug template (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--doctool <path )` | Dump the engine API reference to the given <path> in XML format, merging if existing files are found (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `--doctool <path )` | Dump the engine API reference to the given <path> in XML format, merging if existing files are found (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--no-docbase` | Disallow dumping the base types (used with `--doctool`, `tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `--no-docbase` | Disallow dumping the base types (used with `--doctool`, `tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--build-solutions` | Build the scripting solutions (e.g. for C# projects, `tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `--build-solutions` | Build the scripting solutions (e.g. for C# projects, `tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--gdnative-generate-json-api` | Generate JSON dump of the Godot API for GDNative bindings (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `--gdnative-generate-json-api` | Generate JSON dump of the Godot API for GDNative bindings (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--test <test )` | Run a unit test. Use `--help` first to display the list of tests. (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| `--test <test )` | Run a unit test. Use `--help` first to display the list of tests. (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| `--export-pack <preset> <path )` | Like `--export`, but only export the game pack for the given preset. The <path> extension determines whether it will be in PCK or ZIP format. |
|
||||
| | (`tools <doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
| | (`tools ( doc_introduction_to_the_buildsystem_tools )` must be enabled). |
|
||||
+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
|
||||
Path
|
||||
|
@ -4,7 +4,7 @@ Editor manual
|
||||
In this section, we cover the Godot editor in general, from its interface to
|
||||
using it with the command line. We cover some specific editors' interface in
|
||||
other sections where appropriate. For example, the `animation editor
|
||||
<doc_introduction_animation )`.
|
||||
( doc_introduction_animation )`.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
@ -14,7 +14,7 @@ There are some reasons why you may want to do this:
|
||||
* Add external SDKs that build with your project.
|
||||
|
||||
Configuring the custom build is a fairly straightforward process. But first
|
||||
you need to follow the steps in `exporting for android<doc_exporting_for_android )`
|
||||
you need to follow the steps in `exporting for android( doc_exporting_for_android )`
|
||||
up to **Setting it up in Godot**. After doing that, follow the steps below.
|
||||
|
||||
Set up the custom build environment
|
||||
@ -29,7 +29,7 @@ download them.
|
||||
|
||||
A Gradle-based Android project will be created under `res://android/build`.
|
||||
Editing these files is not needed unless you want to `create
|
||||
your own add-ons<doc_android_plugin )`, or you really need to modify the project.
|
||||
your own add-ons( doc_android_plugin )`, or you really need to modify the project.
|
||||
|
||||
|
||||
Enabling the custom build and exporting
|
||||
|
@ -106,7 +106,7 @@ the **Application → Icon** field.
|
||||
.. note::
|
||||
|
||||
If rcedit fails to change the icon, you can instead
|
||||
`compile your own Windows export templates <doc_compiling_for_windows )`
|
||||
`compile your own Windows export templates ( doc_compiling_for_windows )`
|
||||
with the icon changed. To do so, replace
|
||||
`platform/windows/godot.ico ( https://github.com/godotengine/godot/blob/master/platform/windows/godot.ico )`
|
||||
with your own ICO file *before* compiling export templates.
|
||||
|
@ -12,7 +12,7 @@ Platform support
|
||||
- **Linux:** `Download an official Linux server binary ( https://godotengine.org/download/server )`.
|
||||
To compile a server binary from source, follow instructions in
|
||||
`doc_compiling_for_x11`.
|
||||
- **macOS:** `Compile a server binary from source for macOS <doc_compiling_for_osx )`.
|
||||
- **macOS:** `Compile a server binary from source for macOS ( doc_compiling_for_osx )`.
|
||||
- **Windows:** There is no dedicated server build for Windows yet. As an alternative,
|
||||
you can use the `--no-window` command-line argument to prevent Godot from
|
||||
spawning a window. Note that even with the `--no-window` command-line argument,
|
||||
|
@ -22,12 +22,12 @@ Requirements
|
||||
|
||||
.. warning::
|
||||
|
||||
Projects exported without code signing and notarization will be blocked by Gatekeeper if they are downloaded from unknown sources, see the `Running Godot apps on macOS <doc_running_on_macos )` page for more information.
|
||||
Projects exported without code signing and notarization will be blocked by Gatekeeper if they are downloaded from unknown sources, see the `Running Godot apps on macOS ( doc_running_on_macos )` page for more information.
|
||||
|
||||
Code signing and notarization
|
||||
-----------------------------
|
||||
|
||||
By default, macOS will run only applications that are signed and notarized. If you use any other signing configuration, see `Running Godot apps on macOS <doc_running_on_macos )` for workarounds.
|
||||
By default, macOS will run only applications that are signed and notarized. If you use any other signing configuration, see `Running Godot apps on macOS ( doc_running_on_macos )` for workarounds.
|
||||
|
||||
To notarize an app, you **must** have a valid `Apple Developer ID Certificate ( https://developer.apple.com/ )`.
|
||||
|
||||
@ -50,7 +50,7 @@ If you do not have an Apple Developer ID Certificate
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Keep `Code Signing` enabled and leave the `Identity` option empty (when exporting from a computer running macOS, on other platforms this option is hidden).
|
||||
In this case Godot will use a ad-hoc signature, which will make running an exported app easier for the end users, see the `Running Godot apps on macOS <doc_running_on_macos )` page for more information.
|
||||
In this case Godot will use a ad-hoc signature, which will make running an exported app easier for the end users, see the `Running Godot apps on macOS ( doc_running_on_macos )` page for more information.
|
||||
|
||||
Signing Options
|
||||
~~~~~~~~~~~~~~~
|
||||
|
@ -21,7 +21,7 @@ in the user's browser.
|
||||
.. attention:: `There are significant bugs when running HTML5 projects on iOS
|
||||
( https://github.com/godotengine/godot/issues?q=is:issue+is:open+label:platform:html5+ios )`
|
||||
(regardless of the browser). We recommend using
|
||||
`iOS' native export functionality <doc_exporting_for_ios )`
|
||||
`iOS' native export functionality ( doc_exporting_for_ios )`
|
||||
instead, as it will also result in better performance.
|
||||
|
||||
WebGL version
|
||||
@ -62,7 +62,7 @@ You can choose the **Export Type** to select which features will be available:
|
||||
- *GDNative*: enables GDNative support but makes the binary bigger and slower
|
||||
to load.
|
||||
|
||||
If you plan to use `VRAM compression <doc_import_images )` make sure that
|
||||
If you plan to use `VRAM compression ( doc_import_images )` make sure that
|
||||
**Vram Texture Compression** is enabled for the targeted platforms (enabling
|
||||
both **For Desktop** and **For Mobile** will result in a bigger, but more
|
||||
compatible export).
|
||||
@ -70,7 +70,7 @@ compatible export).
|
||||
If a path to a **Custom HTML shell** file is given, it will be used instead of
|
||||
the default HTML page. See `doc_customizing_html5_shell`.
|
||||
|
||||
**Head Include** is appended into the `<head )` element of the generated
|
||||
**Head Include** is appended into the `( head )` element of the generated
|
||||
HTML page. This allows to, for example, load webfonts and third-party
|
||||
JavaScript APIs, include CSS, or run JavaScript code.
|
||||
|
||||
@ -132,18 +132,18 @@ user's side, this can be worked around by running the project in a separate
|
||||
Threads
|
||||
~~~~~~~
|
||||
|
||||
As mentioned `above <doc_javascript_export_options )` multi-threading is
|
||||
As mentioned `above ( doc_javascript_export_options )` multi-threading is
|
||||
only available if the appropriate **Export Type** is set and support for it
|
||||
across browsers is still limited.
|
||||
|
||||
.. warning:: Requires a `secure context <doc_javascript_secure_contexts )`.
|
||||
.. warning:: Requires a `secure context ( doc_javascript_secure_contexts )`.
|
||||
Browsers also require that the web page is served with specific
|
||||
`cross-origin isolation headers ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy )`.
|
||||
|
||||
GDNative
|
||||
~~~~~~~~
|
||||
|
||||
As mentioned `above <doc_javascript_export_options )` GDNative is only
|
||||
As mentioned `above ( doc_javascript_export_options )` GDNative is only
|
||||
available if the appropriate **Export Type** is set.
|
||||
|
||||
The export will also copy the required GDNative `.wasm` files to the output
|
||||
@ -161,7 +161,7 @@ input event must currently be active.
|
||||
|
||||
For the same reason, the full screen project setting doesn't work unless the
|
||||
engine is started from within a valid input event handler. This requires
|
||||
`customization of the HTML page <doc_customizing_html5_shell )`.
|
||||
`customization of the HTML page ( doc_customizing_html5_shell )`.
|
||||
|
||||
Audio
|
||||
~~~~~
|
||||
@ -173,16 +173,16 @@ player to click or tap or press a key to enable audio.
|
||||
policies ( https://sites.google.com/a/chromium.org/dev/audio-video/autoplay )`.
|
||||
|
||||
.. warning:: Access to microphone requires a
|
||||
`secure context <doc_javascript_secure_contexts )`.
|
||||
`secure context ( doc_javascript_secure_contexts )`.
|
||||
|
||||
Networking
|
||||
~~~~~~~~~~
|
||||
|
||||
Low level networking is not implemented due to lacking support in browsers.
|
||||
|
||||
Currently, only `HTTP client <doc_http_client_class )`,
|
||||
`HTTP requests <doc_http_request_class )`,
|
||||
`WebSocket (client) <doc_websocket )` and `WebRTC <doc_webrtc )` are
|
||||
Currently, only `HTTP client ( doc_http_client_class )`,
|
||||
`HTTP requests ( doc_http_request_class )`,
|
||||
`WebSocket (client) ( doc_websocket )` and `WebRTC ( doc_webrtc )` are
|
||||
supported.
|
||||
|
||||
The HTTP classes also have several restrictions on the HTML5 platform:
|
||||
@ -202,7 +202,7 @@ browser supporting the `Clipboard API ( https://developer.mozilla.org/en-US/docs
|
||||
additionally, due to the API asynchronous nature might not be reliable when
|
||||
accessed from GDScript.
|
||||
|
||||
.. warning:: Requires a `secure context <doc_javascript_secure_contexts )`.
|
||||
.. warning:: Requires a `secure context ( doc_javascript_secure_contexts )`.
|
||||
|
||||
Gamepads
|
||||
~~~~~~~~
|
||||
@ -213,13 +213,13 @@ sadly the `Gamepad API ( https://developer.mozilla.org/en-US/docs/Web/API/Gamepa
|
||||
does not provide a reliable way to detect the gamepad information necessary
|
||||
to remap them based on model/vendor/OS due to privacy considerations.
|
||||
|
||||
.. warning:: Requires a `secure context <doc_javascript_secure_contexts )`.
|
||||
.. warning:: Requires a `secure context ( doc_javascript_secure_contexts )`.
|
||||
|
||||
Boot splash is not displayed
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The default HTML page does not display the boot splash while loading. However,
|
||||
the image is exported as a PNG file, so `custom HTML pages <doc_customizing_html5_shell )`
|
||||
the image is exported as a PNG file, so `custom HTML pages ( doc_customizing_html5_shell )`
|
||||
can display it.
|
||||
|
||||
Shader language limitations
|
||||
@ -240,7 +240,7 @@ servers and can be renamed to e.g. `index.html` at any time, its name is
|
||||
never depended on by default.
|
||||
|
||||
The HTML page draws the game at maximum size within the browser window.
|
||||
This way it can be inserted into an `<iframe )` with the game's size, as is
|
||||
This way it can be inserted into an `( iframe )` with the game's size, as is
|
||||
common on most web game hosting sites.
|
||||
|
||||
The other exported files are served as they are, next to the `.html` file,
|
||||
@ -249,7 +249,7 @@ the engine. The `.pck` file is the Godot main pack containing your game. The
|
||||
`.js` file contains start-up code and is used by the `.html` file to access
|
||||
the engine. The `.png)` file contains the boot splash image. It is not used in
|
||||
the default HTML page, but is included for
|
||||
`custom HTML pages <doc_customizing_html5_shell )`.
|
||||
`custom HTML pages ( doc_customizing_html5_shell )`.
|
||||
|
||||
The `.pck` file is binary, usually delivered with the MIME-type
|
||||
:mimetype:`application/octet-stream`. The `.wasm` file is delivered as
|
||||
@ -302,11 +302,11 @@ returned by `eval()` under certain circumstances:
|
||||
|
||||
Any other JavaScript value is returned as `null`.
|
||||
|
||||
HTML5 export templates may be `built <doc_compiling_for_web )` without
|
||||
HTML5 export templates may be `built ( doc_compiling_for_web )` without
|
||||
support for the singleton to improve security. With such templates, and on
|
||||
platforms other than HTML5, calling `JavaScript.eval` will also return
|
||||
`null`. The availability of the singleton can be checked with the
|
||||
`JavaScript` `feature tag <doc_feature_tags )`::
|
||||
`JavaScript` `feature tag ( doc_feature_tags )`::
|
||||
|
||||
func my_func3():
|
||||
if OS.has_feature('JavaScript'):
|
||||
|
@ -60,7 +60,7 @@ an export template selected while doing so.
|
||||
|
||||
![](img/export_pck.png)
|
||||
|
||||
Another method would be to `export from the command line <doc_command_line_tutorial_exporting )`.
|
||||
Another method would be to `export from the command line ( doc_command_line_tutorial_exporting )`.
|
||||
If the output file ends with a PCK or ZIP file extension, then the export
|
||||
process will build that type of file for the chosen platform.
|
||||
|
||||
|
@ -32,7 +32,7 @@ binary, which is smaller in size, more optimized and does not include
|
||||
tools like the editor and debugger.
|
||||
|
||||
Finally, Godot has a simple but efficient system for
|
||||
`creating DLCs as extra package files <doc_exporting_pcks )`.
|
||||
`creating DLCs as extra package files ( doc_exporting_pcks )`.
|
||||
|
||||
On mobile
|
||||
~~~~~~~~~
|
||||
|
@ -36,7 +36,7 @@ Here is a list of most feature tags in Godot. Keep in mind they are **case-sensi
|
||||
+-----------------+--------------------------------------------------------+
|
||||
| **HTML5** | Running on HTML5 |
|
||||
+-----------------+--------------------------------------------------------+
|
||||
| **JavaScript** | `JavaScript singleton <doc_javascript_eval )` is |
|
||||
| **JavaScript** | `JavaScript singleton ( doc_javascript_eval )` is |
|
||||
| | available |
|
||||
+-----------------+--------------------------------------------------------+
|
||||
| **OSX** | Running on macOS |
|
||||
@ -94,7 +94,7 @@ Here is a list of most feature tags in Godot. Keep in mind they are **case-sensi
|
||||
`false` when running a project exported to HTML5 on a mobile device.
|
||||
|
||||
To check whether a project exported to HTML5 is running on a mobile device,
|
||||
`call JavaScript code <doc_javascript_eval )` that reads the browser's
|
||||
`call JavaScript code ( doc_javascript_eval )` that reads the browser's
|
||||
user agent.
|
||||
|
||||
Custom features
|
||||
|
@ -60,8 +60,8 @@ This automatic translation behavior may be undesirable in certain cases. For
|
||||
instance, when using a Label to display a player's name, you most likely don't
|
||||
want the player's name to be translated if it matches a translation key. To
|
||||
disable automatic translation on a specific node, use
|
||||
`Object.set_message_translation<class_Object_method_set_message_translation )`
|
||||
and send a `Object.notification<class_Object_method_notification )` to update the
|
||||
`Object.set_message_translation( Object_method_set_message_translation )`
|
||||
and send a `Object.notification( Object_method_notification )` to update the
|
||||
translation::
|
||||
|
||||
func _ready():
|
||||
@ -143,4 +143,4 @@ For instance, for Spanish, this would be `application/name_es`:
|
||||
![](img/localized_name.png)
|
||||
|
||||
If you are unsure about the language code to use, refer to the
|
||||
`list of locale codes <doc_locales )`.
|
||||
`list of locale codes ( doc_locales )`.
|
||||
|
@ -145,7 +145,7 @@ To register a messages file as a translation in a project, open the
|
||||
**Project Settings**, then go to the **Localization** tab.
|
||||
In **Translations**, click **Add…** then choose the `.po` or `.mo` file
|
||||
in the file dialog. The locale will be inferred from the
|
||||
`"Language: <code>\n"` property in the messages file.
|
||||
`"Language: ( code>\n"` property in the messages file.
|
||||
|
||||
.. note:: See `doc_internationalizing_games` for more information on
|
||||
importing and testing translations in Godot.
|
||||
|
@ -150,7 +150,7 @@ gdscript GDScript
|
||||
print("T was pressed")
|
||||
```
|
||||
|
||||
.. tip:: See `@GlobalScope_KeyList <enum_@GlobalScope_KeyList )` for a list of scancode
|
||||
.. tip:: See `@GlobalScope_KeyList ( enum_@GlobalScope_KeyList )` for a list of scancode
|
||||
constants.
|
||||
|
||||
.. warning::
|
||||
@ -187,7 +187,7 @@ gdscript GDScript
|
||||
print("T was pressed")
|
||||
```
|
||||
|
||||
.. tip:: See `@GlobalScope_KeyList <enum_@GlobalScope_KeyList )` for a list of scancode
|
||||
.. tip:: See `@GlobalScope_KeyList ( enum_@GlobalScope_KeyList )` for a list of scancode
|
||||
constants.
|
||||
|
||||
Mouse events
|
||||
@ -201,7 +201,7 @@ means that all mouse events will contain a `position` property.
|
||||
Mouse buttons
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Capturing mouse buttons is very similar to handling key events. `@GlobalScope_ButtonList <enum_@GlobalScope_ButtonList )`
|
||||
Capturing mouse buttons is very similar to handling key events. `@GlobalScope_ButtonList ( enum_@GlobalScope_ButtonList )`
|
||||
contains a list of `BUTTON_*` constants for each possible button, which will
|
||||
be reported in the event's `button_index` property. Note that the scrollwheel
|
||||
also counts as a button - two buttons, to be precise, with both
|
||||
@ -240,7 +240,7 @@ gdscript GDScript
|
||||
|
||||
func _input(event):
|
||||
if event is InputEventMouseButton and event.button_index == BUTTON_LEFT:
|
||||
if (event.position - $Sprite.position).length() < click_radius:
|
||||
if (event.position - $Sprite.position).length() ( click_radius:
|
||||
# Start dragging if the click is on the sprite.
|
||||
if not dragging and event.pressed:
|
||||
dragging = true
|
||||
|
@ -30,7 +30,7 @@ Obtaining a ResourceInteractiveLoader
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
Ref<ResourceInteractiveLoader> ResourceLoader::load_interactive(String p_path);
|
||||
Ref( ResourceInteractiveLoader> ResourceLoader::load_interactive(String p_path);
|
||||
|
||||
This method will give you a ResourceInteractiveLoader that you will use
|
||||
to manage the load operation.
|
||||
@ -78,7 +78,7 @@ Obtaining the resource
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
Ref<Resource> ResourceInteractiveLoader::get_resource();
|
||||
Ref( Resource> ResourceInteractiveLoader::get_resource();
|
||||
|
||||
If everything goes well, use this method to retrieve your loaded
|
||||
resource.
|
||||
@ -153,7 +153,7 @@ precise control over the timings.
|
||||
|
||||
var t = OS.get_ticks_msec()
|
||||
# Use "time_max" to control for how long we block this thread.
|
||||
while OS.get_ticks_msec() < t + time_max:
|
||||
while OS.get_ticks_msec() ( t + time_max:
|
||||
# Poll your loader.
|
||||
var err = loader.poll()
|
||||
|
||||
@ -222,7 +222,7 @@ Example class
|
||||
-------------
|
||||
|
||||
You can find an example class for loading resources in threads here:
|
||||
:download:`resource_queue.gd <files/resource_queue.gd )`. Usage is as follows:
|
||||
:download:`resource_queue.gd ( files/resource_queue.gd )`. Usage is as follows:
|
||||
|
||||
::
|
||||
|
||||
|
@ -95,7 +95,7 @@ precision.
|
||||
0: null
|
||||
~~~~~~~
|
||||
|
||||
1: `bool<class_bool )`
|
||||
1: `bool( bool )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+-----------+---------------------------+
|
||||
@ -104,7 +104,7 @@ precision.
|
||||
| 4 | 4 | Integer | 0 for False, 1 for True |
|
||||
+----------+-------+-----------+---------------------------+
|
||||
|
||||
2: `int<class_int )`
|
||||
2: `int( int )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If no flags are set (flags == 0), the integer is sent as a 32 bit integer:
|
||||
@ -124,7 +124,7 @@ a 64-bit integer:
|
||||
| 4 | 8 | Integer | 64-bit signed integer |
|
||||
+----------+-------+-----------+--------------------------+
|
||||
|
||||
3: `float<class_float )`
|
||||
3: `float( float )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If no flags are set (flags == 0), the float is sent as a 32 bit single precision:
|
||||
@ -144,7 +144,7 @@ a 64-bit double precision number:
|
||||
| 4 | 8 | Float | IEEE 754 double-precision float |
|
||||
+----------+-------+---------+-----------------------------------+
|
||||
|
||||
4: `String<class_string )`
|
||||
4: `String( string )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+-----------+----------------------------+
|
||||
@ -157,7 +157,7 @@ a 64-bit double precision number:
|
||||
|
||||
This field is padded to 4 bytes.
|
||||
|
||||
5: `Vector2<class_vector2 )`
|
||||
5: `Vector2( vector2 )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+----------------+
|
||||
@ -168,7 +168,7 @@ This field is padded to 4 bytes.
|
||||
| 8 | 4 | Float | Y coordinate |
|
||||
+----------+-------+---------+----------------+
|
||||
|
||||
6: `Rect2<class_rect2 )`
|
||||
6: `Rect2( rect2 )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+----------------+
|
||||
@ -183,7 +183,7 @@ This field is padded to 4 bytes.
|
||||
| 16 | 4 | Float | Y size |
|
||||
+----------+-------+---------+----------------+
|
||||
|
||||
7: `Vector3<class_vector3 )`
|
||||
7: `Vector3( vector3 )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+----------------+
|
||||
@ -196,7 +196,7 @@ This field is padded to 4 bytes.
|
||||
| 12 | 4 | Float | Z coordinate |
|
||||
+----------+-------+---------+----------------+
|
||||
|
||||
8: `Transform2D<class_transform2d )`
|
||||
8: `Transform2D( transform2d )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+---------------------------------------------------------------+
|
||||
@ -215,7 +215,7 @@ This field is padded to 4 bytes.
|
||||
| 24 | 4 | Float | The Y component of the origin vector, accessed via [2][1] |
|
||||
+----------+-------+---------+---------------------------------------------------------------+
|
||||
|
||||
9: `Plane<class_plane )`
|
||||
9: `Plane( plane )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+---------------+
|
||||
@ -230,7 +230,7 @@ This field is padded to 4 bytes.
|
||||
| 16 | 4 | Float | Distance |
|
||||
+----------+-------+---------+---------------+
|
||||
|
||||
10: `Quat<class_quat )`
|
||||
10: `Quat( quat )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+---------------+
|
||||
@ -245,7 +245,7 @@ This field is padded to 4 bytes.
|
||||
| 16 | 4 | Float | Real W |
|
||||
+----------+-------+---------+---------------+
|
||||
|
||||
11: `AABB<class_aabb )`
|
||||
11: `AABB( aabb )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+----------------+
|
||||
@ -264,7 +264,7 @@ This field is padded to 4 bytes.
|
||||
| 24 | 4 | Float | Z size |
|
||||
+----------+-------+---------+----------------+
|
||||
|
||||
12: `Basis<class_basis )`
|
||||
12: `Basis( basis )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+---------------------------------------------------------------+
|
||||
@ -289,7 +289,7 @@ This field is padded to 4 bytes.
|
||||
| 36 | 4 | Float | The Z component of the Z column vector, accessed via [2][2] |
|
||||
+----------+-------+---------+---------------------------------------------------------------+
|
||||
|
||||
13: `Transform<class_transform )`
|
||||
13: `Transform( transform )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+---------------------------------------------------------------+
|
||||
@ -320,7 +320,7 @@ This field is padded to 4 bytes.
|
||||
| 48 | 4 | Float | The Z component of the origin vector, accessed via [3][2] |
|
||||
+----------+-------+---------+---------------------------------------------------------------+
|
||||
|
||||
14: `Color<class_color )`
|
||||
14: `Color( color )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+---------+--------------------------------------------------------------+
|
||||
@ -335,7 +335,7 @@ This field is padded to 4 bytes.
|
||||
| 16 | 4 | Float | Alpha (0..1) |
|
||||
+----------+-------+---------+--------------------------------------------------------------+
|
||||
|
||||
15: `NodePath<class_nodepath )`
|
||||
15: `NodePath( nodepath )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+-----------+-----------------------------------------------------------------------------------------+
|
||||
@ -378,13 +378,13 @@ For each Name and Sub-Name
|
||||
|
||||
Every name string is padded to 4 bytes.
|
||||
|
||||
16: `RID<class_rid )` (unsupported)
|
||||
16: `RID( rid )` (unsupported)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
17: `Object<class_object )` (unsupported)
|
||||
17: `Object( object )` (unsupported)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
18: `Dictionary<class_dictionary )`
|
||||
18: `Dictionary( dictionary )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+-----------+---------------------------------------------------------------------+
|
||||
@ -396,7 +396,7 @@ Every name string is padded to 4 bytes.
|
||||
Then what follows is, for amount of "elements", pairs of key and value,
|
||||
one after the other, using this same format.
|
||||
|
||||
19: `Array<class_array )`
|
||||
19: `Array( array )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+-----------+---------------------------------------------------------------------+
|
||||
@ -408,7 +408,7 @@ one after the other, using this same format.
|
||||
Then what follows is, for amount of "elements", values one after the
|
||||
other, using this same format.
|
||||
|
||||
20: `PoolByteArray<class_poolbytearray )`
|
||||
20: `PoolByteArray( poolbytearray )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+---------------+-------+-----------+------------------------+
|
||||
@ -421,7 +421,7 @@ other, using this same format.
|
||||
|
||||
The array data is padded to 4 bytes.
|
||||
|
||||
21: `PoolIntArray<class_poolintarray )`
|
||||
21: `PoolIntArray( poolintarray )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+------------------+-------+-----------+---------------------------+
|
||||
@ -432,7 +432,7 @@ The array data is padded to 4 bytes.
|
||||
| 8..8+length\*4 | 4 | Integer | 32-bit signed integer |
|
||||
+------------------+-------+-----------+---------------------------+
|
||||
|
||||
22: `PoolRealArray<class_poolrealarray )`
|
||||
22: `PoolRealArray( poolrealarray )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+------------------+-------+-----------+---------------------------+
|
||||
@ -443,7 +443,7 @@ The array data is padded to 4 bytes.
|
||||
| 8..8+length\*4 | 4 | Integer | 32-bits IEEE 754 float |
|
||||
+------------------+-------+-----------+---------------------------+
|
||||
|
||||
23: `PoolStringArray<class_poolstringarray )`
|
||||
23: `PoolStringArray( poolstringarray )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+----------+-------+-----------+--------------------------+
|
||||
@ -464,7 +464,7 @@ For each String:
|
||||
|
||||
Every string is padded to 4 bytes.
|
||||
|
||||
24: `PoolVector2Array<class_poolvector2array )`
|
||||
24: `PoolVector2Array( poolvector2array )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+-------------------+-------+-----------+----------------+
|
||||
@ -477,7 +477,7 @@ Every string is padded to 4 bytes.
|
||||
| 8..12+length\*8 | 4 | Float | Y coordinate |
|
||||
+-------------------+-------+-----------+----------------+
|
||||
|
||||
25: `PoolVector3Array<class_poolvector3array )`
|
||||
25: `PoolVector3Array( poolvector3array )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+--------------------+-------+-----------+----------------+
|
||||
@ -492,7 +492,7 @@ Every string is padded to 4 bytes.
|
||||
| 8..16+length\*12 | 4 | Float | Z coordinate |
|
||||
+--------------------+-------+-----------+----------------+
|
||||
|
||||
26: `PoolColorArray<class_poolcolorarray )`
|
||||
26: `PoolColorArray( poolcolorarray )`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+--------------------+-------+-----------+--------------------------------------------------------------+
|
||||
|
@ -52,7 +52,7 @@ The location of the `user://` folder depends on what is configured in the
|
||||
Project Settings:
|
||||
|
||||
- By default, the `user://` folder is created within Godot's
|
||||
`editor data path <doc_data_paths_editor_data_paths )` in the
|
||||
`editor data path ( doc_data_paths_editor_data_paths )` in the
|
||||
`app_userdata/[project_name]` folder. This is the default so that prototypes
|
||||
and test projects stay self-contained within Godot's data folder.
|
||||
- If `application/config/use_custom_user_dir`
|
||||
@ -85,7 +85,7 @@ On desktop platforms, the actual directory paths for `user://` are:
|
||||
+---------------------+------------------------------------------------------------------------------+
|
||||
|
||||
`[project_name]` is based on the application name defined in the Project Settings, but
|
||||
you can override it on a per-platform basis using `feature tags <doc_feature_tags )`.
|
||||
you can override it on a per-platform basis using `feature tags ( doc_feature_tags )`.
|
||||
|
||||
On mobile platforms, this path is unique to the project and is not accessible
|
||||
by other applications for security reasons.
|
||||
|
@ -49,8 +49,8 @@ The next step is to serialize the data. This makes it much easier to
|
||||
read from and store to disk. In this case, we're assuming each member of
|
||||
group Persist is an instanced node and thus has a path. GDScript
|
||||
has helper functions for this, such as `to_json()
|
||||
<class_@GDScript_method_to_json )` and `parse_json()
|
||||
<class_@GDScript_method_parse_json )`, so we will use a dictionary. Our node needs to
|
||||
( @GDScript_method_to_json )` and `parse_json()
|
||||
( @GDScript_method_parse_json )`, so we will use a dictionary. Our node needs to
|
||||
contain a save function that returns this data. The save function will look
|
||||
like this:
|
||||
|
||||
@ -92,7 +92,7 @@ Saving and reading data
|
||||
As covered in the `doc_filesystem` tutorial, we'll need to open a file
|
||||
so we can write to it or read from it. Now that we have a way to
|
||||
call our groups and get their relevant data, let's use `to_json()
|
||||
<class_@GDScript_method_to_json )` to
|
||||
( @GDScript_method_to_json )` to
|
||||
convert it into an easily stored string and store them in a file. Doing
|
||||
it this way ensures that each line is its own object, so we have an easy
|
||||
way to pull the data out of the file as well.
|
||||
@ -189,7 +189,7 @@ Additionally, our implementation assumes no Persist objects are children of othe
|
||||
Persist objects. Otherwise, invalid paths would be created. To
|
||||
accommodate nested Persist objects, consider saving objects in stages.
|
||||
Load parent objects first so they are available for the `add_child()
|
||||
<class_node_method_add_child )`
|
||||
( node_method_add_child )`
|
||||
call when child objects are loaded. You will also need a way to link
|
||||
children to parents as the `NodePath
|
||||
<class_nodepath )` will likely be invalid.
|
||||
( nodepath )` will likely be invalid.
|
||||
|
@ -10,7 +10,7 @@ high level of flexibility.
|
||||
Unlike more abstract mathematical concepts, Bezier curves were created for
|
||||
industrial design. They are a popular tool in the graphics software industry.
|
||||
|
||||
They rely on `interpolation<doc_interpolation )`, which we saw in the
|
||||
They rely on `interpolation( doc_interpolation )`, which we saw in the
|
||||
previous article, combining multiple steps to create smooth curves. To better
|
||||
understand how Bezier curves work, let's start from its simplest form: Quadratic
|
||||
Bezier.
|
||||
@ -197,8 +197,8 @@ Traversal
|
||||
|
||||
The last common use case for the curves is to traverse them. Because of what was mentioned before regarding constant speed, this is also difficult.
|
||||
|
||||
To make this easier, the curves need to be *baked* into equidistant points. This way, they can be approximated with regular interpolation (which can be improved further with a cubic option). To do this, just use the `Curve.interpolate_baked()<class_Curve_method_interpolate_baked )` method together with
|
||||
`Curve2D.get_baked_length()<class_Curve2D_method_get_baked_length )`. The first call to either of them will bake the curve internally.
|
||||
To make this easier, the curves need to be *baked* into equidistant points. This way, they can be approximated with regular interpolation (which can be improved further with a cubic option). To do this, just use the `Curve.interpolate_baked()( Curve_method_interpolate_baked )` method together with
|
||||
`Curve2D.get_baked_length()( Curve2D_method_get_baked_length )`. The first call to either of them will bake the curve internally.
|
||||
|
||||
Traversal at constant speed, then, can be done with the following pseudo-code:
|
||||
|
||||
|
@ -23,7 +23,7 @@ And often simplified to:
|
||||
|
||||
The name of this type of interpolation, which transforms a value into another at *constant speed* is *"linear"*. So, when you hear about *Linear Interpolation*, you know they are referring to this simple formula.
|
||||
|
||||
There are other types of interpolations, which will not be covered here. A recommended read afterwards is the `Bezier <doc_beziers_and_curves )` page.
|
||||
There are other types of interpolations, which will not be covered here. A recommended read afterwards is the `Bezier ( doc_beziers_and_curves )` page.
|
||||
|
||||
Vector interpolation
|
||||
--------------------
|
||||
|
@ -27,8 +27,8 @@ Global scope methods are easier to set up, but they don't offer as much control.
|
||||
|
||||
RandomNumberGenerator requires more code to use, but exposes many methods not
|
||||
found in global scope such as `randi_range()
|
||||
<class_RandomNumberGenerator_method_randi_range )` and `randfn()
|
||||
<class_RandomNumberGenerator_method_randfn )`. On top of that, it allows creating
|
||||
( RandomNumberGenerator_method_randi_range )` and `randfn()
|
||||
( RandomNumberGenerator_method_randfn )`. On top of that, it allows creating
|
||||
multiple instances each with their own seed.
|
||||
|
||||
This tutorial uses global scope methods, except when the method only exists in
|
||||
@ -38,7 +38,7 @@ The randomize() method
|
||||
----------------------
|
||||
|
||||
In global scope, you can find a `randomize()
|
||||
<class_@GDScript_method_randomize )` method. **This method should be called only
|
||||
( @GDScript_method_randomize )` method. **This method should be called only
|
||||
once when your project starts to initialize the random seed.** Calling it
|
||||
multiple times is unnecessary and may impact performance negatively.
|
||||
|
||||
@ -52,7 +52,7 @@ gdscript GDScript
|
||||
```
|
||||
|
||||
You can also set a fixed random seed instead using `seed()
|
||||
<class_@GDScript_method_seed )`. Doing so will give you *deterministic* results
|
||||
( @GDScript_method_seed )`. Doing so will give you *deterministic* results
|
||||
across runs:
|
||||
|
||||
gdscript GDScript
|
||||
@ -129,7 +129,7 @@ gdscript GDScript
|
||||
```
|
||||
|
||||
`RandomNumberGenerator.randi_range()
|
||||
<class_RandomNumberGenerator_method_randi_range )` takes two arguments `from`
|
||||
( RandomNumberGenerator_method_randi_range )` takes two arguments `from`
|
||||
and `to`, and returns a random integer between `from` and `to`:
|
||||
|
||||
gdscript GDScript
|
||||
@ -203,7 +203,7 @@ gdscript GDScript
|
||||
This approach can be useful to make random number generation feel less
|
||||
repetitive. Still, it doesn't prevent results from "ping-ponging" between a
|
||||
limited set of values. To prevent this, use the `shuffle bag
|
||||
<doc_random_number_generation_shuffle_bags )` pattern instead.
|
||||
( doc_random_number_generation_shuffle_bags )` pattern instead.
|
||||
|
||||
Get a random dictionary value
|
||||
-----------------------------
|
||||
|
@ -10,10 +10,10 @@ Pathfinding in a 3D environment is crucial for many games, it's commonly
|
||||
how non directly controlled characters or entities find their way around
|
||||
an environment. Godot provides several nodes for this purpose:
|
||||
|
||||
- `Navigation<class_Navigation )` (deprecated)
|
||||
- `NavigationMeshInstance<class_NavigationMeshInstance )`
|
||||
- `NavigationAgent<class_NavigationAgent )`
|
||||
- `NavigationObstacle<class_NavigationObstacle )`
|
||||
- `Navigation( Navigation )` (deprecated)
|
||||
- `NavigationMeshInstance( NavigationMeshInstance )`
|
||||
- `NavigationAgent( NavigationAgent )`
|
||||
- `NavigationObstacle( NavigationObstacle )`
|
||||
|
||||
The map and navigation regions
|
||||
------------------------------
|
||||
@ -23,12 +23,12 @@ the physics engine. It's comprised of navigation regions, these regions
|
||||
define parts of the world that can be navigated around by navigation
|
||||
agents.
|
||||
|
||||
To create a navigation region add the `NavigationMeshInstance<class_NavigationMeshInstance )`
|
||||
To create a navigation region add the `NavigationMeshInstance( NavigationMeshInstance )`
|
||||
node to a 3D scene. Next in the inspector for that mesh create or add a
|
||||
`NavigationMesh<class_NavigationMesh )`. The navmesh contains options
|
||||
`NavigationMesh( NavigationMesh )`. The navmesh contains options
|
||||
for how it will be generated when it's baked. The geometry options control
|
||||
which nodes, and types of nodes, are used to bake the mesh. A full
|
||||
description of each setting and how it works can be found in the `NavigationMesh class reference<class_NavigationMesh )`.
|
||||
description of each setting and how it works can be found in the `NavigationMesh class reference( NavigationMesh )`.
|
||||
|
||||
Once the settings have been properly configured press the "Bake NavMesh"
|
||||
button at the top of the inspector to generate it.
|
||||
@ -79,7 +79,7 @@ with `set_velocity`. Then a new velocity that takes into account other
|
||||
agents and obstacles is generated and emitted with the signal `velocity_computed`.
|
||||
|
||||
However agents can only take into account a set number of other nearby
|
||||
agents, this is the `max neighbors<class_NavigationAgent_property_max_neighbors )`
|
||||
agents, this is the `max neighbors( NavigationAgent_property_max_neighbors )`
|
||||
property of an agent and can be adjusted. This is **not** a limit for
|
||||
how many agents can use a navigation region at the same time.
|
||||
|
||||
|
@ -262,7 +262,7 @@ If `sync` is included, the call can also be made locally. For example, to allow
|
||||
|
||||
.. tip:: You can also use `SceneTree.get_rpc_sender_id()` to have more advanced rules on how an rpc can be called.
|
||||
|
||||
These keywords are further explained in `Synchronizing the game <doc_high_level_multiplayer_synchronizing )`.
|
||||
These keywords are further explained in `Synchronizing the game ( doc_high_level_multiplayer_synchronizing )`.
|
||||
|
||||
With this, lobby management should be more or less explained. Once you have your game going, you will most likely want to add some
|
||||
extra security to make sure clients don't do anything funny (just validate the info they send from time to time, or before
|
||||
|
@ -5,7 +5,7 @@ HTTP client class
|
||||
|
||||
`HTTPClient` provides low-level access to HTTP communication.
|
||||
For a higher-level interface, you may want to take a look at `HTTPRequest` first,
|
||||
which has a tutorial available `here <doc_http_request_class )`.
|
||||
which has a tutorial available `here ( doc_http_request_class )`.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user