.

    Bandwidth
    Console Logging
    Remote Administration Using Telnet
    Dos Window Administration
    Banning
    Mission List

Bandwidth

Server management of client bandwidth consumption  is controlled through two console preferences variables:
 

$pref::PacketRate	Number of update packets per sec. (Int)
$pref::PacketSize	Size of each update packet (Int)

The recommended default values are a packet rate of 10 and a packet size of 200.  Using these defaults values, each client consumes a maximum of about 2000 bytes per sec. or about 16Kbps.

The clients use the same preference variables (accessed through the Options/Network page) to request bandwidth from the server.  The server always grants bandwidth requests up to it's maximum values, which are it's preference settings. So, if the server has it's packet rate set to 10, and a client requests 15, the client only receives 10 packets per sec. The same for the packet size.  Clients may request less.  The server never allocates more bandwidth than a client has requested, so increasing the server settings does not automatically increase the amount for each client.

Player's can adjust their client packet rate and packet size settings on the Network/Options page.  This page presents the player with the following settings (TRIBES defaults to Modem settings):
 

Connection	Packet Rate	Packet Size
Modem	10	200
ISDN	15	300
T1+	15	400

Each client can have it's own settings, and the server can be communicating with each client using a different amount of bandwidth.

Increasing the bandwidth requested by the client, and allocated by the server, can have several effects; smoother motion for enemy players, elevators and doors are the most obvious.  The timing of explosions, projectiles and animation of turrets are also affected.  The more people and activity in a game, the more the increase in bandwidth will be noticeable. Increasing the bandwidth allowed for each client can dramatically increase your total bandwidth requirements, assuming that all the clients are requesting the maximum. Large LAN games is an example of where you may want to increase the bandwidth allowed to each client, without having to worry about your ISP.

Exceeding the bandwidth of your Internet connection will have detrimental effects on game play.  Clients connected to your server will mainly experience this as lag.  If players on your server are often complaining of lag, then you may be exceeding your bandwidth, (or possibly overloading your CPU with too many players).

Decreasing the packet rate and packet size to less than 10/200 is not recommended.  Decreasing the bandwidth will increase the perceived lag on your server, and generally have a detrimental effect on game performance for your clients.

Console Logging

Console logging is controlled using the $Console::LogMode (Int) variable.  When on, the console logs entries to the console.log file in the TRIBES root directory. The console operates in three modes:
 

$Console::LogMode Value (Int)	Mode
0	Logging off (Default)
1	Opens and closes the log file for each log entry
2	Keeps the log file open untill the mode changes

Operating in mode 1 provides access to the file while the server is operating, at the (negligible) expense of opening and closing the file on each update.  This is the recommended mode of operation.  If you have no intention of accessing the file until the server is down, then use mode 2.

Remote Administration Using Telnet

Remote telnet admin basically gives you direct access to the server, the same as if you were typing into the server's DOS box.  The server does not enable telnet by default. Set the following variables in your config file to enable it:
 

$TelnetPort	The port address to bind (Int)
$TelnetPassword	The login password, should be quoted (String)

To connect to the server, simply telnet to the ip/port address you've entered.  You'll be prompted for a password, if entered correctly, you will then have direct access to the server. See the Dos Window Administration section for a list of some of the relevant console commands.

DOS Window Administration

This is not all the console commands, but a few to get you started:
 

ListPlayers();	List all the clients connected to the server
MessageAll(type,"message");	Broadcast a message to all the clients, type (Int) (put 0 for now), message is a String.
CenterPrintAll("message",timeout=5);	Display a message in the center of all client screens, the time-out value, in seconds, defaults to 5
TopPrintAll("message",timeout=5);	Display a message at the top of all client screens, the time-out value, in seconds, defaults to 5
BottomPrintAll("message",timeout=5);	Display a message at the bottom of all the client screens, the time-out value, in seconds, defaults to 5

Client Specific commands.  The clientId (and integer value) can be found by using the ListPlayers() function, the first field for each player in the list is their client ID.
 

Client::SendMessage(clientId,type,"message");	Send a message to a client, clientId, type (Int) (put 0 for now), message is a String.
CenterPrint(clientId,"message",timeout=5);	Display a message in the center of a client's screen, the time-out value, in seconds, defaults to 5
TopPrint(clientId,"message",timeout=5);	Display a message at the top of a client's screens, the time-out value, in seconds, defaults to 5
BottomPrint(clientId,"message",timeout=5);	Display a message at the bottom of a client's screen, the time-out value, in seconds, defaults to 5
Net::Kick(clientId, "message");	Kick a client. The message is displayed on the client.
Server::loadMission(missionName,immediate=false);	Load a new mission, missionName (String) (without the .mis extension), if immediate (Bool) is false, then the game pauses to let players read the final objectives screen.
Server::nextMission(replay=false);	Cycle to the next mission. If the replay (Bool) argument is true, or if the server is in tournament mode, the current mission is restarted.

The naming convention for these functions may seem a little confusing (Client::, Net::, no prefix, etc.)  There actually is a reason for most of it, and as we continue to explain the console language and it's interface with the C++ code, all will become clear.

When connected directly to a server, server config variables, such as $Server::HostName, $Server::TimeLimit and $Server::MaxPlayes, can be changed with immediate effect.  A few variables, such as $Server::Port, will have no effect unless the server is restarted. Changing $Server::MaxPlayers to a lower number than currently logged in will keep new clients from connecting, but will not disconnect any of the current clients.

Banning

Banning keeps a client from both pinging and joining a server.  Clients can be banned with either an explicit transport address or with a transport address that ends in the * wild card.  A transport address is composed of three sections, each separated by a colon:

    Transport Protocal (IP, IPX) : Address : Port

    "IP:198.34.78.130:28000"        // Ban an explicit address, the port is ignored

    "IP:198.34.78.130"                   // Works the same as ubove

    "IP:121.42.45.*"                       // Ban everyone on the 121.42.45 network

The ban list tracks absolute time using the number of seconds since 00:00:00 GMT, January 1, 1970.  It is easier to ban addresses for a specific amount of time using  function BanList::add().  When the server is shutdown normally, the ban list is automatically exported into the tribes\config\banlist.cs file.  This same file is executed when the server starts up, so any entries made during the operation of the server are maintained between sessions.  Since the BanList tracks time internally using absolute time, if you ban someone for a day (86400 seconds), server up or down time will have no effect on the length of this ban.

Banning does not kick a player.  To do this use the Net::Kick function described in Dos Window Administration

Mission List

The mission list is used to control the list of missions presented to the player on both the Host Game screen and the server menu.  It is also used to initialize the next mission array which controls which mission to load after a mission finishes.

Note: The missionList.cs file was added to simplify mission list management, and will be released in version 1.2 of TRIBES.  If you don't have 1.2 (it hasn't been released at the time that this was written), you can download the missionList.cs file and put it in your tribes\config directory.   Download MissionList.cs Here

Mission list functions:
 

MissionList::clear();	Clears the list
MissionList::build();	Builds the mission list by scanning the mission directories of each loaded mod, including the base mod.
MissionList::addMission(missionName);	MissionName (String) is the name of the .dsc file for the mission (without the .dsc extension)
MissionList::initNextMission();	Initialize the next mission array with the missions currently added.

The following lines, added to your server config file, will initialize the mission list to contain two missions.  These will be the only mission presented to the players.
 

    // The exec command is only needed if you've downloade the missionList file

    // for versions 1.0 or 1.1 of TRIBES (doesn't hurt to leave it)

    exec(missionList);

    MissionList::clear();

    MissionList::addMission("Broadside");

    MissionList::addMission("Raindance");

    MissionList::initNextMission();

    $pref::lastMission = "Broadside";

 

 

Since both of these missions are CTF, your server will be a CTF only server.  The missions will cycle in the order that they are declared.  The $pre::lastMission variable is set to the mission to load when the server is started (dedicated servers always start with the last loaded mission).

If you want to change the next mission order without affecting the contents of the mission list, you can do so by setting the $nextMission array directly:
 

    //

    $nextMission["Broadside"] = "CrissCross";

    $nextMission["CrissCross"] = "Raindance";

    $nextMission["Raindance"] = "Broadside";

 

 

By changing this array manually, you can cycle through any mission of any type.  Make sure to make any changes to the nextMission array after you call the MissionList::initNextMission() function.  By default the nextMission array is intialized by the time the server config file or autoexec files are executed.

If you change the next mission array directly, make sure that every mission has an entry. If you miss a next mission entry for a mission, the server will fail to load the next mission and the clients will get stuck on a black screen.