Running dedicated servers
Running a dedicated Turbo Sliders Unlimited server
TSU Dedicated server is currently available for both Windows and Linux.
This document tells how to install and run one.
INSTALLING
The easiest way to install a dedicated server is to use an installation
packet that has scripts for downloading and running a server.
Installation packets can be downloaded from here:
- https://drive.google.com/drive/folders/1tzP1nrEyNShZeEjLyd1KE-lhXC8hRlYd?usp=sharing
Windows version should work as it is, but unfortunately, the Linux
version still requires some manual steps. See the Manual Install
section below for more information, but in short, you need to install
SteamCMD and make sure you have all required libraries installed
on your system (SDL2 is the one often missing by default). The script
must find steamcmd.sh under sub-directory steamcmd.
There is also an unofficial Linux based Docker container made by
Miikka Vainio: https://hub.docker.com/r/mmvv/tsu_server
Repository: https://hub.docker.com/repository/docker/mmvv/tsu_server
Before running the scripts, you can also check the Settings script and
possibly change some settings to for example give yourself admin rights
on the server.
If you run just the Install script, it will use SteamCMD to install or
update the server. The Run script also installs or updates server but
then launches it with the default setup, checking its exit value,
updating and/or relaunching the server if requested.
Note that for a server to be reachable by players, it must be visible
from the outside world. You may need to change your firewall settings
to allow that. Even if you use the server in relay mode, query port
must be reachable for matchmaking to work. There are several service
providers that offer both Windows and Linux servers you can use and
which are visible to outside world by default. For example, check
There are many ways to change server settings: you can use command-line
parameters, define setup scripts, run console commands or modify config
files. More about that later.
MANUAL INSTALL
If you want to install server manually (which is still partially required
for a Linux version), read on. This also helps you understand what the
automatic install scripts do.
First, you need to get SteamCMD. Information about how to do that on
different platforms here (included in the Windows simple installation packet):
- https://developer.valvesoftware.com/wiki/SteamCMD
When you run SteamCMD, you can install or upgrade TSU dedicated server
with the following commands:
force_install_dir ../server/
login anonymous
app_update 1815810 validate
That will set the server directory to '../server' but feel free to change that.
Then, it logins anonymously and installs or updates TSU dedicated server
to the install directory. It is also possible to run the commands
with a one-liner without launching SteamCMD prompt.
steamcmd +force_install_dir ../server +login anonymous +app_update 1815810 validate +quit
MANUALLY RUNNING A SERVER
The server is started by launching TSUs.exe on Windows or TSUs.x86_64
on Linux. As always with Linux, you may have to install some extra
libraries (especially SDL2) or move Steam .so files around for all the
required libraries to be found. Especially, if steamclient.so is not
found, it may mean you have to add a dynamic link from the correct 64-bit
version of steamclient.so to the installation directory (or just copy it).
But what is needed and how that is done may depend on the Linux distro.
By default, the server is run in server mode (anonymous Steam login)
using direct IP address. It is also possible to use relay connections
(command line parameter -relay) but the server should still be
reachable by IP, too, for the server list to work. It is also possible
to run a server in client mode (-client) which means there must be a
Steam user logged on to Steam. Most probably you don't want that as
it makes setup harder.
It is possible to run several instances of the server on one machine
(when not in client mode) but they should not share the same directory
or ports. The easiest way to do this is just to copy the installation
directory. But note that if there are more than one server instances
on one machine, a least one of them must change the default port to
something else, e.g. with command line parameter -port 7757. Note that
each server takes two ports, one for game and one for queries (port+1
by default).
COMMAND-LINE PARAMETERS
-help This help text
-name <name> Sets the server name (max 16 characters,
not used if in client mode)
-setup <setup> Changes the default setup script, running the script
'Scripts/setup.<setup>.src' at every session init
-info <info> Sets the server info text (name + info combined max
length 63 bytes in UTF-8)
-relay Uses relay host instead of a direct IP address
(SteamId based connection)
-client Runs the server in Steam client mode instead of an
anonymous login as server - must be logged on to
Steam then
-port <port> Sets the game port, 7755 by default
-queryPort <port> Sets the server query port
(if not set, using game port + 1)
-ip <ip> Overrides the default IP address with an
alternative address
-public Sets the server discoverability to public
(can be found in server list)
-hidden Sets the server discoverability to hidden
(not found in server list)
-cmd <command> Runs the given console command when hosting starts
(can be used multiple times to run several commands)
-admin <steamId> Adds the player with the given SteamID as an admin,
effectively the same as -cmd "/admins /add <steamId>"
SIMPLE SETUP
Dedicated server has been set up by default so that it keeps running
sessions of random 10 tracks until shut down. If you login with a player
that has admin rights, you have full access to change the settings as if
you were a local host, and also stop or resume the timer.
When the server is at session init state, you can upload your local
levels and vehicles to the server by using the Upload button in the level
and vehicle selectors. You can also change levels, vehicles and event
settings using the settings windows. You can also load settings and level
lists you have previously saved in their respective windows.
In addition to this, there are lots of more complex ways to control
the server, explained in the following chapters.
CONFIG DIRECTORY
By default, TSUs uses the directory 'config' as the root data directory
that is used for settings and content. If that directory is removed or
renamed, TSUs will use system default data folder, on Windows e.g.:
C:/users/<user>/AppData/LocalLow/Turbo Sliders/Unlimited/<steamID>/
Note that updating the server from Steam might redownload the config
directory even if you have removed or renamed it. If you have modified
files that are part of the installation package, they might also get
overwritten by the update so it is recommended to not edit existing
files but to instead create new ones.
The config directory is initially almost empty but once you have run
the game once, the settings will be saved as json files. You can also
edit those files while the server is off so that the new values are
taken into use when you restart it. You can also create Levels and
Vehicles directories to add more levels and vehicles. Dedicated server
updates its levels and vehicles automatically at session init by
default, but it is also possible to use the command /refreshfiles to
do that manually.
Settings can be changed while running the game with console commands
made by admins. Changed settings are saved when server quits or
restarts the session (unless initialization scripts override them).
REMOTE ADMINS
Remote admins can be added with command line option -admin or with console
command /admins /add <username or steam ID>. Alternatively, as any other
settings, they can be directly added to game.json under host/remoteAdmins
before the server is started. Admins are authenticated by their SteamIds.
See /help to find out what kind of commands there are for admins and others.
All settings that are available in the session and event init GUI are
scriptable by commands, too.
IMPORTING LEVELS AND VEHICLES
In addition to manually adding levels and vehicles to their respective
folders, it is also possible to upload or create level and vehicle packs
using the game client. This makes level updating much easier, since
otherwise, it may be hard to find the levels you have subscribed since
they are buried under Steam Workshop folders with varying names.
If you are logged on as admin, you can use the Upload button in the level
and vehicle selectors when a dedicated server is at the session init state.
When that is done and uploading finishes, server updates its levels or
vehicles to match the non-hidden items you have locally, including their
tags (Liked/Keeper) which may affect the random selection probability.
Note that this also removes the items the client does not have.
Another more complex way to import levels is to use the Export button
in the Play Menu's Level Selector, below the selectable levels list.
With that, you can create a zipped file containing all the levels you
have currently visible with your current filters, and also their level
tags (most importantly, Liked and Hidden). That creates an export file
with the extension "exported.zip". If that file is copied to the
server config directory, the server's Levels and LevelLists folders
will be replaced by the ones found inside the zip next time files are
refreshed (either automatically at session init or manually by
/refreshfiles).
Likewise, you can do a similar export in Vehicle Selector and copy the
exported vehicle and vehicle list pack to config directory to replace
the existing vehicles.
Note that all levels or vehicles currently visible in the selectable list
will be added to the export packet. If there are ones you don't want to
end up in the server, hide them or use some other tags or filters to
make them disappear from the list.
SETUP FILES
Files under Scripts directory that are of the format setup.*.src are
considered setup scripts. One default setup is included (setup.default.src)
and when a dedicated server is run, it is used for initial setup. It picks
10 random levels and starts an automatically advancing session (timer on),
also enabling voting.
If you want to use some other setup, you can copy the file with some other
name, e.g. setup.mysetup.src and change the settings to your liking. Now,
if you want to use that setup instead of the default setup, you can either
use command-line parameter -setup or change the setup while the server
is running by using command "/setup mysetup".
If there are more than 1 setups in the Scripts directory, you can also enable
setup voting with the command: /setupVotingOn = true
FLOW
Usually, autoserver should be used with timer.timerOn set to true
(console command "/timerOn = true" or by enabling the timer with the
GUI) so that the server will automatically advance to new states. If
not, an admin must manually advance the server with GUI controls or
using /continue command. The default setup enables timer automatically
but you can also make setups that don't do that if you want to.
If timer.restartSession is true (as it is by default), server will
automatically start a new session after a session ends. Otherwise, the
server will close down after one session. Server can be quit by a
remote admin with the command /quit. You can also specify return
value for quit with /quit /restart or /quit /upgrade so that if the
server was started with a launch script checking the return value, it
can automatically restart or upgrade the server.
Server can naturally be killed with Task Manager or Linux kill command, too,
but that should be avoided as clients do not notice this until after a timeout.
A client based server might also remain in the host list if a clean exit is
not done.
There is also Quit script in the installation packet. It closes the server by
using an autorun command.
AUTORUN COMMANDS
Server periodically checks if there is file autorun.src either in
the executable folder or Scripts folder. If there is, the server will
perform the commands in that file as an admin and delete the file (commands
will not get run before server can delete the file). Files are also deleted
at startup so that old outdated commands are not run.
SCRIPTING
When an admin runs command /src script, file Scripts/script.src is searched
and if found, the commands in that file are run as an admin.
If variable commands.automaticScripts is set to true, certain src files
are automatically run at different stages of the session flow:
- sessioninit.src when session starts
- eventinit.src when event init starts
- eventend.src when an event ends
- sessionend.src when session ends
When an admin runs command /cmd command, file Scripts/command is searched
and if found, it is run as an external executable. This could be a binary
executable or a batch file. For security reasons, no other paths (either
via C:\, .. or subfolders) are allowed and the file must be under Scripts.
If commands.generateStatsFiles is set to true, the game automatically
generates session and event stats as json files at event end. By
enabling automaticScripts and generateStatsFiles it is thus possible
to put /cmd processStats.bat to eventend.src and make a batch file
processStats.bat that reads the results of the event, then possibly
writes to a src file that is run by eventend.src after the /cmd
command.
Note that /cmd file blocks the server until the command has been completed
or until a timeout time has elapsed (10 seconds by default) so whatever it
does should not take much time. Especially, it should not be used when
an event is running since blocking severely affects gameplay. If something
more time consuming needs to be done, the batch file should spawn another
process to handle that.
PROBLEM SOLVING
If the server crashes or there are other issues, there are many ways to
try to find the reason. First of all, check the standard output for
indications on errors and callstacks. Then, you can check the game's own
log under config/Logs. Unity may also put information on crashes to
Player.log on user data folder. Steam may also creates log files for various
errors.
EXIT REASONS
When a server process exits cleanly, it will write its exit reason to
exitReason.rsn, also returning reason as an exit value. By using that
information, it is possible to make a launcher script that checks
the reason and updates and/or relaunches the server if requested.
The default launch script in the installation packet does exactly this.
Exit reasons:
- Quit (0)
- Unknown (220)
- Restart (221)
- Upgrade (222)
- InitFailed (223)
- Finished (224)
- Error (225)