Quake 3 Connection Vars

Here is some basic and advanced info on the connection-related variables in the Quake3 engine.


Measured in Bytes per second. This is the maximum rate at which the server will send data to you. You should set this to the highest downstream rate your own connection can achieve consistently. The hardcoded limit is between 1000 and 90000. If you set your rate higher than what your connection can actually achieve, you are at risk of being flooded with data from the server, which will lag you out. Each server has a limit on the amount of data they will send to a client per second, which is typically of the order of 16000, which is more than enough for large games. These days, most connections are capable of receiving the maximum a server has to offer, and so most players can safely set this to a high value and not worry about it. It is only those with slow/old connections who have to be careful about choosing the right value for their connection.


This setting is the maximum number of 'snapshots' that you wish to receive from the server per second. A snapshot is a 'picture' of what has happened in the game since the last snapshot. This is the data transmission equivalent of a framerate. Servers run at a constant framerate specified by their sv_fps variable. The most a server can give you is one snap per server frame. So you should set your snaps equal to (or greater than) the server's sv_fps value, which is typically 30. Regardless of how high you set your snaps setting, you will not be able to receive more than the server has to offer. So you can set your snaps to 40 and play on a sv_fps 30 server without needing to adjust your snaps - you will receive the maximum of 30 anyway. If you are playing CPMA, your snaps will be automatically set to equal the server's sv_fps on connect, and so you don't have to worry about this setting. However other mods do not do this, and so for other mods, snaps needs to be set manually.


This affects how your client processes the snapshots it receives. Normally the client compares one snapshot with the next and interpolates between the two. If you set this to a negative value, you can adjust the interpolation of snapshots to compensate for lag. The more negative timenudge you use, the more unsmooth other players will appear, but the less latency you will have. The hardcoded limit is between -30 and +30. There is also another side to the timenudge story. You can use positive values of timenudge to affect snapshot interpolation with an opposite effect, making the game much smoother, although deliberately delayed. Timenudge only directly affects the latency of the incoming data and does not directly affect the data that you send to the server.


This is the maximum number of data packets that can be SENT to the server per second. The higher you set this, the smoother your game will feel as your actions (run, shoot, jump etc.) will be updated more frequently. The hardcoded limit is between 30 and 125. [Note that in other Q3 engine games, the upper limit is 100] If you set your maxPackets too high, you will flood your upstream connection, in a similar fashion to the rate flooding above, however if you have a 128 kbps or greater upstream connection, you should be able to set maxPackets to the maximum 125 with no problems. There is also a phenomena whereby using high values of maxPackets causes the ping displayed on the scoreboard to appear higher. This effect should be ignored - you should always use as high a value as your connection allows, and these days most people should be using the 125 maximum.


This is the maximum client framerate permitted. The only valid values are those which are equal to (1000/x) where x is an integer, as Q3 measures frametimes using millisecond integers. So for example your 125fps comes from (1000/8 = 125). If you try and set maxFPS to an invalid value, you will get the next higher value.

1000/3 = ~333
1000/4 = 250
1000/5 = 200
1000/6 = ~166
1000/7 = ~142
1000/8 = 125
1000/9 = ~111
1000/10 = 100
1000/11 = ~90
1000/12 = ~83
1000/13 = ~76
1000/14 = ~71
1000/15 = ~66
1000/16 = ~62
1000/17 = ~58
1000/18 = ~55

cl_maxPackets and com_maxFPS

This is where your graphical framerate affects your connection. The actual number of packets you can send to a server is either one every frame, or one every 2 frames, or one every three frames and so on. So if you are running at 125fps, your possible packets per second are:

125/1 = 125
125/2 = ~63
125/3 = ~42
125/4 = ~32
So if you are using maxPackets 100 at 125fps, you are NOT sending 100 packets per second, you will send one packet every 2 frames, which is 62.5 packets per second. And if your framerate drops to 100fps, then suddenly you will be able to send one per frame, and will get a jump from 62.5 to 100 packets per second.
100/1 = 100
100/2 = 50
100/3 = ~34
So if you have your cl_maxPackets set to 100 and are using 125fps then mostly you will be sending 62.5 packets per second to the server (this is the largest achieveable value not exceeding the input cl_maxPackets limit). However, if the framerate drops to 100fps, you will be sending 100 packets per second, as this is now the largest achieveable value that does not exceed the input cl_maxPackets limit. If your connection cannot handle 100 packets per second, it will cause your ping to rise or spike. Even if it can handle the jump from 63 to 100 packets, this may well cause your latency to fluctuate more than if your actual packets per second were constant. Keep this in mind when choosing a value of cl_maxPackets for your connection. This information is only needed if you have a slow upstream and cannot use the maximum value of 125.

- injx