Click here to edit subtitle

This page is devoted to the game of Quake:

Q3 Ufreeze Networking


Ufreeze has some very powerful and very configurable network settings. I will attempt to explain these in the following page. I will also go over standard q3 networking options and how they affect the game.

In this section:

cl_maxPackets - Standard q3
Every time your client (your copy of q3 which you are running right in front of you) draws a frame on the screen, it also sends a command to the server, such as ‘I moved’ or ‘I fired a gun’ or something like that.

These commands get sent to the server in packets. cl_maxPackets is the maximum number of packets you may send in 1 second. The higher the cl_maxPackets, the more often you will send updates to the server, and as a result, the more smooth and consistent your game will feel. If you have say, 125 frames per second, but only 30 cl_maxPackets (which is the standard q3 default), it will have to bundle 4 commands into 1 packet. As a result these 4 commands will all arrive and be processed on the server at the same time, making it more jerky than if each command was sent as soon as it was generated.

Q3 version 1.32 has a set maxPackets limit of 125, older versions limited this at 100, and some servers with punkbuster etc still enforce 100.
The only reason you do not want to set your cl_maxPackets as high as possible is if you are on a 56k modem which perhaps cannot handle sending that many packets per second.

A side effect of having a higher cl_maxPackets value is that your ping on the default q3 scoreboard will appear higher. It only appears higher, rest assured that it is not actually any higher. If you set cl_maxPackets to a low value in the attempt to have a ping which looks good on the scoreboard, you are only fooling yourself and making your game worse.

cg_truePing - Ufreeze only
Because the standard q3 ping calculation algorithm is not, as it were, “very good”, ufreeze introduced cg_truePing, a client side variable which you can set to either 1 or 0. 0 uses the standard q3 ping calculations, 1 uses the ‘true’ ping, which is the actual time it takes for a command to be issued from your client, travel to the server, be processed, and reply, and be processed.

The important thing here is the processing time is taken into account. Simply doing a ping from a command prompt (DOS box) does not involve any processing, therefore is not a good indication of how well your game will play. cg_truePing however, is. Contrary to standard q3 ping calculations, having a higher cl_maxPackets value will decrease your trueping, which is what is supposed to happen. Also, having a negative value for cl_timenudge (more on this later) will decrease this value. If you have 20 ping, and cl_timenudge -20, then cg_trueping will display 0. This is correct. Although you do not actually have 0 ping, the game will be the same as if you played on a LAN (with actual 0 ping) and no timenudge.

cl_timeNudge - Standard q3
The way the quake 3 engine decides what to draw, is by holding a server-snapshot in a buffer until the next one arrives, then it smoothly interpolates the movement between them. On most servers, the buffer time is 50 milliseconds (corresponding to the default sv_fps 20).
What cl_timeNudge does is adjust this buffering time. Positive values mean the server information will be held longer in the buffer, negative values will release it earlier.

The problem being, if a packet is released early from the buffer, then q3 can no longer smoothly interpolate between it and the next packet, because the next packet will not yet have arrived. This is why in standard quake 3 and other mods such as OSP, setting negative timenudge values results in players looking jerky.
However, what Ufreeze does, is predicts where the players will go, so even with negative timenudge values, everything is still nice and smooth.

Timenudge can only go as low as the packet is being buffered for, so theoretically -50 is the lowest timenudge value that will actually do anything. In practice -30 is about the lowest, because there is some overhead involved in processing and buffering the packets.
Which segues nicely along into…

cg_playerNudge - Ufreeze only
Like with a negative timenudge setting, ufreeze will predict where the player is going. However, cg_playerNudge is not restricted by the buffering process. Therefore you can set cg_playerNudge to values such as 100, which will give you 100ms of prediction. The prediction is capped at whatever your ping is, otherwise setting values greater than your ping would result in being able to see enemies around corners.
Set cg_playerNudge to -1 to have it automatically adjust to your ping.

The practical upshot of this is that I can have 60 ping, set cg_playerNudge to -1 and the game will behave as if I were playing with zero ping. Unlike timenudge however, it will not lower your ping on the scoreboard. Braggers need not apply.

The downside of this, is that because it is predicting to compensate for your ping, the higher your ping is, the more likely it is to have visual errors as there is no such thing as perfect prediction.
80-100 is the upper limit of ‘nice’ prediction. Any more and players will appear to jerk around slightly, and weapon shots will look like they miss when they hit, and vice versa. A good thing to do if you ping overly high (ie: 150 or so) is to set cg_playernudge to 80 or 90 or so, and play as if you were pinging 70 or 80. Visuals will not be as consistent as if you had no playernudge at all, but it’s a ksaj sight easier to lead your shots by 70 millisconds than it is to lead by 150.

Because cg_playerNudge is client-side prediction only, it does not affect the weapon balance, nor does it result in the classic pitfall of unlagged, getting ‘railed around a corner’.

snaps - Standard q3
The maximum number of ’server frames’ or ’snapshots’ which you will recieve from a server per second. The default value of 20 matches up with a server’s default sv_fps of 20.
Note that if you set your snaps higher than the rate at which the server is sending out snapshots, it will not do anything. However, if a server has say sv_fps 100 (sending 100 snapshots a second), and you are bandwidth-starved, you can set snaps to a lower value.
Ideally you want the same number of snaps as the server is sending, the default of 20 applies to 99% of servers so this should be fine.

rate - Standard q3
The maximum number of bytes per second you will recieve. Once again, it is good to have this as high as your connection will allow. Setting your rate to some insane amount will not adversely affect you, because quake 3 / ufreeze servers almost never send more than about 5000 bytes per second anyway.
The only circumstance in which rate does become very important is if you are either bandwidth starved (lowering your rate will help your connection remain more stable) or if you are using ref_getssdemo or ref_getstatsfile to download files in game. (ufreeze 1.21 only)
If you are downloading files in game and your rate is set to a higher value than your connection can handle, the server will attempt to send you more information than you can handle, and you will be flooded off the server and disconnected.

cg_ospNetCode - Ufreeze only
As mentioned above in cl_timeNudge, quake 3 holds information in a buffer (50ms usually) so that it can draw smoothly. However, this means that what you see on the screen will always be 50 ms (depending on the server fps) behind what is actually going on on the server, even if you ping zero. This is the infamous ‘quake 3 50 millseconds lag’.
cg_ospNetCode makes UFreeze use the OSP/CPMA method of fixing this built-in-lag (for your shots) instead of the normal Ufreeze one. Useful for die-hard OSP and CPMA players only, as the normal Ufreeze method is technically better.