Autoserver

Running a dedicated Turbo Sliders server

Most people should not need to read this help. If you want to run a server, in most cases you can just start server normally in the main menu. This file explains how one can run a dedicated Turbo Sliders server which does not have any overhead for graphics. Read on only if you are an expert and know what you are doing.

CREATING A DEDICATED SERVER DIRECTORY

Two Turbo Sliders processes should not be run at the same time in the same directory as this could result in the ini, player and record files being modified by two processes at the same time. Because of this, you must first create a new Turbo Sliders directory. The easiest way is just to copy the whole sliders directory (with its subdirectories) or to extract the installation packet to another location.

In addition to this, you must mark the directory to be a dedicated server directory. This is done by creating a file 'autoserver.srv' in the sliders directory. The file can contain anything but it must exist. After this, you cannot any more run the game in normal mode in this directory.

RUNNING SERVER

Automatic server is started with the command line option "-autoserver 1". To make starting server easier in Windows, I suggest you create a shortcut for this. When the server is in autoserver mode, it automatically performs commands defined in 'macros.ini' in different situations. The file can also be edited to change the times the server waits in different situations. The macro file is reloaded every time a new cup starts.

Automatic server can be run in full mode even if there is not a full license for normal playing. However, if you want to run the server in demo mode (to allow non-full game players join), use command line option "-demo 1".

COMMANDS AND SHUTTING DOWN

To make the server perform other admin commands than the automatic ones in 'macros.ini', you must put them in a file named 'autoserver.cmd'. The server periodically checks if this file exists (every 3 seconds or so), and if it does, it performs the line that is in the first line (and only that one), and then, removes the file. Note that this may take some time and you cannot have two commands at the same time.

For quitting the server, I suggest you make the following file (and name it for example "quitserver.bat"):

del autoserver.cmd
echo /quit > autoserver.tmp
rename autoserver.tmp autoserver.cmd

The rename stuff is there to make it a bit less probable that the server process happens to read the file before it has been completed. You can also try simply "echo /quit > autoserver.cmd" but there might be a slight probability that it fails.

If you just kill the server process, some data files can get corrupted and you must delete autoserver.lck before the next time you start the server. The lock file is there to make it hard to run two autoserver processes at the same time.

REMOTE ADMINS

You can also authorize remote clients to run admin commands. This is a security risk since passwords are sent in plain-text and IPs can be spoofed, but if you are sure you want to do it, here is how. There can be at most 30 different remote admins that can be added with the command /addadmin. For example:

/addadmin 127.0.0.1 pAsSwOrD

The first line means that clients that come from the IP 127.0.0.1 can now run admin commands this way:

/admin pAsSwOrD /ban NastyDriver
/admin pAsSwOrD /laps 10

You can also enter permanent admin mode with the command:

/admin pAsSwOrD

After that, all your commands are considered admin commands until you end the admin session by commanding "/admin pAsSwOrD" again.

If you set IP to ALL, it means that everyone who knows the password can run admin commands. This is of course an even bigger security risk. Note that if you want to connect to the master server using the same machine where the server is running, you probably need to use IP 127.0.0.1 instead of the real IP. You can check the IP what the server sees with the command '/who' when connected with the client. Special IP 'xxx' may also mean some broken IPs so don't use it. Admin rights can be removed with /removeadmin , but remember that if you have added admin rights in macros.ini (which is the preferred way to do it), the rights are restored when the next cup starts as the file gets reloaded. Password can be changed with /addadmin (if the IP already exists), but again, new cups reload macros.ini and its settings. Current admin IPs can be listed with '/admin' without parameters.

Remote admin commands, including authentication failures, are reported in log.txt.

CONFIGURING

One way to configure the game is to use the macros file. The Reg script in 'macros.ini' can be used to define settings for the particular cup. The default reg script defined in 'macros.ini' automatically creates cups with ten randomly selected tracks from the main tracks directory. You can also use other macro files by using the command line option '-macros '. Thus, you can specify ini files for different tracks, different laps etc. It is also possible to define macros that are automatically run before a certain track is to be raced. Read macros.ini for more information.

Starting from version 2.0.0, it is also possible to add source files in the game directory which are run with "/source " command. For example, command "/source test" executes commands from file 'test.src' which must be in the game directory. This is only allowed for admin users. Starting from 2.4.2.3, the game also searches for 'sources/test.src' if 'test.src' is not found in the game directory.

Another way is to use the main ini file. Automatic server uses the same configuration file 'sliders.ini' as the main game. So you can either edit this file or edit the settings running the normal game in this directory and changing the settings using menus (remember that you must first delete autoserver.srv to be able to do this and then recreate it).

Note that with automatic server, the server never stops using the master server if it has been configured to use it. Normal servers stop if there is a fatal error or three successive non-fatal errors. Thus, it is important to make sure that the master server is actually working when using an automatic server.

SCRIPTS

Starting from version 1.0.6, it is possible to define a script to be run after every race. RaceEndCmd in sliders.ini defines the name of the script and to enable it, you can either have "ScriptsOn 1" in sliders.ini or use the server command /scripts 1 (or to disable it with /scripts 0). Remember that if you use Linux, you probably need to add "./" in front of the script name unless "." is in your default PATH. And of course, the script needs to have execution rights. So, the required lines in sliders.ini could be like this:

ScriptsOn 1 RaceEndCmd ./raceEnd.sh

When the race end script is enabled, the game writes stats of the last race in an easy-to-parse form to racestats.log and runs the script after every race with racestats.log as its command line parameter. The working directory is the game directory. The idea of this feature is to make it possible to build stats systems for servers. You can use the scripts even with normal servers and local games, but note that when running the game in full screen in Windows, you will probably lose focus when the script is run. Also remember that the script should never block for a long time (even in error situations) since the game waits until it is finished.

In versions 2.0.0 and later, it is also possible to define custom script file which is automatically executed with command '/cmd'. If scripts are on, the file is by default "custom.cmd". All parameters given are written to file "input.prm" and the name of that file is also given as a parameter to the script. After the execution of the script has ended, source file "custom.src" is run and removed if found. This way, it is possible to make the script file display output or change settings. CustomCmd in sliders.ini defines the script file. If ScriptsOn is 1, only admins can run this command. If the value is 2, all users can run the command. Note that extra care with security must be taken, especially if every user can run the command. It should also be noted that running the command during a race can cause serious lag if executing the command is slow since the game waits for it to finish. Also, if the external command hangs, the game will not continue.