This page is a MIRROR of Myrkul's page view the original at myrkul's homepage.

Descent on the Net

Author: Charles Kendrick aka Myrkul (myrkul@myrkul.org)

You can also go to Myrkul's homepage.

This is a detailed explanation of the behavior of Descent when played over the internet. In particular I'll cover the way Descent networking is implemented, and the effect of lag and loss on Descent game play.

This is a big document, and there are a few ways to go through it. Each question and answer is marked green, blue or red according to how difficult it is to understand. Here's what the colors mean:

Green

Easy to understand, or at least, required reading to understand the basics. All the green questions are basically sequential are you should read them all to get a good understanding of Descent over networks.

Yellow

Optional and somewhat more difficult to comprehend. Most people will be able to understand these with very little computer knowledge, typically because I have described or explained any terminology I use. These question/answer pairs are sometimes weaved into a sequence of green questions.

Purple

This might be very difficult to understand, or possibly I've just decided to use a lot of computer terms without defining them, because it would take too long to explain them. Some of these questions might gravitate to blue if I add more to them.

INTRO

Why are YOU writing this?

Well I've played on Kali via both modem and direct connect, and I've played lots of games on a LAN. Also I'm a computer science major, have taken courses on networking, and know about the 'net, eg routers and such. Also I'm an extremely finicky player, and effects like lag and loss really bother me, and thus caught my interest. Also, as a Kali Descent addict, I wanted to know how to kill people despite lag and loss. So I ended up figuring all this stuff out, and I thought I'd broadcast it to the world...

Also, there are plenty of people on Kali with bad misconceptions about the role of lag, loss, modems and CPU speed in Kali Descent games. These people tend to get very angry or frustrated with other players, and blame anything that goes wrong on lag or some other supposed disadvantage. This document is also here to try to alleviate some of that.

So you're a CS major huh? Is this going to be techo-gibberish that'll go right over my head?

No, not at all. I'll barely even have to mention the word "router" to explain Descent's behavior. You'll need to have played Descent on Kali and experienced lag in order to understand me, however.

SECTION ONE: HOW DESCENT WORKS IN NET-MODE

Ok, how does the game work in general on a network?

Gee, that was something of a manufactured question...

Several people are running Descent on their computers, and the copies of Descent communicate over the network through the use of "packets". Packets are basically small pieces of data just like what is used in an FTP session or any other network communication. In the case of Descent, each packet is some kind of game event, eg firing a shot or opening a door. When each player receives a packet telling what another player is doing, Descent then renders that action on the machine that receives the packet.

So for instance, ships move around because all players in the game send "position packets". If enough position packets are getting through between any two players, they appear to move relatively continuously to each other, because position packets are sent several times a second. If a lot of these position packets are being lost your opponent will appear to jump around.

How do you mean Descent "renders that action on the machine that receives the packet."?

What I mean is that for instance, the copy of Descent running on your machine receives a packet from another player that says "I just fired a fusion bolt". Your machine will then place the shot in the game in a certain orientation, heading in a certain direction. From then on, that fusion bolt will be rendered locally on your machine without any further information from the person who fired it, just like a shot from a robot in a single player game.

This has a few immediate consequences; for one, if your computer is a lot faster than another person's computer, so much faster that they fly significantly slower in a single player game, the same difference in speed will be present in a networked game. This difference in computer speed will also affect rate of fire of weapons and give a better framerate. Having a faster computer is generally an advantage, although it can impact certain playing styles more or less adversely than others.

Ok, basically that jibes with what I've seen.. maybe... but what makes you think it works that way?

For several reasons:

Missiles aren't lagged

When a player fires a missile at you, it doesn't freeze in mid-air, and it doesn't track to where you were a few seconds ago, even if the player who fired it is jumping all over the place. If the player who fired the missile was still sending packets controlling the behavior of the missile, it would be just as jumpy as that player, and just as lagged. This means your machine is controlling the missile, just like a missile fired in single player mode.

Shots all move at the correct speed relative to you

If every player kept controlling his shots after they were fired, you'd get shots moving at Pentium speed on a 486, and shots moving at 486 speed on Pentiums. When an opponent's game slows down because of a lot of activity on a slow machine, shots would suddenly grind nearly to a halt and hang there momentarily. Ever seen that?

Parallax wouldn't have written the game that way

Consider the number of packets required to send position updates every fraction of a second, to notify another player of a series of shots, to keep track of all items, breakable panels, and doors in the mine. Every player must be capable of sending this many packets, and receiving that many packets multiplied by the number of players in the game. Now imagine if, in addition to notifying another player of a shot, you also sent out position packets describing the path of that shot, as often as were required to make the movement continuous. Now imagine three players firing thirty shot plasma bursts. You get the picture.

In addition, there really is no reason for position updates to be sent for every shot. Most weapons move in a straight line at constant speed, and you wouldn't want to subject missiles to lag.

SECTION TWO: LAG, LOSS, MODEMS AND THE NET

What is lag? I mean, officially.

Lag is latency. Latency is the amount of the time it takes for a packet to get from sender to receiver.

What is loss?

Loss is when a packet is "dropped" or lost somewhere between sender and receiver. Contrary to popular Kali belief, this is most often due to modems rather than any of the networking in between.

How does Kali Descent look when you have a direct connection (DC)?

Every player moves continuously and fires continuously, whether they are on a modem or not, no matter how many players are in the game.

Ok, not everybody. Like about 85% of people. One simple reason why someone wouldn't move continuously for a DC is that their frame rate is very low. In this case they only send position updates as often as their position is updated (every time they see a frame), so you see a reflection of their frame rate. Other reasons are more complex, see the advanced section.

So basically, when you have DC, you can just kick everyone's ass without even trying, you sack of shit.

No, not at all. DC players experience all the same difficulties as modem players. We drill people into the wall with megas and bursts of plasma and they fly on without noticing.

WTF?? How can that be?

Having a direct connection just means that I can receive everything that everyone is sending, ie, all position updates and shots. We still can't do anything about all the packets that modem players drop, which is the primary reason for problems in the game.

But wait a minute.. if modem players are dropping all of the packets you send them... they're obviously out of bandwidth.. yet they send you everything they are doing just fine??

Precisely. Descent and/or your computer and/or the packet driver are in charge of how the modem's bandwidth gets used. Thus, anytime Descent wants to send a packet, it grabs control of the modem and does so almost instantly. The rest of the bandwidth gets used for receiving packets.

Thus, again contrary to popular Kali belief, everyone is sending the same amount of information out into the game.

A DC player joining your game does not cause any more lag than just another modem player joining the game.

Problems occur when the number of players in the game gets large, and people's modems can not handle all the incoming packets. This is the primary reason for severe packet loss. Packets that come in when the modem is busy are generally lost. These packets are kept in a very small buffer in your Internet Service Provider's networking hardware, generally only large enough to hold a packet or two. Packets overwrite each other in this buffer until the modem becomes free to receive a packet. Then whichever packet is the most recent, ie overwrote all the earlier packets which were lost, gets sent.

Thus, when loss gets really bad, other players in the game begin to hop around because of lost position packets. They still might move somewhat continuously, as basically you get one packet out of every X packets, and it's the Xth packet every time, meaning that you get a relatively continuous stream of packets, just with larger gaps.

So how can I tell when things are getting really bad?

Given that the default position packet rate in D1 and D2 is 10 packets per second, if someone is moving discontinuously at all you are probably receiving only 2 or 3 of those ten.

Also, anytime players you are actually seeing the effects of loss on your machine, assuming all modems are of approximately even speed, any other modem players are dropping about as many packets. In practice the assumption that all modem players are getting the same bandwidth is a pretty bad assumption, since ISPs vary widely in their level of service. The key idea here is that if you can see the effects of loss, it's likely the game has become totally chaotic and unplayable for all involved.

SECTION THREE: SPECIFIC EXAMPLES

People seem to jump around more if I start firing.

Your using more of your bandwidth for outgoing packets (eg shot packets), leaving less bandwidth to receive packets with, so you're dropping more packets.

Why do thousands of duplicate items begin to appear in the game?

When a player picks up an item, he sends out a packet that says he just picked it up. If you're on a modem you may drop that packet. Even if your on a DC, if two other players get the same item, they will both spew that item when they die.

Sometimes items can even duplicate in a pure DC or LAN game. This happens because there is still some small latency (say a tenth of a second) and two players go for the same item simultaneously. They then typically ram into each other and both get the item.

This guy keeps disconnecting and reconnecting.

A person disconnects when you haven't received any "I'm here" packets from him in a long time. If it's just one person, it might be on his end, see the discussion of outgoing packet problems. If everyone's disconnecting and reconnecting, you're in a game your modem can't handle.

Other players are talking to somebody who I saw disconnect, and sometimes they seem to be dogfighting ghosts. I thought they were crazy or stupid until I got a message that the disconnected guy killed one of them.

This is a common problem that even happens to DCs and among DCs sometimes. Basically, packet loss has caused your machine to decide that a certain player has disconnected, whereas other players who didn't drop the important packets still see that player. Then when one of those players is killed by the player you saw disconnect, he broadcasts a message "I got killed by X" and your computer blithely reports this to you, not realizing that it makes no sense.

These disconnects between two specific players can be one way or two way, ie it can be that two or more intersecting sets of players are playing, where some players can see everyone and others can't. Before you sell your modem, however, realize that this is a very rare phenomenom, unlikely to happen more than once to people in the same game.

While a lossy connection increases the chance that this phenomenom will occur, as I said it happens to DCs, and seems to be related to missing certain very specific packets rather than consistently receiving most of the packets. In other words, you could have a good connection and this could happen to you by dumb luck.

If it happens to you and you realize it, just exit and rejoin the game. The person who started the game will then resend you a list of all the players (although it is possible that his list will also be incorrect, it's unlikely).

Kali is full of cheaters. I fire multiple megas at some people, and huge bursts of plasma, and they don't even try to dodge, but they don't get hit.

First let me say that yes, there is a hacked copy of Descent out there that works on Kali. It gives the cheater 32000 shields, unlimited ammunition, and the ability to fire weird weapons, eg twin or quad megas, quad flares, even reactor balls.

However, this hack is extremely rarely used. Most people who don't have psychological problems just try it once and get bored of it, then go back to normal Descent.

Almost always if you're having trouble killing someone it's a matter of very high loss. They may be on a slow modem, or have a bad ISP. Another possibility is that the other player has seen you disconnect from the game, as in the previous example.

Fine, I'll take your word for it, but how could I tell if someone is actually cheating?

There are basically only three ways.

They are using impossible weapons

This one is pretty obvious. If someone fires reactor balls or quad megas, they are using the hack.

They are using megas or some other weapon not found on the level, or on any of the previous levels

Make sure you know about every little nook and cranny of a level before you accuse someone of cheating on this basis. This is really only a reliable way to tell someone is cheating if you, for instance, get hit with a mega on First Strike level 1. And even then, it's not necessarily the person firing who's cheating. Another player who is the one actually cheating may have introduced megas to the level.

These criteria can be loosened slightly, if you are very very careful. For instance if you follow a player around for a long time and watch him take a clearly excessive and ridiculous amount of damage, you've probably got a case of cheating on your hands. Be wary, however, of the tendency to claim that a player who is doing a lot better than you are (or were, before they arrived) is cheating.

It seems like certain levels make for more lag than others. Also, sometimes lag will increase as a game goes on.

A lot of traffic goes back and forth describing the items in a level, and describing the opening of doors. If there are a lot of items on a level, or a lot of items end up duplicating, this adds to the traffic. Also, there is a popular level called "The Doors" which has a room full of, basically, doors. This causes a lot of loss, and typically people who try to join the game are told that they are missing packets.

Also, because of how Descent's rendering engine works, large levels take longer to render, decreasing your framerate. Occasionally a player will drop a packet because his computer can't deal with it in time, and a large level can add to that problem.

I killed someone, he spun around for a sec, and then he just disappeared without spewing anything.

I killed a guy and I wasn't given a kill. Sometimes though, other players know I got the kill.

A guy backed right through me and stuffed a mega up my ass.

I fired a mega at point blank and killed myself, but the other guy didn't die.

I got a message that "so and so killed himself". I turned around and there he was blowing up behind me!

He never fired anything, WTF?

Ok basically you should be able to figure out the reasons for the above and most of the rest of the problems you might have. Basically someone has dropped a packet or isn't getting packets often enough.

I flew right through a wall and then my monitor blew up!!

Suddenly Satan appeared to me and asked me the size of my genitalia!!

I really SUCK!!

Sorry, can't help you there. Most likely unrelated to Descent networking. Check your hardware and your brain (if there's a distinction any more).

SECTION FOUR: ASSYMETRY IN LATENCY, LOSS AND COMPUTER SPEED

I have a DC and I'm getting slaughtered in netgames. Some people seem to never die. They tell me lag gets everyone. Do I just suck??

No. You don't at all.

All you modem players out there, let this come across loud and clear: a DC has no inherent advantage.

The fundamental thing you should understand is that a connection on a network is point-to-point. If I have a direct connection to the backbone of the 'net and you have a modem connection to it, my connection to you is via a modem. Any traffic moving between us is limited and affected by that. There is no "game" that a DC could have a better connection to: the game is created by the distributed packet-passing of all the computers participating.

The difference between a DC player and a modem player in a Descent netgame is that a DC player receives basically every packet because a DC has more bandwidth available. Lag (read: latency) is generally symmetric.

For instance: visualize a Total Chaos level 2 netgame full of modem players with one DC player. Players will gather in the central arena and use plasma guns like firehoses, with the occasional mega missile thrown in. If you are on a modem you are probably dropping at least half of it. If you are on a DC, you see every last plasma bolt, and you are right in the middle of it.

A DC does have the advantage that no matter how lagged a player is, he still moves continuously in the DC's view, which is good for aiming and leading, potentially giving the DC an advantage in making kills. However, the only games where this presents a significant advantage are games where everyone on a modem sees people jumping around. And when everyone is already jumping around for anyone on a modem, loss has become such a significant factor in the game that the DC player begins to have a disadvantage because he does not drop packets, and is therefore more vulnerable.

Furthermore, in any game which is moving relatively continuously for all players involved, modem players still experience significant loss. This is partly because packets arrive in bursts a lot of the time, and due to the way the 'net is set up, they may arrive at the data rate your ISP is working with, typically 1.5Mbps. Because your modem is going at a slower data rate, it cannot instantaneously retransmit all of those packets and some are lost.

This means that, in your typical game that has not totally fallen apart due to loss, the modem players have the same latency and can see the motion of other players about as smoothly or clearly as the DCs, but frequently, and entirely beneficially, drop packets that represent shots. Clearly, they are also more likely to drop spew packets (for instance) than DCs, but when a smart missile to the face is the packet dropped, it becomes clear where the advantage lies.

One of the more obvious results of "normal" loss is what happens when you are laying down a line of shots and a player tries to fly through it. Typically a modem player will sail through successfully, possibly taking a couple of hits. A DC will jerk to a halt in the middle of the stream, pinned by repeated hits, and usually get killed. In fact, a modem player once told me that this behavior difference is the primary way he knows when someone is a DC.

Advantages conferred by connection type are not an easy thing to judge. Given the right situation (though it may be contrived or unlikely) the advantage can go to either player, and it's is usually not clear (especially given that you are looking at only your screen) who may or may not have had an advantage at any given instant. The critical thing to remember when thinking about the effect of lag and loss is that information flowing in both directions is extremely important to both players. Each player receives the position of the enemy ships that he is trying to fire at right along with the shots they are firing at him, and loss or lag in either direction adversely affects both players, although possibly differently. The real reason to crave a DC is that you can play virtually lagless and lossless games with other DCs.

How does it affect the game if one machine is significantly faster than another?

Well, as long as there is lag and loss in the game, you almost might as well not worry about differences in computer speed unless you are on a 486/66 and are actually stressing your machine playing Descent.

The effect of differences in machine speed are most obvious in LAN or pure DC games where there is almost no lag or loss to blame anything on.

I play on a high speed LAN with guys from work. There's this one guy with a 486 and the rest of us have Pentiums. I've noticed that sometimes if he's moving across my screen and I'm trying to lead him, if I only wing him, like hit the tail end of his ship, he won't get hit.

Everything is moving at different speeds in each player's view of the game: ships, shots, and missiles. When you fire a shot and watch it complete it's path, you are not guaranteed that it will strike the same objects on another machine.

You might think that the situation of one player leading another player with shots would by symmetric, ie, both the shots and the speed of the evading ship are effected by the relativism, so leading shots still hit. This is not the case.

The player on the Pentium is getting position updates from the 486. He sees the actual speed of the player on the 486, the same speed the player on the 486 sees. However, he sees the speed of his shots as rendered on a Pentium, meaning they move faster than on the 486. Therefore, shots that would seem to hit the tail end of the 486 player's ship actually miss because the shots move slower on the 486 while the ship moves at the same speed that was seen by the shooter.

Ok, also, he says if he leads by a little too much and only hits my front end, sometimes that doesn't hit.

This is the same principle in reverse. The 486 player sees the actual speed of the Pentium's ship, but his shots move faster when rendered by the Pentium. Therefore they go in front of the Pentium player's ship.

Ok, last thing, sometimes we'll fire missiles at each other, and one of us will see the missile hit a wall, but the other guy actually got hit. Or also vice-versa.

Let me say first that it is a multiply tested and verified result that missiles track better on a faster machine. You can verify it for yourself by setting up fixed positions for shooter and dodger, and defining the keys that are held down to dodge. It's an obvious result - not even very close.

It also makes perfect sense in terms of game speed. Missile tracking in Descent is basically computational, and is done by modifying the direction and speed of the missile at discrete intervals. If the computer running the game is faster, these updates can happen more often, resulting in better missile tracking.

If you know about double-buffering, you will also understand that the tracking ability is most likely related to the framerate the player is currently getting.

Also, aside from missiles that just track better, the same thing that happens with leading shots can affect missile fire. A player on a pentium might see a missile get to a 486 player before he gets behind a wall, whereas the 486 player sees the missile hit the wall.

Or, stranger yet, the Pentium player may see that missile hit the wall while the 486 player actually got hit. This is because the Pentium player saw the missile track very agressively, swinging right into a wall, while on the 486, the missile took a smoother turn and then hit the player.

Ok, I can see how packet loss explains most of the things that happen... still, though, there are some players that act like they are as much as ten seconds behind the game. They fire at where I used to be, and if I fire a single mega at them and then wait long enough while they aren't moving, it will get them eventually.

Occasionally you will find a player like this, although this is somewhat difficult to distinguish from a player who is just losing a lot of packets. These players are usually having their incoming packets buffered by their ISP.

Your typical ISP will have a LAN (local area network) set up, using some 10Mbps network technology (10baseT, BNC, ..), and have a combination router/T1 device that is their connection to larger provider, and so on "up the chain". One or more machines on the ISPs LAN are then connected to sets of modems. These machines handle answering calls and allocating IPs and such, and have a way of splitting incoming traffic to go to the appropriate modem.

Because this machine (it can also be a dumber device) is on the ISPs 10Mbps LAN, any traffic arriving that is addressed to your machine's IP address is arriving at the data rate of 10Mbps. Since this is different from the data rate of your modem (28.8Kbps typically), there cannot be a 1 to 1 real-time transfer of data between the 10Mbps line and your modem, and there is a necessity for a buffer. Basically this is a small amount of memory that makes up for the difference in line speed by temporarily storing packets.

Since Descent is a real-time application a large buffer is mostly useless. If your modem can handle the current bandwidth requirements of the game, a small buffer might help you lose less packets, if, for instance, a few came in a burst. In this case you would be trading less lost packets for a temporary increase in latency, until your modem clears the buffer.

If your modem can not handle the current bandwidth of the game a buffer will only fill up and overflow; when it does overflow, the oldest packet will be discarded. This will result in an added artificial latency, the size of which will be equal to the size of the buffer divided by the speed of your modem (essentially the time needed to clear the buffer). The player will still receive only as many packets as they would get with a minimum buffer, and drop the rest. A buffer is basically the only thing that explains latencies over 2 full seconds (given a modem that is pulling 24Kilobits/s, this would require only about a 6Kilobyte buffer). Players who are having their incoming traffic buffered will react to events that are several seconds old, and anything you do might get to them several seconds late, or might just be lost.

The bad news is, a buffer is a perfectly good thing for your ISP to put in place for you. If you are FTPing a file for instance, a buffer will stop you from dropping packets, and because the machine sending the file will only send data as fast as you can acknowledge receiving it, you won't end up consistently overflowing the buffer. A buffer only becomes useless for a real-time application where the bandwidth required is consistently higher than you can receive, which is something you "shouldn't be doing anyway".

It's also very difficult to distinguish who's end the buffer is on. It could be on either, neither, or both ends, or even somewhere in between, and the only time you can tell if buffering is happening is when you are losing a lot of packets anyway. Basically the only way to tell for sure if there is buffering going on is to intentionally get into a game with too much traffic for your modem and ask a DC to test the latency to you, while you in the middle of a firefight, and are moving and firing yourself (so that you can be sure there is too much traffic for your modem). At this point it is almost easier to just read the section on getting a better connection.

You keep saying that all players move continuously for a DC but kinda not. And you keep saying latency is usually symmetric. What gives, why all the mysticism?

A lot of the time in a large game, a DC will see 3 or 4 players moving perfectly continously and one player jerking and jumping about. This is clearly not due to a problem local to that DC, at least in the sense that the problem is not happening anywhere in between the furthest point that all the packets the DC is receiving are travelling along (in my particular case, this would be the far end of Stanford's T3 connection to BBN Planet).

Other than the simple case of the jumpy player just having a really poor frame rate, the problem is basically packets being lost or otherwise screwed up somewhere between the outermost "local" point and the jumpy player.

Three major classes of problems are responsible about 90% of the time:

Outgoing Packet Queuing/Buffering

An outgoing buffer presents a serious problem for a Descent player. Here's a demo (882k) of a player who's outgoing traffic is being buffered. (BTW, suggestion to those intimidated by the demo's size: start DLing the demo, finish reading the FAQ then view the demo and delete it) Notice the way he will hang in one position and then slingshot over to another position, moving continuously, but much faster than is possible during normal flight. His outgoing traffic is being queued and delivered in bursts.

This behavior is most likely the result of both outgoing queuing and a rotational bandwidth allocation scheme, possibly a large token ring, although given the low frequency I would guess it was something more primitive, like modem banks taking turns.

Saturated (or malfunctioning) lines or nodes

Saturated lines are lines that are consistently being asked to carry more data than they can. In several places on the 'net, this is the norm. For instance there are a paltry number of 64Kbps lines running under the oceans connecting the continents (satellites help), and during peak hours (which may not coincide with US peak hours) these lines are 100% full, 100% of the time, for hours on end. Obviously traffic like that cannot simply be buffered infinitely, and the only remaining choice is to lose a certain percentage of the traffic at random until the lines can be upgraded or augmented.

Temporary problems can also result in temporarily saturated lines, in the US, or even in your own city or your ISP. A certain kind of temporary problem, colloquially referred to as a "netsplit", happens where a router or a larger chunk of the 'net goes dead (power outage, fried rodent, who knows..). Since routers work by continuosly updating each other on the "best routes" they know of, this can create temporary "black holes", where routers try to deliver to dead routers (until they figure out the routers are dead). This is what is usually responsible for games that split in half, leaving two intact games with disjoint sets of players.

Preferenced lines

Your modem and the preference it displays to outgoing traffic is what I mean by a preferenced line, that is, traffic in one direction (incoming) is lost so that traffic in the other direction (outgoing) won't be. Your modem may not be the only such line between you and another player. Most ISPs are just offering access to the net to everyday people with the usual client software, and the only servers in the ISP's subnet are news servers and the like meant for local use, plus possibly one small web server. If the vast majority of traffic was incoming the ISP might well set up some kind of preference system in order to handle it all, and might be dropping only outgoing packets, which the ISP might consider to be less important.

SECTION FIVE: DESCENT II

Does D2 behave differently from D1 on Kali?

To make a sweeping statement, no. The problems of lag and loss still exist, as they are a part of the internet and not anything that can really be programmed around. However, there are a few changes worth noting. First the simple ones.

 

Spawning/Duplication has been reduced

The phenomenon of duplicating items (aka spawning) has been reduced but not eliminated.

Capture the Flag Multiplayer Mode

I've personally seen some strange things happen in pure DC flag games, and as far as I know, it never caught on for the masses because of the yet stranger things that happen when you play flag on modems. I haven't played enough flag to really feel qualified to comment, but suffice to say I've seen games with multiple flags and games with no flags (might be wrong about second part).

Ping and Kick

In multiplayer games you can now type "PING:PLAYER" as a message (F8) to ping a player in the game without using flares. This can be particularly useful in detecting players whose pings soar when they are dogfighting (when a ping is generally untestable by flare test). Also, if you are the person who started the game, or you inherited game ownership from a person who disconnected, you can use "KICK:PLAYER" to boot a player out of the game. There's only one thing I have to say about that: there are very, very few times when KICK should be used and I personally have never had a sufficient reason to use it, to date.

New Multiplayer Cheats and Cheat Detection

There is at least one new cheat (hacked .exe) out there, and this one is much improved in terms of stealth. It gives the user unlimited energy, unlimited copies of any missile picked up, and an automatic energy->shield converter that is silent. This means that most of the ways of detecting cheats that I listed for D1 will not work for D2, at least for detecting this particular cheat.

Fastjoin

This is actually a Kali95 hack on Descent. If you turn the "fastjoin" option on (reachable in Kali95 by File->Settings->Advanced) and then start (not join) a D2 (or D1) game, any player who subsequently joins your game will get the mine in the starting state, ie all weapons available and in their initial positions, no lights broken, etc. This will mean that less data will have to be sent when players join your games, making joins quicker and more likely to succeed, and it arguably helps gameplay by causing duplication of weapons so that "hording" is impossible. However, this has caused a new method of "cheating" to come into existence, namely, rejoining a game repeatedly in order to get all the starting items and therefore new copies of all the powerful single-use items (like invuls and shakers).

And now, the major change. The following is the unedited text of an email sent to me by Jason Leighton, one of Parallax' multiplayer programmers. He's responding to my asking Parallax to "bless" this FAQ as accurate information:

Hi Charles,

You asked if one of us would read the FAQ and give our blessing on
the information contained therein.  I've looked over it and it
appears that the FAQ contains very accurate information.

It would be great if you could cover the packets per second and short
packets features of Descent II and give tips on what the best
settings are for various line speeds.  For example, ANY game played
over KALI should have the Short Packets option turned on.  The
packets per second rate should be as follows:

Connect      PPS
--------    ------
ISDN/T1      7
28.8 Modem   5
14.4 Modem   3

This will help the game run a bit smoother.

Thanks for taking the time to write the FAQ.  It's a good resource
for Descent players!


Jason Leighton
Multiplayer Programmer
Parallax Software
leighton@pxsoftware.com

Just to be excessively clear: yes that says that on Kali you should always turn short packets on. Short packets are nearly 3 times smaller than normal packets, due to some omitted, compressed and lower precision data. According to Mike Kulas of Parallax software, posting in alt.games.descent:

The information you lose is the low order bits on things like
orientation and position.  Since the amount of precision we use is a
big overkill, I don't think you'll notice the degradation.

Also, we do some obvious compression, like sending segment-relative
coordinates (rather than absolute) to save on data needs.

Also, in D2, velocity information for ships is sent right along with position information so that D2 can extrapolate a ship's flight path from the ship's last known position, thereby giving you position updates/changes that match your frame rate rather than the position packet rate. The "short packets" option appears to disable this extrapolation, either by omitting velocity information, or by using different or compressed velocity information that the extrapolation system isn't written to use. If you see a player suddenly begin to "coast" in a fixed direction and then disconnect, this means that the "short packets" option has not been turned on, as the "coasting" effect is the result of mindless extrapolation with no new position packets during the delay before your computer decides that the other player has officially disconnected. If you see this happen, you might want to tell whoever started the game (blue usually) that short packets should always be used on Kali, and/or refer him to this FAQ.

Second, the PPS (packets per second) rate being referred to is settable only by the person who starts the game, and can be set by selecting "more options" in the start game dialog. This value sets the number of position packets sent per second by each player who joins the game. It does not set the general amount of traffic the game uses, as clearly there is no way to reduce the traffic in a dogfight where packet=shot (although there may be a couple of other minor places where traffic could be reduced).

Both lowering the PPS value and the use of short packets are tradeoffs between smoothness of flight and loss and lag, and it is generally a win where bandwidth is scarce, since extra packets or extra information sent in order to provide smoothness will cause additional loss and lag, eliminating any otherwise beneficial effect.

As to the table, well, since the traffic of the game clearly increases with the number of players, those numbers should be taken as general guidelines. Let's assume those packet rates refer to average-sized Kali games of, say, 5 players. Then if you expect the player with the slowest connection in the game to be on a 28.8, you should set the packet rate to 5. If you set it higher to match the other players in the game, the 28.8 will most likely end up lagged, although the rest of the players will be fine.

For my own part, if I start a game that I expect will field several typical modem players, I set the PPS to 5, turn short packets on, and set the maximum players to 4. I also usually turn fastjoin on, because I outlaw several of the weapons ("more options"->"objects allowed") and I want copies of the weapons that are allowed to be readily available.

SECTION SIX: WHAT CAN I DO TO GET A BETTER CONNECTION?

ISDN lines work just like normal phone lines: you "dial" (this is nearly instant) into a local number to connect to your ISP, who also has ISDN lines, and charges you monthly for usage. Pacific Bell offers Basic Rate Home ISDN (128Kbps) in California, and they are also an ISDN ISP. Here's a list of some other ISDN ISPs.

You've got to be very careful about the ISP you choose for ISDN. Many ISPs add ISDN service as an afterthought, and use ISDN "modems" in the same configuration as normal analog modems. I've seen people using ISDN lines that behaved (for Descent) about as well as people on T1s, and I've seen people whose ISDN lines behaved worse than some of the better modem connections.

As far as cable modems go, well that'll be available RSN (Real Soon Now). There may be a beta test going on you could participate in. To find out, try doing an Alta Vista search on "cable modems, [your state]". You have an excellent excuse as you will be testing "real-time application software". Write exactly that phrase on your beta test application.

So let's say you have no money. First of all maybe you can afford a US Robotics Courier modem or one with the same chipset. Try these guys and thank me later. USR Couriers connected to USR Couriers seem to get significantly better throughput through superior compression and noise correction. If you get quoted a data rate of 115200 aka 115KBaud, however, that is always bullshit. You won't ever see better than 40000 baud.

Even if you can get a USR Courier, you have to worry about the hardware that your Internet Service Provider has. You want to know:

1) What kind of modems do you have?

You want them to say USR Courier. This is only really important if you too have a USR Courier, or if they have super budget modems.

2) What kind of connection do you have to the 'net? How many "hops" is it to the nearest backbones?

You want them to have either a T1 or T3 connection to the net. T3 is the faster of the two (much faster). ISDN is generally unacceptable, although any connection speed will do if they have few enough users. Also be very aware that an ISP may be growing fast and may saturate their connection. A saturated connection leads to loss.

You want to hear that they are within 6 hops of the nearest backbone at least. 2 or 3 hops is very good.

3) Do you allow true PPP connections?

Basically you want to be absolutely sure you get a true PPP connection. TIA and Slirp are not the same thing as PPP. Neither is SLIP, but it's workable.

If you run into someone who can't answer these questions, go over his head. This is your money and your time. Especially go over the head of anyone who tells you, "I don't know, but it's good I'm sure."

There are lots of other factors important in picking a good ISP. I've only outlined the ones critical to getting a good Descent game. If you want to find a good ISP for Descent, one method is to ask the people with the lowest pings what ISP they are using.

Some problems you see are not your ISP's fault, they are misconfigurations that you can correct. There is an excellent site called "How to Improve Your Ping" that will help you improve your connection. This site really starts from scratch: making sure you have all the latest service packs and updates for Win95/NT, making sure your network settings are optimal, then guiding you through installing some third-party tweaks.

SECTION SEVEN: HOW CAN I PLAY WELL UNDER LAG?

Well, basically, you can't. This is a pet peeve of mine. When you are playing with high loss and latencies as high as 1/2 second, you aren't really playing Descent. Reaction time doesn't count. Aim is skewed. Certain players are more easily hit than others.

When loss gets really bad, you're basically in your own little world. Any other players who aren't experiencing loss percieve you as blind and invulnerable.

In addition, if you play under severe lag you are most likely not improving very much, or even stunting your existing skills.

Hopefully instead of dealing with lag you will either get yourself a better connection or find a pool of good modem players to play small games with, and will restart the game occasionally to deal with duplicating items. But, on those occasions that you are basically forced to deal with lag, you can:

In addition, even if you are a DC playing a bunch of lossy, plasma spewing modem players, using fusion against them is still a worthwhile tactic. I do this often, and you better watch your back for Tika.

Anticipate by several seconds

If you realize a player is about to go through a door or opening, ignore the player and fire at the doorway. In general, lead by more than you have to to hit the player on your screen. This is extremely difficult and will degrade your skills for high-speed, lossless games.

Get a player moving directly into your guns

This can be done by catching someone in a limited space, or by tricking them into backing toward you. Basically the idea is that it's so difficult to get a feel for how much you need to lead a player by that it becomes almost as effective to try to use tricky flying maneuvers to force a lagged or lossy player into a stream of shots.

Use guided weapons

Basically this is the solution that "Mega-deth" games represent. If you fire a mega missile and the other player receives it it will begin tracking to them without any further difficulty, and lead to a one-shot kill. In fact, even if you fire as much as 90 degrees off it's likely that the missile will do your job for you. So when loss has made skill almost a non-factor in your games, maybe Mega-deth is the thing for you. "Total Chaos" also provides a plethora of mindless guided weaponry.

Real players might warm up in Mega-deth.

SECTION EIGHT: MISCELLANEOUS

The extreme short range phenomenon

You'll only realize this is a separate phenomenon from loss if you've played on a LAN. Basically what happens is that a player will fire a shot at extreme short range, ie when two ships are actually colliding. This shot will never be received by the other player.

You might expect that, due to lag, the shot would simply hit the wall behind the player, or something similar. This phenomenon is usually noticed when a mega missile is the shot in question, and both ships are in a confined space where a mega would kill them both no matter what. The player firing will be killed by the mega missile, while the other player never saw it.

My current theory is that basically the position of the shot as rendered by the machine receiving the packet is inside that player's ship, and that Parallax, in an effort to prevent mystical events where a player dies without ever seeing a shot in the air, just intentionally has Descent throw that packet away.

This is the only thing I've been able to think of so far. Let me know if you have an alternate theory.

One day in a game I suddenly found this dormant ship lying around. I could drill it with weapons and actually knock it around, but it wouldn't move on it's own, and no one could kill it. My friends and I played hockey with it using megas.

This is some kind of Descent bug. Basically Descent loses contact with the person controlling a ship, and usually you will be told that that player has disconnected, but Descent leaves the ship in the game.

This is only likely to happen in very lossy games. Essentially think of it as a total breakdown in information about whether a player is in the game.

This FAQ is GREAT!! I totally understand this stuff now! What can I do?

Send donations, flowers, etc to...

JUST KIDDING.

Hey, this isn't entirely an altruistic act. As I said, I'm trying to edify the people who think they know something and don't, and I'm also trying to improve the lag and loss of the games I play in. Plus, imagine how much fun it will be to answer questions with: "See my FAQ, http...".

But seriously folks, what you can do for me is just point people to this FAQ, especially the kind of person who asks questions of the world at large. Hopefully if enough people read this FAQ we'll lower the ignorance level of the Kali crowd.

Cya all in Descent,

	Myrkul