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 <ip>, 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 <macrofile>'. 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 <file>" 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.
