Armagetron Advanced - User contributions [en]

Configuration Files

2011-02-02T08:37:37Z

Tank Program:

== File Locations ==

=== Linux ===

;datadir
:<code>/etc/games/armagetronad-dedicated</code>
:<code>/etc/games/armagetronad</code>

;userdatadir
:<code>~/.armagetronad-dedicated</code>
:<code>~/.armagetronad</code>

=== Mac OS X ===

;datadir
:The <code>Armagetron Advanced Dedicated/</code> directory
:<code>Armagetron Advanced.app/Contents/Resources</code>

;userdatadir
:<code>~/Library/Application Support/Armagetron Advanced Dedicated</code>
:<code>~/Library/Application Support/Armagetron Advanced</code>

=== Windows ===

;datadir
:<code>C:\program files\armagetronad</code>

;userdatadir
:<code>C:\documents and settings\<username>\<appdata>\Armagetron</code>

== File Purposes ==

Here are the files you will find (Note: this is for the 0.2.8 server, older servers vary):

;aiplayers.cfg
:This file contains the information used to determine the AI player names and skills. You can edit this file to make a more customized set of AI players, but make sure to take backups. When you upgrade or reinstall the server this file will be overwritten.

;default.cfg
:This file contains a reasonable set of defaults and shouldn't be edited.

;master.srv
:This file contains the location of the master server and connection parameters. You can edit it, but then your server won't be able to communicate with the master server that everyone uses, so only do so if you really know what you're doing and have a good reason to do it.

;rc.config
:This file is used to configure the UNIX daemon. It may not be present in Windows/Mac OS X.

;settings.cfg
:This file contains the basic set of settings used by both the client and the server. You should not edit this file.

;settings_dedicated.cfg
:This file contains an extended set of settings used by the dedicated server. You should not edit this file either.

So where should you make your changes? There are 4 files that were not listed, but they are the files you should edit! Why aren't they listed? ''You'' are supposed to make them, using a regular text editor. So, open settings_dedicated.cfg and copy the appropriate lines into the following files:

;autoexec.cfg
:In the old days, up to and including 0.2.7.1, server admins were advised to create this file and put all of their settings here. This file is still used in 0.2.8, but using it is no longer recommended as we move to a more modular configuration system. So, if you're trying to setup a server with 0.2.7.1 or earlier, please use autoexec.cfg. Otherwise, read on for what to use.

;server_info.cfg
:You should put server policy settings here, as well as the SERVER_NAME and connection information.

;settings_custom.cfg
:This is the file that should contain game rule and simulation settings. If you obey the convention for <code>server_info.cfg</code> and <code>settings_custom.cfg</code>, your server will not only be easier to maintain, but also easier to exchange settings with other administrators.

;everytime.cfg
:This file is loaded and processed every round. In a running server, that means you can use this file to change settings on the fly. It also means you can put special information using console commands here. For example:

<code>
SAY Server stats at http://www.armagetronadstats.com/
</code>

...will display "Admin: Server stats at http://www.armagetronadstats.com/" between every round. Very useful! You can also put:

<code>
INCLUDE settings_custom.cfg
</code>

...and your settings_custom.cfg file will be reloaded every round. Not particularly useful, but it can be helpful when you need to tweak simulation settings.

Note: If you're reading this guide because you want to migrate a 0.2.7.x server to 0.2.8, you should just copy your autoexec.cfg file to the new installation. It would be best if you factored out the settings in autoexec.cfg into server_info.cfg and settings_custom.cfg, but it's not required.

User:Tank Program

2009-02-05T16:21:07Z

Tank Program:

Hi.

http://guru3.net/
http://armagetronad.net/
http://launchpad.net/
http://sourceforge.net/

User:Tank Program

2009-02-05T16:20:02Z

Tank Program:

Hi.

http://guru3.net/
http://armagetronad.net/
http://launchpad.net/

User:Tank Program

2009-02-05T16:19:35Z

Tank Program:

Hi.

http://guru3.net/
http://armagetronad.net/

User:Tank Program

2009-02-05T16:08:26Z

Tank Program:

Hi.

http://guru3.net/

User:Tank Program

2009-02-05T16:07:55Z

Tank Program: New page: Hi.

Hi.

Hash Authentication Design

2008-08-29T22:58:20Z

Tank Program: /* Phase 2: Server looks up authority */

{{Sections}} 

= Hash Based Authentication Design =

== Ingredients ==

This document describes the interaction between three entities: the game client with the player who wishes to authenticate, the game server the player is currently playing on, and the authority, in charge of checking the player's identity. We only care about the high level interactions here; the details of the communications are left out (game client and server communicate over the game internal network protocol, game server and authority communicate over HTTP).

We are currently using the hashing algorithm md5 which transforms a data block of arbitrary size into a 16 byte hash value. The operation of md5 is simply denoted with "hash = md5(data)". With "+", we denote concatenation of data blocks to larger data blocks; strings are to be interpreted of data blocks containing the latin1 encoded characters and do not include the C-style trailing 0.

The protocol works in different phases.

== Phase 0: Before all that ==

Already before the client starts the authentication process, it transmits a list of supported authentication methods (hash shemes) to the server. This happens right when the connection is established. Clients not sending the list will be assumed to be old clients supporting the "bmd5" hash scheme only.

As the server logs in to the master servers, it gets told what its public IP address is.

== Phase 1: Client requests authentication ==

The authentication process is usually started by the client (a modified server is allowed to skip this step, if, for example, authentication is to be required to even be on the server). There are two possibilities: The player issues a special chat command: "/login" for logins with a default identity transmitted earlier/a local server account if no default identity has been transmitted, "/login authority" to log in to a selected authority, or "/login user@authority" to log in as a specific user. Alternatively, there is a special login message containing the user name and authority the player wishes to authenticate with. Such a packet is sent by clients that support it via the game menu "Authentication" button.

== Phase 2: Server looks up authority ==

When the server receives the client's authentication request, it contacts the authority and queries the list of supported methods. From that, its own list of supported methods and the list from the client, the server then selects the best method. It queries the authority again and fetches a list of additional parameters for the selected method.

The server then generates a random 16 byte wide salt data block and transmits the salt, the selected method, its parameters and the username back to the client. A menu title message is also transmitted.

The [[Authentication_Server|authority]] has the potential to return additional information to the verification of a user/password pair. "Blurbs" are currently understood by the server in a very basic form, but are essentially unused. There are proposed blurbs to be understood in the next revision of the armaauth protocol, specifically to increase the potential ability of the role of authentication server as a means of logging into Armagetron related websites.

== Phase 3: Client collects password ==

Upon receiving that information, the client starts a password entry menu, where the player can change his username
one last time and enter the password. While that menu is active, keypresses are
scrambled in a potentially running debug recording. Then, depending on the selected method, different scrambling
techniques are used:

=== Method bmd5 ===

The client calculates
prehash = md5(password + "\0")
hash = md5(prehash + salt)
"\0" is a single byte of value 0. Obviously, it's there because of an error in the old implementation, but now we're stuck with it.

=== Method md5 ===

This method has two parameters, a prefix and a suffix. Before they enter the scrambling, the sequence "%u" in them is replaced by the username the client entered. Before the password is scrambled, the salt gets scrambled by
salt2 = md5( md5(salt) + md5(serverIP))
where serverIP is the string representation of the server's IP address and port. Then,
prehash = md5( prefix + password + suffix )
hash = md5(prehash + salt2)
is calculated.

In both methods, the resulting hash value is then sent back to the server, along with the value of serverIP used for scrambling the salt (only on post-0.2.8.2.1-clients) and the possibly modified username.

== Phase 4: Authentication request ==

The server checks whether the serverIP value sent by the client matches the IP it was told by the master servers earlier or retrieved by other means. If it does not match, an error is returned to the user immediately. The server then transmits the following data to the authority:
- the selected method
- the user name
- the salt value for the bmd5 method/the salt2 value for the md5 method, calculated on the server using its known IP
- the hash value returned by the client

The authority then has to check the password for correctness. Usually, it will have the value of prehash pre-calculated in its database, but it can also choose to calculate it on the fly from a plaintext password (plaintext passwords would increase the network security as they would allow periodic changes to prefix and suffix strings, prehashed passwords make loss of the database less of a problem). Either way, the authority just checks whether a) the user exists and b) hash is the correct md5(prehash + salt(2)) value. The result of the comparison is reported to the game server, which then either reports an error to the client and player or accepts the authentication.

= Known Weaknesses =

* With the bdm5 method, badmins runnig a server can steal player logins; as a player logs in on their server, they can instead abuse the system to imposter that player on a different server. the md5 method has some protection against that in the form of the server's IP the client entangles into the hash.
* No strong encryption is used. A badmin that has the power to imposer a server completely with its IP address and port still can steal player logins.
* the md5 hash sum algorithm itself is known to have some flaws; none of the flaws already found inhibit its usefulness for our purposes here, but it's only a question of time.

{{Sections}}

Authentication Server

2008-08-29T22:52:08Z

Tank Program: /* Blurb */

{{Sections}}

= How to run an Authentication Server =

Have a look at [[Hash Authentication Design|the protocol]] to see what is expected of an Authentication Server. Game servers will issue HTTP requests to it with
* user name
* salt
* scrambled password hash
And your job is to figure out whether the password the hash was generated from was correct. That's easiest if you have the users' plainext password stored somewhere; however, that is not common practice. To support the bmd5 hash protocol (the only one available on 0.2.8.2.1 resp. 0.3.0 clients and earlier), you specifically need
the md5 hashsum of the password with an appended 0 byte. For the newer md5 hash protocol, the md5 sum of (prefix + password + suffix), where prefix and suffix choice is up to you, is needed.

If you don't have the password in this form in your database, you'll need to generate it. forums.armagetronad.net uses a trick: whenever a user logs on, the server gets the plaintext password, and then the hash for the bmd5 protocol is stored. phpBB2 already stores the plain md5 hash of the password, so the md5 protocol is natively supported with prefix=suffix="".

To run an authentication server, you need control over a web server with scripting available. If your authority name shall be bla.blubb.net, game servers will query the URI http://bla.blubb.net/armaauth/0.1 with an appended query string; if you make /armaauth/0.1 a directory and put your authentication script there, named index.php or index.py or even index.sh, whatever your server supports, it will be called to process the requests.

If you can't access /armaauth/0.1, you can put it into a subdirectory. If you put it into /~user/armaauth/0.1, then your authority will be named bla.blubb.net/~user.

Users of your authority will be known as username@authority. Don't worry about naming collisions between users of equal name at different authorities, the authority part appears in all logs, and by default, there is no forced link between the screen name and user name of a player.

== Shorthand names ==

If you want a shorthand authority name, talk to Tank Program/Guru3. Shorthand names get expanded to <shorthand>.authentication.armagetronad.net, and we can set up a DNS CNAME entry that maps this name to your server. There are some conditions for that:
* Your authority must be free for everyone to join. Clan authorities that only authorize clan members are out.
* Your authority must make a reasonable effort to give only one username to a single person; email verification is enough.
* It needs to either already have a couple of members or show promise for growth. We don't need Yet Another Dead Forum.

== The script ==

We have two example scripts. One is armagetronad/batch/authentication_reference.php of the current 0.2.8 branch or the trunk. It is written by a php n00b and therefore should be understandable by php n00bs :) You can attach your "business logic", the password retrieval, either in the getPassword() function or the getPasswordHash() function. The comments there should tell you what you need to do.

The other script is more elaborate and can directly plug into user databases; you'll just have to configure it with your database connection and tell it in what row and table of a database username and password hash can be found. it can be checked out with
svn co https://armagetronad.svn.sf.net/svnroot/armagetronad/tools/http-auth-server

== Blurb ==

On successful authentication, you can also pass additional data about the user in the lines following the one containing "PASSWORD_OK". In the future,
there may be standard blurb messages the game server itself understands; currently, however, there is only one effect: A blurb line of the form
<TOKEN> <further data>
where <TOKEN> is a single word and <further data> is arbitrary text will be logged in ladderlog.txt as
AUTHORITY_BLURB_<TOKEN> user@authority <further data>

One standard blurb message would be
ALIAS otheruser@otherauthority
telling ladderlog parsers that choose to believe your authority that the just authenticated user is actually the same person as the user given in the alias.

=== Proposed Blurbs for spec 0.2 ===
* EMAIL_VERIFIED true/false

{{Sections}}

Debug Recording

2008-06-13T07:15:58Z

Tank Program: /* Mac OS X */

== What is it? ==
Armagetron Advanced 0.2.8+ has a feature to record a play session. This session can later be used by developers to find and squash bugs.
== What is it not? ==
A tool to record games and make the recording available for others or yourself to watch later. Feel free to use it as such, but be aware that
the for the debug recordings to actually be a help in finding bugs, it has to have these limitations:

* you can't play the recording back in any other version of Armagetron than you recorded it with
* you can't even reliably play it back with the same version on a different machine
* you can't play the recording back at any framerate your client can manage
* you can't skip backward
* you always have to watch a long recording from the beginning, there is no really fast way to skip to the middle
* the recording contains your configuration and forces it on the one playing it back (apart from some graphics settings)

These restrictions are fundamental and can't be worked around. Other limitations would be technically possible to work around, for example it would be possible to switch the camera to different players or have a fast forward hotkey or to allow "cut" files that automatically play a recording back, skipping the parts that were cut out; in some special cases, it may be possible to get rid of the last limitation. But the first two limitations are so severe that it plainly doesn't make sense to improve the usability of debug recording playback into that direction, and the changes would all make more code aware that a debug recording is running, which is a bad thing for debugging. You don't want code to know it's getting debugged. What you really want is a different kind of recording, which may or may not materialize in the future.

== Creating a Debug Recording ==

=== All Platforms ===

Use your shell to pass some command line arguments to armagetron:

To record: <code>armagetronad --record filename</code><br />
To playback: <code>armagetronad --playback filename [--fast-forward SECONDS]</code>

where <code>filename</code> is the name of the file to be recorded to / played back.

(On windows, you can issue shell commands by entering them in startmenu->run. Remember to give the full path to armagetronad.exe if you do that.)

=== Mac OS X ===
Use the helper application included with the game to start or playback an Armagetron Advanced recording. The application has a feature to compress a recording using bzip2 after Armagetron Advanced quits, so you can upload to the forums easily. It also will decompress a bzip2 or zip file for playback.

http://forums.armagetronad.net/viewtopic.php?p=34800#34800

=== Windows ===

The installer creates links in the start menu to record/playback to/from a file called ArmagetronAdvancedDebugRecording.aarec that is located directly on your desktop. To attach it on the forum, you'll need to either rename it to have an accepted extension (best choice: ArmagetronAdvancedDebugRecording.aarec.not.zip) or, better, really compress it with a zip program like WinZip or WinRar.

As of version 0.2.8.3 and the test versions for that, you can play back a recording simply by doubleclicking on it.

Customizing the game

2007-06-06T09:04:20Z

Tank Program:

Often people ask how to install a moviepack, how you make your cycle color different from your tail's, etc. Read on if you want to know how.

== Moviepacks ==
=== Installing a Moviepack ===

[[Moviepacks]] are packages that completely change the look of the game. the floor, the walls, the cycles, everything. Nowadays, you can download many from different places around the net; for pointers, consult the [[Moviepacks list]]. They usually come in a ZIP file containing a ''moviepack'' folder. This folder goes into your armagetron advanced installation or user configuration directory:

'''''Default armagetron advanced installation folder'''''

'''Windows''': C:\Program Files\Armagetron Advanced\

'''Unix/Linux''': /usr/local/share/games/armagetronad/ or /usr/share/games/armagetronad/

'''Mac OS X''': None. The game is self contained and may be installed anywhere.

'''''Default armagetron advanced configuration folder. Note that you have to enable viewing hidden files to see some directories. '''''

'''Windows 2000/XP''': C:\Documents and Settings\[Username]\Application Data\Armagetron

'''Windows Vista''': C:\Users\[Username]\AppData\Roaming\Armagetron

'''Unix/Linux''': ~/.armagetronad

'''Mac OS X''': ~/Library/Application Support/Armagetron Advanced

''TODO: put folder locations in a single wiki entry and validate''

''The armagetron installation and configuration paths should be somewhere else on the wiki, too''

=== Problems ===

sometimes you get errors after installing a moviepack, such as
[[Image:moviepack_err.gif]]

this means that the moviepack you installed is not complete, i.e. Armagetron Advanced looks for files that are not present in the moviepack. The easiest way around this is to first install the [http://armagetron.sourceforge.net/old/addons.html original moviepack (get the ZIP)] and install the moviepack you actually want ''on top of it''.

In Unix based Operating Systems, where file case is important, sometimes a texture doesn't display even though it appears to be installed correctly. to correct this, manually change the case of the file to suit. In particular, upper case extensions can cause problems. ie, change filename.JPG to filename.jpg and it will probably be OK. You should also inform the author of the moviepack of the problem so he can fix it.

== Installing a new model ==
In your Armagetron Advanced moviepack directory (see above) locate bike.png and cycle.ase and replace with the new ones.

== Customizing default textures ==
=== Installing a different default texture ===

ArmagetronAd allows to change textures of the floor, the walls, the cycles and the sky.
All textures are contained in the "textures" folder. Textures are images displayed during the game.
For exmaple the image on the outer wall can be changed by exchanging the '''rim_wall.png''' file.
Instead of replacing any texture files, you should rename the original file and then copy the new one into the folder.
Now you have a backup available if you want to restore the original.

'''''Where to find those textures ?'''''

'''Windows''': C:\Program Files\Armagetron Advanced\

'''Unix/Linux''': /usr/local/share/games/armagetronad/

'''Mac OS X''': ~/Library/Application Support/Armagetron Advanced/textures

You must create the textures folder.

''''TODO: put folder locations in a single wiki entry and validate''''

'''''Which file is what ?'''''

'''rim_wall.png''' = texture for the outer walls

'''sky.png''' = texture for the lower sky (the upper sky uses the floor*.png)

'''floor.png''' = single textured floor (and upper sky)

'''floor_a.png, floor_b.png''' = dual textured floor

'''bike.png''' = cycle's texture

=== Creating a new texture ===

Creating a texture is as simple as making an image and saving it as described above. For the best results, follow these guidelines:

==== Power-of-two sizes ====

The size of OpenGL's standard 2D textures must be a power of two. If the size of an image isn't, the game (or more accurately, GLU) will scale it to the nearest power of two before sending it to OpenGL, resulting in lower quality. Powers of two include:

* 2^0 = 1
* 2^1 = 2
* 2^2 = 4
* 2^3 = 8
* 2^4 = 16
* 2^5 = 32
* 2^6 = 64
* 2^7 = 128
* 2^8 = 256
* 2^9 = 512
* 2^10 = 1024
* 2^11 = 2048

Note that a texture need not be square; 512x64 textures are fine.

==== Use transparency wisely ====

There are several things to keep in mind when using transparent textures:

* Because of to the way OpenGL prevents background objects from drawing over foreground objects, it might not be possible to see everything through a transparent texture.
* Colors will bleed from neighboring texels (texture pixels) if both color and transparency are different. An exception to this is the cycle texture, which is preprocessed by the game and has no transparency in the end.

==Cycle Colors==

=== The basics of cycle color ===

First you have to understand how computers understand colors. In armagetron, colors are saved with three values: the ''red'', ''green'' and ''blue'' (R, G and B) parts.
Each of these three so-called RGB values can hold a number from 0 to 15 - 0 means none and 15 means as much as
possible. A few examples:

r 15, g 0, b 0 : strong red
r 0, g 15, b 0 : strong green
r 0, g 0, b 15 : strong blue
r 8, g 0, b 0 : darker red

you can also combine the colours (follows the same rules as when you combine red,green and blue light):

r 15 g 0 b 15 : strong pink
r 0 g 15 b 10 : strong cyan
r 15 g 15 b 0 : yellow
r 15 g 8 b 0 : orange (less green => more red than yellow)

you get the gist. So how do you set these colours ? you can set them via the player setup menu, but if you want to have
different cycle and trail colours, you have to use the [[Console]]. The commands are

color_r_1 X # set red component of the 1st player's cycle to X
color_g_1 Y # set green component of the 1st player's cycle to Y
color_b_1 Z # set blue component of the 1st player's cycle to Z

The best way to learn how to write the colour you want is to experiment a bit.

=== Different Cycle and trail colors ===

Remember me saying that the colors were saved as numbers between 0 and 15 ? Well, that was not entirely true. If you set
a color to a value over 15, the trail part is set to 15 and the cycle is (usually) set to the actual value minus 16.
For example:

r 16 g 16 b 0 : yellow tail (r 15 g 15) and black bike (16 - 16 = 0)

higher numbers can give you multi-colored trails. Again, experiment.

For an exact explanation, see [[elaborate color explanation]].

Developer's note: this behavior of the game is technically a bug and is officially unsupported. It is tolerated, though, because it's fun :) But some servers, especially team play servers where your color is no mere decoration, will clamp your color settings to 15 and this trick does not work.

==Chat Colors==

If you want to use different colors when chatting you have to use a different syntax for colors. For example if you want to say a text in red you would enter (at the chat prompt):
0xff0000 this appears in red
note that this is '''all''' zeroes (not o's), so zero-xff-zero-zero-zero-zero. This is important since it won't work otherwise.

The first two digits after the "0x" indicate the red part of the color, the two digits after that the green one and the two last ones the blue part. They signify numbers from 00 to ff (0 to 255) written in hex (base 16); people who ever used color
codes in HTML or CSS will be familiar with this. Only lowercase letters are accepted in the code.

A few different two- letter combos are as follows:

* ff: works like 15 in the bike color
* ee: like 14
* dd: 13
* cc: 12
* bb: 11
* aa: 10
* 99: 9
* 88: 8
* ...
* 00: 0

Note that you can use different hex numbers like in 0xab1234 which lets you chose your color more exactly, but in most cases you won't need this. If you are so paranoid that you think you need exactly ''your'' shade of pink feel free to read the article [[Bases]] on this.

Other combos to get you started are:
0x00ff00 this is green
0x0000ff this is blue
0xff8800 this is orange
0xffffff this is white
0xffff88 this appears in the normal chat yellow (no change)

Developer's note: these color codes were not intended for use by the players; the choice of 0x as intro string was a bit unfortunate. Some servers will filter away your codes, so do your testing in a local game. Since it was not intended for use, no thought was given on usability, and for example upper case codes are not accepted. So use 0xff0000 for red, not 0xFF0000. And don't be angry about future unannounced changes to the format.

[[Category:Client Features]]

File:Test.png

2007-05-25T18:53:09Z

Tank Program: