- This guide will explain how you can make your quake 3 running the way it was made/should run.
- This is also assuming you do not have a wireless connection or a 56k connection or cant even hold 125fps solid. otherwise don’t bother with half of these settings.
- These settings are also with complete disregard to personal preference and could possible hinder your abilities, so experiment with what works for you and for different pings.
Measured in Bytes per second. This is the maximum rate at which you will be able to receive data from the server. You should set this to the highest downstream rate your own connection can achieve consistently. This should not be set higher than 25000. For most of you this will be set at 25000, but for others with slower connections, you can take the rate at which you connect at and divide it by 10 to get your Rate value. If you set your rate higher than what your connection can actually achieve, this is what will happen:
When there are more players on the server (or just players constantly shooting) there is more data that needs to be sent from the server to the clients. If you have your rate set too high, the server will try to take advantage of your extra bandwidth. So when the server tries to send you 250Kbps down your 36Kbps connection, you will be flooded, your ping will 999, you will get mass packetloss and your connection will either hang or you will get kicked by the server.
Rate 25000 or 50000 (25-50kbps)
Watch your lagometers green spikes when this is set lower. mostly everyone can handle this it just depends on how solid your connection is, routing, the server, etc..
This setting is the number of ‘snapshots’ that you receive from the server per second. A snapshot is a ‘picture’ of what is happening in the game since the last snapshot. This is the data transmission equivalent of a framerate. This setting should be set equal to the server’s sv_fps setting (default is 20). Some servers use sv_fps 30 and I have seen some sv_fps 40 servers. I have never seen a server using a sv_fps greater than 40. Regardless of how high you set your snaps setting, you will not be able to receive more than the rate at which the server runs which is defined by its sv_fps setting. So you can set your snaps to 40 and play on a sv_fps 30 server without needing to adjust your snaps – it will run at 30 anyway.
If you have dialup or wireless you will probably be better using snaps 20. The higher the snaps the more bandwidth will be needed, so snaps 30 or 40 may cause the connection to be less stable.
Snaps 40 is a general number because the server will lower it to the servers sv_fps for you. cpma forces your snaps to equal the servers sv_fps when you connect so dont bother setting a value.
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. Broadbanders will be able to go up to 125 (but not higher) but this depends on your individual connections. Dialup users will just about be able to manage 30, so 20 is more of a stable setting.
Also if you set your MaxPackets too high, your ping will start to rise. This is due to the increase in upstream bandwidth usage. So you should set your MaxPackets as high as you can without it affecting your ping (and without going over 125).
xxx equals your COM_MAXFPS, if you set this to ANY NUMBER lower than your com_maxfps, it will CUT YOUR MAXPACKETS IN HALF. example: COM_MAXFPS =125 CL_MAXPACKETS =100 means your MAXPACKETS BECOME 63 (half your fps because 100 is NOT divisible by 125).
This is the maximum graphical framerate permitted. You can not use any MaxFPS value. The only valid values are those which are equal to (1000/x) where x is an integer. So for example your 125fps comes from (1000/8 = 125). If you try and set MaxFPS to 120, you will still get 125fps. This is because any invalid setting is rounded up to the next (1000/x).
Some valid Values for MaxFPS:
1000/2 = 500
1000/3 = ~333
1000/4 = 250
1000/5 = 200
1000/6 = ~166
1000/7 = ~142
1000/8 = 125
1000/9 = ~111
1000/10 = 100
CL_MAXPACKETS & COM_MAXFPS
This is where your graphical framerate affects your connection. The actual MaxPackets sent to the server MUST be equal to (your_FPS/x), once again where x is an integer. If you set your MaxPackets to a value which is not equal to (your_FPS/x) then your MaxPackets will actually be rounded down to the nearest valid setting.
Most of you will use MaxFPS 125. If so, your valid MaxPackets values will be as follows (assuming your PC can achieve its MaxFPS value constantly):
(always round up these calculations to integers)
125/1 = 125
125/2 = 63
125/3 = 42
125/4 = 32
125/5 = 25
You should choose the largest value that your connection can handle. If your MaxPackets is not set to a valid value, it is a potential waste of bandwidth and therefore potential lag/instability.
For example, if your framerate drops to 100 then your valid MaxPackets values will change to:
100/1 = 100
100/2 = 50
100/3 = 34
100/4 = 25
So if you have your Cl_MaxPackets set to 100 and are using 125fps then mostly your MaxPackets will be at 63 (this is the largest value not exceeding the input Cl_MaxPackets limit). However, when the framerate drops to 100fps, the MaxPacket will change to 100 as this is now the largest value that does not exceed the input Cl_MaxPackets limit. If your connection cannot handle 100 packets 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 ping to fluctuate more than if your actual MaxPackets were constant.
*Oh and having maxfps 333 can mess up a server by causing everyone else to lag. I don’t know why or under what circumstances, but I’ve seen it happen when two or three players with 333fps get on the same server.
0 uses the least ammount of bandwidth and doesn’t “waste” time sending packets twice. Set higher if you have much packetloss. You can check your packetloss easily by using cg_predict 1. I use cl_packetup 2 or 3 is about as high as i would go.
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 by making your client start interpolating BEFORE it recieves the next snapshot. In other words, it will be predicting what the next snapshot will look like and using that prediction as a basis for the interpolation. At some point during this nudged interpolation, the actual next snapshot will arrive from the server. At this point, the client will replace the predicted snapshot by the actual snapshot and recalculate the interpolation. This difference between the two is the prediction error. However at this point, you will not see a huge jerk due to the change from predicted to actual data as the prediction error is decayed away to ensure the gameplay remains as smooth as possible, even if it is slightly inaccurate.
The more negative timenudge you use, the more predictions will happen and therefore the more inaccurate the predicted data will be. Therefore, even though these errors are decayed, the jerks will be more noticable and as a result other players will seem to move less smoothly.
Effectively, the greatest negative value is equal to 1000/sv_fps (of the server) however -12 is a recommended maximum to keep the gameplay smooth and accurate, even if there is a little less lag compensation.
There is also another side to the timenudge story. You can use positive values of timenudge to affect snapshot interpolation with an opposite effect. Using positive values means that your client will wait for extra time before interpolating the 2 snapshots. This can be useful if you have a higher ping or a packetlossy connection. In these cases snapshots are likely to be lost and the time between each snapshot arriving can fluctuate greately as some packets are delayed or whatever. In this case, even if you are not using any timenudge, the client may have to start interpolating before the next snapshot has arrived, simply because it is late. By using a positive timenudge, you can ensure that the client waits those crucial few milliseconds more to allow the next snapshot to arrive successfully, thus keeping gameplay smooth and accurate – even if the incoming data is deliberately lagged.
Btw using timenudge will not affect your ping on the screen, simply because your ping has not changed. Timenudge has nothing to do with your actual ping, but it has everything to do with your lag. I would like to add that timenudge only directly affects the lag of the incoming data and does not directly affect the data that you send to the server. Whether timenudge indirectly affects your outgoing data is unlikely but that issue is best being left for a timenudge-specific topic.
Quake3e & cl_autoNudge
cl_autoNudge automatic time nudge that uses your average ping as the time nudge, values:
0 – use fixed \cl_timeNudge
[0..1] – factor of median average ping to use as timenudge
SOURCES: Changelogs, ReadMe’s, and Various Sources compiled for you.