Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Redot.
Checking the stable version of the documentation...
Command line tutorial¶
Some developers like using the command line extensively. Redot is designed to be friendly to them, so here are the steps for working entirely from the command line. Given the engine relies on almost no external libraries, initialization times are pretty fast, making it suitable for this workflow.
Note
On Windows and Linux, you can run a Redot binary in a terminal by specifying its relative or absolute path.
On macOS, the process is different due to Redot being contained within an
.app
bundle (which is a folder, not a file). To run a Redot binary
from a terminal on macOS, you have to cd
to the folder where the Redot
application bundle is located, then run Godot.app/Contents/MacOS/Godot
followed by any command line arguments. If you've renamed the application
bundle from Godot
to another name, make sure to edit this command line
accordingly.
Command line reference¶
Legend
Available in editor builds, debug export templates and release export templates.
Available in editor builds and debug export templates only.
Only available in editor builds.
Note that unknown command line arguments have no effect whatsoever. The engine will not warn you when using a command line argument that doesn't exist with a given build type.
General options
Command |
Description |
|
Display the list of command line options. |
|
Display the version string. |
|
Use verbose stdout mode. |
|
Quiet mode, silences stdout messages. Errors are still displayed. |
Run options
Command |
Description |
|
Separator for user-provided arguments. Following arguments are not used by the engine, but can be read from |
|
Start the editor instead of running the scene. |
|
Start the Project Manager, even if a project is auto-detected. |
|
Start the editor debug server ( |
|
Quit after the first iteration. |
|
Quit after the given number of iterations. Set to 0 to disable. |
|
Use a specific locale. |
|
Path to a project ( |
|
Scan folders upwards for 'project.godot' file. |
|
Path to a pack (.pck) file to load. |
|
Render thread mode ('unsafe', 'safe', 'separate'). See Thread Model for more details. |
|
Remote filesystem ( |
|
Password for remote filesystem. |
|
Audio driver. Use |
|
Display driver (and rendering driver). Use |
|
Renderer name. Requires driver support. |
|
Rendering driver (depends on display driver). Use |
|
Use a specific GPU (run with |
|
Text driver (Fonts, BiDi, shaping). |
|
Pen tablet input driver. |
|
Enable headless mode ( |
|
Run the engine in a way that a movie is written (usually with .avi or .png extension).
|
Display options
Command |
Description |
|
Request fullscreen mode. |
|
Request a maximized window. |
|
Request windowed mode. |
|
Request an always-on-top window. |
|
Request window resolution. |
|
Request window position. |
|
Request window screen. |
|
Use a single window (no separate subwindows). |
|
Select XR mode ('default', 'off', 'on'). |
Debug options
Command |
Description |
|
Debug (local stdout debugger). |
|
Breakpoint list as source::line comma-separated pairs, no spaces (use |
|
Enable profiling in the script debugger. |
|
Show a GPU profile of the tasks that took the most time during frame rendering. |
|
Enable graphics API validation layers for debugging. |
|
Abort on GPU errors (usually validation layer errors), may help see the problem if your system freezes. |
|
Remote debug ( |
|
Scene tree runs in single-threaded mode. Sub-thread groups are disabled and run on the main thread. |
|
Show collision shapes when running the scene. |
|
Show path lines when running the scene. |
|
Show navigation polygons when running the scene. |
|
Show navigation avoidance debug visuals when running the scene. |
|
Print all StringName allocations to stdout when the engine quits. |
|
Simulate high CPU load (delay each frame by <ms> milliseconds). |
|
Force time scale (higher values are faster, 1.0 is normal speed). |
|
Forces disabling of vertical synchronization, even if enabled in the project settings. Does not override driver-level V-Sync enforcement. |
|
Disable render loop so rendering only occurs when called explicitly from script. |
|
Disable crash handler when supported by the platform code. |
|
Force a fixed number of frames per second. This setting disables real-time synchronization. |
|
Enable or disable frame delta smoothing ('enable', 'disable'). |
|
Print the frames per second to the stdout. |
Standalone tools
Command |
Description |
|
Run a script. |
|
Only parse for errors and quit (use with |
|
Starts the editor, waits for any resources to be imported, and then quits. Implies |
|
Export the project using the given preset and matching release template. The preset name should match one defined in export_presets.cfg.
|
|
Like |
|
Like |
|
Convert project from Redot 3.x to Redot 4.x. |
|
Show what elements will be renamed when converting project from Redot 3.x to Redot 4.x. |
|
Dump the engine API reference to the given |
|
Disallow dumping the base types (used with |
|
Rather than dumping the engine API, generate API reference from the inline documentation in the GDScript files found in <path>
(used with |
|
Build the scripting solutions (e.g. for C# projects). Implies |
|
Generate GDExtension header file 'gdnative_interface.h' in the current folder. This file is the base file required to implement a GDExtension. |
|
Generate JSON dump of the Redot API for GDExtension bindings named 'extension_api.json' in the current folder. |
|
Validate an extension API file dumped (with the option above) from a previous version of the engine to ensure API compatibility. If incompatibilities or errors are detected, the return code will be non-zero. |
|
Benchmark the run time and print it to console. |
|
Benchmark the run time and save it to a given file in JSON format. The path should be absolute. |
Path¶
It is recommended to place your Redot editor binary in your PATH
environment
variable, so it can be executed easily from any place by typing redot
.
You can do so on Linux by placing the Redot binary in /usr/local/bin
and
making sure it is called redot
(case-sensitive).
To achieve this on Windows or macOS easily, you can install Redot using
Scoop (on Windows) or Homebrew
(on macOS). This will automatically make the copy of Redot installed
available in the PATH
:
# Add "Extras" bucket
scoop bucket add extras
# Standard editor:
scoop install godot
# Editor with C# support (will be available as `godot-mono` in `PATH`):
scoop install godot-mono
# Standard editor:
brew install godot
# Editor with C# support (will be available as `godot-mono` in `PATH`):
brew install godot-mono
Setting the project path¶
Depending on where your Redot binary is located and what your current working directory is, you may need to set the path to your project for any of the following commands to work correctly.
When running the editor, this can be done by giving the path to the project.godot
file
of your project as either the first argument, like this:
redot path_to_your_project/project.godot [other] [commands] [and] [args]
For all commands, this can be done by using the --path
argument:
redot --path path_to_your_project [other] [commands] [and] [args]
For example, the full command for exporting your game (as explained below) might look like this:
redot --headless --path path_to_your_project --export-release my_export_preset_name game.exe
When starting from a subdirectory of your project, use the --upwards
argument for Redot to
automatically find the project.godot
file by recursively searching the parent directories.
For example, running a scene (as explained below) nested in a subdirectory might look like this when your working directory is in the same path:
redot --upwards nested_scene.tscn
Creating a project¶
Creating a project from the command line can be done by navigating the
shell to the desired place and making a project.godot
file.
mkdir newgame
cd newgame
touch project.godot
The project can now be opened with Redot.
Running the editor¶
Running the editor is done by executing Redot with the -e
flag. This
must be done from within the project directory or by setting the project path as explained above,
otherwise the command is ignored and the Project Manager appears.
redot -e
When passing in the full path to the project.godot
file, the -e
flag may be omitted.
If a scene has been created and saved, it can be edited later by running the same code with that scene as argument.
redot -e scene.tscn
Erasing a scene¶
Redot is friends with your filesystem and will not create extra metadata files.
Use rm
to erase a scene file. Make sure nothing references that scene.
Otherwise, an error will be thrown upon opening the project.
rm scene.tscn
Running the game¶
To run the game, execute Redot within the project directory or with the project path as explained above.
godot
Note that passing in the project.godot
file will always run the editor instead of running the game.
When a specific scene needs to be tested, pass that scene to the command line.
redot scene.tscn
Debugging¶
Catching errors in the command line can be a difficult task because they
scroll quickly. For this, a command line debugger is provided by adding
-d
. It works for running either the game or a single scene.
redot -d
redot -d scene.tscn
Exporting¶
Exporting the project from the command line is also supported. This is especially useful for continuous integration setups.
Note
Using the --headless
command line argument is required on platforms
that do not have GPU access (such as continuous integration). On platforms
with GPU access, --headless
prevents a window from spawning while the
project is exporting.
# `godot` must be a Redot editor binary, not an export template.
# Also, export templates must be installed for the editor
# (or a valid custom export template must be defined in the export preset).
redot --headless --export-release "Linux/X11" /var/builds/project
redot --headless --export-release Android /var/builds/project.apk
The preset name must match the name of an export preset defined in the
project's export_presets.cfg
file. If the preset name contains spaces or
special characters (such as "Windows Desktop"), it must be surrounded with quotes.
To export a debug version of the game, use the --export-debug
switch instead
of --export-release
. Their parameters and usage are the same.
To export only a PCK file, use the --export-pack
option followed by the
preset name and output path, with the file extension, instead of
--export-release
or --export-debug
. The output path extension determines
the package's format, either PCK or ZIP.
Warning
When specifying a relative path as the path for --export-release
, --export-debug
or --export-pack
, the path will be relative to the directory containing
the project.godot
file, not relative to the current working directory.
Running a script¶
It is possible to run a .gd
script from the command line.
This feature is especially useful in large projects, e.g. for batch
conversion of assets or custom import/export.
The script must inherit from SceneTree
or MainLoop
.
Here is an example sayhello.gd
, showing how it works:
#!/usr/bin/env -S redot -s
extends SceneTree
func _init():
print("Hello!")
quit()
And how to run it:
# Prints "Hello!" to standard output.
redot -s sayhello.gd
If no project.godot
exists at the path, current path is assumed to be the
current working directory (unless --path
is specified).
The first line of sayhello.gd
above is commonly referred to as
a shebang. If the Redot binary is in your PATH
as redot
,
it allows you to run the script as follows in modern Linux
distributions, as well as macOS:
# Mark script as executable.
chmod +x sayhello.gd
# Prints "Hello!" to standard output.
./sayhello.gd
If the above doesn't work in your current version of Linux or macOS, you can always have the shebang run Redot straight from where it is located as follows:
#!/usr/bin/redot -s