~ (Tilde) - Toggle the debug console which many commands are run from. Use list to see a list of commands. Use help someCommand to get info about a command. The list command can also be provided with a filter like so: list show.
F3 - Toggle the debug overlay. Has a lot of useful info on networking, rendering, and other game state. Mouse over entities and areas to see things like entity id, grid id, coordinates and more.
F5 - Toggle entity spawn window
F6 - Toggle tile spawn window
B - Toggle sandbox window
Shift + F4 - Toggle UI
View Variables or VV for short is a tool to view and modify the variables of things. You can VV an object with the vv command or using the right-click verb.
You can also use the vvread, vvwrite and vvinvoke commands to use VV directly from the console.
Parameters the vv commands take:
vv /path/to/an/object will VV the path you entered. Check command auto-completion for all possibilities.
vv <IoC Interface>, eg vv IPlayerManager, will VV a client-side IoC thing.
vv S<IoC Interface>, eg vv SIPlayerManager, will VV a server-side IoC thing.
vv CE<Entity System>, eg vv CEPhysicsSystem, will VV a client-side entity system.
vv SE<Entity System>, eg vv CSPhysicsSystem, will VV a server-side entity system.
vv <EntityUid> will VV an entity. Both client and server, at once.
vv guihover will VV the current GUI control under the mouse.
devwindow opens a secondary window that contains a growing number of useful debugging and development tools:
- Secondary debug console
- UI tree view
YAML linter is a tool that attempts to serialize and validate every prototype defined in a .yml file, along with prototypes' member fields. It will collect information on any prototype it cannot serialize and provide the user with an output of those entities. This makes it incredibly useful for identifying where errors are occuring in your yaml, particularly typos and elusive inheritance issues.
To run YAML linter, you can use the shell command dotnet run --project Content.YAMLLinter in your project folder. If you're using an IDE such as Rider or VSCode, you can also use the YAML linter preset to run your project.
Integration tests are extremely minimal simulations of a SS14 environment that are designed to run 'test' code in order to locate issues that can only be found through live game simulation. You can use integration tests to make sure a system works as intended by simulating its effects and comparing them against expected values, for example making sure that when you buckle someone to a chair, then that person can't move.
To run integration tests, use the shell command dotnet test in your project folder. You can also use dotnet test --filter followed by the name of a specific test if you don't want to run every test at once. This is recommended as some tests can take a long time to run - see the section below about enabling server GC to make test runs more efficient! IDEs such as Rider or VSCode may also have built-in ways to run tests without using the terminal.
When you open a PR to the Wizard's Den repository on GitHub, integration tests will run on your PR automatically. If tests fail, you'll need to update your PR before it can get properly reviewed.
`Content.IntegrationTests` is the directory containing integration tests. It is not the same thing as the similarly-named `Content.Tests` folder.
Unit tests test a single "unit" without loading data from any other units, while integration tests check all units against each other. For example, a hypothetical unit test of `LocalizedDataset` might have a unit test which uses spoofed data to make sure that all the methods within that class work as expected alone, while an integration test may go through all the instances of that data type in the game (including resource loading, yaml parsing, prototype management, etc.) to make sure they work as expected together.
Unit/integration tests are used widely in software development outside of SS14, so ask around if you want more information on the distinction!
It's recommended that you enable server GC to run SS14 tests, especially integration tests (it cuts integration test times in half).
To enable this in various editors:
Unit Testing -> Test Runner and add an environment variable for COMPlus_gcServer=1
Pass -e COMPlus_gcServer=1 to the dotnet test command
Somebody who uses VS please fill this in
Scripting allows you to run a C# Interactive REPL inside the game! You can run scripts on both server and client. Note that scripting is disabled for release client builds due to size and security concerns, and you obviously need host level permissions to do it on the server.
To open scripting, there are two commands: csi and scsi. The former is on the client and the latter on the server. There is also watch which shows the output of a list of commands each frame (like your debugger's watch window).
See this link for an introduction (I guess).
Default globals you can use are defined in IScriptGlobals on both client and server. Useful ones are vv on the client, res<T>() for quick IoC resolve, etc...
By default the server is ran in "no lobby" mode. This means that the lobby is disabled and you're sent straight into the game when you connect to the server. This is convenient for testing of course, but if you want to actually test the lobby you can imagine why it's annoying.
To enable the lobby you need to set the config variable game.lobbyenabled to true. There are multiple ways to do this:
- Edit the server config file in the server's bin folder and add
lobbyenabled=trueunder the[game]section. - Pass
--cvar game.lobbyenabled=trueto the command you're using to launch the game. - Modify the variable mid-game by running
cvar game.lobbyenabled truein the server console. You will have to respawn your character to reach the lobby if you connected before doing this.
If you are using Rider, I would recommend making a separate run configuration (see below) with --cvar game.lobbyenabled=true.
To quickly check the lobby with a lighter setup, golobby will end the round, enable lobby, and dump you in the pregame lobby. You can skip the timer for the next round with forcepreset sandbox (or whatever gamemode you wish.)
sudoallows you to execute commands as the server console from your client. Most admin commands (likeban) are automatically sent to server if you have permission to use them, but certain server management commands likecvarcan only be executed from the server console normally. That's where you usesudo. Of course, this requires+HOST.exec <file>allows you to execute script files in the user data directory (%appdata%/space station 14/datafor client or similar depending on OS,datafolder next to executable for server). You could make alobbyscript that automatically restarts the round into lobby and then run it likeexec lobby:
sudo cvar game.lobbyenabled 1
restartroundnow
These are a few useful console commands and what they do. This is by no means an extensive list. To see all console commands use list.
guidump- dumps a complete dump of the GUI tree to a text file in%APPDATA%/Space Station 14/guidump.txt(Windows),~/Library/Application Support/Space Station 14/guidump.txt(macOS), or~/.local/share/Space Station 14/guidump.txt(Linux, yes it uses XDG base dir env variables).showrays- toggles debug drawing of physics rays. It takes a parameter for the lifetime of the rays.showbb- Visualizes bounding boxes and grids. Grids are shown as blue volumes, with their bounds being red lines. Bounding boxes are shown as red lines.physics shapes- Shows you the exact collision hulls of objects. Very useful if you are trying to configure a structure with a novel shape.dumpentities- dumps entity list of UIDs and prototypes.debugai- used for the tooltips above mob heads (currently covers thinking as well as pathfinder for that specific mob).pathfindercovers off overall pathfinding, which is currently the graph, routes, nodes (especially useful for JPS).togglelight- toggles light rendering. Useful for mapping.net_graph- Turn on withnet_graph 1, off withnet_graph 0. Shows graph of network usage.tp- Teleports a player to any location. Usage:tp <x> <y> [<MapId>].aghost- Toggles admin ghost mode for quickly exploring map.\restartroundnow- Unless you are working on the post game screen, usually what you want to end the round with. Restarts the round without the minute wait.restartround- Restarts the round as it normally ends, sending players back to the pre-round lobby.restart- Completely restarts the server.launchauth- Loads authentication tokens from your launcher settings when ran from the client. You can run this before connecting to a server to easily enable and test authentication from dev builds.deadmin- If you are working on anything that behaves differently for admins and non-admins, such as chat, you want to make sure that you manually de-admin to ensure it works for normal players too.
If you are using Rider, make the most out of run configurations to quickly switch between scenarios you are testing. This is more necessary if you need to alternate between testing various scenarios such as different database backends, but get creative. For example these are the run configurations I have at the time of writing:
You can use --cvar or +command to modify server configuration and automatically execute commands to set up your test environments easily. Look around the rest of this page for some ideas if you want.
By default, Rider will disable optimizations on all assemblies when running via debugger. This means that even BCL code (System) will run much slower than it otherwise would. This can make running things in the debugger quite painful.
You can disable this by unticking this checkbox in Settings -> Build, Execution & Deployment -> Debugger:
- renderdoc - Perfect for debugging the rendering engine and shaders.