Armagetron Advanced - User contributions [en]

Camera Glance Keys

2006-10-30T12:26:47Z

Meriton: reflected minor change in control logic and reduced the size of headings

<div style="background:#ccc; border:1px solid black; margin:0.4em; padding:0.2em;">'''Note:''' This page describes the behavior of 0.3.0. Previous releases used a slightly different system.</div>

== Manual Camera Control ==

While the camera tries to show the areas of the grid that are most interesting to you, the camera can not always anticipate your wishes. Manual camera control permits you to adjust the perspective while playing to show the things that really matter.

The keys for manual camera control can be configured in

Main Menu/Player Setup/Player x Settings/Camera Input Configuration

== What Is Glancing? ==

Glancing is the most common form of custom camera control. It causes the camera to face towards a specific direction and is controlled by the four glance keys "glance forward", "glance backward", "glance left" and - you guessed it - "glance right". Unless you changed them in the player options, the glance keys are the arrow keys.

== Why Would I Want to Glance? ==

Glad you asked ;-). Using glancing, you can look in any direction, regardless of where you are driving to. You can glance backwards to check whether someone (friend or foe) is grinding your wall. You can glance right to check whether you or the opponent is ahead. You can watch what happens at a fortress while driving by or watch its interior while circling it.

The only disadvantage about glancing is that you might be so absorbed in the action around you that you forget to watch what might endanger your cycle ...

== How Do I Glance? ==

Glancing is activated by pressing a glance key and maintained by keeping any glance key pressed.

For instance, pressing "glance left" for a while will show you the area left of your cycle until you release the key, upon which the automatic camera control takes over again.

More precisely, when you press a glance key, you "load" that key with a request to face towards a specific direction, and while you keep pressing the key, the request will be acted upon (if you keep more than one glance key pressed, the most recently pressed one is active).

The direction you request is the current view direction, snapped to the closest axis, rotated as specified by the glance key.

Note that glancing is completly independent of the cycle's driving direction. Therefore, there is nothing wrong with glancing over extended periods of time.

== How Can I Configure Glancing? ==

Aside from adjusting the glance keys, glance behavior is controlled by the following options:

;CAMERA_GLANCE_ANGULAR_VELOCITY
:Controls how swiftly the camera rotates towards the requested facing. More precisely, this setting contains the angular velocity (if the camera's facing is perpendicular to the requested facing). Unit: Radians per second.
;CAMERA_GLANCE_MODE
:Controls how the camera rotates towards the requested facing. Possible values are:
:;0
::The camera aproaches the requested facing with constant angular velocity.
:;1
::The camera approaches the requested facing with angular velocity propotional to angle left to travel.
:;2
::The camera approaches the requested facing with constant angular velocity if the angle left is larger than 90°, otherwise with angular velocity proportional to sin(angle).
:;any other setting
::The camera always "jumps" instantly to its new position. Totally useless IMHO.
;CAMERA_GLANCE_ANGULAR_VELOCITY_BONUS
:Factor to CAMERA_GLANCE_ANGULAR_VELOCITY if CAMERA_GLANCE_MODE is set to 2 and the angle deft is larger than 90°

Since the smart camera offers a (in the dev's humble opinion) poor perspective when glancing, its location is configurable independently:

;CAMERA_SMART_GLANCING_BACK
:How far the camera is moved behind the cycle when glancing
;CAMERA_SMART_GLANCING_HEIGHT
:How far the camera is moved up. There is no pitch setting, the cycle always appears in the centre of the screen

Note that CAMERA_SMART_GLANCE_CUSTOM no longer exists. Those who prefer the old behavior are advised to use the preceeding options to simulate it.

== Known Limitations ==

Due to axis snapping, if the current view direction is right between two axis, the glance directions are unspecified. Most automatic modes rarely reach that point on their own, but may do so if glancing has just been recently deactivated. We haven't found an easy way around that (as axis snapping is very useful).

[[Category:Camera]]

Talk:SteveTaylor

2006-10-17T17:09:46Z

Meriton: /* Rematch */

I want to join... hheheh Looking good lack...--[[User:2020|2020]] 11:13, 9 September 2006 (CDT)

Don't know if you guys saw, but Durka placed links for the 4 Team Fortress tourney everywhere. Well, there was one on the team page too, asking if we were interested, which I removed. Just a notice. --[[User:Madmax|Madmax]] 18:09, 29 September 2006 (CDT)

== what we need to do better ==

I just watched my recording from our semi final again. I think the chief reason for us losing were:

- no coordination
- bad grind; they were always faster rsp. we split too late
- no team leader to change strategy on the fly (no one thought of a tactic to permit efficient attack and could cause that to happen)
- relieving a good goalie by a less good one when the _offense_ does not work
- stopping offense (that never works imho. but we could only have stopped taking risks in the offense and tried to split earlier to counter their speed advantage)

=== Lessons ===
* We should practice before the tourney.
* We should assign responsibilities (offense coordinator, defense coordinator) prior to the match and not change them during it. (the executing person can change, of course).
* We should agree on tactical matters such as the function of a sweeper. There are two variants:
*# the sweeper must keep attackers away from the goalie. Only after he is dead can they get through
*# the sweeper should delay attackers until the goalie has set up, let them through in small doses, and squezze them against the goalie's wall to kill them (and be prepared to take half the zone if the goalie is cut)
* in my opinion, 2. is much better, as the attackers have to deal with two of us at once instead of one at a time.

[[User:Meriton|Meriton]] 17:16, 1 October 2006 (CDT)

Your thoughts?

: I'm not sure if you know what their defence looked like. They had SeBoL158 making a box where he overlapped his own tail a lot. Newbie was sweeping (one of the best sweepers). In my opinion there is not much point in me cruising around their zone when there is virtually no chance to conquer it. I felt useless attacking so I suggested that we would try without attackers. About sweepers; the difference between the two variants is very small. It's impossible to stop a good attacker from reaching the defender, so the first variant will become the second one quite fast when the attackers are good. If you felt that you were doing a good job as a goalie (which you were in my opinion) you should have said so and not let Lackadaisical take over. Personally I don't think it's worth the hassle to set up trainings and assign responsibilities for just a couple of games, I just play because it's fun, don't care much about the results in the end. --[[User:MaZuffeR|MaZuffeR]] 18:23, 1 October 2006 (CDT)

:: I know what their defense looked like. I was there once, and watched the replay. Crusing around their zone has a point: It occupies both the goalie and the sweeper. If we don't attack, that very same skilled sweeper will dogfight close to our fortress, putting stress on our defense. But I think the main reason is that some attacking assigns clearer areas of responsibility. We'd be less likely to have redundant defense walls or step on each other's toes. I am not saying the offense did a poor job; I agree their defense was very skilled. But all of us sweeping did not seem to work any better than the attacks we made in the beginning. [[User:Meriton|Meriton]] 19:46, 1 October 2006 (CDT)

::: The few rounds I had time to look, newbie was staying quite close to their zone until a few of us had died even if no one of us was attacking. I would of course have started attacking if I had noticed SeBoL158 being alone or our defence not having any problems with the attackers. I agree that everyone sweeping didn't work any better than me attacking, but we were losing and we had to change our tactic in some way. --[[User:MaZuffeR|MaZuffeR]] 07:56, 2 October 2006 (CDT)

:: I think the difference between the two variants is important. I don't agree that variant 1 usually turns into variant 2. Just as often, the sweeper takes risks and dies. I agree I should not have let lacka take over.

:: You did not say anything about the grind/split. Was my impression of too little speed/too late a break correct? [[User:Meriton|Meriton]] 19:46, 1 October 2006 (CDT)

::: From what I rememeber the grind/split was fine, not great, but fine. In my opinion we did not lose the match because of bad grinding or splitting too late. I can't remember them ever reaching our zone before you had set up, which should be enough to win matches. --[[User:MaZuffeR|MaZuffeR]] 07:56, 2 October 2006 (CDT)

: Actually I did ask for change of tactic but it's hard to give commands when you are playing the game at the same time. I think if one of the wings double grinded (the one without the def on their side) and the other split soon, we could've overtook them on one side and attack their base fast, hopefully before sebol has set up his def. Holers did a good job their first match against pronoobz because they could disrupt sebols def by either overtaking the wings or do a center attack. Another thing we could've done was torpedo sebol, but we would still need to make sure newbie was dead and a torpedo is risky when you only have five people on a team since you need three people to make sure it works. The reason i wanted to take def was because i saw people get into the def because you had a gap, but it's true i did a worse job. Personally I'd rather had someone mimicing sebols def on our side.
: We could've done with more preparation before the match, and i already had the idea but i was too late (just a few minutes before the first match would start) to set things up properly. About practice, how about i try and arrange a 'revenge' match with pronoobz? Who would be up for that? --[[User:Lackadaisical|Lackadaisical]] 19:01, 1 October 2006 (CDT)

:: My defense speciality is sumo defense, so that's what I tried to do. That defense works just as well (actually I think it's better) if executed right, but requires a different separation of roles than endless spinning à la sebol. Alas, we had never before talked about that, otherwise, the defense would have worked a lot better. I acknowledge that my defense was not perfect, and in the 5 rounds before you took over, I lost 2 rounds to cut attacks. I lost 1 rounds in a tight fight against two opponents and 1 due to the misunderstanding where Lack killed me and himself. The round we won was when only 3 opponents and I were left and I killed all 3. But the analysis shows that the offense had a problem, not the defense. (In most rounds, I failed after you all died). So wanting defense was premature IMHO, and me granting it was out of a wrong sense of politeness. Anyway, I think we have learned from this what we can.

:: A revenge match sounds interesting. [[User:Meriton|Meriton]] 19:46, 1 October 2006 (CDT)

:: I try to take part in a revenge match if you can arrange one at a suitable time (I'm away next weekend). Hopefully I'll have a better day than yesterday when/if this happens. --[[User:MaZuffeR|MaZuffeR]] 07:56, 2 October 2006 (CDT)

::: I'm up for that match. Best time for me is around 9/10PM GMT on pretty much any day (as long as it's settled with time). --[[User:Madmax|Madmax]] 06:27, 3 October 2006 (CDT)

::::I PM'd newbie and we agreed on '''17 october 8pm GMT''', I hope that's not too early for you max, newbie thought 9pm might be a bit too late for some of his people. I informed Blackbird about it who didn't know if (s)he was available yet. --[[User:Lackadaisical|Lackadaisical]] 17:59, 8 October 2006 (CDT)

===Rematch===
Ok, I hope everyone has seen my previous message, because the match is tonight. I'm gonna try to be on irc at least an hour before the match starts, and then switch around to see if i can catch newbie on the grid to see where we are gonna play. I'm guessing this will be at LOD since ady has admin there so we can keep other people out. Hope to see you all on irc too so we can talk about the strategies etc. (#armagetron at freenode) --[[User:Lackadaisical|Lackadaisical]] 05:08, 17 October 2006 (CDT)

Ok, cu there [[User:Meriton|Meriton]] 12:09, 17 October 2006 (CDT)

Ladle Feedback

2006-10-02T17:08:42Z

Meriton: /* Feedback for the Fourth Ladle */

{{Ladle-4}}

Please write your comments below about your experience of the event. You can also add comments about how it could be better... This information may be useful for anyone who tries to do such a thing again... We have to discuss stuff so that decisions made...

== Feedback for the Fourth Ladle ==

;[[User:2020|2020]] 02.31, 29 September 2006 (CDT)
:Haven't started, one day to go, and the preparation, redesigning of wiki, simplifying procedure, hasn't increased the numbers of participants. My impression is, a lot of good players just want to turn up on the night and play. They don't want to plan, organise or anything. Kind of like anarchists, which is why maybe Anarchic Wanderers seemed to work. As for lack of clan presence, I think there are only two clans this time, that may be because I didn't advertise, but that is a bit of a lame excuse. So... although I hope we have a few good games tomorrow, I don't think it is going to run very smoothly. This is through no no fault of the system, nor even the players because that is just what they do. The idea of designing a system which is flexible enough to deal with no preparation on the part of the players... hmmm...
:I think all that is required is that you have just one person on the team organised enough to stick down names etc. On the night, it just depends who turns up. But if they don't use IRC, this could be very tricky indeed. Still, with the brackets set, it might just work...
:Finally, it doesn't take a month to organise this. It should if there are a lot of players and a lot of activity in the challenge board, teams meeting up and practicing and so on. But Tronic Monkeys haven't had one game together, and I haven't got contact details for most of them... Most of the other teams seem more solid though. But a month? Not needed.

;[[User:2020|2020]] 17.01, 1 October 2006 (CDT)
:Got kicked out of AST for some reason while recording the first match of the finals... pity we won't have a recording of the game... Tronic Monkeys were a bunch of monkeys, badly organised and not enough skill, so we lost in the quarters against WPN, the better team without a doubt. I saw and recorded most of Steve Taylor v proNoobz in the semi and that was some game. Impressive. Everything seemed to go proNoobz way on the breaks...
:Rounds are too short, at least not for the actual match, between the two quarters, one started on time, and the other about half an hour late. Mad and manta mentioned timing, and said it wasn't clear enough.
:Some players were very critical. Some get stressed. That's because some players are just not getting together on time, or people are trying to organise while playing... which is difficult to concentrate.
:On the whole, I think it demonstrates that people can self-organise. I mean, 6 teams playing matches in under three hours. That's not bad.

; [[User:Meriton|Meriton]] 17.27, 1 October 2006 (CDT)
:IRC worked well to agree on servers IMHO. All in all, it was well organised (and definitely worked better than last time). The few areas for improvement:
: I think we need a rule to deal with incomplete teams: At the official start time of the match, WS had 3 players. We waited 20 minutes to start (they had 4 by that time). Even then, some actually suggested to wait an hour (!) for spidey to emerge. The actual match took less time than waiting for it ...
: The issue about many ordinary players joining a server while a match is in progress remains unresolved. It was particularly bad as WildWest in our first match. My instant chat that asked them to leave was used every couple of minutes. Less, though still annoying are spectators how persist in chatting while a match is going on. Even worse was the question about the current standing that was asked every few minutes. Please, if you want instant news, delegate one person to watch the game who announces intermediate results in IRC.
: I'd like to play best of 5 to increase the proportion of playing with respect to waiting time.

;[[User:Durka|Durka]] 17.30, 1 October 2006 (CDT)
:Well, [[We Pwn Noobs|WPN]] killed the [[Tronic Monkeys]] in the first round. Then, the second round started almost immediately. We should have gotten like a 15 minute break...my brain was fried. The second round we played against the [[Holers]]. They completely slaughtered us. They took every hole possible. [[User:Sasha|Sasha]] went thru our middle it seemed like every time. We never really got a rythm going. One of our clanmates (not to be named right now) got kicked out of the clan due to his behavior during the Ladle. All in all, it was much better organized than the previous Ladles. Great job 2020 once again!

'''Alex ~~'''
:2020 - i asked you to leave while we were sorting out our teams but you didnt. i never kicked you though.
:if you want my full response, read the General forum.
::That's cool...I was there to record, that was all, and the reason i didn't answer was a) your teammates were asking for me to stay and b) if i responded i would have spoiled the recording... As it happened, an autoban occured for one reason or another, and I couldn't complete the recording of the first match or the second... sorry. it's a learning experience for us all --[[User:2020|2020]] 03:37, 2 October 2006 (CDT)
:::Just hit an instant chat key between every two rounds. You should be safe then, as nothing interesting is happening anyways.—[[User:Wrtlprnft|Wrtlprnft]] 09:04, 2 October 2006 (CDT)

; [[User:Lackadaisical|Lackadaisical]] 1 October 2006 (CDT)
: I think it needs to be regulated what happens when one team has less players than the other. When SteveTaylor played against pronoobz we had one person on the sideline because they had one less so we could play 5v5, but when pronoobz played against Holers, holers insisted on playing with 7 people, which seems to have been a problem because well.. they only had five. In the end psyko and me subbed for pronoobz (which in hindsight i shouldn't have done because i was already on another team, but pressure was high and people seemed to get really stressed out because there wasn't any play.)
: And there was a consensus about the minimum members a team needs to show up with, which was five. I think the lack of someone who is harsh enough to dissapoint four people by disqualifying them hurts the way this 'rule' is handled.

; [[User:eggcozy|eggcozy]] 1 October 2006 (CDT)
: I strongly suggest we instate a rule allowing teams to play with any number of players up to the max number. No rules about team imbalance, no rules about teams having too few players. If we put the max at 8, there should be nothing to keep a team from fielding 8, even if the other team shows up with 6. In a soccer match, you don't lower the number of players down from 11 if the other team shows up with 9. It is the problem of the team if they can not get their players to show. I am sick of teams whining about the number of players who are on the other team whether it be too few or too many. My team should be able to play, even if we only have 3 or 4 players. Each team should have the freedom to play with however many players they want to play with, as long as it is not more than max. I sat out of our first match this tourney. There was talk of letting me in ... 2020 offered, then Garisimo, probably our best player left. This is just silly. It should not happen.

:: The problem is that most competition servers have enforced team balancing enabled, and usually there is no admin at hand who could disable that on time. [[User:Meriton|Meriton]] 12:08, 2 October 2006 (CDT)

; Luzifer 2 October 2006 (CDT)
: All in all, I liked the Ladle (it was my first one). But I agree with egg about a rule about what happens if one team shows up with less or more players than the other one. The suggestion from egg sounds good to me. About the communication: I think the main-problme was that most players didn't read the wiki and/or were on IRC. I read the wiki and when the Ladle started, I knew where I had to play and against which team. Except of one player (who didn't show up), our team was well informed.

== Previous Feedback ==

*[[Ladle-1/Feedback]]
*[[Ladle-2/Feedback]]
*[[Ladle-3/Feedback]]

Debug Recording

2006-10-02T15:27:51Z

Meriton:

== 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.

== 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.

=== Windows ===

The beta release installer creates links in the start menu to record/playback to/from a file called recording.aarec that is located in the program directory.

Debug Recording

2006-10-02T15:27:04Z

Meriton: command line arguments apply to all platforms / mention start menu links in windows

== 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.

== 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 filename 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.

=== Windows ===

The beta release installer creates links in the start menu to record/playback to/from a file called recording.aarec that is located in the program directory.

Talk:SteveTaylor

2006-10-02T00:46:10Z

Meriton: /* what we need to do better */

I want to join... hheheh Looking good lack...--[[User:2020|2020]] 11:13, 9 September 2006 (CDT)

Don't know if you guys saw, but Durka placed links for the 4 Team Fortress tourney everywhere. Well, there was one on the team page too, asking if we were interested, which I removed. Just a notice. --[[User:Madmax|Madmax]] 18:09, 29 September 2006 (CDT)

== what we need to do better ==

I just watched my recording from our semi final again. I think the chief reason for us losing were:

- no coordination
- bad grind; they were always faster rsp. we split too late
- no team leader to change strategy on the fly (no one thought of a tactic to permit efficient attack and could cause that to happen)
- relieving a good goalie by a less good one when the _offense_ does not work
- stopping offense (that never works imho. but we could only have stopped taking risks in the offense and tried to split earlier to counter their speed advantage)

=== Lessons ===
* We should practice before the tourney.
* We should assign responsibilities (offense coordinator, defense coordinator) prior to the match and not change them during it. (the executing person can change, of course).
* We should agree on tactical matters such as the function of a sweeper. There are two variants:
*# the sweeper must keep attackers away from the goalie. Only after he is dead can they get through
*# the sweeper should delay attackers until the goalie has set up, let them through in small doses, and squezze them against the goalie's wall to kill them (and be prepared to take half the zone if the goalie is cut)
* in my opinion, 2. is much better, as the attackers have to deal with two of us at once instead of one at a time.

[[User:Meriton|Meriton]] 17:16, 1 October 2006 (CDT)

Your thoughts?

: I'm not sure if you know what their defence looked like. They had SeBoL158 making a box where he overlapped his own tail a lot. Newbie was sweeping (one of the best sweepers). In my opinion there is not much point in me cruising around their zone when there is virtually no chance to conquer it. I felt useless attacking so I suggested that we would try without attackers. About sweepers; the difference between the two variants is very small. It's impossible to stop a good attacker from reaching the defender, so the first variant will become the second one quite fast when the attackers are good. If you felt that you were doing a good job as a goalie (which you were in my opinion) you should have said so and not let Lackadaisical take over. Personally I don't think it's worth the hassle to set up trainings and assign responsibilities for just a couple of games, I just play because it's fun, don't care much about the results in the end. --[[User:MaZuffeR|MaZuffeR]] 18:23, 1 October 2006 (CDT)

:: I know what their defense looked like. I was there once, and watched the replay. Crusing around their zone has a point: It occupies both the goalie and the sweeper. If we don't attack, that very same skilled sweeper will dogfight close to our fortress, putting stress on our defense. But I think the main reason is that some attacking assigns clearer areas of responsibility. We'd be less likely to have redundant defense walls or step on each other's toes. I am not saying the offense did a poor job; I agree their defense was very skilled. But all of us sweeping did not seem to work any better than the attacks we made in the beginning.

:: I think the difference between the two variants is important. I don't agree that variant 1 usually turns into variant 2. Just as often, the sweeper takes risks and dies. I agree I should not have let lacka take over.

:: You did not say anything about the grind/split. Was my impression of too little speed/too late a break correct? [[User:Meriton|Meriton]] 19:46, 1 October 2006 (CDT)

: Actually I did ask for change of tactic but it's hard to give commands when you are playing the game at the same time. I think if one of the wings double grinded (the one without the def on their side) and the other split soon, we could've overtook them on one side and attack their base fast, hopefully before sebol has set up his def. Holers did a good job their first match against pronoobz because they could disrupt sebols def by either overtaking the wings or do a center attack. Another thing we could've done was torpedo sebol, but we would still need to make sure newbie was dead and a torpedo is risky when you only have five people on a team since you need three people to make sure it works. The reason i wanted to take def was because i saw people get into the def because you had a gap, but it's true i did a worse job. Personally I'd rather had someone mimicing sebols def on our side.
: We could've done with more preparation before the match, and i already had the idea but i was too late (just a few minutes before the first match would start) to set things up properly. About practice, how about i try and arrange a 'revenge' match with pronoobz? Who would be up for that? --[[User:Lackadaisical|Lackadaisical]] 19:01, 1 October 2006 (CDT)

:: My defense speciality is sumo defense, so that's what I tried to do. That defense works just as well (actually I think it's better) if executed right, but requires a different separation of roles than endless spinning à la sebol. Alas, we had never before talked about that, otherwise, the defense would have worked a lot better. I acknowledge that my defense was not perfect, and in the 5 rounds before you took over, I lost 2 rounds to cut attacks. I lost 1 rounds in a tight fight against two opponents and 1 due to the misunderstanding where Lack killed me and himself. The round we won was when only 3 opponents and I were left and I killed all 3. But the analysis shows that the offense had a problem, not the defense. (In most rounds, I failed after you all died). So wanting defense was premature IMHO, and me granting it was out of a wrong sense of politeness. Anyway, I think we have learned from this what we can.

:: A revenge match sounds interesting. [[User:Meriton|Meriton]] 19:46, 1 October 2006 (CDT)

Ladle Feedback

2006-10-01T22:28:18Z

Meriton:

Ladle Feedback

2006-10-01T22:27:50Z

Meriton: /* Feedback for the Fourth Ladle */

Talk:SteveTaylor

2006-10-01T22:16:12Z

Meriton: /* what we need to do better */

Talk:SteveTaylor

2006-10-01T22:15:39Z

Meriton: what we need to do better

SteveTaylor

2006-09-24T19:57:41Z

Meriton: added myself

[[Image:Teamstevetaylor.gif|center|]]

Hello! We are Steve Taylor and we would like to welcome you to our page dedicated to Steve Taylor. We are one of the offspring-teams of the [[Anarchic wanderers]], and are planning to combine new and experienced players to fight in the [[Ladle-4]]. The head of Steve Taylor, or captain if you may, is [[User:Lackadaisical|Lackadaisical]] (you might have heard of him from legends and tales as 'The AW vs SS match' and 'Winning The Spoon without actually playing the finals'). Currently we are still looking for people to join, so if you are interested to play in one the most notoire tournaments in Armagetron History, there is a chance you will find what you are looking for here at Steve Taylor!

==News==
===Steve Taylor has been born===
Yes, you are seeing it right! The Anarchic wanderers has produced yet another spawn, and it will be playing in and training for the Ladle-4.

--[[User:Lackadaisical|Lackadaisical]] 11:07, 7 September 2006 (CDT)

==Who are part of Steve Taylor?==
*Lackadaisical
*Blackbird
*JC
*madmax
*meriton

==Applying==
If you want to apply, you just need to put your name down on either the list here or on the [[Ladle-4/Team_List|Ladle Team List]], or both. I'll try to make sure that the lists stay synchronized. Oh, one more thing, if you tend to not watch the wiki every single day like some of us do, just send [[User:Lackadaisical|Lack]] an email and he'll try to keep you updated through that.

==Contact==
We could use the [[Talk:SteveTaylor|Talk Page]] for discussion/comments about stuff. If you have any general questions which might be usefull for others I suggest putting them on the FAQ and hopefully someone else (perhaps the head of Steve Taylor himself!) can answer them.

==FAQ==
;Who's this Steve Taylor dude?
:We are Steve Taylor.

;Are you related to Charles Taylor(president of Liberia from 1997 to 2003)?
:No.

;Are you my first grade teacher's husband?
:No.

Ladle-4/Team List

2006-09-24T19:56:48Z

Meriton: added myself

{{Ladle-4}}

The Fourth Tronic Ladle will be played on Sunday 1st October with the finals at 9pm GMT (US: 5pm EDT, 3pm MDT, 4pm CDT, UK: 10pm BST, DE: 23:00 CEST).

Form a team or add your name to one. The following list is provisional: actual players on the day may be different. It is merely a record of intention. Please indicate a Team-Captain. This is a very important role and requires reasonable responsibility -- choose carefully.

== [[Tronic Monkeys]] (5 Players) ==

*[[User:2020|2020]] (please check teampage...)
* rain
* n00b
* THE COOOL CAT -- HYYYYYYPHY LEOPARD
* Captain gArIsImO (uhahahahahah)

== [[We Pwn Noobs|WPN]] (4 Players) ==
* [[User:Durka|Durka]]
* [[User:Legit|Legit]]
* [[User:Chuck|Chuck]] aka Betu
* G5
(more will sign up)

== Abominable Snowmen (3 Players) ==
* [[User:Wrtlprnft|Wrtlprnft]] (captain for now, until someone else takes it)
* help im a bug
* ghableska

== proN00bz ];) (5 Players) ==
* newbÎe (captain)
* ~*SP*~Slash
* Luzifer
* ~*LoD*~SlaYer
* ct|SeBoL158

==[[SteveTaylor|Steve Taylor]] (4+1 Players)==
* [[User:Lackadaisical|Lackadaisical]] (capitán, open for sign ups, check our page)
* Blackbird
* JC (spare wheel, not really good player)
* madmax
* meriton

==[[Holers]] (7 Players)==
* [[User:Sasha|Sasha]]
* Infamous (Ok you can be captain alex)
* '''~}{Alex}{~''' [Captain YAAYYYYYYYY :D]
* $ubzero [yes alex u will :D ]
* fr34ky! (if you want ;)/got asked by a guy in this team)
* HoAX
* cyclotron //should be captain tho ;}

== [[Wraith Squadron]] (4 Players) ==
*kamakazi
*Manta
*Goodygumdrops
*AshitakA
New sign-ups welcome, please try to attend practice sessions.

== Tronners in Pyjamas .[[TiP]] (2 Players) ==
* H.A.K (captain)
* Thunder

It has been suggested that one of the ways we can make the event more exciting is by experienced players starting up new teams. For example, [[anarchic wanderers]] players will each or in pairs, start up a new team. They will be responsible for recruiting new players, training them up, and presenting them at the next Tronic Ladle. Could be fun.

{{Ladle-4}}

Talk:Playing Maps

2006-09-17T11:02:07Z

Meriton:

The "place your map part" does not apply if the user wants to play an already existing map, which I reckon will be the default case (this page is also linked from the player documentation). I suggest to remove it from this page and direct those pages needing it to [[Testing Resources]] instead.

Location of config items is also scattered across the wiki. Factor this out to a dedicated page?

[[User:Meriton|Meriton]] 06:02, 17 September 2006 (CDT)

Testing Resources

2006-09-16T22:57:16Z

Meriton: /* Tell Armagetron to use it */

So you have written a new resource and would like to test it? Then you have come to the right place :)

=== Save it ===

==== Resource directory ====
Resources that should be available to a ''specific'' user are stored in

* Linux - <home>/.armagetronad/resource
** ''Example'': /home/Joe/.armagetronad/resource
* Windows - <appdata>\Armagetron\resource
** ''Example'': C:\Documents and Settings\Joe\Application Data\Armagetron\resource
* Mac OS X - <home>/Library/Application Support/Armagetron Advanced/resource
** ''Example'': /Users/Joe/Library/Application Support/Armagetron Advanced/resource

Resources that should be available to ''all'' users of a computer are stored in

* Linux - /usr/share/games/armagetronad/resource
* Windows - C:\Program Files\Armagetron Advanced\resource
* Mac OS X - Armagetron Advanced.app/Contents/Resources/resource

respectively

* Linux — ~/.armagetronad/resource
* Windows — C:\Program Files\Armagetron Advanced\resource
* Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource

==== Filename ====

Inside the resource directory, resources are located at

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

where type, name, version, author and category must match those stated in the resource:

<Resource '''type'''="..." '''name'''="..." '''version'''="..." '''author'''="..." '''category'''="...">

In windows, the subdirectories must be seperated by '\', not '/'.

=== Tell Armagetron to use it ===

by setting the configuration item

* MAP_FILE (for maps)
* COCKPIT_FILE (for [[Cockpit Tutorial|cockpits]])

to

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

(note that you have to use '/' regardless of whether you use windows)

Configuration items can be set using the [[console]] or by editing a configuration file. The configuration file shared by all users on the computer is located at

* Linux - /usr/etc/games/armagetronad/settings.cfg
* Windows - C:\Program Files\Armagetron Advanced\config\settings.cfg
* Mac OS X - Armagetron Advanced.app/Contents/Resources/settings.cfg

or is it (FIXME)

*Linux — ~/.armagetronad/config/settings_custom.cfg
*Windows — C:\Program Files\Armagetron Advanced\config\settings_custom.cfg
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/config/settings_custom.cfg

Settings in this file may be overridden for a specific user in the file

* Linux - <home>/.armagetronad/var/autoexec.cfg
* Windows - <appdata>\Armagetron\var\autoexec.cfg
* Mac OS X - <home>/Library/Application Support/Armagetron Advanced/autoexec.cfg

You may have to create the override file since it is not created automatically.

=== Run Armagetron ===

Now its time to play Armagetron Advanced locally.

If you have saved it wrong or the path you put is incorrect it will tell you.

If your settings or code is wrong it will also tell you a line number.

Cockpit Tutorial

2006-09-16T22:51:43Z

Meriton: links for what to do after the file is written

This document describes canonically how to create a cockpit resource file. Hopefully it'll be easy to read, too.

'''This is only implemented in the 0.3 development snapshots, not in actual releases. For already existing projects see [[Cockpits list]].'''

== A Cockpit—The Concept ==

The cockpit is where you're sitting when you play the game. There is the concept of a virtual cockpit which is implemented in the internal camera view, but we'll ignore that, for the most part. Otherwise, the cockpit is where you're sitting and what you're using.

A cockpit resource file provides the layout of some of the visual items you see while you're playing. Traditionally, these were referred to as the HUD, and the HUD is still the main information that's carried in a cockpit file.

In the resource file, gauges and other things have been abstracted to a Widget. Each Widget is capable of displaying all of the information you're used to seeing, and is likely capable of displaying the same information in different formats...thanks to the cockpit resource file.

== Overview of the Cockpit file ==

The cockpit file consists of two sections. Technically they're just one, but you don't really have to worry about that. The two sections are pretty simple. The first just hooks it into the resource system for the whole game, using tags and stuff you may already know from the map files. The second section contains all the beautful cockpit stuff.

In the Cockpit section you'll find a series of widget tags that contain data tags to hook the widget into some game data. There's a caption, some position and size parameters, and so forth. You can also specify background and foreground colors, with gradiants, and with graphics, to provide a really custom gauge. Additionally, widgets can be associated with a camera, or made for all cameras, with the option of excluding specific cameras, offering the possibility to give a completely custom view for each camera you use. All of this gets mixed together and rendered to screen as your cockpit.

A complete gauge, in concept, isn't necessary a single widget in the cockpit file. As an example, you might want to build a "Performance" gauge that includes ping, frames per second, cpu usage, overall system load, and bandwidth usage. That would require placing several widgets together, stacked on top of each other or on each other's sides, to build the conceptual Performance gauge you intend. Here, we'll use "gauge" to refer to a specific gauge and "widget" to refer to the larger conceptual gauge. Most widgets that you'll build will just be gauges, so it's not a big deal. (Note: At the time of writing, all of the data in the hypothetical Performance gauge isn't available to the cockpit, but the system is easily extensible and there's no reason to think it will never be available)

Within each gauge there are a series of tags that are used to define what it looks like, what data it uses, and so forth. The tags that are available vary from gauge to gauge, but the meaning of each tag never varies. Two gauges that are diametrically opposite to each other might interpret the tag differently, but it will still mean the same thing for both gauges. That's an important subtlety that you should keep in mind.

== Construction of a Gauge ==

Each gauge is a layered affair. In technical terms, first the back of the gauge is painted. Then the middle is painted on top of the back, and finally the front is painted on top of the middle. This is intended to allow for complete configurability for each gauge. The middle layer is always the representation of the data, whatever it is. The back and front are equivalent in size and shape and are intended for window-dressing. By painting a texture with alpha-blended pixels it should be possible to reshape parts of the gauge and give it a unique appearance. Two gauges can be identical in all ways except which texture is used for the front and have very different appearances to the user.

Gauges that are text-driven are generally constructed on a table. While you don't have to use a table to build the gauge, the table allows you to organize it in rows and columns, which is the most useful way to organize data that you expect to read only in glances.

Each gauge has to specify which piece of data it displays, along with related pieces of data, and how to display them. This can vary dramatically! As an example, on the old HUD, in the rubber gauge, you saw a needle with some text to show the amount of rubber currently used. Then you had a minimum, which was 0, and a maximum, which varied from server to server. In the new rubber gauge you'll choose an appropriate widget and tell it where to get its minimum, its maximum, and its current data. Technically this is implemented with callbacks so that any data can be made available to be used by a gauge, even if it doesn't make sense to do so, and the callback name to use is what you'll give it in the cockpit file. If that doesn't make sense to you, don't worry about it. Just make sure to provide what's needed to show your gauge and be happy.

Every gauge supports an attribute called "camera". The camera attribute allows you to specify for which camera the gauge will appear. This in turn allows your cockpit to look/feel/be completely different depending on the user's camera. The primary purpose is to allow the internal camera to actually appear like you're inside the light cycle while providing minimal HUDs for the other cameras, and it's this purpose from which the name "cockpit" is derived. But you shouldn't let that block your creativity when you're creating your own nice cockpit. Possible cameras are:

* <code>custom</code>—Custom camera
* <code>follow</code>—Following camera (the one that follows the cycle, but doesn't turn by itself)
* <code>free</code>—Free camera
* <code>in</code>—Incam and the autoincam of the smartacm if enabled
* <code>server_custom</code>—Server–defined custom camera
* <code>smart</code>—Smartcam, default camera
* <code>mer</code>—The new mercam
* <code>all</code> or <code>*</code>—All cameras at once (default if you omit the attribute)

The camera attribute can contain multiple cameras separated by spaces, if it starts with a <code>^</code> the widget will appear in all cameras but the ones specified. Examples:

* <code>camera="in"</code>—Only show in incam mode
* <code>camera="^in free"</code>—Don't show in in– or freecam mode, but in everything else
* <code>camera="^all"</code>—Never show, kinda pointless.

Finally all gauges support the <code>viewport</code> attribute. Possible values are "top" and "all", the latter being the default. "top" means that the widget will be rendered on top of the screen, "all" means it will be rendered for every player in multiplayer mode. Some data sources are only available in "all" mode, but you might not want a separate map for each player, so choose "top" then.

== General Gauge Information ==

Every gauge supports an interpretation of some tags that are needed for every gauge. We'll discuss those here.

=== Data Source ===

The DataSet tag is a container that contains AtomicData tags. It defines all of the data that will be used to construct the gauge and may contain from 1 to 3 AtomicData tags within it. Here's an example:

<DataSet>
<AtomicData field="source" source="player_speed" />
<AtomicData field="minimum" source="0" />
<AtomicData field="maximum" source="max_speed" />
</DataSet>

As you can see, each AtomicData tag contains two attributes, field and source. Field may be any of source, minimum, or maximum. Source determines where the data will be retrieved. If the contents of source match up with a known location of data, then that location will be called. If not, then the contents of source will be the data. This is easier to understand by just reading the snippet given, where "player_speed" will put the player's cycle's current speed in the field "source", but it will just put "0" in the field "minimum". This snippet is a speed gauge, and you can easily visualize a needle with 0 on the left, "max_speed" on the right, and the player's current speed marked by the needle itself as on the old HUD.

A DataSet can have an id associated with it that you can use to refer to it later for presentation. This is most important in a Label. Indeed, it's required in a Label but it doesn't really make sense in a NeedleGauge, does it?

==== Possible contents for data sources ====

===== Numbers =====

Those can be whole numbers or fractions. Examples: <code>source="42"</code>, <code>source="1.5"</code>

===== Strings =====

Any text, example: <code>source="Hello World!"</code>

===== Configuration Items =====

Any config items as you would type them on the console to get their value: <code>source="CYCLE_RUBBER"</code>

===== Special Values =====

These values are replaced by actual data from the game. Here's a complete list of possibilities:


{| border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#F9F9F9; font-size:95%; empty-cells:show;"
! souce="…"
! Content
|-
| player_rubber || The rubber that's used for the player currently being watched. Ranges from 0 to CYCLE_RUBBER.
|-
| current_ping || The ping time in milliseconds for the client.
|-
| player_speed || The speed of the cycle currently being watched.
|-
| max_speed || The theorethical maximum of the speed a cycle can reach according to the current settings.
|-
| player_brakes || The amount of brakes left. Ranges from 0 to 1.
|-
| enemies_alive || The number of enemies alive, from the view of the player the viewport belongs to.
|-
| friends_alive || The number of teammates alive, from the view of the player the viewport belongs to.
|-
| current_framerate || The current framerate in frames per second.
|-
| current_acceleration || The current cycle acceleration in m/s^2. Note, this is instantaneous acceleration, not average acceleration.
|-
| time_since_start || The time the game is running in seconds.
|-
| current_minutes || The time of the day in minutes.
|-
| current_hours || The time of the day in hours.
|-
| current_hours12h || The time of the day in hours (12- hour format).
|-
| current_seconds || The time of the day in seconds.
|-
| current_score || The score of the player the viewport belongs to.
|-
| top_score || The highest score.
|-
| fastest_speed || The speed of the fastest cycle.
|-
| fastest_name || The name of the player that's fastest right now.
|-
| fastest_speed_round || The speed of the fastest cycle during the whole round. This doesn't have to be the fastest cycle on the grid, it is just the hightest “peak”.
|-
| fastest_name_round || The name of the player that reached the hightest speed during the round.
|-
| time_to_impact_front || The approximate time it will take the cycle to reach a wall in front of it. This source is stupid, it has no prediction, so if it returns 3 seconds and someone drives in front of you in that time it will jump
|-
| time_to_impact_right || Same as time_to_impact_front, but on the right side (if you were to turn in that direction without loss of speed)
|-
| time_to_impact_left || Same as time_to_impact_front, but on the left side (if you were to turn in that direction without loss of speed)
|-
| current_song || The filepath to the song that's currently played. Should be altered to display the title instead.
|-
| current_name || The name of the player that's currently being watched
|-
| current_colored_name || The name of the player that's currently being watched, in the correct color
|-
| current_pos_x || The position of the player in grid units, x- coordinate
|-
| current_pos_y || The position of the player in grid units, y- coordinate
|}

=== Position and Size ===

Position and size are given by two tags, aptly "Position" and "Size". The point given by position represents the center of the gauge. Don't forget this! It's common for the position point of a widget to be the top left corner, but that is not the case. Here, it's the center of the gauge. An example says everything that needs to be said:

<Position x="-0.165" y="-0.9" />
<Size height="0.15" width="0.15" />

Positions and sizes are not in pixels, but in units of a special coordinate plane. The point at the bottom left is always (-1, -1) and the point at the bottom right is always (1, -1). So the x- coordinate always goes from -1 (left) to 1 (right).

The y- coordinate is chosen in a way so x and y have the same scale. (-1, 1) would refer to the point that is (width of your screen) up from the bottom edge. Of course, for most screens this means this point is off the screen.

This is an illustration of the coordinate system:

[[Image:Cockpit Coordinate System.png|illustration of the coordinate system]]

=== Field Flags ===

Besides determining where the data should come from for a given field it is also necessary to tell the gauge whether or not to show that field. It's important to understand the distinction between using the data to draw the gauge and displaying the data on the gauge. The canonical example is the brake gauge displayed as a bar. In this example, minimum is always 0 and maximum is always 1, and current is always something in between. In order to compute the size of the gauge for the purpose of drawing the bar, you must have AtomicData for all three fields as discussed above. But you may not want to present that data. Maybe you just want to see the bar and nothing else. In that case, you need to deal with the field flags. How to actually use them is best seen in an example:

<ShowCurrent value="true" />
<ShowMaximum value="true" />
<ShowMinimum value="true" />

=== Reverse ===

Sometimes it's better to show a gauge the other way, ie the maximum on the left instead of on the right. This is how it's done:

<Reverse value="true" />

=== Caption ===

Every gauge can have a caption. The caption need not be displayed. Again, an example says everything that needs to be said:

<nowiki><Caption location="bottom">
<Text value="Speed" />
</Caption></nowiki>

Possible locations are top, bottom, and off. Location of "off" means the caption won't be displayed.

=== Layers ===

As previously discussed, each gauge is drawn with three layers. So far we've only talked about what is shown in the middle layer, the data layer. That is the gauge itself. In addition to the middle layer you have the background and foreground layers in which you can draw, and they are done with the aptly named Background and Foreground tags. You can put textures, solid colors, and gradients, or just leave the tag out completely if you don't need it. Here are some examples:

* A solid foreground color, red, with no alpha transparency.

<Foreground>
<Solid>
<Color r="1." g="0." b="0." alpha="1." />
</Solid>
</Foreground>

* A lightly transparent 3-color gradient. The "at" parameter marks the borders between the colors and ranges from 0 to 1. The orientation determines how the gradient will be drawn.

<Foreground>
<Gradient orientation="horizontal">
<Color r="0." g="1." b="1." alpha=".7" at="0" />
<Color r="0." g="0." b="1." alpha=".7" at=".5" />
<Color r="1." g="0." b="1." alpha=".7" at="0.8" />
</Gradient>
</Foreground>

: There are three different types of gradients, indicated by the orientation attribute. Possible values are "horizontal" and "vertical" which will make horizontal or vertical gradients. A special value is "value" which will result in a solid area which changes color according to the value of the displayed data. The color with at="0" will be used at the minimum value and at="1" will be used at the maximum.

== Available Gauges ==

Here are all of the available gauges, along with which tags are supported.

=== NeedleGauge ===

A needle gauge requires all three fields to exist in the DataSet tag. It supports all general tags. Here's an example speed gauge:

<NeedleGauge camera="*">
<DataSet>
<AtomicData field="source" source="player_speed" />
<AtomicData field="minimum" source="0" />
<AtomicData field="maximum" source="max_speed" />
</DataSet>
<Position x="-0.165" y="-0.9" />
<Size height="0.15" width="0.15" />
<ShowCurrent value="true" />
<ShowMaximum value="true" />
<ShowMinimum value="true" />
<Caption location="bottom">
<Text value="Speed" />
</Caption>
<Foreground>
<Solid>
<Color r="1." g="0." b="0." alpha="1." />
</Solid>
</Foreground>
</NeedleGauge>

=== BarGauge ===

A bar gauge requires all three fields to exist in the DataSet tag. It supports all general tags. Here's an example rubber gauge:

<BarGauge camera="^in">
<DataSet>
<AtomicData field="source" source="player_rubber" />
<AtomicData field="minimum" source="0" />
<AtomicData field="maximum" source="cycle_rubber" />
</DataSet>
<Position x="-0.55" y="-0.9" />
<Size height="0.05" width="0.15" />
<ShowCurrent value="true" />
<ShowMaximum value="true" />
<ShowMinimum value="true" />
<Caption location="bottom">
<Text value="Rubber" />
</Caption>
<Background>
<Gradient orientation="value">
<Color r="0." g="1." b="0." alpha=".0" at="0." />
<Color r="0." g="1." b="0." alpha=".1" at=".3" />
<Color r="1." g="1." b="1." alpha=".2" at=".4" />
<Color r="1." g="1." b="1." alpha=".2" at="1." />
</Gradient>
</Background>
<Foreground>
<Gradient orientation="value">
<Color r="0." g="1." b="0." alpha=".7" at="0." />
<Color r="0." g="1." b="0." alpha=".7" at=".3" />
<Color r="1." g="1." b="0." alpha=".7" at=".6" />
<Color r="1." g="0." b="0." alpha=".7" at=".8" />
<Color r="1." g="0." b="0." alpha=".7" at="1." />
</Gradient>
</Foreground>
</BarGauge>

=== VerticalBarGauge ===

Identical to a BarGauge, but renders vertically instead. Labels are currently broken for it, so don't use them yet.

=== Label ===

A label may have only one field in each DataSet tag and that field must be "source". It also requires each DataSet to have an id, which you will use to reference that data farther down. It supports any number of DataSets. In addition, you need a Face to describe how to build the Label. Here's an example for the enemies alive gauge:

<pre>
<Label camera="*">
<DataSet id="enemies">
<AtomicData field="source" source="enemies_alive" />
</DataSet>
<DataSet id="friends">
<AtomicData field="source" source="friends_alive" />
</DataSet>
<Position x="0.06" y="-0.96" />
<Size height="0.035" width="0.017" /> 
<Caption location="off">
<Text value="Player Status" />
</Caption>
<Face>
<Table>
<Row>
<Cell><Text value="Enemies:" /></Cell>
<Cell><GameData data="enemies" /></Cell>
<Cell><Text value="Friends:" /></Cell>
<Cell><GameData data="friends" /></Cell>
</Row>
</Table>
</Face>
</Label>
</pre>

==== Tables ====

A table is much like a basic HTML table: It consists of rows, coulumns, and cells. Each cell can contain multiple <Text> or <GameData> nodes, they will just be concatenated. Here's an example of a table that shows the time, the framerate, and how long Armagetron Advanced is running:

<nowiki> <Label camera="*" viewport="top">
<DataSet id="hours">
<AtomicData source="current_hours12h" minwidth="2" fill="0" />
</DataSet>
<DataSet id="minutes">
<AtomicData source="current_minutes" minwidth="2" fill="0" />
</DataSet>
<DataSet id="ampm">
<Conditional field="source" lvalue="current_hours" rvalue="12" operator="le">
<IfTrue>
<AtomicData source="AM" />
</IfTrue>
<IfFalse>
<AtomicData source="PM" />
</IfFalse>
</Conditional>
</DataSet>
<DataSet id="fps">
<AtomicData source="current_framerate" />
</DataSet>
<DataSet id="seconds">
<AtomicData source="time_since_start" />
</DataSet>
<Position x="0.4" y="0.45" />
<Size height="0.04" width="0.02" /> 
<Caption location="top">
<Text value="Time/Fps/Timestamp" />
</Caption>
<Face>
<Table>
<Row>
<Cell><Text value="Time:" /></Cell>
<Cell><GameData data="hours" /><Text value=":" /><GameData data="minutes" /><Text value=" " /><GameData data="ampm" /></Cell>
</Row>
<Row>
<Cell><Text value="Framerate:" /></Cell>
<Cell><GameData data="fps" /><Text value=" FPS" /></Cell>
</Row>
<Row>
<Cell><Text value="Running for:" /></Cell>
<Cell><GameData data="seconds" /><Text value=" Seconds" /></Cell>
</Row>
</Table>
</Face>
</Label></nowiki>

=== Map ===

The Map is a very special gauge that displays a map of the arena. As a special gauge it has very special requirements. It supports Position, and Size, nothing else. Also, it will anchor its own aspect ratio, so it might not use the whole width or height you specified. The map will be as big as possible while keeping its aspect ratio and fitting in the width and height you specify.

Here's an example:

<Map camera="*" viewport="top">
<Position x="0.73" y="-0.72" />
<Size height="0.25" width="0.25" />
</Map>

== Gauge Templates ==

Templates can be used for multiple similar gauges. Say you want three gauges for Brakes, Speed and rubber, they're all the same exept for position, caption and data.

You could copy and paste the different attributes, but that leads to a larger file, and if you later decide you want your gauges smaller you'd have to edit all three of them. That's where templates come in.

This is how you define a template:

<WidgetTemplate id="MyTemplate">
<Size height="0.3" width="0.3" />
<Position y="-.7" x="0" />

</WidgetTemplate>

The <code>id</code> attribute is used to reference your template for later use. Inside a <code><WidgetTemplate /></code> you can have all possible tags for widgets.

This is how you use your template:

<NeedleGauge usetemplate="MyTemplate">
<Position x="-.5" y="0" />

</NeedleGauge>

This internally gets replaced by the following:

<NeedleGauge>
<Size height="0.3" width="0.3" />
<Position y="-.7" x="0" />

<Position x="-.5" y="0" />

</NeedleGauge>

See how there's two <code><Position /></code> tags now? Since there's more than one tag they'll get added to each other, resulting in the widget being positioned at (-.5, -.7). <code><Size /></code> tags will get multiplied, so you could scale a template. All other tags just overwrite each other, so the last one "wins".

You can use multiple templates in one tag by seperating their names by spaces, like this: <code><Label usetemplate="MyTemplate MyOtherTemplate">...</Label></code>

== Toggle Keys ==

Are you annoyed by the HUD map being to small, but don't like a big map permanently cluttering up your screen? There's a solution, toggle keys. You can map the five available toggle keys in the global keybord configuration screen, and what they do depends entirely on the cockpit file.

Here's an example of a HUD map that gets toggled by key 1 and is visible by default (that is, until you press the key and turn it off):

<Map camera="*" viewport="top" toggle="1" toggleSticky="true" toggleDefault="on" >
<Position x="0" y="-.25" />
<Size height=".75" width="0.7" />
</Map>

There are three attributes that influence toggling behavior:
;toggle
:The toggle key to be used, needs to be a number from 1-5 or 0 for no toggle key (default if you omit it)
;toggleSticky
:If the value is "true" (default) pressing the key and releasing it will change the visibility. If it is false pressing the key and holding it will change the state, but it will return the default once you release it.
;toggleDefault
:"on" (default) means the widget will be visible until you press the toggle key, "off" means it will be invisible first.

== For Server Admins ==

There are many new kinds of gauges that might be considered as cheating by some people, or at least it gives a certain advantage to people who use them.

If you want to disable certain data sources you can change the FORBID_COCKPIT_DATA setting. It contains a colon–separated list of data sources that will be disabled (it will just display 0 instead of a value):

FORBID_COCKPIT_DATA time_to_impact_front:time_to_impact_left:time_to_impact_right:player_rubber

This will prevent the client from displaying the time_to_impact data sources and the current rubber. Likewise the HUD minimap can be disabled by the following command:

FORBID_HUD_MAP 1

Bear in mind, though, that the server has no way of knowing if the client is actually following these rules. All data sources use data that is known to the client, it wouldn't be hard to hack a client to ignore this setting. This is basically the same problem as with the FORBID_CAMERA_* settings: You have to trust on the users of your servers to play fair.

= QA and release =

For testing your cockpit, see [[Testing Resources]]. You can make your work available to others by uploading it to the [[Resource repository]]. If you do that, you might want to add an entry to [[Cockpits list]] to tell users about your cockpit.

[[Category:Client Features]]

Testing Resources

2006-09-16T22:27:44Z

Meriton: /* Tell Armagetron to use it */

So you have written a new resource and would like to test it? Then you have come to the right place :)

=== Save it ===

==== Resource directory ====
Resources that should be available to a ''specific'' user are stored in

* Linux - <home>/.armagetronad/resource
** ''Example'': /home/Joe/.armagetronad/resource
* Windows - <appdata>\Armagetron\resource
** ''Example'': C:\Documents and Settings\Joe\Application Data\Armagetron\resource
* Mac OS X - <home>/Library/Application Support/Armagetron Advanced/resource
** ''Example'': /Users/Joe/Library/Application Support/Armagetron Advanced/resource

Resources that should be available to ''all'' users of a computer are stored in

* Linux - /usr/share/games/armagetronad/resource
* Windows - C:\Program Files\Armagetron Advanced\resource
* Mac OS X - Armagetron Advanced.app/Contents/Resources/resource

respectively

* Linux — ~/.armagetronad/resource
* Windows — C:\Program Files\Armagetron Advanced\resource
* Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource

==== Filename ====

Inside the resource directory, resources are located at

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

where type, name, version, author and category must match those stated in the resource:

<Resource '''type'''="..." '''name'''="..." '''version'''="..." '''author'''="..." '''category'''="...">

In windows, the subdirectories must be seperated by '\', not '/'.

=== Tell Armagetron to use it ===

by setting the configuration item

* MAP_FILE (for maps)

to

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

(note that you have to use '/' regardless of whether you use windows)

Configuration items can be set using the [[console]] or by editing a configuration file. The configuration file shared by all users on the computer is located at

* Linux - /usr/etc/games/armagetronad/settings.cfg
* Windows - C:\Program Files\Armagetron Advanced\config\settings.cfg
* Mac OS X - Armagetron Advanced.app/Contents/Resources/settings.cfg

or is it (FIXME)

*Linux — ~/.armagetronad/config/settings_custom.cfg
*Windows — C:\Program Files\Armagetron Advanced\config\settings_custom.cfg
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/config/settings_custom.cfg

Settings in this file may be overridden for a specific user in the file

* Linux - <home>/.armagetronad/var/autoexec.cfg
* Windows - <appdata>\Armagetron\var\autoexec.cfg
* Mac OS X - <home>/Library/Application Support/Armagetron Advanced/autoexec.cfg

You may have to create the override file since it is not created automatically.

=== Run Armagetron ===

Now its time to play Armagetron Advanced locally.

If you have saved it wrong or the path you put is incorrect it will tell you.

If your settings or code is wrong it will also tell you a line number.

Testing Resources

2006-09-16T22:13:05Z

Meriton: added user resource directories

So you have written a new resource and would like to test it? Then you have come to the right place :)

=== Save it ===

==== Resource directory ====
Resources that should be available to a ''specific'' user are stored in

* Linux - <home>/.armagetronad/resource
** ''Example'': /home/Joe/.armagetronad/resource
* Windows - <appdata>\Armagetron\resource
** ''Example'': C:\Documents and Settings\Joe\Application Data\Armagetron\resource
* Mac OS X - <home>/Library/Application Support/Armagetron Advanced/resource
** ''Example'': /Users/Joe/Library/Application Support/Armagetron Advanced/resource

Resources that should be available to ''all'' users of a computer are stored in

* Linux - /usr/share/games/armagetronad/resource
* Windows - C:\Program Files\Armagetron Advanced\resource
* Mac OS X - Armagetron Advanced.app/Contents/Resources/resource

respectively

* Linux — ~/.armagetronad/resource
* Windows — C:\Program Files\Armagetron Advanced\resource
* Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource

==== Filename ====

Inside the resource directory, resources are located at

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

where type, name, version, author and category must match those stated in the resource:

<Resource '''type'''="..." '''name'''="..." '''version'''="..." '''author'''="..." '''category'''="...">

In windows, the subdirectories must be seperated by '\', not '/'.

=== Tell Armagetron to use it ===

by setting the configuration item

* MAP_FILE (for maps)

to

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

(note that you have to use '/' regardless of whether you use windows)

You may want to set the configuration item permanently by editing

*Linux — ~/.armagetronad/config/settings_custom.cfg
*Windows — C:\Program Files\Armagetron Advanced\config\settings_custom.cfg
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/config/settings_custom.cfg

=== Run Armagetron ===

Now its time to play Armagetron Advanced locally.

If you have saved it wrong or the path you put is incorrect it will tell you.

If your settings or code is wrong it will also tell you a line number.

Testing Resources

2006-09-16T21:53:31Z

Meriton: /* Tell Armagetron to use it */

So you have written a new resource and would like to test it? Then you have come to the right place :)

=== Save it ===

Resources are stored in

*Linux — ~/.armagetronad/resource
*Windows — C:\Program Files\Armagetron Advanced\resource
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource

Inside this directory, resources are located at

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

where type, name, version, author and category must match those stated in the resource:

<Resource '''type'''="..." '''name'''="..." '''version'''="..." '''author'''="..." '''category'''="...">

In windows, the subdirectories must be seperated by '\', not '/'.

=== Tell Armagetron to use it ===

by setting the configuration item

* MAP_FILE (for maps)

to

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

(note that you have to use '/' regardless of whether you use windows)

You may want to set the configuration item permanently by editing

*Linux — ~/.armagetronad/config/settings_custom.cfg
*Windows — C:\Program Files\Armagetron Advanced\config\settings_custom.cfg
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/config/settings_custom.cfg

=== Run Armagetron ===

Now its time to play Armagetron Advanced locally.

If you have saved it wrong or the path you put is incorrect it will tell you.

If your settings or code is wrong it will also tell you a line number.

Making Maps for Beginners

2006-09-16T21:48:26Z

Meriton: linked generic resource testing how to

This is going to teach you how to build custom maps for game play like the ones that the Crazy Tronners Wild Fortress uses.

==What do I need to make a map==
===Text Editor===

I used notepad but I found out that [http://www.pspad.com/ PSPad] was a lot better with handling codes
#[http://www.pnotepad.org/ Programmer's Notepad] Open source, syntax highlighting for xml files.
#[http://www.pspad.com/ PSPad (Windows)]
#[http://sourceforge.net/projects/turbopad Turbopad (Windows, Linux)]
#[http://www.context.cx/ ConText (Windows)]
#[http://www.vim.org/ Vim (many operating systems)]

===Optional Items===
You also may want [http://www.armagetron.de/armabell.html Armabell] but it is very buggy. You can design the map on [http://www.armagetron.de/armabell.html Armabell], but you will still need a text editor.

Also you will need to read [http://armagetron.de/league.html here] to set up [http://www.armagetron.de/armabell.html Armabell]

Also for ellipses and circles i use [http://generalconsumption.org/armagetron/ General Consumption]. You can also preview your maps there.

==How to make a map==
Working on instructions.
===The basic code layout===


<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<Resource type="aamap" name="name" version="0.0.0" author="author"
category="fortress">
<Map version="0.2.8">
<Settings>

</Settings>
<World>
<Field>

</Field>
</World>
</Map>
</Resource>

<small>This is the basic code structure to making a map.</small>

This includes no content right now so if you were to load the map exactly as it is Armagetron Advanced will load in the default map and settings.

=== Saving the map===

====where are the maps i downloaded ====
*Windows Vista—C:\Users\Username\AppData\Roaming\Armagetron
*Windows XP—C:\Documents and settings\Username\Application Data\Armagetron

==== Where do I need to save it====
*Linux — ~/.armagetronad/resource/'''author'''/'''category'''
*Windows — C:\Program Files\Armagetron Advanced\resource\'''author'''\'''category'''
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource/'''author'''/'''category'''

in your code there are setting that you set and must mach up when you sove the code.

<Resource type="aamap" name="name" version="0.0.0" author="'''author'''"
category="'''fortress'''">

*in the '''author''' spot rememer to put the exact name of the author from the code.
*in the '''category''' spot rememer to put the exact name of the category from the code.

==== What do I need to title it====

<Resource type="'''aamap'''" name="'''name'''" version="'''0.0.0'''" author="author"
category="fortress">

you simply save it as

'''name'''-'''version'''.'''type'''.xml

for this one it would be
name-0.0.0.aamap.xml

===What do I need in my map===
====Settings====
All the setting they you may set will be shown on a separate page

I am currently working on this secion

Here is a complete list of [[Console Commands|Map settings]]

====Axes====

<World>
<Field>
'''<Axes number="4"/>'''

</Field>
</World>
</Map>
</Resource>

The number 4 represents the number of directions in which you can turn. 4 is the default value for this.

====Spawn Points or Starting Position====

<World>
<Field>
<Axes number="4"/>
'''<Spawn x="700" y="1100" xdir="0" ydir="1"/>'''
'''<Spawn x="700" y="300" xdir="0" ydir="1"/>'''

</Field>
</World>
</Map>
</Resource>

In the spawn
*the x and y refers to the coordinates (x,y) where the team starts.
*the xdir and ydir tell what way that you are facing
**Instead of the xdir and ydir you can put in angle="'''degrees'''" where '''degrees''' is in degrees starting from the positive x direction.
*Each spawn creates a new starting position

Also, when you make levels that have just two spawn points, multiple cycles will be created at them in game if more then two people join. This can be useful when making team maps (such as ones for the CT Wild Server), as you only have to make two spawn points instead of 14

====Walls====

<World>
<Field>
<Axes number="4"/>
<Spawn x="700" y="1100" xdir="0" ydir="1"/>
<Spawn x="700" y="300" xdir="0" ydir="1"/>

'''<Wall>'''
'''<Point x="0" y="0"/>'''
'''<Point x="1400" y="0"/>'''
'''<Point x="1400" y="1400"/>'''
'''<Point x="0" y="1400"/>'''
'''<Point x="0" y="0"/>'''
'''</Wall>'''
</Field>
</World>
</Map>
</Resource>

This is the code for a wall surrounding the level, which prevents players from going on to infinity. Your level MUST have at least this type of wall, for it to be classified as a level.

NOTE:If you want a square (four sided shape) you must specify 5 wall points. If you want a 6-sided shape, then you must specify 7 wall points.

If you want to use Circles go to [http://generalconsumption.org/armagetron/ General Consumption]. That site also works good with any polygon you just need to declare you segments. you also may have to adjust the start and end angle for some maps

====Zones====

=====Fortress Zones=====

<World>
<Field>
<Axes number="4"/>
<Spawn x="700" y="1100" xdir="0" ydir="1"/>
<Spawn x="700" y="300" xdir="0" ydir="1"/>

<Wall>
<Point x="0" y="0"
<Point x="1400" y="0"
<Point x="1400" y="1400"
<Point x="0" y="1400"
<Point x="0" y="0"
</Wall>
'''<Zone effect="fortress">'''
'''<ShapeCircle radius="20">'''
'''<Point x="700" y="300" />'''
'''</ShapeCircle>'''
'''</Zone>'''
'''<Zone effect="fortress">'''
'''<ShapeCircle radius="20">'''
'''<Point x="700" y="1100" />'''
'''</ShapeCircle>'''
'''</Zone>'''
</Field>
</World>
</Map>
</Resource>

Above is the method of creating conquest zones for a fortress map. As well as these, you can also create deathzones and winzones:

=====Deathzones=====

<Zone effect="death">
<ShapeCircle radius="10">
<Point x="700" y="700"/>
</ShapeCircle>
</Zone>

=====Winzone Code=====

<Zone effect="win">
<ShapeCircle radius="5">
<Point x="700" y="700"/>
</ShapeCircle>
</Zone>

If you wish to tamper with the zone effects, change the [[Console Commands|Map settings]]

==What your final map code should look like==

This section is about what your final coding should look like, so you can double check before you test your map.

===Free-for-all===

<World>
<Field>
<Axes number="4"/>
<Spawn x="200" y="100" xdir="0" ydir="1"/>
<Spawn x="200" y="300" xdir="0" ydir="-1"/>

<Wall>
<Point x="0" y="0"/>
<Point x="400" y="0"/>
<Point x="400" y="400"/>
<Point x="0" y="400"/>
<Point x="0" y="0"/>
</Wall>
</Field>
</World>
</Map>
</Resource>

This format will have two sets of opponants (even though it is still free-for-all) facing each other like so:

<nowiki>****insert a pic Ed****</nowiki>

The level stats are:
Size: 400×400
Axes:4

===Fortress===

<World>
<Field>
<Axes number="4"/>
<Spawn x="200" y="100" xdir="0" ydir="1"/>
<Spawn x="200" y="300" xdir="0" ydir="-1"/>

<Wall>
<Point x="0" y="0"/>
<Point x="400" y="0"/>
<Point x="400" y="400"/>
<Point x="0" y="400"/>
<Point x="0" y="0"/>
</Wall>
<Zone effect="fortress">
<ShapeCircle radius="20">
<Point x="200" y="100" />
</ShapeCircle>
</Zone>
<Zone effect="fortress">
<ShapeCircle radius="20">
<Point x="200" y="100" />
</ShapeCircle>
</Zone>
</Field>
</World>
</Map>
</Resource>

==How to Test your map==
See [[Testing Resources]].

==Commands==
This is a [[Console Commands|Map settings]] link to the page where we have set up a list of commands (or settings as they are more usually known) that you can add to your map to make it more effective

==Examples==
The following are examples of the codes and pictures of each of the <i>other</i> two main types of maps

===Free-for-all map with walls===
This is a map that is a free for all melee, but it has some neat obsicles that you may want to avoid, like the four triangles in the middle

<World>
<Field>
<Axes number="4"/>
<Spawn x="200" y="50" xdir="0" ydir="1"/>
<Spawn x="200" y="350" xdir="0" ydir="-1"/>

<Wall>
<Point x="0" y="0"/>
<Point x="400" y="0"/>
<Point x="400" y="400"/>
<Point x="0" y="400"/>
<Point x="0" y="0"/>
</Wall>
<Wall>
<Point x="175" y="100"/>
<Point x="100" y="175"/>
<Point x="175" y="175"/>
<Point x="175" y="100"/>
</Wall>
<Wall>
<Point x="225" y="100"/>
<Point x="300" y="175"/>
<Point x="225" y="175"/>
<Point x="225" y="100"/>
<Wall>
<Point x="175" y="300"/>
<Point x="100" y="225"/>
<Point x="175" y="225"/>
<Point x="175" y="300"/>
</Wall>
<Wall>
<Point x="225" y="300"/>
<Point x="300" y="225"/>
<Point x="225" y="225"/>
<Point x="225" y="300"/>
</Wall>
</Wall>
</Field>
</World>
</Map>
</Resource>

===Fortress map with walls===
This is a map that incorporates two fortress zones per team, one of each teams is in the middle, forming a sumo. There are some walls and side entrances to allow some sneaky attacking and defending.

<World>
<Field>
<Axes number="4"/>
<Spawn x="102" y="40" xdir="0" ydir="1" />
<Spawn x="98" y="360" xdir="0" ydir="-1" />
<Wall>
<Point x="0" y="0" />
<Point x="200" y="0" />
<Point x="200" y="400" />
<Point x="0" y="400" />
<Point x="0" y="0" />
</Wall>
<Wall>
<Point x="0" y="200" />
<Point x="65" y="200" />
</Wall>
<Wall>
<Point x="135" y="200" />
<Point x="200" y="200" />
</Wall>
<Wall>
<Point x="65" y="240" />
<Point x="65" y="160" />
</Wall>
<Wall>
<Point x="135" y="240" />
<Point x="135" y="160" />
</Wall>
<Zone effect="fortress">
<ShapeCircle radius="30">
<Point x="100" y="40" />
</ShapeCircle>
</Zone>
<Zone effect="fortress">
<ShapeCircle radius="30">
<Point x="100" y="360" />
</ShapeCircle>
</Zone>
<Zone effect="fortress">
<ShapeCircle radius="35">
<Point x="100" y="200" />
</ShapeCircle>
</Zone>
<Zone effect="fortress">
<ShapeCircle radius="35">
<Point x="100" y="200" />
</ShapeCircle>
</Zone>
</Field>
</World>
</Map>
</Resource>

Testing Resources

2006-09-16T21:45:55Z

Meriton: appearance improved

So you have written a new resource and would like to test it? Then you have come to the right place :)

=== Save it ===

Resources are stored in

*Linux — ~/.armagetronad/resource
*Windows — C:\Program Files\Armagetron Advanced\resource
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource

Inside this directory, resources are located at

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

where type, name, version, author and category must match those stated in the resource:

<Resource '''type'''="..." '''name'''="..." '''version'''="..." '''author'''="..." '''category'''="...">

In windows, the subdirectories must be seperated by '\', not '/'.

=== Tell Armagetron to use it ===

by setting the relevant configuration item to

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

(note that you have to use '/' regardless of whether you use windows)

You may want to set the configuration item permanently by editing

*Linux — ~/.armagetronad/config/settings_custom.cfg
*Windows — C:\Program Files\Armagetron Advanced\config\settings_custom.cfg
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/config/settings_custom.cfg

=== Run Armagetron ===

Now its time to play Armagetron Advanced locally.

If you have saved it wrong or the path you put is incorrect it will tell you.

If your settings or code is wrong it will also tell you a line number.

Testing Resources

2006-09-16T21:42:42Z

Meriton:

So you have written a new resource and would like to test it? Then you have come to the right place :)

=== Save it ===

Resources are stored in

*Linux — ~/.armagetronad/resource
*Windows — C:\Program Files\Armagetron Advanced\resource
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource

Inside this directory, resources are located at

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

where type, name, version, author and category must match those stated in the resource:

<Resource '''type'''="..." '''name'''="..." '''version'''="..." '''author'''="..." '''category'''="...">

In windows, the subdirectories must be seperated by '\', not '/'.

=== Tell Armagetron to use it ===

by setting the relevant configuration item to

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

(note that you have to use '/' regardless of whether you use windows)

You may want to set the configuration item permanently by editing

*'''Windows'''—C:\Program Files\Armagetron Advanced\config\settings_custom.cfg
*'''Mac OS X'''—~/Library/Application Support/Armagetron Advanced/config/settings_custom.cfg
*'''Linux'''—~/.armagetronad/config/settings_custom.cfg

=== Run Armagetron ===

Now its time to play Armagetron Advanced locally.

If you have saved it wrong or the path you put is incorrect it will tell you.

If your settings or code is wrong it will also tell you a line number.

Testing Resources

2006-09-16T21:42:02Z

Meriton: initial import and reformatting from Map_Testing

So you have written a new resource and would like to test it? Then you have come to the right place :)

=== Save it ===

Resources are stored in

*Linux — ~/.armagetronad/resource
*Windows — C:\Program Files\Armagetron Advanced\resource
*Mac OS X — ~/Library/Application Support/Armagetron Advanced/resource

Inside this directory, resources are located at

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

where type, name, version, author and category must match those stated in the resource:

<Resource '''type'''="..." '''name'''="..." '''version'''="..." '''author'''="..." '''category'''="...">

In windows, the subdirectories must be seperated by '\', not '/'.

=== Tell Armagetron to use it ===

by setting the relevant configuration item to

'''author'''/'''category'''/'''name'''-'''version'''.'''type'''.xml

(note that you have to use '/' regardless of whether you use windows)

You may want to set the configuration item permanently by editing

*'''Windows'''—C:\Program Files\Armagetron Advanced\config\settings_custom.cfg
*'''Mac OS X'''—~/Library/Application Support/Armagetron Advanced/config/settings_custom.cfg
*'''Linux'''—~/.armagetronad/config/settings_custom.cfg

=== Run Armagetron ===

Now its time to play Armagetron Advanced locally.

If you have saved it wrong or the path you put is incorrect it will tell you.

If your settings or code is wrong it will also tell you a line number.

Cockpits List

2006-09-16T20:07:25Z

Meriton: fix broken link

This is a list of a few cockpit files that are available. You can only use them if you have downloaded a version of Armagetronad later than 0.3.0_alpha4872 and if you know how to use the [[Console]]. Be aware that your use of upper/lowercase for the console command matters.

== Abyss ==

[[Image:Abyss-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Abyss]]
;Author
:[[User:Spidey|Spidey]]
;Description
:TODO-Spidey: add this.
;Console Command
:<code>COCKPIT_FILE spidey/abyss-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/spidey/abyss-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Classic ==

[[Image:Classic-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Classic cockpit]]
;Author
:[[User:Wrtlprnft|Wrtlprnft]]
;Description
:This cockpit file tries to emulate the cockpit of 0.2.8 as much as possible. It doesn't include a HUD minimap and uses the traditional needle gauges. Boooooring.
;Console Command
:<code>COCKPIT_FILE wrtlprnft/classic-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/wrtlprnft/classic-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Pink ==

[[Image:Pink-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Pink]]
;Author
:[[User:Spidey|Spidey]]
;Description
:TODO-Spidey: add this.
;Console Command
:<code>COCKPIT_FILE spidey/pink-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/spidey/pink-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Playroom ==

[[Image:Playground-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Playground]]
;Author
:[[User:Lucifer|Lucifer]]
;Description
:This cockpit is designed for fortress play. All gauges are placed near where your eyes are normally focused so you never have to look far. Play with it enough and you find you always know your speed, amount of brake, and stuff. Enemies alive gauge is color-coded to show at a glance whether or not you're outnumbered. Look at the gauge itself to see how badly you're outnumbered, and look at the map to see where everybody is.
;Console Command
:<code>COCKPIT_FILE Lucifer/sick/Playroom-0.0.1.aacockpit.xml</code>
<div style="clear:right;"></div>

== Standard Cockpit ==

[[Image:Standard-0.0.1.aacockpit.xml (Screenshot) (1).png|thumb|Standard cockpit in smartcam mode]]
[[Image:Standard-0.0.1.aacockpit.xml (Screenshot) (2).png|thumb|Standard cockpit in incam mode]]
;Author
:[[User:Wrtlprnft|Wrtlprnft]] and [[User:Lucifer|Lucifer]]
;Description
:This is the default cockpit in 0.3.0. It has the new HUD map and bar gauges, but displays about the same data as 0.2.8.
:Try switching to incam mode for a camera tailored to incam playing.
;Console Command
:<code>COCKPIT_FILE Anonymous/standard-0.0.1.aacockpit.xml</code>
<div style="clear:right;"></div>

== Vanoriginal ==

[[Image:Vanoriginal-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Vanoriginal]]
;Author
:[[User:Vanhayes|Vanhayes]]
;Description
:I Made all the meters Vertical Bar guages, took out all of the information that was showed in the top right corner except time and FPS, though you can toggle them off.Put the enemies/friends alive meter from incam. You can also toggle off the map If it is in the way and you can toggle on the impact meters, Front left and right.The toggles are cockpit keys: 1(map),2(impact meters), and 5(FPS/Time)
;Console Command
:<code>COCKPIT_FILE Vanhayes/cockpit/vanoriginal-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/Vanhayes/cockpit/vanoriginal-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Wrtl's Cockpit ==

[[Image:Testfile-0.0.1.aacockpit.xml (Screenshot) (1).png|thumb|
Wrtl's cockpit with everything at initial state]]
[[Image:Testfile-0.0.1.aacockpit.xml (Screenshot) (2).png|thumb|
Wrtl's cockpit with the HUD map switched off]]
[[Image:Testfile-0.0.1.aacockpit.xml (Screenshot) (3).png|thumb|
Wrtl's cockpit with dimmed 3D rendering]]
;Author
:[[User:Wrtlprnft|Wrtlprnft]]
;Description
:This is my approach on creating the ultimate cockpit.
:The huge rubber gauge on the left helps you know instantly how risky you can play and the player information on the top right helps you determine if your help defending is needed.
:On the bottom right is a special gauge that shows the approximate time to the next impact with a wall, useful if you want to know if you outgrinded someone. You can switch of the big map by pressing the first cockpit key (bind it in global keyboard config) and dim the 3D rendering by pressing the second key—useful for chico maps.
;Console Command
:<code>COCKPIT_FILE wrtlprnft/testfile-0.0.1.aacockpit.xml</code>
;Resource Repository Links
:[http://beta.armagetronad.net/resource-browser/resource/wrtlprnft/testfile-0.0.1.aacockpit.xml Version 0.0.1]
:[http://beta.armagetronad.net/resource-browser/resource/wrtlprnft/testfile-0.0.3.aacockpit.xml Version 0.0.3—doesn't work with 0.3.0, will work with 0.3.1]
<div style="clear:right;"></div>

== Xevi's Cockpit ==

[[Image:Xevi-0.0.3.aacockpit.xml (Screenshot).png|thumb|Xevi's Cockpit, version 0.0.3]]
[[Image:Xevi-0.0.4.aacockpit.xml (Screenshot).png|thumb|Xevi's Cockpit, version 0.0.4]]
[[Image:Xevi_cockpit_05.JPG|thumb|Xevi's Cockpit, version 0.0.5]]
[[Image:Xevi.0.0.7.JPG|thumb|Xevi's Cockpit, version 0.0.7]]
;Author
:[[User:Xevic|Xevi]]
;Description
:Some evolutions of the real hud ;) there are also versions 0.0.1 and 0.0.2, but they are just a step to 0.0.3, then there is a couple of evolutions, in 0.0.4 I added wrtl's impact time widget. Version 0.0.5 adds warning bars, there is one for front impact, another for left and one for right. The new 0.0.6 is a improvement of last one with better look bars and better parameters. News on 7: bars tunning, front impact moved bottom to allow better notice, avoid chat and transparency problems there, new big map switch with toggle 3, now it won't desappear, it will appear the full screen version.
Enjoy them.
;Console Command
:<code>COCKPIT_FILE xevi/xevi-0.0.7.aacockpit.xml</code>
;Resource Repository Links
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.3.aacockpit.xml Version 0.0.3]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.4.aacockpit.xml Version 0.0.4]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.5.aacockpit.xml Version 0.0.5]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.6.aacockpit.xml Version 0.0.6]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.7.aacockpit.xml Version 0.0.7]
<div style="clear:right;"></div>

Cockpits List

2006-09-16T20:06:43Z

Meriton: playground has been renamed to playroom in the release

This is a list of a few cockpit files that are available. You can only use them if you have downloaded a version of Armagetronad later than 0.3.0_alpha4872 and if you know how to use the [[Console]]. Be aware that your use of upper/lowercase for the console command matters.

== Abyss ==

[[Image:Abyss-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Abyss]]
;Author
:[[User:Spidey|Spidey]]
;Description
:TODO-Spidey: add this.
;Console Command
:<code>COCKPIT_FILE spidey/abyss-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/spidey/abyss-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Classic ==

[[Image:Classic-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Classic cockpit]]
;Author
:[[User:Wrtlprnft|Wrtlprnft]]
;Description
:This cockpit file tries to emulate the cockpit of 0.2.8 as much as possible. It doesn't include a HUD minimap and uses the traditional needle gauges. Boooooring.
;Console Command
:<code>COCKPIT_FILE wrtlprnft/classic-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/wrtlprnft/classic-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Pink ==

[[Image:Pink-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Pink]]
;Author
:[[User:Spidey|Spidey]]
;Description
:TODO-Spidey: add this.
;Console Command
:<code>COCKPIT_FILE spidey/pink-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/spidey/pink-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Playroom ==

[[Image:Playroom-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Playground]]
;Author
:[[User:Lucifer|Lucifer]]
;Description
:This cockpit is designed for fortress play. All gauges are placed near where your eyes are normally focused so you never have to look far. Play with it enough and you find you always know your speed, amount of brake, and stuff. Enemies alive gauge is color-coded to show at a glance whether or not you're outnumbered. Look at the gauge itself to see how badly you're outnumbered, and look at the map to see where everybody is.
;Console Command
:<code>COCKPIT_FILE Lucifer/sick/Playroom-0.0.1.aacockpit.xml</code>
<div style="clear:right;"></div>

== Standard Cockpit ==

[[Image:Standard-0.0.1.aacockpit.xml (Screenshot) (1).png|thumb|Standard cockpit in smartcam mode]]
[[Image:Standard-0.0.1.aacockpit.xml (Screenshot) (2).png|thumb|Standard cockpit in incam mode]]
;Author
:[[User:Wrtlprnft|Wrtlprnft]] and [[User:Lucifer|Lucifer]]
;Description
:This is the default cockpit in 0.3.0. It has the new HUD map and bar gauges, but displays about the same data as 0.2.8.
:Try switching to incam mode for a camera tailored to incam playing.
;Console Command
:<code>COCKPIT_FILE Anonymous/standard-0.0.1.aacockpit.xml</code>
<div style="clear:right;"></div>

== Vanoriginal ==

[[Image:Vanoriginal-0.0.1.aacockpit.xml (Screenshot).png|thumb|
Vanoriginal]]
;Author
:[[User:Vanhayes|Vanhayes]]
;Description
:I Made all the meters Vertical Bar guages, took out all of the information that was showed in the top right corner except time and FPS, though you can toggle them off.Put the enemies/friends alive meter from incam. You can also toggle off the map If it is in the way and you can toggle on the impact meters, Front left and right.The toggles are cockpit keys: 1(map),2(impact meters), and 5(FPS/Time)
;Console Command
:<code>COCKPIT_FILE Vanhayes/cockpit/vanoriginal-0.0.1.aacockpit.xml</code>
;Resource Repository Link
:[http://beta.armagetronad.net/resource-browser/resource/Vanhayes/cockpit/vanoriginal-0.0.1.aacockpit.xml Version 0.0.1]
<div style="clear:right;"></div>

== Wrtl's Cockpit ==

[[Image:Testfile-0.0.1.aacockpit.xml (Screenshot) (1).png|thumb|
Wrtl's cockpit with everything at initial state]]
[[Image:Testfile-0.0.1.aacockpit.xml (Screenshot) (2).png|thumb|
Wrtl's cockpit with the HUD map switched off]]
[[Image:Testfile-0.0.1.aacockpit.xml (Screenshot) (3).png|thumb|
Wrtl's cockpit with dimmed 3D rendering]]
;Author
:[[User:Wrtlprnft|Wrtlprnft]]
;Description
:This is my approach on creating the ultimate cockpit.
:The huge rubber gauge on the left helps you know instantly how risky you can play and the player information on the top right helps you determine if your help defending is needed.
:On the bottom right is a special gauge that shows the approximate time to the next impact with a wall, useful if you want to know if you outgrinded someone. You can switch of the big map by pressing the first cockpit key (bind it in global keyboard config) and dim the 3D rendering by pressing the second key—useful for chico maps.
;Console Command
:<code>COCKPIT_FILE wrtlprnft/testfile-0.0.1.aacockpit.xml</code>
;Resource Repository Links
:[http://beta.armagetronad.net/resource-browser/resource/wrtlprnft/testfile-0.0.1.aacockpit.xml Version 0.0.1]
:[http://beta.armagetronad.net/resource-browser/resource/wrtlprnft/testfile-0.0.3.aacockpit.xml Version 0.0.3—doesn't work with 0.3.0, will work with 0.3.1]
<div style="clear:right;"></div>

== Xevi's Cockpit ==

[[Image:Xevi-0.0.3.aacockpit.xml (Screenshot).png|thumb|Xevi's Cockpit, version 0.0.3]]
[[Image:Xevi-0.0.4.aacockpit.xml (Screenshot).png|thumb|Xevi's Cockpit, version 0.0.4]]
[[Image:Xevi_cockpit_05.JPG|thumb|Xevi's Cockpit, version 0.0.5]]
[[Image:Xevi.0.0.7.JPG|thumb|Xevi's Cockpit, version 0.0.7]]
;Author
:[[User:Xevic|Xevi]]
;Description
:Some evolutions of the real hud ;) there are also versions 0.0.1 and 0.0.2, but they are just a step to 0.0.3, then there is a couple of evolutions, in 0.0.4 I added wrtl's impact time widget. Version 0.0.5 adds warning bars, there is one for front impact, another for left and one for right. The new 0.0.6 is a improvement of last one with better look bars and better parameters. News on 7: bars tunning, front impact moved bottom to allow better notice, avoid chat and transparency problems there, new big map switch with toggle 3, now it won't desappear, it will appear the full screen version.
Enjoy them.
;Console Command
:<code>COCKPIT_FILE xevi/xevi-0.0.7.aacockpit.xml</code>
;Resource Repository Links
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.3.aacockpit.xml Version 0.0.3]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.4.aacockpit.xml Version 0.0.4]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.5.aacockpit.xml Version 0.0.5]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.6.aacockpit.xml Version 0.0.6]
:[http://beta.armagetronad.net/resource-browser/resource/xevi/xevi-0.0.7.aacockpit.xml Version 0.0.7]
<div style="clear:right;"></div>

Camera Glance Keys

2006-09-16T19:57:02Z

Meriton: it is in the release now

<div style="background:#ccc; border:1px solid black; margin:0.4em; padding:0.2em;">'''Note:''' This page describes the behavior of 0.3.0. Previous releases used a slightly different system.</div>

= Manual Camera Control =

While the camera tries to show the areas of the grid that are most interesting to you, the camera can not always anticipate your wishes. Manual camera control permits you to adjust the perspective while playing to show the things that really matter.

The keys for manual camera control can be configured in

Main Menu/Player Setup/Player x Settings/Camera Input Configuration

= What Is Glancing? =

Glancing is the most common form of custom camera control. It causes the camera to face towards a specific direction and is controlled by the four glance keys "glance forward", "glance backward", "glance left" and - you guessed it - "glance right". Unless you changed them in the player options, the glance keys are the arrow keys.

= Why Would I Want to Glance? =

Glad you asked ;-). Using glancing, you can look in any direction, regardless of where you are driving to. You can glance backwards to check whether someone (friend or foe) is grinding your wall. You can glance right to check whether you or the opponent is ahead. You can watch what happens at a fortress while driving by or watch its interior while circling it.

The only disadvantage about glancing is that you might be so absorbed in the action around you that you forget to watch what might endanger your cycle ...

= How Do I Glance? =

Glancing is activated by pressing a glance key and maintained by keeping any glance key pressed.

For instance, pressing "glance left" for a while will show you the area left of your cycle until you release the key, upon which the automatic camera control takes over again.

More precisely, when you press a glance key, you "load" that key with a request to face towards a specific direction, and while you keep pressing the key, the request will be acted upon (if you keep more than one glance key pressed, the most recently pressed one is active).

The direction you request is the current view direction, snapped to the closest axis, rotated as specified by the glance key. (If you were already glancing, only the rotation specified by the glance key is updated, the base direction remains unchanged).

Note that glancing is completly independent of the cycle's driving direction. Therefore, there is nothing wrong with glancing over extended periods of time.

= How Can I Configure Glancing? =

Aside from adjusting the glance keys, glance behavior is controlled by the following options:

;CAMERA_GLANCE_ANGULAR_VELOCITY
:Controls how swiftly the camera rotates towards the requested facing. More precisely, this setting contains the angular velocity (if the camera's facing is perpendicular to the requested facing). Unit: Radians per second.
;CAMERA_GLANCE_MODE
:Controls how the camera rotates towards the requested facing. Possible values are:
:;0
::The camera aproaches the requested facing with constant angular velocity.
:;1
::The camera approaches the requested facing with angular velocity propotional to angle left to travel.
:;2
::The camera approaches the requested facing with constant angular velocity if the angle left is larger than 90°, otherwise with angular velocity proportional to sin(angle).
:;any other setting
::The camera always "jumps" instantly to its new position. Totally useless IMHO.
;CAMERA_GLANCE_ANGULAR_VELOCITY_BONUS
:Factor to CAMERA_GLANCE_ANGULAR_VELOCITY if CAMERA_GLANCE_MODE is set to 2 and the angle deft is larger than 90°

Since the smart camera offers a (in the dev's humble opinion) poor perspective when glancing, its location is configurable independently:

;CAMERA_SMART_GLANCING_BACK
:How far the camera is moved behind the cycle when glancing
;CAMERA_SMART_GLANCING_HEIGHT
:How far the camera is moved up. There is no pitch setting, the cycle always appears in the centre of the screen

Note that CAMERA_SMART_GLANCE_CUSTOM no longer exists. Those who prefer the old behavior are advised to use the preceeding options to simulate it.

= Known Limitations =

Due to axis snapping, if the current view direction is right between two axis, the glance directions are unspecified. Most automatic modes rarely reach that point on their own, but may do so if glancing has just been recently deactivated. We haven't found an easy way around that (as axis snapping is very useful).

[[Category:Camera]]

Competition Hub

2006-09-04T09:44:48Z

Meriton:

Want to join a tournament, browse an old one, or organize/create a new one... well you're in the right place
<br />
<br />
{|- border="1" cellpadding="5" cellspacing="0"
| style="background:lightgray" | '''[[4_Team_Fortress_Tourney_1|4 Clan Fortress Tournament]]'''
|-
| The first 4 team fortress tournament <br />
Discussion [[Talk:4_Team_Fortress_Tourney_1 | here]]
|-
|-
| style="background:lightgray" | {{LadleTbl}}
|-
| The Fourth Tronic Ladle, is set for the first Sunday of the month, which is the 1st of October 2006... details pending...
|-
| style="background:lightgray" | '''earlier competitions...'''
|-
|
The Third [[THE LADLE|Tronic Ladle]] was won by [[Ladle Winners|Anarchic Wanderers]] on 3rd September 2006.

The first [[International_Tron_World_Cup|Tron World Cup]] took place in July and August 2006 and was won by the United Kingdom. Full scores of the matches are available on the [http://lod.bigreddesign.co.uk/twc/ Official TWC Site]

The Second [[THE LADLE|Tronic Ladle]] was won by [[Ladle Winners|Anarchic Wanderers]] on 29th August 2006.

The First [[THE LADLE|Tronic Ladle]] was a fortress tournament with seven teams and was won by [[Ladle Winners|Shadow League]] on 1st July 2006.

The [[THE SPOON|Tronic Spoon]] was a fortress tournament of 87 players arranged into 8 and was won by [[Team somethingsomething]] in March 2006.
|}

Competition Hub

2006-09-04T09:43:25Z

Meriton:

Want to join a tournament, browse an old one, or organize/create a new one... well you're in the right place
<br />
<br />
{|- border="1" cellpadding="5" cellspacing="0"
| style="background:lightgray" | '''[[4_Team_Fortress_Tourney_1|4 Clan Fortress Tournament]]'''
|-
| The first 4 team fortress tournament <br />
Discussion [[Talk:4_Team_Fortress_Tourney_1 | here]]
|-
|-
| style="background:lightgray" | {{LadleTbl}}
|-
| The Third Tronic Ladle fortress tournament was played on Sun 3rd September '''with the final''' at 9pm GMT!
* First Stage: stick your name down on one of the [[LADLE team-lists|teams]] -- 58 players in 6 teams so far!
* Second Stage: make sure your captain visits the [[Challenge Room]].
* Third Stage: captains make use of the [[Challenge Board]] to determine provisional play-offs.
* Fourth Stage: check in with your team at 6.45pm GMT... though first games probably at 7.30 pm GMT. Have fun!
|-
| style="background:lightgray" | '''earlier competitions...'''
|-
|
The Third [[THE LADLE|Tronic Ladle]] was won by [[Ladle Winners|Anarchic Wanderers]] on 3rd September 2006.

The first [[International_Tron_World_Cup|Tron World Cup]] took place in July and August 2006 and was won by the United Kingdom. Full scores of the matches are available on the [http://lod.bigreddesign.co.uk/twc/ Official TWC Site]

The Second [[THE LADLE|Tronic Ladle]] was won by [[Ladle Winners|Anarchic Wanderers]] on 29th August 2006.

The First [[THE LADLE|Tronic Ladle]] was a fortress tournament with seven teams and was won by [[Ladle Winners|Shadow League]] on 1st July 2006.

The [[THE SPOON|Tronic Spoon]] was a fortress tournament of 87 players arranged into 8 and was won by [[Team somethingsomething]] in March 2006.
|}

Ladle Feedback

2006-09-04T09:27:24Z

Meriton: /* Feedback for the Third Ladle */

{{Ladle}}

Please write your comments below about your experience of the event. You can also add comments about how it could be better... This information may be useful for anyone who tries to do such a thing again... We have to discuss stuff so that a decision is made -- check out [[Talk:Challenge Room]]

== Feedback for the Third Ladle ==

;Manta

Each ladle keeps getting better and I think we had a great turnout. It's nice to see so many different teams participating. However I'm beginning to think we should do a way with team captains deciding the matches on game day. Once again the first match started almost an hour late do to delays by team captains. And I'm not blameless here either. We really need to just go with the lineup we have already decide upon ahead of time in the challenge page. Many good players are sadly getting burned since they are told to show up at a certain time only to be informed to wait around for decisions to be made.

Also for my location the timing of this match worked out to being on a Sunday morning on one of the biggest holiday weekends of the year. Could there please be a little more consideration for players living in the Americas next time. WS was at 4 players because of this. Thank you to those who generously volunteered to help. It would also be nice to have it scheduled a few hours later on in the day but even as it is the players located in China can't easily make it.

On another point: I am beginning to think there is no fix for this issue of disparaging ping difference. After just a few weeks of hosting my own server I have noticed that most players located in Europe (but not all luckily) refuse to play on servers where they do not get a 50 ping. Their first comments are generally "this server is $@%&*, I have a 190 ping" and leave. Heck I play with 350!! of course not as well as I would like. Because of the size of the land mass many Americans average a 190 ping on THEIR OWN servers!!! I'm sadly beginning to get some VERY unfavorable impressions of certain players. And lets not forget there are some people left out not matter what such as the Chinese players. No one will play on their servers since we do nothing but bitch. but they "QUIETLY" put up with 300 - 400+ pings NO matter the server and they still play well. We could learn a lot from them.

The only way I can see to fix this advantage of pitting teams in the ladle with such different pings is for people to stop unilaterally refusing to play above a 100 ping. And the other is teams need to actively recruit members from all parts of the world. This is an internal game after all.

Sorry if I offended some people but I think this needed to be brought up and I tried not to mention any names.

---

Reply to above: I don't mind a high ping, I can play with that. What i do mind is servers that have sudden lag jumps for everyone that make it luck whether you win or lose.

For the ladle: First of all, it was fun. A lot of fun, actually. One thing that annoyed me was the fact that a certain someone started taking over all organisation just an hour before the thing started. Suddenly we had two conflicting brackets (2020 already posted his version ages ago, [[Ladle Brackets]] was useless), a certain someone joining the server my team was on wanting to tell us what to do, and other things that only delayed it IMHO. Of course, that guy wasn't in IRC which would have made it easy to communcicate, but went in and out of servers just at he liked.

In the end we still got great matches (though I sucked even more than usual). I think having the wiki more organized and have one IRC channel '''all''' ladle- related people are in will prevent such conflicting information. —[[User:Wrtlprnft|Wrtlprnft]] 01:19, 4 September 2006 (CDT)

---

I agree with Manta about team-captains... timing is tricky, I just opted for first sunday of the month; and in europe the final ends at round about midnight which is getting late for a Sunday night game... ping will always remain and issue, but it is best solved if players put in a little effort, research the servers they wish to play on, inform their team-captain, who eventually makes a decision as to what server to play on based on the average ping of the players... i like your solution about enlisting players from different geographic locations, but it is already tricky enough forming teams...

I agree with wrtl about ping-spikes, and I would have thought captains would choose servers that they know they can trust... and I like the idea of everyone being invited to IRC, with separate chatrooms for different teams... yeah... sounds useful... -- [[User:2020|2020]] 07.45 4 September 2006 (GMT)

;2020
Wow... The standard of play was high... I was at the bottom of the scorecard in most games... The fact that we managed to play any games was, quite frankly, amazing. My team-mates were superlative in their skills. The first game against WPN was chaotic, and I subbed myself off half-way through because my ping was god-awful and my skills just can't cope; we won 2-1. Because of the confusion in organisation, I ended up playing in the second team-challenge versus Shadow League, which was a huge game; again we won 2-1. It came down to an all-AW final, and again the moves being pulled were astounding; AW won 2-1 ehhehe.

I had great fun, mostly because I was skyped with Ghableska. I was in hysterics with the initial dis-organisation, haven't laughed so hard in ages... didn't know who was in what team... who were the opponents... where we'd play... it was completely crazy... If I hadn't been connected to ghab, I think I would have ended up crying, but as it happened, I just laughed and laughed.

Man of the tournament for me was Alex, from AW. At one point, we were trailing badly in the third match against SL I think, and they had three against our two Madmax and Alex, and somehow, they held their nerve and turn it around for a win... Alex defended valiantly many times, saving the team from defeat. His defence was questioned by many, but if they can't break it, then it works, IMO. I can't say what the other team-mates were doing, especially offence, since I so rarely took part, and we won quite a lot... I would be happy for another player to be nominated for offence...

Right... as for the organisation... A shambles. With all this technology, we have tiny little one-liners, at some point I had to have a server open to chat, another window to look at the servers, a window to IRC to chat, another couple of windows to check brackets, challenge boards... it was complete chaos. Before the event I was heartened when I saw the challenge board was finally being used.. but the course of play was not followed... team-captains did not stick to the plan... they ended up wandering about challenging other teams, telling players where to go and who to play... I have to thank those involved who actually managed to get anything happening, I think special attention goes to Lack for trying to keep things together, Van and wrtl. We had weeks of preparation, feedback invitations, and yet... chaotic... I am tempted to agree with the detractors of self-organisation, and agree to sign away my trust in human beings.. in blood...

However, I think we can learn from this. The more active people are, the more experience we get, and the more we can learn. I intend to contact various players, talk about things, and develop a system which is flexible, yet easy enough to manage that it can work. I believe the central weakness is that players panicked, team-captains did not get their teams together, nor did they register together at the right times, and make essential decisions together. I believe one or two individuals took it upon themselves to try to organise everyone, and not just their own teams. Self-organising only works if people share the responsibillity of organising, and this comes down to team-captains, at least in the current configuration. I resisted the urge to take charge, since there were too many cooks already IMHO, and I had put plenty of effort in setting it up with wiki et al... on the night, I just want to be a player, play with my team-mates, and trust my captain...

I think there is hope. I had a laugh, there were a few good games, and all done within a few hours. A little unstable, perhaps, but I think the toddler is taking a few first steps...

=== Organization ===

;meriton

I was acting captain for SL. The chief issue I had with organization was there were many channels for organization. Specifically, there is the wiki, the team captain server, the IRC channel and in-game chat. The channels disagreed on many matters, sometimes even with itself (For instance, there were more teams on the challenge board than in the brackets page.)

Documentation was so bloated and disorganized everyone considered a different subset. Some team captains were also not well prepared (in my case, this was because I was elected replacement captain 10 minutes before the first match). Also, some channels are inadequate for coordinating stuff. For instance, in-game chat on a full server where everyone is talking, and where the other team captain is busy playing most of the time. A team captain room that is empty most of the time. An irc channel announced in a poorly visible location (buried under tons of other stuff). And the wiki that isn't updated and buries essential info under tons of nice-to-know.

I suggest to consolidate and purify these sources of information and dispose of the inadequate ones:

* abolish the team captain chat in favour of the IRC channel
* no in-game organizing except for trivial matters
* clean the wiki. Let's create a single page with all rules and only rules.

In terms of infrastructure, some servers listed appeared not capable to host a full team without lag fluctuation. It would be good if the servers could be checked in advance.

== Feedback for the Second Ladle ==
;Sky
:for the sake of fairness. could teams not be allowed to adopt players at the last second unless theyre in the registered team? so a team doesnt get a huge boost. instead maybe have teams substitute players to adjust to the amount of players on the other team.
;2020
:Ping was a big determiner in who won the matches. Ideas suggested during the game was to split the final between two servers. Also, the captains did not make use of the challenge room in the wiki. It was all just organised before the matches, which was ok because we only have four teams of about five players each. The idea is for the system to be future-proof, scalable to hundreds if not thousands of team... I can't see this working that well with more than four teams. I think team captains should take a little more responsibillity for making sure they choose a server that suits their players. And of course, it is the responsibility of the players to turn up! Oh well... Also... it would be nice to have little animations of the highlight, specific moves, climax battles, that kind of thing... can I change the format of the recording to make it quicktime? [[User:2020|2020]]
;Lackadaisical
:Would it be possible to do the next ladle on a sunday and maybe a bit earlier? Saturday night isn't the best time to go play a computergame for the europeans.

;Meriton
:The time the event takes place (start at 11:30 PM) is a bit tough for me. Might it be possible to indulge us European players and have it take place a couple of hours earlier next time? Personally, I prefer Saturday to Sunday as I have to get up early on Mondays.
----

;Manta
:If we are to drop scheduled games again from not enough teams show, we should move those matches up in time instead of delaying. WS lost half their players do to the time being changed. We do need to work out the scheduling on the wiki better next time as the matches ended up being switched right before game time.

:The procedural changes made since the last ladle really improved things. You did a GREAT job coordinating everything 2020. Thank you! Team coordination seemed to flow very well and having an admin on hand was a big help. The team captains were able to work out any issues and the players were polite to each other. I'd say we all had fun and in the end that is the reason we all showed up. Congratulations to everyone who played!

:And dealing with the ping issue: Over all having a few low ping players on any one team does not make it unfair. It is when 100% of one team's players have 1/3 the ping of the other that attrition will catch up every time. (Not to bring up my 438 ping ;), lol) An average 180s on one side vs 60s on the other can be a bit unbalanced. Similar to a 4 vs 7 player match. To solve this I don't think a single server can be found to please everyone. Germany does have some of the most active players so it would be wrong to say force them to play a US server for example. Perhaps some ideas can be worked out before the next ladle. Playing half the games on one server then switching might cause it's own logistics issues. What are some other peoples ideas?

----

;AshitakA
:I think it was great... And thanks to all players and those, who made this possible.The solution for the high pings would be a server on which every player could play with equal ping. But there is no one. So i think, like you said Manta, the server has to be changed. But in a fair way. Maybe every team has to play on different servers, or every game would be played twice on two different servers. However, i look forward to the coming ladle. Have fun, all!

----
;madmax
:I agree on the scheduling issue. The time, and I think specially the day arent the best. For me, Saturday night is usually for going out. Btw, congrats to AW!!! :D

== Feedback for the First Ladle ==

=== The Quality of Your Playing ===
;2020
:I was a passenger. I moved house, was using an old computer (fps was 15), and my connection got broken 3 times while playing Shadow League in the Semi's -- aaaaarrrrrghghghghgh. Like Van, hehe, and Durka I think.
* Yep me 2---[[User:Durka|Durka]]
*heh ya I wish my connection dropped only 3 times, More like 10-15, there was a storm going on at the time--[[User:Vanhayes|Vanhayes]]

;Manta
:It was a nice surprise that my ISP didn't have their usual holiday weekend hiccups. :) Over all I certainly could have done better, I'm not very good under pressure and my dialup connection seems to get saturated with more than 12 players on the grid. Oh and Manta sucks at sweeping :P

;sky
:well my computer already sucks haha. so i did fine until the AW match. made a lot more mistakes. only in the last AW match i was able to get like 8 or 10 points or somethin. but the other rounds there were less players playing like 7v7s or 6v6s and it was much easier to get through. also my ping was nicer. i want a pc haha. still had a great time though

=== The Quality of Your Team Playing ===
;2020
:Anarchic Wanderers were amazing. I never got to see much of the offence, but defence was superb. Garissimo was solid at the back, only getting beaten when the odds were 4 to 1. I saw Vanhayes pulling off a major stunt -- amazing! And Eggcozy was superb as sweeper. I had fun playing with the offence of the other teams most times; we just kept them back for ages while our offence did the biz. Superb quality of play.
*;[[User:Durka|Durka]]
*:I played for AW in the match against SL. I didn't get to see much of the amazing defense by our team. Everytime I would just bust through their middle and take up part of Sasha's def before he could make it complete. The problem was SL sometimes delayed Zop and the others from getting there soon enough...so I would be cramming part of the zone, but it would sometimes do nothing as we had no one else. SL realized this and Sasha's teammates would try and trap me in their zone. But, sometimes it did work and Zop would get their fast along with one other person and we would capture the zone fast (3 offense vs. 2 defense). It was a great team effort...4 points from winning the second match and 2 from winning the third. Well done SL and CONGRATULATIONS.
*'''sKy'''
:awesome

=== Getting Your Team Ready for The Match ===
;2020
:Damned messy. I couldn't get on the server for about 10 mins. We started about 30 mins late... it gets a little tedious when people are there, some playing, some just waiting for the real game. It would be nice if we could just import an entire team into a server. Have some kind of pre-grid preparation like in the film. Once teams are sorted, we just port into the server. Would be simple. Players would then turn up on time, otherwise, they just miss the boat. Trying to organise a match while playing is tough... too many distractions. Still... we managed it in the end... somehow...

*;[[User:Durka|Durka]]
*:I got to play one round with ¡LØL! because I was late. I showed up and only 2 people that were ACTUALLY on WS were playing. Everyone else was picked up "from the streets." (Example: man2d played with ¡LØL!, (WS), & SL during the tourney...just a little unfair). Also, we really needed 8 teams not 6 (there were 7, but CT didn't show). (Example: the ¡LØL! vs. WS match in the first round was actually a semi-final match so who-ever won was automatically in the finals...yet again weird. But, overall, the tourney was definately fun. Next time 2020, can we please not try and play the tournament '''ALL IN ONE DAY!!!''' Too chaotic!

;Manta
:Getting Wraith Squadron ready for each match was actually quite easy. All our players met in an MSN chat room one hour before the start time and we did all our coordinating from there. This made it very easy for us to all show up on one server at the same time. We then disconnected during game play of course. ---- Since there were ONLY 2 ladle servers and LOL & WS were the last teams paired we were forced to use Bugfarm fortress. This caused quite a bit of confusion with visiting players joining the match. Kindly, most willingly left or stayed as spectators. Also I don't believe man2d played for WS at any time during the tournament as he was on each of the opposing teams we played. Wish we had had him though.

=== Team-Captains and the Challenge Room ===
;2020
:As admin of 2020's T-room it was ok... but a bit stressful. Loads of people, including non-captains and noobs entering. The text area was too small and too many people were talking. Some were asking me to die so that they could join the game -- as if we were meant to be playing! Some of the non-captains were useful since they could leave the T-room and search for players like Xevi for Crazy Tronners, and the state of play in matches.
:Team-captains did the job well though, challenging one another, then setting off to do their matches. However, I think we should have waited until everyone knew who was playing who and where before leaving. The only real way of doing this is building a simple interface with challenge-board, etc so that people could see if they were challenged and whether they accepted etc. Still.. on the whole, it worked.

;Manta
:While using the T-room was problematic it did serve it's purpose well and its probably the only 100% sure way everyone has to communicate. 2020 took down the chat-server while he played which is understandable but we really need one up at all times for team captains to check in on each other while another match may still be ongoing. THANK YOU for all your work 2020, the ladle would not have been the success it was without you!

=== Anything else? ===
;2020
:Could have done with more matches. Also, losing teams could have played one another. In fact, we probably had time to play a round-robin affair. What was best about it is that we ended up with a winner. We trusted team-captains, and they pulled it off.
:My wishlist? Somehow keep teams together, maybe with some kind of pre-grid preparation room like the film. If this runs simultaneously to gameplay, you can be playing around in some server, and then when your team is assembled and ready, you are notified and requested to port to the proper server where your team assembles against the opposing team. Also, some kind of software to automate the challenges. The chat-facility was not good enough... too much noise...
:It is all to do with timing. As a first attempt, I think it was successful. The trick is... how to make it better...

;Manta
:--- Having the ability to lock a server to a certain number of players ahead of time. While letting there be room for a couple of spectators so backup team members can standby but keeping riffraff from joining. --- Letting a small majority successfully kick someone, without having to distract all the players with the vote. --- Have shuffle down AND up enabled to allow team placement. --- Have more servers available. --- Personally I liked the month long idea but I must say having the games all on one day seemed to work better. But this also made it very hectic and with elimination, losing teams only got to play one match after the effort of getting everyone coordinated. --- Over all I'd say the ladle was a great success and everyone had a great time which is most important.

Challenge Board

2006-09-03T19:44:24Z

Meriton:

{{Ladle}}
The Challenge Board is designed to make the pairing off of team easier. Team Captains should take careful note of how to best use this system.

Please note, it is for Team Captains only to issue challenges by locating their [[LADLE team-lists|teams]] appropriately on the board. If they can not do this here, they will have to do it on the day in less than 5 mins, so... be cool and be brave...

Your placement of the team determines who you are playing in the first round and subsequent rounds if you win. If, for example, with only two teams listed, then one team must be listed in team 1-8 and the other in team 9-16. As more teams join, the placement will determine who you will play in subsequent rounds and on which servers. Check this listing ocassionally, alter your team-place if you wish, until it settles and we are ready to play on Sun 3rd September.

Please do not replace another team-name with yours. Only fill vacant spaces. In this way, Team Captains have a way of jockeying for position.

We seem to have five teams, so...

* Team 1 is... [[anarchic wanderers]] team A
* Team 2 is...
* Team 3 is... [[Wraith Squadron]]
* Team 4 is... [[anarchic wanderers]] team B
* Team 5 is... [http://teamlotsoflove.com LOL]
* Team 6 is... [[We Pwn Noobs|WPN]]
* Team 7 is... SL
* Team 8 is... [http://www.crazy-tronners.com CT]

==Possible Brackets?==
[[Ladle Brackets]]

== Provisional Play-offs ==
Do not insert names of teams here. This is merely the structure and timing of the games. The actual teams which will be playing against one another will be based on the Challenge Board above and the Team Captains which register their teams at before the first game on Sun 3rd September.

Note, the server allocation may change, especially as we move through into the quarters and semi finals depending on Team Captain discussion on the day. Check out [[LADLE fortress-servers]] available.

Note also, we might by-pass the first round if we have 8 teams or less... which is what the state of play is currently...

=== Quarter Finals 7.30pm GMT ===
* Team 1 challenges Team 2 on LOD Fortress Server or Z-man's Tournament Fortress
* Team 3 challenges Team 4 on AST or US Fortress Server
* Team 5 challenges Team 6 on Bugfarm LOD Server or Wildwest -- Fortress (ladle)
* Team 7 challenges Team 8 on AST or Dark Syndicates Fortress

=== Semi Finals 8.15pm GMT ===
* Team 1/2 challenges Team 3/4 on LOD Fortress Server
* Team 5/6 challenges Team 7/8 on AST or US Fortress Server

=== Finals 9pm GMT ===
* Team 1/2/3/4 challenges Team 5/6/7/8 on LOD or US Fortress

Lag

2006-09-02T18:38:44Z

Meriton: /* Description of Lag */

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

# the command is transmitted to executing musles
# the musles contract / the key is beeing pressed
# armagetron is busy doing other stuff
# armagetron processes the key press and dispatches the information to the game server
# (network games only) the network forwards the information to the game server
# (network games only) the server processes the key press and dispatches it to all players
# (network games only) the network forwards the message (as in 5)
# the armagetron client updates his view

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

* Stages 1 and 2 takes a predicatable fraction of a second, less with training.
* Stage 3 predictably takes at most 1000 ms / [[fps]].
* Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
* The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
* Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
* Stage 8 predictably takes at most 1000 ms / [[fps]].

== Network Lag ==

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Avoiding - 6 pigs, 7 nipples! ===

Buy a better internet connection and/or keep your other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

=== Reason ===
==== Light Speed Now, Mr. Scott ====

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

==== Hops, not beer ====

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Lag

2006-09-02T10:19:12Z

Meriton: reorganized stuff

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

# the command is transmitted to executing musles
# the musles contract / the key is beeing pressed
# armagetron is busy doing other stuff
# armagetron processes the key press and dispatches the information to the game server
# (network games only) the network forwards the information to the game server
# (network games only) the server processes the key press and dispatches it to all players
# (network games only) the network forwards the message (as in 5)
# the armagetron client updates his view

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

* Stages 1 and 2 takes a predicatable fraction of a second, less with training.
* Stage 3 predictably takes at most 1000 ms / fps.
* Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
* The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
* Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
* Stage 8 predictably takes at most 1000 ms / fps.

== Network Lag ==

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Avoiding - 6 pigs, 7 nipples! ===

Buy a better internet connection and/or keep your other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

=== Reason ===
==== Light Speed Now, Mr. Scott ====

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

==== Hops, not beer ====

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Lag

2006-09-02T09:57:08Z

Meriton: /* Reflexes */

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

# the command is transmitted to executing musles
# the musles contract / the key is beeing pressed
# armagetron is busy doing other stuff
# armagetron processes the key press and dispatches the information to the game server
# (network games only) the network forwards the information to the game server
# (network games only) the server processes the key press and dispatches it to all players
# (network games only) the network forwards the message (as in 5)
# the armagetron client updates his view

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

* Stages 1 and 2 takes a predicatable fraction of a second, less with training.
* Stage 3 predictably takes at most 1000 ms / fps.
* Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
* The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
* Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
* Stage 8 predictably takes at most 1000 ms / fps.

=== Network Lag ===

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Reason for Network Lag ===
==== Light Speed Now, Mr. Scott ====

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

==== Hops, not beer ====

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== 6 pigs, 7 nipples! ==

You can also improve your lag by keeping other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Lag

2006-09-02T09:56:09Z

Meriton: /* Measuring Latency */

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

# the command is transmitted to executing musles
# the musles contract / the key is beeing pressed
# armagetron is busy doing other stuff
# armagetron processes the key press and dispatches the information to the game server
# (network games only) the network forwards the information to the game server
# (network games only) the server processes the key press and dispatches it to all players
# (network games only) the network forwards the message (as in 5)
# the armagetron client updates his view

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

* Stages 1 and 2 takes a predicatable fraction of a second, less with training.
* Stage 3 predictably takes at most 1000 ms / fps.
* Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
* The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
* Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
* Stage 8 predictably takes at most 1000 ms / fps.

=== Network Lag ===

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Reason for Network Lag ===
==== Light Speed Now, Mr. Scott ====

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

==== Hops, not beer ====

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

== Reflexes ==

Now that you understand network latency, you should be able to make the jump to understand latency in your body's nervous system. When your eyes process the image you see on the screen, they send a signal to your brain. Your brain makes a decision on what to do, and then sends a signal down your arm or whatever to push whatever button it's decided to push. We generally call this ''finger lag'', although there's certainly no requirement that fingers be involved. Neuropsychologists have measured the time it takes for a signal to leave your brain and arrive at its destination along many paths, if you find this topic interesting you should certainly investigate it further.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== 6 pigs, 7 nipples! ==

You can also improve your lag by keeping other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Lag

2006-09-02T09:53:19Z

Meriton: /* Description of Lag */

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

# the command is transmitted to executing musles
# the musles contract / the key is beeing pressed
# armagetron is busy doing other stuff
# armagetron processes the key press and dispatches the information to the game server
# (network games only) the network forwards the information to the game server
# (network games only) the server processes the key press and dispatches it to all players
# (network games only) the network forwards the message (as in 5)
# the armagetron client updates his view

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

* Stages 1 and 2 takes a predicatable fraction of a second, less with training.
* Stage 3 predictably takes at most 1000 ms / fps.
* Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
* The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
* Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
* Stage 8 predictably takes at most 1000 ms / fps.

=== Network Lag ===

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Reason for Network Lag ===
==== Light Speed Now, Mr. Scott ====

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

==== Hops, not beer ====

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

=== Measuring Latency ===

We refer to the time it takes for a signal on the network to leave its starting point, reach its destination, and have a response sent back as ''network latency''. Network latency is one type of lag, it's the parent type. It is the thing from which all lag is inherited. It's the Sun Source Of Lag. And it's measured in milliseconds, typically.

Armagetron Advanced gives you a number, called ''ping'', which is measured in milliseconds. That number represents the amount of time it takes a signal from you to reach the game server and be processed on the game server, and then sent back. The game takes regular measurements along the way and always tells you your most up-to-date ping.

== Reflexes ==

Now that you understand network latency, you should be able to make the jump to understand latency in your body's nervous system. When your eyes process the image you see on the screen, they send a signal to your brain. Your brain makes a decision on what to do, and then sends a signal down your arm or whatever to push whatever button it's decided to push. We generally call this ''finger lag'', although there's certainly no requirement that fingers be involved. Neuropsychologists have measured the time it takes for a signal to leave your brain and arrive at its destination along many paths, if you find this topic interesting you should certainly investigate it further.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== 6 pigs, 7 nipples! ==

You can also improve your lag by keeping other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Lag

2006-09-02T09:45:12Z

Meriton: /* Hops, not beer */

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

1 the command is transmitted to executing musles (couple of milliseconds)
2 the musles contract / the key is beeing pressed (couple of milliseconds)
3 armagetron is busy doing other stuff (depending on your machine, between 0 and 1000 ms / fps)
4 armagetron processes the key press and dispatches the information to the game server (couple of microseconds)

network games only:
5 the network forwards the information to the game server (depending on the quality of connection. An average value is given by our ping / 2)
6 the server processes the key press and dispatches it to all players (couple of microseconds, unless it is busy doing something else)
7 the network forwards the message (as in 5)

8 the armagetron client updates his view (between 0 and 1000 ms / fps)

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

Stages 1 and 2 takes a predicatable fraction of a second, less with training.
Stage 3 predictably takes at most 1000 ms / fps.
Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
Stage 8 takes at most 1000 ms / fps.

=== Network Lag ===

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Reason for Network Lag ===
==== Light Speed Now, Mr. Scott ====

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

==== Hops, not beer ====

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

=== Measuring Latency ===

We refer to the time it takes for a signal on the network to leave its starting point, reach its destination, and have a response sent back as ''network latency''. Network latency is one type of lag, it's the parent type. It is the thing from which all lag is inherited. It's the Sun Source Of Lag. And it's measured in milliseconds, typically.

Armagetron Advanced gives you a number, called ''ping'', which is measured in milliseconds. That number represents the amount of time it takes a signal from you to reach the game server and be processed on the game server, and then sent back. The game takes regular measurements along the way and always tells you your most up-to-date ping.

== Reflexes ==

Now that you understand network latency, you should be able to make the jump to understand latency in your body's nervous system. When your eyes process the image you see on the screen, they send a signal to your brain. Your brain makes a decision on what to do, and then sends a signal down your arm or whatever to push whatever button it's decided to push. We generally call this ''finger lag'', although there's certainly no requirement that fingers be involved. Neuropsychologists have measured the time it takes for a signal to leave your brain and arrive at its destination along many paths, if you find this topic interesting you should certainly investigate it further.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== 6 pigs, 7 nipples! ==

You can also improve your lag by keeping other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Lag

2006-09-02T09:44:55Z

Meriton: /* Reason for Network Lag - Light Speed Now, Mr. Scott */

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

1 the command is transmitted to executing musles (couple of milliseconds)
2 the musles contract / the key is beeing pressed (couple of milliseconds)
3 armagetron is busy doing other stuff (depending on your machine, between 0 and 1000 ms / fps)
4 armagetron processes the key press and dispatches the information to the game server (couple of microseconds)

network games only:
5 the network forwards the information to the game server (depending on the quality of connection. An average value is given by our ping / 2)
6 the server processes the key press and dispatches it to all players (couple of microseconds, unless it is busy doing something else)
7 the network forwards the message (as in 5)

8 the armagetron client updates his view (between 0 and 1000 ms / fps)

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

Stages 1 and 2 takes a predicatable fraction of a second, less with training.
Stage 3 predictably takes at most 1000 ms / fps.
Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
Stage 8 takes at most 1000 ms / fps.

=== Network Lag ===

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Reason for Network Lag ===
==== Light Speed Now, Mr. Scott ====

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

=== Hops, not beer ===

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

=== Measuring Latency ===

We refer to the time it takes for a signal on the network to leave its starting point, reach its destination, and have a response sent back as ''network latency''. Network latency is one type of lag, it's the parent type. It is the thing from which all lag is inherited. It's the Sun Source Of Lag. And it's measured in milliseconds, typically.

Armagetron Advanced gives you a number, called ''ping'', which is measured in milliseconds. That number represents the amount of time it takes a signal from you to reach the game server and be processed on the game server, and then sent back. The game takes regular measurements along the way and always tells you your most up-to-date ping.

== Reflexes ==

Now that you understand network latency, you should be able to make the jump to understand latency in your body's nervous system. When your eyes process the image you see on the screen, they send a signal to your brain. Your brain makes a decision on what to do, and then sends a signal down your arm or whatever to push whatever button it's decided to push. We generally call this ''finger lag'', although there's certainly no requirement that fingers be involved. Neuropsychologists have measured the time it takes for a signal to leave your brain and arrive at its destination along many paths, if you find this topic interesting you should certainly investigate it further.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== 6 pigs, 7 nipples! ==

You can also improve your lag by keeping other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Lag

2006-09-02T09:39:23Z

Meriton: added definition of lag, enumeration of possible causes and distinction between constant and non-constant lag

Have you wondered why sometimes you think you dumped the other guy only to find that your dumped yourself? Does it ever feel like the things you do don't happen quite the same way to everyone on the grid? There's a reason for that, and the reason is called ''lag''.

== Description of Lag ==
Ideally, the game would respond the very instant you or someone else hit a steering key. However, the underlying hardware is not capable of truly instantanious response, and therefore, neither is armagetron. This difference is called Lag.

When you decide to hit a key, the following stages are passed:

1 the command is transmitted to executing musles (couple of milliseconds)
2 the musles contract / the key is beeing pressed (couple of milliseconds)
3 armagetron is busy doing other stuff (depending on your machine, between 0 and 1000 ms / fps)
4 armagetron processes the key press and dispatches the information to the game server (couple of microseconds)

network games only:
5 the network forwards the information to the game server (depending on the quality of connection. An average value is given by our ping / 2)
6 the server processes the key press and dispatches it to all players (couple of microseconds, unless it is busy doing something else)
7 the network forwards the message (as in 5)

8 the armagetron client updates his view (between 0 and 1000 ms / fps)

Every step along the way causes a certain delay. If this delay is constant, its effect can be mitigated by hitting the key earlier. If the delay is different every time though, this is not possible.

The delay introduced by the individual stages can be approximated as follows:

Stages 1 and 2 takes a predicatable fraction of a second, less with training.
Stage 3 predictably takes at most 1000 ms / fps.
Stage 4 predictably takes a couple of microseconds unless the client's computer is very busy otherwise (such a case has never been reported)
The sum of the delay in stages 5 and 7 is called network lag. It is determined by the quality of the network connection between client and server, in case of the internet the chief influences are the client's and the server's connection to the internet, as well as the geographical distance between client and server. The sum of the average network delay is called ping and displayed on the score board. For a good connection, the delay is about constant, for a bad connection the delay may vary wildly (it is entirely possible for a message to take 3 times as long to deliver as the previous one). Since usually this is the primary source of lag, we describe it in more detail below.
Stage 6 is negligible unless the machine running the server is otherwise occupied at the time the message arrives.
Stage 8 takes at most 1000 ms / fps.

=== Network Lag ===

Armagetron provides two facilities to assist players in coping with constant network lag: Prediction and the lag-o-meter. Prediction displays other cycles at where the are predicted to currently be on the server assuming they did not turn in the meantime. As a result, cycles jump on the client's display on a turn (because the client guessed wrong). If prediction is disabled, cycles are displayed on the last position confirmed by the server, i.e. they are really no longer there, but the client does not know yet where they are. The lag-o-meter highlights the area where the cycle could presently be. Prediction and the lag-o-meter can be enabled/disabled in game->network game->network setup.

Due to its non-predictable nature, armagetron can not cope well with non-constant network lag. Non-constant network delay is caused by heavy use of any link in the network connection. Therefore, a substantial proportion of the link should be idle. Non-constant network lag manifests in retroactive display updates on the client, i.e. other cycles jumping outside of their lag-o-meter or your own cycle's recent turn point beeing moved. It may also cause lag-o-meter to suddely grow or shrink.

=== Reason for Network Lag - Light Speed Now, Mr. Scott ===

As you've probably learned at one time or another, electrical signals travel at a speed very close to the speed of light. Consider that it takes 8 minutes (approximately) for light from the Sun to reach the Earth, if you were to stretch a copper wire from the Earth to the Sun, it would take approximately 8 minutes for an electrical pulse to travel that distance. So electrical signals don't travel instantaneously, they merely travel so fast that the conscious brain perceives it as instantaneous. So, to start with, every time you press a button on your computer, the electrical pulse associated with that button press has to travel some distance from the button itself to a location in the computer, and then be sent out over the wire to the game server.

=== Hops, not beer ===

The signal's first hop is the game itself. Of course, that doesn't mean anything unless you know what a hop is. A hop is considered a point along the path where the signal has to be processed and understood, at least in part, to determine where it's going to go next. So the first hop is your computer. The keypress has to be sent up from the hardware to your operating system's kernel, which then has to send it to the program that wants it, in this case the game client. The game client does some processing on it (did he turn? Did he want to say something?), and then sends it's action down through the kernel to the network interface.

Follow? This is not an instantaneous thing! It is very very '''very''' fast, but it's not instantaneous.

The next hop is probably your router, if you have one. If you're on a high speed network, you have one. It may be called a "dsl modem", "dsl router", "cable modem", or whatever, but it's still a router. It processes the signal to some extent, enough to figure out where to send it. Then it sends it. If you're running a local network attached to a cable ISP (a very common setup among players), then your first router sends it to the second router. So now you've had 3 hops and the signal hasn't even left the house yet!

Then your ISP's router will pick it up, process it again, and determine where to send the signal. Then their wholesale provider picks it up, and so on and so forth. The signal will reach a point we generally consider the midpoint, although that's a bit of a misnomer, called the backbone. This is the highest-speed and highest-traffic part of the internet. It is the backbone of the internet! From there the signal goes through another series of hops to get to the game server's house.

From there, it usually goes first through a high speed connection device, such as a dsl router or somesuch, and then goes to a regular router used in homes to setup home networks, and finally arrives at the game server. Now what? Well, now the game server processes your turn, usually some fraction of a second ''after'' you originally pressed the button to indicate your turn. Is it done?

No, it has to send a signal back to your client when it marked the turn.

=== Measuring Latency ===

We refer to the time it takes for a signal on the network to leave its starting point, reach its destination, and have a response sent back as ''network latency''. Network latency is one type of lag, it's the parent type. It is the thing from which all lag is inherited. It's the Sun Source Of Lag. And it's measured in milliseconds, typically.

Armagetron Advanced gives you a number, called ''ping'', which is measured in milliseconds. That number represents the amount of time it takes a signal from you to reach the game server and be processed on the game server, and then sent back. The game takes regular measurements along the way and always tells you your most up-to-date ping.

== Reflexes ==

Now that you understand network latency, you should be able to make the jump to understand latency in your body's nervous system. When your eyes process the image you see on the screen, they send a signal to your brain. Your brain makes a decision on what to do, and then sends a signal down your arm or whatever to push whatever button it's decided to push. We generally call this ''finger lag'', although there's certainly no requirement that fingers be involved. Neuropsychologists have measured the time it takes for a signal to leave your brain and arrive at its destination along many paths, if you find this topic interesting you should certainly investigate it further.

== Bugs in the game? ==

Bugs in the game are usually blamed for lag. In fact, you can tell who's at least new and/or who doesn't know jack about computers by how much they blame the game for the inaccuracies they see on the screen. The simple fact is, Armagetron Advanced has a very solid network system that is relatively bug-free. I'm not going to pretend it's perfect, but it's definitely good enough that if you suspect a bug and you didn't write the network code yourself, then you're probably wrong. I'm not saying you are wrong, just that you're probably wrong. I'd bet money that the lag you're experiencing and blaming the game for comes from somewhere else.

An associated comment usually comes along the lines of "but there has to be something in the game that can be done to compensate for it." This statement frequently accompanies a list of other games where lag isn't as big of a problem.

=== Z-man's take ===

I'd like to add that the prime reason you feel more lag in AA than in, say, Counter Strike, is the difference in the game dynamics. In shooters, moving (thus defending by taking cover) and attacking (pointing your mouse and shooting) are independent actions. Taking a hit does not influence your movement immediately (it does later if you get wounded, or immediately if your pushed away by an explosion). Thus, it its possible to treat attack and defense separately in the network code and hide the lag. When you shoot at someone, you can shoot at the position you see him now, and even though your enemy really has moved away already, you'll still hit him because the server can compensate.

In AA, attacking is moving. Defending is moving. Getting hit has an immediate and strong impact on your movement. It's not possible to divide the different aspects of movement in the network code. (Well, it is, but the result would be that it would be impossible to survive close combat for both participants) In this sense, AA is a sports game, a beat em up to be precise. And you don't see them played over the net a lot precisely because they're heavily affected by network latencies (and because it's that much more fun if you're playing against someone in the same room).

=== Z-man's take (part 2) ===

There are several causes of lag.

You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cycle is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. If any/all of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen with possible crashes.

*'''(1)''' Maybe the reason is a network problem, packets from the server to your client getting lost or delayed.
*'''(2)''' Maybe it is a bug in your client that causes the extrapolation to be wrong or it may just a regular gameplay thing.
*'''(3)''' Maybe you've been riding within the laggometer of another player, and that player turned and threw a wall your way.

(note)Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.

So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server.

*'''(4)''' Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so.
*'''(5)''' If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extrapolation, which brings us back to (1).

(note)The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client.

*'''(6)''' (almost the same as 1) Those updates can again be lost or delayed, making the cycles go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update
*'''(7)''' (almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution
*'''(8)''' (almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.

*'''(9)''' There is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.

*'''(10)''' GPU lag, when your graphics card is lagging behind the rendering commands sent to it; This should only happen if you modify the "Swap Mode" default in the performance tweaks section. ''[Finish is pretty much a guarantee of no trouble, flush should work, and fastest is not guaranteed to do anything. The swap function the current SDL uses on Mac OS X does a flush all by itself, so on that platform fastest is flush, flush is double flush, and finish is finish followed by flush. The performance impact of a redundant flush in this sense is negligible, however. —[[User:Jonathan|Jonathan]]<nowiki>]</nowiki>''
*'''(11+12)''' timer lag on the server or client, when the timer is somehow behaving wrongly; since the timer is essential for everything, bad things happen then. The two worst cases not caused by code bugs seen so far were a 5% accelerated clock rate on a client because the MB was overclocked, and timer jumps due to occasional clock syncs on Bugfarm.
*'''(13+14)''' CPU lag on server and client, when the processor is not strong enough to simulate the game and your commands get delayed because of that.

== 6 pigs, 7 nipples! ==

You can also improve your lag by keeping other network usage down. When you see someone's ping fluctuating in the game, it's usually a safe bet that they have a really large download going on somewhere, KaZaA or some other large downloading program. Web browsing while playing the game will create more lag for you, which will in turn get pushed out to other players. You have a limited amount of bandwidth available on your internet connection, and the game server has a limited amount of bandwidth available on its connection. Some server admins will limit the number of players on their server to address this issue, but it's still not complete. You have to behave yourself and keep your bandwidth usage low.

A corollary to this is when the game server in particular is sharing a connection with other servers. For example, the Crack Pipe runs on a server that is also a web server, mail server, cvs server, and a few other things. On top of that, it's used as an alarm clock, and as a regular desktop computer. So it's using a fair amount of bandwidth just running, which gets pushed out to game clients. But also under the heading of limited resources vs amount of demand, the Crack Pipe only has a 900mhz AMD Duron processor and 256MB RAM. That's not really a lot of system resources for the amount of work it does. So occasionally spam will be sent to the machine and it will have to spend some of its precious CPU time receiving the spam. In the meantime, game clients suffer a little bit. Some players have gotten to where they can identify how much spam the mail server receives while playing the game.

== What can be done about lag? ==

''Lucifer sez''

Fix the internet.

As flippant as that is, it is the source of lag. We've experimented (we as in "server admins") with a number of solutions over the last year or so (and I assume it was happening earlier) and here's what we've found, near as I can tell.

If the machine is dedicated to the armagetron server, it will have less lag. Even my server has some interesting lag effects whenever it receives mail (it's a mail server too), and that's with the armagetronad process reniced to a low level (-15 I think it is).

If the machine is on a slow processor with a small cache, it will have more lag. This effect is amplified if the machine is not dedicated to the game and/or if you run more than one game server.

Lag is reduced by parallel processing on the server, so if you have a fancy Xenon processor or a dual proc setup you can have less lag.

Lag is reduced by running a 2.6 Linux kernel over *any* other kernel (Windows, Linux 2.4, I dont' know that any others have been tested in this way). It can probably be reduced even further by applying the low-latency patches, but since those are mostly used for audio work I don't know how well they'd work here.

The closer the server is to the backbone, the less lag. The closer the client is to the backbone, the less lag the client has. (I'm pretty far from it, hence the high pings on teh Crack Pipe, but they do look better than they used to be)

After you've done all of this, the lag will be noticeably less, but there will still be numerous complaints. This is because the internet itself is the source of all lag. So all of these measures only decrease the roundtrip time for a packet that has already crossed the internet and reached the machine.

There have been a number of improvements in this area. 0.2.7.1 had simulation improvements, and also an improvement where the server can be anchored to a certian number of simulation steps per minute. So that's why 0.2.7.1 servers have more predictable lag than older servers, and when everyone is connected with newer clients, you can really see the difference. 0.2.8_beta2 has a major network refactoring that also seems to reduce lag, even though it may not be noticeable in your ping. I don't know that it would be noticeable in your ping, and since there aren't yet that many servers running the new betas the only measure I have is my own, which has less lag than the older version.

The only improvements I can think of would be to optimize code here and there, and I don't even know which code needs to be optimized. I know that periodically some one or more developers profile various pieces of code and that there has been optimizing. I also know that most of the developers around here think about performance while coding. ANd I also know that there is code that is not well optimized (although I can't point to any specific line, if I could do that, I could optimize it, right?).

So let's assign a value, C, which represents how much work is required to thoroughly optimize the code and reduce latency to bare minimum while retaining reliability and accuracy. Now let's assign a value, T, which represents how much time the entire development team has to dedicate to exactly that. Let's assign one more variable that represents how long before really fast internet arrives in everyone's houses (faster than even broadband now) and includes faster processors, faster network cards, and generally very low latency on the hardware end. We'll call this one H, for "toy".

C / T > H

== Brain Lag ==

It's worth pointing out that there is also lag in your body. Psychologists have even measured it. It's the same basic problem as network latency, but it's worth considering. Your eyes see what's on the screen, but it takes some milliseconds for the signal to be processed in your brain. Then it takes some milliseconds for you to determine a reaction and act on it, and then it takes some milliseconds for the signal from your brain to travel to your fingers and make something happen. Because of the visual nature of the game, you can't take advantage of certain reflexive systems, but through training your fingers you can reduce the amount of nerve bandwidth needed to command your light cycle.

When I took my Intro to Psychology class, my teacher didn't have any actual numbers, it would be awfully nice of someone were to google them up. Nevertheless, brain lag is real, and it really affects the game. It's not as noticeable as network latency, but when you add the two together you get some interesting results. --Lucifer

[[Category:Game Concepts]]

Ladle Feedback

2006-07-30T00:58:55Z

Meriton: /* Feedback for the Second Ladle */

{{Ladle}}

Please write your comments below about your experience of the event. You can also add comments about how it could be better... This information may be useful for anyone who tries to do such a thing again...

== Feedback for the Second Ladle ==

;2020
:Ping was a big determiner in who won the matches. Ideas suggested during the game was to split the final between two servers. Also, the captains did not make use of the challenge room in the wiki. It was all just organised before the matches, which was ok because we only have four teams of about five players each. The idea is for the system to be future-proof, scalable to hundreds if not thousands of team... I can't see this working that well with more than four teams. I think team captains should take a little more responsibillity for making sure they choose a server that suits their players. And of course, it is the responsibility of the players to turn up! Oh well... Also... it would be nice to have little animations of the highlight, specific moves, climax battles, that kind of thing... can I change the format of the recording to make it quicktime? [[User:2020|2020]]
;Lackadaisical
:Would it be possible to do the next ladle on a sunday and maybe a bit earlier? Saturday night isn't the best time to go play a computergame for the europeans.

;Meriton
:The time the event takes place (start at 11:30 PM) is a bit tough for me. Might it be possible to indulge us European players and have it take place a couple of hours earlier next time? Personally, I prefer Saturday to Sunday as I have to get up early on Mondays.
----

;Manta
:If we are to drop scheduled games again from not enough teams show, we should move those matches up in time instead of delaying. WS lost half their players do to the time being changed. We do need to work out the scheduling on the wiki better next time as the matches ended up being switched right before game time.

:The procedural changes made since the last ladle really improved things. You did a GREAT job coordinating everything 2020. Thank you! Team coordination seemed to flow very well and having an admin on hand was a big help. The team captains were able to work out any issues and the players were polite to each other. I'd say we all had fun and in the end that is the reason we all showed up. Congratulations to everyone who played!

:And dealing with the ping issue: Over all having a few low ping players on any one team does not make it unfair. It is when 100% of one team's players have 1/3 the ping of the other that attrition will catch up every time. (Not to bring up my 438 ping ;), lol) An average 180s on one side vs 60s on the other can be a bit unbalanced. Similar to a 4 vs 7 player match. To solve this I don't think a single server can be found to please everyone. Germany does have some of the most active players so it would be wrong to say force them to play a US server for example. Perhaps some ideas can be worked out before the next ladle. Playing half the games on one server then switching might cause it's own logistics issues. What are some other peoples ideas?

----

== Feedback for the First Ladle ==

=== The Quality of Your Playing ===
;2020
:I was a passenger. I moved house, was using an old computer (fps was 15), and my connection got broken 3 times while playing Shadow League in the Semi's -- aaaaarrrrrghghghghgh. Like Van, hehe, and Durka I think.
* Yep me 2---[[User:Durka|Durka]]
*heh ya I wish my connection dropped only 3 times, More like 10-15, there was a storm going on at the time--[[User:Vanhayes|Vanhayes]]

;Manta
:It was a nice surprise that my ISP didn't have their usual holiday weekend hiccups. :) Over all I certainly could have done better, I'm not very good under pressure and my dialup connection seems to get saturated with more than 12 players on the grid. Oh and Manta sucks at sweeping :P

;sky
:well my computer already sucks haha. so i did fine until the AW match. made a lot more mistakes. only in the last AW match i was able to get like 8 or 10 points or somethin. but the other rounds there were less players playing like 7v7s or 6v6s and it was much easier to get through. also my ping was nicer. i want a pc haha. still had a great time though

=== The Quality of Your Team Playing ===
;2020
:Anarchic Wanderers were amazing. I never got to see much of the offence, but defence was superb. Garissimo was solid at the back, only getting beaten when the odds were 4 to 1. I saw Vanhayes pulling off a major stunt -- amazing! And Eggcozy was superb as sweeper. I had fun playing with the offence of the other teams most times; we just kept them back for ages while our offence did the biz. Superb quality of play.
*;[[User:Durka|Durka]]
*:I played for AW in the match against SL. I didn't get to see much of the amazing defense by our team. Everytime I would just bust through their middle and take up part of Sasha's def before he could make it complete. The problem was SL sometimes delayed Zop and the others from getting there soon enough...so I would be cramming part of the zone, but it would sometimes do nothing as we had no one else. SL realized this and Sasha's teammates would try and trap me in their zone. But, sometimes it did work and Zop would get their fast along with one other person and we would capture the zone fast (3 offense vs. 2 defense). It was a great team effort...4 points from winning the second match and 2 from winning the third. Well done SL and CONGRATULATIONS.
*'''sKy'''
:awesome

=== Getting Your Team Ready for The Match ===
;2020
:Damned messy. I couldn't get on the server for about 10 mins. We started about 30 mins late... it gets a little tedious when people are there, some playing, some just waiting for the real game. It would be nice if we could just import an entire team into a server. Have some kind of pre-grid preparation like in the film. Once teams are sorted, we just port into the server. Would be simple. Players would then turn up on time, otherwise, they just miss the boat. Trying to organise a match while playing is tough... too many distractions. Still... we managed it in the end... somehow...

*;[[User:Durka|Durka]]
*:I got to play one round with ¡LØL! because I was late. I showed up and only 2 people that were ACTUALLY on WS were playing. Everyone else was picked up "from the streets." (Example: man2d played with ¡LØL!, (WS), & SL during the tourney...just a little unfair). Also, we really needed 8 teams not 6 (there were 7, but CT didn't show). (Example: the ¡LØL! vs. WS match in the first round was actually a semi-final match so who-ever won was automatically in the finals...yet again weird. But, overall, the tourney was definately fun. Next time 2020, can we please not try and play the tournament '''ALL IN ONE DAY!!!''' Too chaotic!

;Manta
:Getting Wraith Squadron ready for each match was actually quite easy. All our players met in an MSN chat room one hour before the start time and we did all our coordinating from there. This made it very easy for us to all show up on one server at the same time. We then disconnected during game play of course. ---- Since there were ONLY 2 ladle servers and LOL & WS were the last teams paired we were forced to use Bugfarm fortress. This caused quite a bit of confusion with visiting players joining the match. Kindly, most willingly left or stayed as spectators. Also I don't believe man2d played for WS at any time during the tournament as he was on each of the opposing teams we played. Wish we had had him though.

=== Team-Captains and the Challenge Room ===
;2020
:As admin of 2020's T-room it was ok... but a bit stressful. Loads of people, including non-captains and noobs entering. The text area was too small and too many people were talking. Some were asking me to die so that they could join the game -- as if we were meant to be playing! Some of the non-captains were useful since they could leave the T-room and search for players like Xevi for Crazy Tronners, and the state of play in matches.
:Team-captains did the job well though, challenging one another, then setting off to do their matches. However, I think we should have waited until everyone knew who was playing who and where before leaving. The only real way of doing this is building a simple interface with challenge-board, etc so that people could see if they were challenged and whether they accepted etc. Still.. on the whole, it worked.

;Manta
:While using the T-room was problematic it did serve it's purpose well and its probably the only 100% sure way everyone has to communicate. 2020 took down the chat-server while he played which is understandable but we really need one up at all times for team captains to check in on each other while another match may still be ongoing. THANK YOU for all your work 2020, the ladle would not have been the success it was without you!

=== Anything else? ===
;2020
:Could have done with more matches. Also, losing teams could have played one another. In fact, we probably had time to play a round-robin affair. What was best about it is that we ended up with a winner. We trusted team-captains, and they pulled it off.
:My wishlist? Somehow keep teams together, maybe with some kind of pre-grid preparation room like the film. If this runs simultaneously to gameplay, you can be playing around in some server, and then when your team is assembled and ready, you are notified and requested to port to the proper server where your team assembles against the opposing team. Also, some kind of software to automate the challenges. The chat-facility was not good enough... too much noise...
:It is all to do with timing. As a first attempt, I think it was successful. The trick is... how to make it better...

;Manta
:--- Having the ability to lock a server to a certain number of players ahead of time. While letting there be room for a couple of spectators so backup team members can standby but keeping riffraff from joining. --- Letting a small majority successfully kick someone, without having to distract all the players with the vote. --- Have shuffle down AND up enabled to allow team placement. --- Have more servers available. --- Personally I liked the month long idea but I must say having the games all on one day seemed to work better. But this also made it very hectic and with elimination, losing teams only got to play one match after the effort of getting everyone coordinated. --- Over all I'd say the ladle was a great success and everyone had a great time which is most important.

Ladle Winners

2006-07-02T12:56:30Z

Meriton: /* Congratulations to the Winners! */

{{Ladle}}
The Ladle played between within three hours on 1st July 2006 was... Shadow League!

== Congratulations to the Winners! ==

'''They beat Wraith Squadron in straight matches (2-0) in the final.'''

'''They beat Anarchic Wanderers in a nail-biting climax after going down in the first match (2-1) in the semi-finals.'''
*It was a close game. A very close game. Garrisimo was playing like a man on fire, but this still didn't prevent Shadow League from taking our zone once too often. They came back from first match loss, and in the third match, they came from behind to reach a nail-biting 98-98... well done! I played like a noob, and the rest of my team carried me. Next time... Shadow League... next time.... [[User:2020|2020]] 2nd July 2006

* In the first match, zop (who was playing for AW) was doing his usual speed-grinding thing towards or right side and by sheer bad luck, in the confusion of everyone shuffling around, our second (Ossi) and third defender (meriton) were both starting on the left side, whereas our goalie (Sasha) started on the right (IIRC), but due to sealing the center lane ended up on the left as well. To make matters worse, the other players on the right side did not realize they had no defender on their side or simply could not handle zop's speed grind: They grinded until the last moment, only to be surrounded by the speed-grinding zop, who then directly proceeded to insert himself (and a few friends of his ;) in our zone. Until we finally realised what went wrong, the match was nearly over, with us very much behind. I then shuffled over to the right and - by virtue of splitting real early - managed to delay zop until sasha had had a chance to setup. From then on, the teams were very evenly matched, but with the lead AW had gained, the first match went to them. The second match saw some very close fighting among great players, I don't recall much except - for the first time I can recall - feeling dwarfed by the great skill surrounding me. Both teams fought well, and as the last round arrived, it became clear that whoever won this round would win the match (both teams were slightly above 90 points IIRC). Luckily for SL, they made it, avoiding to drop out of the tournament by a very narrow margin. The third and final match started with a few rounds going to AW, and again every outcome was possible. After fierce fighting on both sides, both team got more than 90 points at the beginning of the last round (IIRC, it was 96 : 94 for AW). After some minutes, it was 98:96 for AW, and AW began to hunt our weaker players. In doing so, they left their goalie (garisimo) alone, and I was able to slip through to him. I used a standard speed attack, and trying not to leave me any space while still hiding behind his wall, garisimo tripped over his tail, and I was able get inside and claim the zone. At about the same time, one of our attackers got one of his pursuers, so the final score was 110:98 for SL.

:On our side, I could chiefly assess the performance of our defense team, were Sasha was a class of his own. Surrounded by 3 players, among which zop and lacka, he managed to hold them off for minutes, never leaving a gap, reclaiming all reachable space, and frequently killing them with his wall's edges. I was also able to assess the performance of AW's attack, which was humbling in its skill and coordination. Especially zop, who was chiefly responsible for AW's victory in the first match and AW's near victory in the second match, but also lacka and the others who provided who got there slower, but were no less effective once they were close. Never on the grid have I seen such skill, determination, and cooperation, and I can say that it would have been no shame at all to have to have lost that game to AW. [[User:Meriton|Meriton]] 14:54, 2 July 2006 (CEST)

'''They beat Lords of Destruction in straight matches (2-0) in the quarter finals.'''

.:thankyou. we played our best and i think the others would agree, AW gave us all a '''very''' difficult and stressful match. although we were missing belenus infamous and maverik. meriton and road came on the spot. and badzilla played very well in the AW match. sasha played very nice defense and Ossi played good as sweeper. Mayday and Man2d came in the finals and also played very nicely. and then Choco sub'd in for sasha later that match. thankyou meriton, badzilla, ossi, may.day, man2d, road, sasha, choc, and nazgul for coming to the events. this also goes to show you that there are plenty of nonclan players who know their stuff. To the teams that we did not play: if you guys would like to play us to see how u fare. find me in the games and we'll try to work something out. and thanks 2020 and the others for organizing this tournament. it was a lot of fun:. -SL(sKy)

== The Full Results ==
Please write as much info as you know and any game comments you wish to add...

=== Quarter-finals ===
'''Anarchic Wanderers v Speeders at Z-man's Ladle (2-0)'''

The Anarchic Wanderers were Zop, Eggcozy, Nii, Garissimo, Hayline, Vanhayes, Lackadaisical and 2020.

The Speeders were Psyko, What-up, Speed, Xell, Blackfang, Joda.bot, Oblivion, and Kenny.

* Tough game, and I think we caught them cold. With the best of 3, there is not much room for mistakes. Zop I think played well, and somehow he and my team-mates managed to penetrate Psyko's defence. The midfield was amazing. The skill level high. As part of the defence, it was amazing playing with Eggcozy and Vanhayes... and with Garissimo at the back doing his contracting and expanding, we kept them back for ages giving our offence time to do their magic. I was surprised how fast it went. [[User:2020|2020]] 2nd July 2006

'''Wraith Squadron v LOL at Bugfarm Fortress (2-1)'''

Wraith Squadron were ....

LOL were...

'''Lords of Destruction v Shadow League at LoD Lords of Destruction Clanserver (0-2)'''

The Lords of Destruction were...

The Shadow League were...

'''Crazy Tronners were not represented so they got into the next round...'''

=== Semi-finals ===

'''Anarchic Wanderers v Shadow League at Z-man's Ladle (1-2)'''

The Anarchic Wanderers were Zop, Vanhayes, Garissimo, Eggcozy, Haylin, Lackadaisical, 2020, and Durka.

The Shadow League were Road66, Sky, Ossi, Man2d, Meriton, Badzilla, Mayday, and Sasha.

*(see Congratulations above) We were missing several of our regulars... Ghableska, Madmax, Featherfcuk, TBL... but we did ok in the end with some phenomenal players wearing the [AW] tag. Amazing amount of skill. [[User:2020|2020]] 2nd July 2006

'''Wraith Squadron v Crazy Tronners at Bugfarm Fortress (CT do not turn up)'''

=== Finals ===

'''Wraith Squadrn v Shadow League at Z-man's Ladle (0-2)'''
* Wraith Squadron were...
* The Shadow League were: Road66, Sky, Ossi, Man2d, Meriton, Badzilla, Mayday, Sasha and Choco who substituted for Sasha

{{Ladle}}

Ladle Winners

2006-07-02T12:54:30Z

Meriton: Match commentary: AW vs. SL

{{Ladle}}
The Ladle played between within three hours on 1st July 2006 was... Shadow League!

== Congratulations to the Winners! ==

'''They beat Wraith Squadron in straight matches (2-0) in the final.'''

'''They beat Anarchic Wanderers in a nail-biting climax after going down in the first match (2-1) in the semi-finals.'''
*It was a close game. A very close game. Garrisimo was playing like a man on fire, but this still didn't prevent Shadow League from taking our zone once too often. They came back from first match loss, and in the third match, they came from behind to reach a nail-biting 98-98... well done! I played like a noob, and the rest of my team carried me. Next time... Shadow League... next time.... [[User:2020|2020]] 2nd July 2006

* In the first match, zop (who was playing for AW) was doing his usual speed-grinding thing towards or right side and by sheer bad luck, in the confusion of everyone shuffling around, our second (Ossi) and third defender (meriton) were both starting on the left side, whereas our goalie (Sasha) started on the right (IIRC), but due to sealing the center lane ended up on the left as well. To make matters worse, the other players on the right side did not realize they had no defender on their side or simply could not handle zop's speed grind: They grinded until the last moment, only to be surrounded by the speed-grinding zop, who then directly proceeded to insert himself (and a few friends of his ;) in our zone. Until we finally realised what went wrong, the match was nearly over, with us very much behind. I then shuffled over to the right and - by virtue of splitting real early - managed to delay zop until sasha had had a chance to setup. From then on, the teams were very evenly matched, but with the lead AW had gained, the first match went to them. The second match saw some very close fighting among great players, I don't recall much except - for the first time I can recall - feeling dwarfed by the great skill surrounding me. Both teams fought well, and as the last round arrived, it became clear that whoever won this round would win the match (both teams were slightly above 90 points IIRC). Luckily for SL, they made it, avoiding to drop out of the tournament by a very narrow margin. The third and final match started with a few rounds going to AW, and again every outcome was possible. After fierce fighting on both sides, both team got more than 90 points at the beginning of the last round (IIRC, it was 96 : 94 for AW). After some minutes, it was 98:96 for AW, and AW began to hunt our weaker players. In doing so, they left their goalie (garisimo) alone, and I was able to slip through to him. I used a standard speed attack, and trying not to leave me any space while still hiding behind his wall, garisimo tripped over his tail, and I was able get inside and claim the zone. At about the same time, one of our attackers got one of his pursuers, so the final score was 110:98 for SL. To say this was a close game would be an understatement of titanic proportions.

:On our side, I could chiefly assess the performance of our defense team, were Sasha was a class of his own. Surrounded by 3 players, among which zop and lacka, he managed to hold them off for minutes, never leaving a gap, reclaiming all reachable space, and frequently killing them with his wall's edges. I was also able to assess the performance of AW's attack, which was humbling in its skill and coordination. Especially zop, who was chiefly responsible for AW's victory in the first match and AW's near victory in the second match, but also lacka and the others who provided who got there slower, but were no less effective once they were close. Never on the grid have I seen such skill, determination, and cooperation, and I can say that it would have been no shame at all to have to have lost that game to AW. [[User:Meriton|Meriton]] 14:54, 2 July 2006 (CEST)

'''They beat Lords of Destruction in straight matches (2-0) in the quarter finals.'''

.:thankyou. we played our best and i think the others would agree, AW gave us all a '''very''' difficult and stressful match. although we were missing belenus infamous and maverik. meriton and road came on the spot. and badzilla played very well in the AW match. sasha played very nice defense and Ossi played good as sweeper. Mayday and Man2d came in the finals and also played very nicely. and then Choco sub'd in for sasha later that match. thankyou meriton, badzilla, ossi, may.day, man2d, road, sasha, choc, and nazgul for coming to the events. this also goes to show you that there are plenty of nonclan players who know their stuff. To the teams that we did not play: if you guys would like to play us to see how u fare. find me in the games and we'll try to work something out. and thanks 2020 and the others for organizing this tournament. it was a lot of fun:. -SL(sKy)

== The Full Results ==
Please write as much info as you know and any game comments you wish to add...

=== Quarter-finals ===
'''Anarchic Wanderers v Speeders at Z-man's Ladle (2-0)'''

The Anarchic Wanderers were Zop, Eggcozy, Nii, Garissimo, Hayline, Vanhayes, Lackadaisical and 2020.

The Speeders were Psyko, What-up, Speed, Xell, Blackfang, Joda.bot, Oblivion, and Kenny.

* Tough game, and I think we caught them cold. With the best of 3, there is not much room for mistakes. Zop I think played well, and somehow he and my team-mates managed to penetrate Psyko's defence. The midfield was amazing. The skill level high. As part of the defence, it was amazing playing with Eggcozy and Vanhayes... and with Garissimo at the back doing his contracting and expanding, we kept them back for ages giving our offence time to do their magic. I was surprised how fast it went. [[User:2020|2020]] 2nd July 2006

'''Wraith Squadron v LOL at Bugfarm Fortress (2-1)'''

Wraith Squadron were ....

LOL were...

'''Lords of Destruction v Shadow League at LoD Lords of Destruction Clanserver (0-2)'''

The Lords of Destruction were...

The Shadow League were...

'''Crazy Tronners were not represented so they got into the next round...'''

=== Semi-finals ===

'''Anarchic Wanderers v Shadow League at Z-man's Ladle (1-2)'''

The Anarchic Wanderers were Zop, Vanhayes, Garissimo, Eggcozy, Haylin, Lackadaisical, 2020, and Durka.

The Shadow League were Road66, Sky, Ossi, Man2d, Meriton, Badzilla, Mayday, and Sasha.

*(see Congratulations above) We were missing several of our regulars... Ghableska, Madmax, Featherfcuk, TBL... but we did ok in the end with some phenomenal players wearing the [AW] tag. Amazing amount of skill. [[User:2020|2020]] 2nd July 2006

'''Wraith Squadron v Crazy Tronners at Bugfarm Fortress (CT do not turn up)'''

=== Finals ===

'''Wraith Squadrn v Shadow League at Z-man's Ladle (0-2)'''
* Wraith Squadron were...
* The Shadow League were: Road66, Sky, Ossi, Man2d, Meriton, Badzilla, Mayday, Sasha and Choco who substituted for Sasha

{{Ladle}}

LADLE team-lists

2006-07-01T18:56:26Z

Meriton: added myself

{{Ladle Team Legend}}
{{Ladle}}
Stick your name down on a list, or start your own team. There are a maximum of 16 teams allowed for [[THE LADLE]]. Indicate a captain. Don't just put your name in the pool list. It would be better if you would just create a team as we are trying to get up to 16 teams.

'''Today is the day! Please elect a team captain and check out the [[Challenge Room]]'''

== [[Anarchic wanderers]] ==
* 2020
* madmax
* T to the BL
* featherfcuk
* gArIsImOoOoOoOoOoOoOoOoOoOoO
can we get lacks to join us as well as maz, cycle and pavel? please

== [[~*SpeederS*~]] ==
* Team captain: PsYkO (gogodsmackgo@hotmail.com)
* omega
* Joda
* demon
* slash
* Oblivion
* PsYkOCIRCLE!
* cyclotron
* error
* kenny
* speed
* freak
* leeroy
* xell
* sonar

== -=Lords Of Destruction=- ==

* Ady-Lucifer
* Mephisto
* Dez
* $ubzero
* Hay-Lin

== [[Shadow League (fe)]] ==
* sKy
* Radian
* Ryu
* Ossi
* Nazgul
* Monk
* Gusbo T. Jam esq (if that's ok with you guys....:))
* (Cho)
* belenus
* Infamous
* Sasha
* Maverik
* Meriton (if you need me, I am here)

== [[Wraith Squadron]] ==
Special forces who are not only unrivaled in a star fighter cockpit but unmatched with a vibrio blade in hand to hand combat.
Unfortunately our slicer met an untimely demise and now we have been forced to digitized ourselves and enter our flight computers to core dump these wayward programs.

* BlAzE
* Manta
* me
* treeripe
* upacreek

== [http://tron.plantpeanuts.co.uk/portal.php CrazyTronners] ==
We finally sign up, let's take fun dudes. Our players list is subjected to changes, cause we are live clan. [[CrazyTronners]]
* Xevi
* 1394-freak
* 4400
* cid
* ed
* i play rs
* kilabit
* King
* Kyle
* loops
* man2d
* PTA
* Robed
* root
* Shadow
* syllabear
* Voodoo
* Warzelan
* Also our padawans

== [http://teamlol.8k.com ¡LØL!] ==
We are getting more players everyday so the list will continue to increase. If you would like to play with us, register [http://www.setbb.com/claneverybodyel/profile.php?mode=register&mforum=claneverybodyel HERE] and I'll put your name on the list.
[[¡LØL! Clan|Wiki Page]]
*Dµ®Kå
*WiLdCaT
*Chuck
*Goodygumdrops
*JJBean
*Legit
*JJBean
*PyRoTeK
*G5
*Trace
*2b|!2b?
*Sha9y
*Scythe
*RyRy
*SATAN
*Amafuckdisbitch
*IceStage
*Nate
*Blader

== [[the pool]] ==
For unaffiliated players who would like to play on the day...
* Lackadaisical -I doubt i can play, but if i am i'll be at the irc channel, appreciate the offer psyko, but i guess it would be better to join a team who doesn't have (more than enough) players.
* Vanhayes-might be busy, but I will show up on the day if I can and play if I am needed.
* Phresh/Pandemonium
* Pez
* I guess we could take Lack - PsYkO
give him and the other pool players to a team that doesnt have about 15 people -_-.

Camera Glance Keys

2006-05-20T05:55:20Z

Meriton: reflected changes in latest test version

<div style="background:#ccc; border:1px solid black; margin:0.4em; padding:0.2em;">'''Note:''' This page describes glancing as implemented by the glancing test version. The current releases use a slightly different system.</div>

= Manual Camera Control =

While the camera tries to show the areas of the grid that are most interesting to you, the camera can not always anticipate your wishes. Manual camera control permits you to adjust the perspective while playing to show the things that really matter.

The keys for manual camera control can be configured in

Main Menu/Player Setup/Player x Settings/Camera Input Configuration

= What Is Glancing? =

Glancing is the most common form of custom camera control. It causes the camera to face towards a specific direction and is controlled by the four glance keys "glance forward", "glance backward", "glance left" and - you guessed it - "glance right". Unless you changed them in the player options, the glance keys are the arrow keys.

= Why Would I Want to Glance? =

Glad you asked ;-). Using glancing, you can look in any direction, regardless of where you are driving to. You can glance backwards to check whether someone (friend or foe) is grinding your wall. You can glance right to check whether you or the opponent is ahead. You can watch what happens at a fortress while driving by or watch its interior while circling it.

The only disadvantage about glancing is that you might be so absorbed in the action around you that you forget to watch what might endanger your cycle ...

= How Do I Glance? =

Glancing is activated by pressing a glance key and maintained by keeping any glance key pressed.

For instance, pressing "glance left" for a while will show you the area left of your cycle until you release the key, upon which the automatic camera control takes over again.

More precisely, when you press a glance key, you "load" that key with a request to face towards a specific direction, and while you keep pressing the key, the request will be acted upon (if you keep more than one glance key pressed, the most recently pressed one is active).

The direction you request is the current view direction, snapped to the closest axis, rotated as specified by the glance key. (If you were already glancing, only the rotation specified by the glance key is updated, the base direction remains unchanged).

Note that glancing is completly independent of the cycle's driving direction. Therefore, there is nothing wrong with glancing over extended periods of time.

= How Can I Configure Glancing? =

Aside from adjusting the glance keys, glance behavior is controlled by the following options:

;CAMERA_GLANCE_ANGULAR_VELOCITY
:Controls how swiftly the camera rotates towards the requested facing. More precisely, this setting contains the angular velocity (if the camera's facing is perpendicular to the requested facing). Unit: Radians per second.
;CAMERA_GLANCE_MODE
:Controls how the camera rotates towards the requested facing. Possible values are:
:;0
::The camera aproaches the requested facing with constant angular velocity.
:;1
::The camera approaches the requested facing with angular velocity propotional to angle left to travel.
:;2
::The camera approaches the requested facing with constant angular velocity if the angle left is larger than 90°, otherwise with angular velocity proportional to sin(angle).
:;any other setting
::The camera always "jumps" instantly to its new position. Totally useless IMHO.

Since the smart camera offers a (in the dev's humble opinion) poor perspective when glancing, its location is configurable independently:

;CAMERA_SMART_GLANCING_BACK
:How far the camera is moved behind the cycle when glancing
;CAMERA_SMART_GLANCING_HEIGHT
:How far the camera is moved up. There is no pitch setting, the cycle always appears in the centre of the screen

Note that CAMERA_SMART_GLANCE_CUSTOM no longer exists. Those who prefer the old behavior are advised to use the preceeding options to simulate it.

= Known Limitations =

Due to axis snapping, if the current view direction is right between two axis, the glance directions are unspecified. Most automatic modes rarely reach that point on their own, but may do so if glancing has just been recently deactivated. We haven't found an easy way around that (as axis snapping is very useful).

Fe goes spoon

2006-04-16T07:39:36Z

Meriton:

= Notice =

As you can probably judge from this page, my efforts at marshalling enough fe for spoon have not been met with success. At this time, a last minute effort to attract more players is underway. Should this fail, fe will not participate at the spoon. Further information will be posted tomorrow.

I apologize for the premature team entry I submitted. I had taken it for granted that members in a clan called fortress elite were interested in a fortress tournament. Apparently, I was wrong.

Regards

[[User:Meriton|Meriton]] 08:09, 6 April 2006 (CDT)

Maybe will manage after all, but it is still fuzzy. Theoretically we now have enough players, but whether we can assemble them at the same time is yet to be determined.

[[User:Meriton|Meriton]] 12:06, 8 April 2006 (CDT)

sKy is still trying. he is asking opponents to drop by our forum at fe-clan.mlbel.de .

[[User:Meriton|Meriton]] 02:26, 16 April 2006 (CDT)

= Availability =

To schedule the games, we need to know when players are available.

All times in GMT, please; you might wish to convert times using [http://www.timezoneconverter.com/cgi-bin/tzc.tzc this website].

== Deutsche Übersetzung ==

Um unsere Spiele zu planen müssen wir wissen, wer wann spielen kann.

Bitte schreibt alle Zeiten in GMT, die Website hilft beim umrechnen. Wenn ihr in Mitteleuropa seid: Die Zeitdifferent zwischen mitteleuropäischer Zeit und GMT beträgt 2 Stunden; 10 GMT ist 12:00 MEZ.

== week 2 ==
(Monday 10th - Sunday 16th)

meriton: Monday-Thursday is impossible, Friday between 18 and 21 GMT, Saturday and Sunday between 8 and 20 GMT.

Speed: All the times above or earlier but no later than 22:00 GMT.

Nazgul: Every day 13 GMT, 17 GMT

sKy: every day cept maybe tuesday and sunday. but plz weekend if possible becuz AP exams are coming up for me and im gonna be pretty busy throughout the week.

== week 3 ==
(Monday 17th - Sunday 22nd)

meriton: Monday between 8 and 20 GMT, Tuesday to Friday impossible, Saturday and Sunday between 7 and 19 GMT.

Fe goes spoon

2006-04-16T07:34:25Z

Meriton: german translation of instructions, my availability for next week

= Notice =

As you can probably judge from this page, my efforts at marshalling enough fe for spoon have not been met with success. At this time, a last minute effort to attract more players is underway. Should this fail, fe will not participate at the spoon. Further information will be posted tomorrow.

I apologize for the premature team entry I submitted. I had taken it for granted that members in a clan called fortress elite were interested in a fortress tournament. Apparently, I was wrong.

Regards

[[User:Meriton|Meriton]] 08:09, 6 April 2006 (CDT)

Maybe will manage after all, but it is still fuzzy. Theoretically we now have enough players, but whether we can assemble them at the same time is yet to be determined.

[[User:Meriton|Meriton]] 12:06, 8 April 2006 (CDT)

We're still trying... sKy is asking opponents to drop by our forum at fe-clan.mlbel.de .

[[User:Meriton|Meriton]] 02:26, 16 April 2006 (CDT)

= Availability =

To schedule the games, we need to know when players are available.

All times in GMT, please; you might wish to convert times using [http://www.timezoneconverter.com/cgi-bin/tzc.tzc this website].

== Deutsche Übersetzung ==

Um unsere Spiele zu planen müssen wir wissen, wer wann spielen kann.

Bitte schreibt alle Zeiten in GMT, die Website hilft beim umrechnen. Wenn ihr in Mitteleuropa seid: Die Zeitdifferent zwischen mitteleuropäischer Zeit und GMT beträgt 2 Stunden; 10 GMT ist 12:00 MEZ.

== week 2 ==
(Monday 10th - Sunday 16th)

meriton: Monday-Thursday is impossible, Friday between 18 and 21 GMT, Saturday and Sunday between 8 and 20 GMT.

Speed: All the times above or earlier but no later than 22:00 GMT.

Nazgul: Every day 13 GMT, 17 GMT

sKy: every day cept maybe tuesday and sunday. but plz weekend if possible becuz AP exams are coming up for me and im gonna be pretty busy throughout the week.

== week 3 ==
(Monday 17th - Sunday 22nd)

meriton: Monday between 8 and 20 GMT, Tuesday to Friday impossible, Saturday and Sunday between 7 and 20 GMT.

Fe goes spoon

2006-04-16T07:26:35Z

Meriton: moved sKy's notice to the top so it might be seen :)

= Notice =

As you can probably judge from this page, my efforts at marshalling enough fe for spoon have not been met with success. At this time, a last minute effort to attract more players is underway. Should this fail, fe will not participate at the spoon. Further information will be posted tomorrow.

I apologize for the premature team entry I submitted. I had taken it for granted that members in a clan called fortress elite were interested in a fortress tournament. Apparently, I was wrong.

Regards

[[User:Meriton|Meriton]] 08:09, 6 April 2006 (CDT)

Maybe will manage after all, but it is still fuzzy. Theoretically we now have enough players, but whether we can assemble them at the same time is yet to be determined.

[[User:Meriton|Meriton]] 12:06, 8 April 2006 (CDT)

We're still trying... sKy is asking opponents to drop by our forum at fe-clan.mlbel.de .

[[User:Meriton|Meriton]] 02:26, 16 April 2006 (CDT)

= Availability =

To schedule the games, we need to know when players are available.

All times in GMT, please; you might wish to convert times using [http://www.timezoneconverter.com/cgi-bin/tzc.tzc this website].

== week 1 ==
(Monday 3rd - Sunday 9th)

meriton: Monday, Tuesday and Wednessday between 10 GMT and 1 GMT. Thursday and Friday between 8 GMT and 23 GMT, Saturday and Sunday between 7 GMT and 21 GMT.

Speed:Most days 12:00gmt to 22:00gmt

Nazgul:Every day 13 GMT, 17 GMT
radian..im,e free on the 10th and 12th .. unfortunatly the spoon has coinsided with four gigs that i must play with my band [redhouse] on the 13th 14th 15th 16th on these days i am free up to 6.30pm gmt and wont get back home till 11.30pm gmt............

== week 2 ==
(Monday 10th - Sunday 16th)

meriton: Monday-Thursday is impossible, Friday between 18 and 21 GMT, Saturday and Sunday between 8 and 20 GMT.

Speed: All the times above or earlier but no later than 22:00 GMT.

Nazgul: Every day 13 GMT, 17 GMT

sKy: every day cept maybe tuesday and sunday. but plz weekend if possible becuz AP exams are coming up for me and im gonna be pretty busy throughout the week.

Fe goes spoon

2006-04-15T09:33:11Z

Meriton: we don't play

= Notice =

As you can probably judge from this page, my efforts at marshalling enough fe for spoon have not been met with success. At this time, a last minute effort to attract more players is underway. Should this fail, fe will not participate at the spoon. Further information will be posted tomorrow.

I apologize for the premature team entry I submitted. I had taken it for granted that members in a clan called fortress elite were interested in a fortress tournament. Apparently, I was wrong.

Regards

[[User:Meriton|Meriton]] 08:09, 6 April 2006 (CDT)

Maybe will manage after all, but it is still fuzzy. Theoretically we now have enough players, but whether we can assemble them at the same time is yet to be determined.

[[User:Meriton|Meriton]] 12:06, 8 April 2006 (CDT)

I have been out of the loop during the week, but to the best of my knowledge, assembling a team has failed. I am sorry for the time wasted by my premature team entry. The thought that 15 members of a clan called fortress elite would not get a 5 player team ready didn't cross my mind. Apparently, it should have.

[[User:Meriton|Meriton]] 04:33, 15 April 2006 (CDT)

= Availability =

To schedule the games, we need to know when players are available.

All times in GMT, please; you might wish to convert times using [http://www.timezoneconverter.com/cgi-bin/tzc.tzc this website].

== week 1 ==
(Monday 3rd - Sunday 9th)

meriton: Monday, Tuesday and Wednessday between 10 GMT and 1 GMT. Thursday and Friday between 8 GMT and 23 GMT, Saturday and Sunday between 7 GMT and 21 GMT.

Speed:Most days 12:00gmt to 22:00gmt

Nazgul:Every day 13 GMT, 17 GMT
radian..im,e free on the 10th and 12th .. unfortunatly the spoon has coinsided with four gigs that i must play with my band [redhouse] on the 13th 14th 15th 16th on these days i am free up to 6.30pm gmt and wont get back home till 11.30pm gmt............

== week 2 ==
(Monday 10th - Sunday 16th)

meriton: Monday-Thursday is impossible, Friday between 18 and 21 GMT, Saturday and Sunday between 8 and 20 GMT.

Speed: All the times above or earlier but no later than 22:00 GMT.

Nazgul: Every day 13 GMT, 17 GMT

Fe goes spoon

2006-04-15T09:32:52Z

Meriton: we don't play

= Notice =

As you can probably judge from this page, my efforts at marshalling enough fe for spoon have not been met with success. At this time, a last minute effort to attract more players is underway. Should this fail, fe will not participate at the spoon. Further information will be posted tomorrow.

I apologize for the premature team entry I submitted. I had taken it for granted that members in a clan called fortress elite were interested in a fortress tournament. Apparently, I was wrong.

Regards

[[User:Meriton|Meriton]] 08:09, 6 April 2006 (CDT)

Maybe will manage after all, but it is still fuzzy. Theoretically we now have enough players, but whether we can assemble them at the same time is yet to be determined.

[[User:Meriton|Meriton]] 12:06, 8 April 2006 (CDT)

I have been out of the loop during the week, but to the best of my knowledge, assembling a team has failed. I am sorry for the time wasted by my premature team entry. The thought that 15 members of a clan called fortress elite would not get a 5 player team ready didn't cross my mind. Apparently, it should have.

[[User:Meriton|Meriton]] 04:32, 15 April 2006 (CDT)

= Availability =

To schedule the games, we need to know when players are available.

All times in GMT, please; you might wish to convert times using [http://www.timezoneconverter.com/cgi-bin/tzc.tzc this website].

== week 1 ==
(Monday 3rd - Sunday 9th)

meriton: Monday, Tuesday and Wednessday between 10 GMT and 1 GMT. Thursday and Friday between 8 GMT and 23 GMT, Saturday and Sunday between 7 GMT and 21 GMT.

Speed:Most days 12:00gmt to 22:00gmt

Nazgul:Every day 13 GMT, 17 GMT
radian..im,e free on the 10th and 12th .. unfortunatly the spoon has coinsided with four gigs that i must play with my band [redhouse] on the 13th 14th 15th 16th on these days i am free up to 6.30pm gmt and wont get back home till 11.30pm gmt............

== week 2 ==
(Monday 10th - Sunday 16th)

meriton: Monday-Thursday is impossible, Friday between 18 and 21 GMT, Saturday and Sunday between 8 and 20 GMT.

Speed: All the times above or earlier but no later than 22:00 GMT.

Nazgul: Every day 13 GMT, 17 GMT

Fe goes spoon

2006-04-08T17:06:48Z

Meriton: /* Notice */

= Notice =

As you can probably judge from this page, my efforts at marshalling enough fe for spoon have not been met with success. At this time, a last minute effort to attract more players is underway. Should this fail, fe will not participate at the spoon. Further information will be posted tomorrow.

I apologize for the premature team entry I submitted. I had taken it for granted that members in a clan called fortress elite were interested in a fortress tournament. Apparently, I was wrong.

Regards

[[User:Meriton|Meriton]] 08:09, 6 April 2006 (CDT)

Maybe will manage after all, but it is still fuzzy. Theoretically we now have enough players, but whether we can assemble them at the same time is yet to be determined.

[[User:Meriton|Meriton]] 12:06, 8 April 2006 (CDT)

= Availability =

To schedule the games, we need to know when players are available.

All times in GMT, please; you might wish to convert times using [http://www.timezoneconverter.com/cgi-bin/tzc.tzc this website].

== week 1 ==
(Monday 3rd - Sunday 9th)

meriton: Monday, Tuesday and Wednessday between 10 GMT and 1 GMT. Thursday and Friday between 8 GMT and 23 GMT, Saturday and Sunday between 7 GMT and 21 GMT.

Speed:All weekdays (some earlier than seven if needed) 19:00 to 21:30. Saturday and Sunday 12:00 to whatever time i supose but no later than 23:00.

Nazgul:Every day 13 GMT, 17 GMT

== week 2 ==
(Monday 10th - Sunday 16th)

meriton: Monday-Thursday is impossible, Friday between 18 and 21 GMT, Saturday and Sunday between 8 and 20 GMT.

Speed: All the times above or earlier but no later than 23:00.

Nazgul: Every day 13 GMT, 17 GMT

Fe goes spoon

2006-04-06T13:09:35Z

Meriton: notice

Fe goes spoon

2006-04-03T18:13:15Z

Meriton: structure and meriton's availability

= Availability =

To schedule the games, we need to know when players are available.

All times in GMT, please; you might wish to convert times using [http://www.timezoneconverter.com/cgi-bin/tzc.tzc this website].

== week 1 ==
(Monday 3rd - Sunday 9th)

meriton: Monday, Tuesday and Wednessday between 10 GMT and 1 GMT. Thursday and Friday between 8 GMT and 23 GMT, Saturday and Sunday between 7 GMT and 21 GMT.

== week 2 ==
(Monday 10th - Sunday 16th)

meriton: Monday-Thursday is impossible, Friday between 18 and 21 GMT, Saturday and Sunday between 8 and 20 GMT.