Advanced Server Administration Guide

Revision as of 08:36, 4 August 2006 by G5 (talk | contribs) (Internet Speed Test)

So you've been running a server for awhile and now you'd like to do more with it? Maybe you've found that there are some punk-ass players out there that you really want to kick off your server? Maybe your players are asking for more, and you're saying "Hell yeah!" but you don't know what to actually do about it?

You've come to the right place!

Going further - Game Variations

There are a number of combinations of settings that make for interesting variations of the game. Here you will find more information on what you can and can't do.

Players | Competitions | Servers | Clans | Teams | Etiquette | What is a clan? | Gametypes

Fortress Style

  • Fortress: Capture the enemy base. This game can be played with teams or death match style.
    • Wild Fortress (Sty): Objective is to conquer the opponents' zone while defending yours on various maps.
    • Flag Fortress (FF) (Sty): A fortress game with fortress physics with the objective being to capture the opponents flag. Players are respawned if they are dead and a player (ally or opponent) touches the base with the respective color.
    • Onslaught (Sty): A fortress game in which respawning is enabled. You have three lives each to capture the opponent's base, or defend yours. There is only one team defending and one team attacking at a time.
  • Sumo: The object is to stay in a zone while trying to force the opponent out.
    • Team Sumo: Sumo with teams.


  • Classic: The oldest game variation, and until recently the only game variation available. Most of the documentation found on this wiki applies to it, either directly or indirectly.
    • Free-for-all (sometimes referred to as Deathmatch): Players compete against one another as either individuals or teams, in an "every player (or team) for him- or herself" scenario. Scoring may be awarded (or deducted) based on one or any combination of core dumps (kills), general protection faults (deaths), "suicides", winzone contact, and/or round win/survival. Match completion may be decided by one or any combination of score limit, round limit, or time limit.
    • Last Man Standing: Distinguished by round win/survival accounting for the sole or predominant method of scoring.
  • Rubber Value. Many players have taken to further classifying standard FFA or LMS servers by the basic and/or general amount of rubber available (and ensuing gameplay mechanics). Simplistically, they are as follows:
    • No Rubber (NR): CYCLE_RUBBER is set to 0 or some fraction of 1.
    • Low Rubber (LR): Rubber value of 1 to 3.
    • Medium Rubber (MR): Rubber value of 3 to 5.
    • High Rubber (HR): Any value over 5, though generally 10 and above. These servers also tend to have a large arena, high speed, low CYCLE_DELAY, and strong brakes.
      • It should be noted that there are several rubber-related settings which all act in concert, and usually relative to speed and cycle delay to boot. These can all be manipulated in such a manner that the resulting gameplay may deviate from the above definitions. These should only be considered short-hand reference.
  • Variations.
    • Dog Fight (DF): Currently it is a mode that consists of slow bikes and medium rubber (around 10). In most DF servers, theres are rules to trapping your opponent that is widely accepted throughout the armagetron advanced community, but is not completely defined. You may not trap you opponent using a "seal" or "stab". [editor's note: this section should be rewritten for greater clarity and precision about Dogfight rules, irrespective of game physics--and/or link to a page specifically about "Dogfight/open/loose" gameplay and terminology.]
    • Repawns: Also known as "respawning", this game mode is similar to Classic except that players who die respawn. After respawning, they may be invulnerable and blink for a number of seconds to clear any nearby walls. Players joining the game spawn immediately, and do not need to wait for a new round. The match is usually only ended by a score or time limit-- rounds almost never end except by win zone since deaths are temporary. The hack required to do this is included with recent versions or arma, but you need to #define RESPAWN_HACK (or -DRESPAWN_HACK) when compiling the server to use it.

Note: Almost every Deathmatch server, regardless of name or amount of rubber, has degraded to the constant propagation of arbitrary rules and the enforcement of them through kick polls. "No Rubber" servers seem to be the safest place for those who actually like to core dump their opponents instead of mashing buttons and typing expletives.


Racing and Maze

  • Race: Race to the win zone at the end of the map.
    • Cockpit Racing: Racing with only a cockpit view enabled.
  • Maze: Find a path to the win zone.
  • Roulette: Multiple players create a "maze" Then try to navigate out.

Flag Based Sty Patch

These require you to apply a Source Patch and to recompile arma.

  • Capture the Flag (CTF): Capture the opponents' flag. Players are respawned if they are dead and a player (ally or opponent) touches the base on the respective side.
    • Capture The Flag Shooting (CTFS): Capture the opponents' flag while shooting. Players are respawned if they are dead and a player (ally or opponent) touches the base on the respective side.
    • Flag Fortress (FF): A fortress game with fortress physics with the objective being to capture the opponents flag. Players are respawned if they are dead and a player (ally or opponent) touches the base with the respective color.
  • Hold The Flag (HTF): A flag is placed in the map. The object of the game is to take it and survive as long as possible without being killed.

Non-Flag Based Sty Patch

These require you to apply a Source Patch and to recompile arma.

  • Shooting: A team death match where the object is to try to shoot the other team's players with death zones.
  • StyBall (Soccer): Two teams have a goal each. A ball is bounced between players from both teams who attempt to move it into the enemy goal, which awards points and ends the round. New players and dead players respawn.
  • Wild Fortress: Objective is to conquer the opponents' zone or zones zone while defending yours' on various maps.
  • Onslaught: A fortress game in which respawning is enabled. You have three lives each to capture the opponent's base, or defend yours. There is only one team defending and one team attacking at a time.



Labyrinth 22.png

Labyrinth is both a type of map. We use the word 'labyrinth' in order to differentiate a specific map type from a grid game.

On a labyrinth, you ride your cycle through a big maze with winding and twisting corridors. The server can be configured in any of the regular ways, so you could be on a team trying to capture the enemies' fortresses, or you can be in a gladiatorial-style fight. There's a third type, however. In the third type, the map maker has placed a zone at a strategic place in the labyrinth and the first person to reach the zone wins the round. In this type of game, the purpose of the game is to solve the labyrinth faster than the other players. Point awards will usually be based on solving the maze rather than slaughtering the other players.

There is at least one script that generates maze maps that work in Armagetron Advanced. Check the Code_hacks page for it.

There also is a tutorial that shows how you can make your own server with random maps.

MCP Attack

This game mode is based off the final scene from the movie TRON. The goal of the red team (the MCP Warrior Elite) is to defend the MCP (slow rotating red zone) while the goal of the blue team (the Video Warriors) is to try to conquer it as a zone. The MCP Warrior Elite can not be killed by ordinary means as they can drive through walls. Upon the Video Warriors conquering the MCP zone, it turns blue and kills off the MCP Warrior Elite.

A version with the required hack is available from SVN.

Christians vs Satanists

This game mode relies on three teams: Satanists (played by humans), Christians (also human), and God (played by AI). The God team CANNOT be killed, and any attempt will result in the death of the offender. The Christian team loses points for killing. Their goal is to stay close to players from the God team such that any Satanists attempting to harm them get smitten by God. Satanists mostly play as usual, being careful not to get in God's way.

A version with the required hack is available from SVN.


Summary: This game mode is based on the sport we all love, Paintball. Also, it is the first first person shooter in Armagetron. To move you simply you hold your brake key down and to shoot an opponent you tap your brake key. Paintball is still in development and some bugs still occur.

Objective: The objective is to concur the other team, although soon there will be different versions of paintball we call "minigames", they will have different objectives.

Rules: The only rule is no wall-hacking (going up to a 'big' wall [unlike a sniper ship] and shooting other players, because they cannot defend themselves. Other:

  • Game Mode Made By: Dukevin
  • Game Mode currently available in: RX PAINTBALL and DJ RICHARD PAINTBALL

Dealing with Lag

The simple fact is, there's a certain amount of lag you can't fix. For the rest, there's MasterCard!

Bandwidth Limiting

Bandwidth is measured in kilobytes per second and is controlled by MAX_OUT_RATE. If you set it to 4, there will be some lag at the beginning of the round. 6 is considered minimum for a production server.

To calculate how many players to limit on your server, you need to know how much upstream bandwidth you have. That's bandwidth leaving your server.  :) Then figure out how much of that you want your game server to use. Divide it by 6. If you get a really large number, such as 3000, then you probably don't need to worry about limiting bandwidth. On the other hand, if you come out near 20, then try a higher number. Keep trying until you get to the highest number for the number of players.

You can test your internet speed by visiting one of the websites in the resource section at the bottom of this page.


You have 512kbit/sec of upstream bandwidth. That converts to 64kilobytes/second of upstream bandwidth. 64/6 = 10.6666. Since you can't have 2/3 of a player, that's 10 players. That's also using the recommended minimum setting. Let's assume you want to have a maximum of 12 players on your server. Divide 64 by 12 and you get: 5.33333kb/sec. So you can go ahead and do MAX_OUT_RATE 5.3333333 and MAX_CLIENTS 12 and your full server will need all available upstream bandwidth.

Now, you say you want to be able to surf the web and send email while people are playing on your server? Easy enough. Leave some room. So you decide that 32kb/sec is enough for you to do your other internet tasks without significantly disturbing the players on your server. 64-32=32kb/sec available for the server. 32/12=2.66666666, so you won't be able to handle 12 clients and leave that much room for other uses.

Simulation Framerate

If you're running on an older server, or you just want a more predictable server, you should consider limiting the framerate of the simulation. What is the simulation framerate? Well, it's just like the FPS number you see, only it applies to the internal simulation of the game on the server. Since that doesn't make sense, just think of it as the number of times per second the server thinks about the game. The rest of the time, it just eats chips or something.

You limit the framerate of the simulation with DEDICATED_FPS. You'll have to decide what you prefer for the simulation, but you can use this setting to get more mileage out of your server. Good values range from 50-100. You should aim for a certain CPU usage target. So for example, you decide that 10% usage is the most the server should take up, then you connect MAX_CLIENTS number of clients to the server, open up a process viewer that shows CPU load for the server process, and play with DEDICATE_FPS until the process uses about 10%, which is your target in this example.

There's no hard and fast rule, and CPU usage will vary depending on how much it has to simulate, so pick a DEDICATED_FPS that makes for the most stable game you like to play.

Other network settings that affect lag


CYCLE_SYNC_FF Speed of simulation of the extrapolating sync; decrease for lower CPU load, but higher effective ping
CYCLE_SYNC_FF_STEPS Number of extrapolation simulation timesteps each real timestep; increase for better accuracy
CYCLE_SYNC_INTERVAL_ENEMY Time in seconds between server-client updates of enemy cycles


CYCLE_SYNC_INTERVAL_SELF Time in seconds between server-client updates of enemy cycles owned by the client itself

Dealing with unruly players

There are several ways to deal with unruly players. We'll touch on each of them here.


A common way is to have a group of moderators available so that your server usually has people logged in and playing who can use in-game admin to kick evil doers out of the server. You do this by setting ADMIN_PASS in your settings_custom.cfg file and then giving that password out to your preferred moderators. Then they will use the password like this:

While playing on the server, in a chat prompt, type /login ADMIN_PASS, replacing ADMIN_PASS with the password you have set for the server. This logs the player into the in-game admin system. Now you can execute commands with /admin COMMAND ARGUMENTS. Use /logout to leave the in-game admin system.

Every command is available, so be cautious to whom you give your ADMIN_PASS!


Voting is a popular way to deal with unruly players. It has the advantage of giving power to the players on the server and letting them decide how they want the grid to be when playing. It comes at a cost, though. First, as an admin you need to respect your players' choices. This doesn't mean you should let them walk all over you, but what's the point of letting them vote in the first place if you're just going to override it? Second, it is possible to exploit the voting system as an unruly player. There will be some more safeguards in 0.2.8 to deal with this, but in the meantime it is an issue you may need to face.

To enable voting, you should copy the group of settings from settings_dedicated.cfg into your server_info.cfg. The reason it goes in server_info.cfg is because these settings are considered "policy" and are not something you'd necessarily share with someone who asked. You might still share them, don't get me wrong, but if someone wants to clone your server and you want to help them, you'd normally just send them settings_custom.cfg and let them come up with their own server policies.

Here are the setting items you'll want to address, along with their default values:

Voting Policy Settings

These are the ones that really define how voting is to be accomplished.

Turns on voting.
Allows spectator players to vote. Generally not something you want to enable, hence the default.
Number of virtual voters opposing every change. You can think of this as the Republican Party simulated by the game server, where the game server will always oppose every vote in favor of maintaining the status quo.
Level of secrecy of the votes. 2 makes the vote as secret as possible, -2 makes it fully public. There are those who consider voting to be very personal and private, and would prefer to keep votes secret so nobody can retaliate against voters for voting against them. There are others (me) who find that making the votes public keeps voters honest and prevents people from backstabbing one another.
Voting spam protection. This is new in 0.2.8 and is intended to prevent people from filling the server with polls and annoying everybody.
Number of voters that need to be online to enable voting. So it's a quorum threshold.

Voting Simulation Settings

You won't normally need to adjust these, but if you want to make votes happen quicker or something, you'll change these.

Number of seconds before a vote times out. A vote will time out if nobody votes either way and action will not be taken.
Number of seconds after that the non-voters start to get ignored
One non-voter is ignored everytime this many seconds pass
The spam level of issuing a vote.
The spam level of getting your vote rejected.

IP Banning

Starting with version 0.2.8, banning users by IP address is supported in game.

todo: write this


For older servers, you'll still need to use a firewall.

Installing a firewall is a big job, potentially. There are firewalls that are really rockin' and do all sorts of stuff, and there are firewalls that don't rock. In order to use a firewall to deal with unruly players, you'll need one that supports some sort of IP-based filtering, such as iptables in Linux. In that case, banning a player is a matter of figuring out their IP address and adding it to your firewall.

The most basic way of banning an evil doer is to just drop UDP packets from their IP address that are going to port 4534 (or whatever port your server runs on). For many admins, this is not only a complicated rule to write, but ineffective to deal with the player, so you'll probably find it better to just ban the IP address completely. Be warned, however, that a common way around this is for the evil doer to just turn off their cable modem (or dsl router) and turn it back on. The good news is that it's more inconvenient to them to do that than it is for you to add their new IP address to your firewall.  :) The bad news is that this isn't a foolproof method of banning a user.

To help you, Armagetron Advanced supports some additional logging, listed here.

Decorates every line of console output with the client ID
Decorates every line of console output with the client IP

There is more good news, actually. Many consumer-grade NAT routers come with built-in firewalls or at least make available a firewall option, and will do the job for you--from a web browser! If you have such a beast, you should use it and save your players the hit of the evil-doers packets making another hop down the wire before being cut off.


Internet Speed Test