The Stingray engine accepts all command-line parameters detailed on this page.
If you launch the Stingray engine from a command-line prompt, you can use these parameters to specify the project data the game should load, to kick off the compilation and/or bundling processes, or to control other specific aspects of the engine operation.
You can also provide command-line parameters when you set up a target in the Connections panel of the Stingray Editor. See Using the Connections panel.
All parameters are optional, unless otherwise specified.
In your gameplay code, you can access all of the command-line parameters that were used to start the engine by calling the stingray.Application.argv() function. You can use this to read and respond to any of the parameters listed on this page, or to custom parameters whose names and significance you define.
Run the engine using the project settings from a particular toolchain directory (this will also compile the data if necessary):
stingray_win64_dev.exe --toolchain C:\work\toolchain
Run the engine using compiled data from a particular folder:
stingray_win64_dev.exe --data-dir D:\Projects\testbed_data\win32
Run the engine using bundled data:
stingray_win64_dev.exe --bundle-dir D:\Projects\testbed_data\win32_bundled
Run the engine using streamed data from a TCP/IP file server. The --data-dir is the directory on the file server the engine should use. The --secret should match the content of a .stingray-asset-server-secret file in that directory.
stingray_win64_dev.exe --host 172.64.22.32 --data-dir D:\Projects\testbed_data\win32 --secret PqdjliMO52Tu4As+FxuJig==
Cross-compile project data from the toolchain settings for a particular platform (win32, xb1, android, macosx, ios, ps4) :
stingray_win64_dev.exe --compile-for ps4 --toolchain C:\work\toolchain
Cross-compile and bundle project data using the toolchain settings:
stingray_win64_dev.exe --compile-for ps4 --bundle --toolchain C:\work\toolchain
Compile Win32 project data using a mapped core folder:
stingray_win64_dev.exe --compile --source-dir D:\projects\testbed --data-dir D:\projects\testbed_data\win32 --map-source-dir core C:\work\toolchain
Compile and bundle Win32 project data:
stingray_win64_dev.exe --compile --bundle --source-dir D:\projects\testbed --data-dir D:\projects\testbed_data\win32 --bundle-dir D:\projects\testbed_data\win32_bundled --map-source-dir core C:\work\toolchain
Specifies the end of the list of arguments for the engine. Any arguments following -- are assumed to be arguments for the game. They will be ignored by the engine but be available in Application.argv(). (Note that Application.argv() also includes all engine arguments.)
When this parameter is used, you don't have to specify --data-dir, --bundle-dir or --source-dir, instead your current project settings will be read from the folder DIRECTORY/settings and the directories will be inferred from there.
When you use the --toolchain parameter the data will first be compiled to the data directory and then the engine will be launched with that data. If you combine it with the --bundle parameter, the data will be bundled and then run from the bundle directory.
You can also use --toolchain with --compile-for. In that case, the data will be compiled for the specified platform and then the executable will exit.
Specifies the directory for compiled data.
When running the engine, data will be read from this directory if specified.
When --compile is used, this parameter specifies the destination for the data that the engine compiles for your project.
Specifies the directory for bundled data.
When running the engine, bundled data will be read from this directory if specified.
When --bundle is used, the compiler will build bundled data to this directory.
Specifies an URL to load bundled data from. When running, the engine will stream bundle data from this HTTP directory.
Tells the engine to load the settings from the specified .ini file instead of settings.ini.
This disables all rendering functionality. It is used to save memory and processing time when you want to run the engine as a server.
Tells the engine to boot in silent mode. In this mode, the engine won't prompt on asserts and errors
Adds modules to the callstack logging. Used when doing callstack translation. Only available on windows.
Tells the engine to perform initialization in forward mode. In this mode, the entire engine initialization is done before the update loop. This is default on all platforms except Web and UWP.
Tells the engine to perform initialization in deferred mode. In this mode, part of the engine initialization is done in the update loop. This is the default on Web and UWP.
Adds an additional directory to search for engine plugins. You can use multiple --plugin-dir arguments to add additional directories.
The plugin directories supplied with this argument are automatically set to be hot-reloadable.If a new plugin is found in the directory dir that matches the name of an already loaded plugin and that plugin supports the hot reload interface, the plugin will be reloaded.
Since the engine locks the DLLs it is using and the debugger can lock an arbitrary number of old .pdb files, you are recommended to add the following steps to your plugin's pre-build step:
rename ${plugin}.dll ${plugin}.dll.old rename ${plugin}.pdb ${plugin}.${timestamp}.pdb.old del *.old
Renaming ensures that the engine can still continue to use the old DLL while the new one is being created. We need to add a timestamp when renaming the PDB, since the debugger will lock any PDB it has encountered. The final del command must be set up to tolerate failure -- it will fail on the DLLs and PDBs that are still in use, leaving them in place.
Specify a piece of Lua code to be run after the Lua init() function has run.
Specifies the TCP/IP port that the engine's console server will be hosted on. External tools can connect to this port to communicate with the running engine.
On most consoles, where only one copy of the engine can run at a time, the engine will use port 14030 unless one is specified with this parameter.
On Xbox One, port 4601 will be used, since that is the default port for XboxOne desktop connections.
On PC where there can be many engine instances running simultaneously, the console server will use a random free port unless one is specified. On the PC, the Console finds running game engines to connect to by searching for running executables called "stingray_*.exe" with open TCP/IP ports
Tells the engine to delay starting up until the editor's Lua debugger connects to it and sends along all the debugging information it needs, like breakpoint locations. This is a more dependable way to ensure that the debugger will be fully initialized before the project starts up, instead of using --wait.
Tells the engine to wait for a connection to the logging console for the specified number of seconds before running. This ensures that the logging console captures early output from the game.
Tells the engine to wait for a connection to the logging console if an error occurs. This ensures that early errors are captured by the logging console.
Instructs the engine to compile the data in your project's source directory instead of running the game.
If you use this parameter, you must also provide:
The source directory for the project, using the --source-dir parameter.
The destination for the compiled data, using the --data-dir parameter.
Instructs the engine to create a bundle from the compiled data for your project instead of running the game.
If you use this parameter, you must also provide:
The directory that contains the compiled data, using the --data-dir parameter.
The destination for the bundled data, using the --bundle-dir parameter.
When --compile is used, this parameter specifies the location of your project's source folder.
When --compile or --bundle is used, this parameter tells the engine which platform you want to compile the data for. The platform value may be win32, ps4, android, ios or xb1.
When --compile or --bundle is used, this parameter tells the engine to continue and run the game after completing the data compilation and/or bundling steps. Note that you cannot use this parameter when you are cross-compiling for a different platform than you are running on.
When this flag is enabled, the compiler will query the network for compiled data before compiling locally. This can speed up compilation times (but can also make compile issues harder to debug). When the flag is enabled, the compiler will look for a cache server for compiled files at an address specified by the environment variable SR_REMOTE_CACHE_IP and query it for compiled versions of certain file types.
Tells the data compiler that debug information should be stripped from .lua files during compilation.
Tells the data compiler to try to verify that compiles are deterministic, by compiling every resource twice and comparing the result.
This parameter can be used to map a source path to a different directory than the --source-directory. It is most commonly used to map the core folder, i.e.:
--map-source-dir core c:\work
This will cause any source path in the core folder to be loaded from c:\work\core instead of from SOURCE_DIRECTORY/core.
You could use this to specify other shared folders than core.
Note that the second argument to --map-source-dir specifies the root directory in the other location, not the directory of the mapped dir. The mapped directory name will be joined to this root.
Tells the engine to compile in serial (no parallelization). This is typically used to debug the data-compile (as running in serial is simpler to understand). It can also be used if the parallel compile fails consistently as a way to continue working.
Specifies that resources should be compiled with the assumption that the specified flag is true.
Specifies that resources should be compiled with the assumption that the specified flag is false.
Only used for debugging. Says that the engine should freeze in the boot process, so that you have a chance to attach a debugger to it before continuing.
This will make the engine print its version number.
Tells the engine to dump a physics metadata file after booting. This file is needed for each platform that we want to compile physics objects for. Pre-built files are found in core/physx_metadata so you should never need to use this parameter.
Tells the engine to boot in Thumbnail Server mode. In this mode, the engine will listen to requests to generate thumbnail images for project resources and service them.
Tells the engine to run its unit tests.
Enable long running unit tests --test-for-minutes and --test-for-hours
Only tests that match the specified NAME will be run.
Do a hard assert for each test, instead of reporting errors at the end.
Allow unit tests to touch the disk.
Allow unit tests to use the network.
Used to run the engine with data streamed from a File Server. The engine will try to contact a file server at the specified IP address and stream the project from its --data-dir or --bundle-dir.
You can use a comma-separated list of IPs if you want to try to connect to multiple servers.
You can specify multiple host arguments to look for a file server on multiple addresses. This can be useful when the file server is a machine with multiple network cards.
A security option that prevents arbitrary clients from connecting to the asset server. To be able to connect the server and the client must be started with the same --secret argument. In addition, only directories that have a file called .stingray-asset-server-directory in them can be accessed. The content of the .stingray-asset-server-directory file does not matter.
On mobile devices, the engine will cache the served files locally in order to speed up the streaming over wifi. If you for some reason want to disable that cache, you can use this parameter.
You can use this parameter to specify a different directory for the file cache than the default. You can also use it to enable file caching on non-mobile platforms.
When this argument is used, all files in the local file cache are cleared.
When this argument is used, all the streaming resources are touched at the boot of the engine, causing them to be cached locally so that they don't stall on later playback.
When this argument is used, all the content from the file server will be installed locally in the specified directory, so that the engine can run without connection to the file server later.
The same as the --install-dir argument, but uses a default directory for installation instead of a user-specified directory. Only available on iOS.
Tells the engine to boot in Asset Server mode. In this mode the engine will listen for requests to compile data on port 14032 and service those requests.
When this parameter is used, the engine will first load its settings from settings.ini (or whatever has been specified with the --ini parameter), then it will load the settings from the file specified in --editor-ini and use that to override the settings from settings.ini.
This is typically used to start the engine in editor mode.
Forces the engine into pumped mode, where it won't advance to a new frame unless it is explicitly told to do so (over the TCP/IP connection).
This sets an integer that can be queried with Application.session_id() to distinguish between multiple running copies of the application.
These are internal parameters used by the Java layer to pass information to the executable on Android.
This disables automatic window creation and puts the responsibility for windows creation on the gameplay layer
Tells the engine to boot in Viewport Provider mode. In this mode the engine doesn't create its own window.
Specifies the dimensions of the engine main window.
Do not let the engine automatically attach to the parent process console automatically
Specifies that the engine main window should be created as a child window to the specified window. (Windows only.)
Disables the use of raw WM_INPUT messages in the engine.