The goal of this thread is to teach you to improve Quake 4's fluidity without having too much unpleasant secondaries effects.

There are 2 reasons why you could have some visual "freezes" :
·Not having a sufficient bandwidth (upload and/or download bandwidth) : this will result in Packet Loss, and so in lag.
·Pings in Quake 4 are jumping a lot ; this means informations arn't coming at a steady speed. Packets which are late will cause lag unless you configure Quake 4 to predict frames.

Note : As a player you are a "client" (you are in the clientside, opposed to serverside)

Menu :
1) Connection tools
2) Connection cvars
3) Some usefull binds
4) Q4TV settings



1) Connection tools :
*net_clientLagOMeter

The lagometer draws two lines :
Bottom yellow line (1) : Amount of Packet Loss (PL)
This will result in lag ; higher is the spike, the more packet have been lost during this time interval.

Upper yellow/green line : Frames rendering
Yellow (2) : Count of frames "predicted behind the server", in other words : they are late (client had to wait longer than usual to receive updates from server ; the cause may be pings jumps or PL).
Green (3) : Count of frames predicted ahead the server (these are predicted frames).
Basically what you need is no green nor yellow.

Notes :
-The cvar "net_clientLagOMeterResolution" modify the lagometer upper line ordinate resolution ; it can be set from 16 (default) to 1 (more accurate).
-The lagometer could (or not) cause some light fps drops.


*com_showAsyncStats

·out rate/in rate : your uploading/downloading speed to/from the server ; if it reaches your connection limits, you will experience PL (throw away your old 56k modem) and you'll have to increase net_clientUsercmdPacking.
·packet loss : Informations travel in packets and some packets can be lost along the way (because of network disruption or insufficient bandwidth)
·client prediction : current amount of clientside prediction
·predicted frames : number of predicted frames at the moment

Note : B means byte ; byte (B) = octet (o) = 8 bits (b)


*com_showfps - hud_fps
"com_showfps" display the number of frames rendered per second ; Q4max's players can use "hud_fps" which is a better implementation of com_showFPS.
Usefull when you have freezes to know if it's just your PC that cannot handle the game's graphics, or if it may be lag.



2) Connection cvars :
Note : "net_clientPrediction" and "net_clientmaxprediction" are the important values and may be set everytime you enter a server, oppositely to "net_clientUserCmdBackup", "net_clientUserCmdBackup" and "net_clientUsercmdPacking" which should be set only one time.

*net_clientPrediction
·Definition : Amount of prediction (in milliseconds) added (or subtracted, when using negative numbers) to the already existing gameworld clientside prediction (e.g. other players movements predictions).
·Increasing it :
-Advantage : Less lags (If an information from the server is missing -lost or late-, the frame would have been already created by prediction : no freeze).
-Disadvantage : Frames can be wrongly predicted ; i.e. the more you set it high, the more you'll experience ghost hitting (that's when you plain hit a player, but it doesn't register damage : your PC -clientside- was drawing by prediction a player but he actually wasn't at this location on the serverside)

-Advice : Increase net_clientPrediction until you arn't experiencing lags anymore ; then counterbalance the disadvantage of clientPrediction by lowering "net_clientmaxprediction" (see below).

Note : It can be preferable to have more lags and less prediction ; you will have to find your favourite balance between having lags and hitting ghosts.


*net_clientmaxprediction
·Definition : It cap the client prediction ; it is set by default to 1000ms (useless at this setting). Basically it's a gate : any frame predicted ahead from this gate will be cancelled and recalculate later.
·Decreasing it :
-Advantage : It will cancel frames predicted too much ahead (the more ahead frames are predicted, the more erroneous they could be).
-Disadvantage : If you lower it too much you'll experience the worst lags ever.
-Advice : Lower it until you reach the "worst lags ever"-barrier, then increase it a bit (e.g. 10ms ; it'll depends of how high your ping is jumping).


*net_clientUserCmdBackup
·Definition : Determines how may duplicate movement/action commands are sent, range is 1 to 5. If a packet gets lost then a 'backup' command may still be received. You can reduce uploading bandwidth usage by lowering this at the expense of possibly losing a movement/action packet.
·Increasing it :
-Advantage : Reduces Packet Loss.
-Disadvantage : Increases amount of used client's uploading bandwidth.
-Advice : Set it to 1 if you arn't experiencing PL.


*net_clientUsercmdPacking
·Definition : Client->server traffic is sent once every net_clientUsercmdPacking frames. This reduces the client->server traffic, and increases the predict ahead slightly.
·Increasing it :
­Advantage : Lower amount of used client uploading bandwidth.
-Disadvantage : Increases client prediction.
-Advice : Set it to 1 if your uploading connection speed allows it.


*net_clientMaxRate
·definition : Set as bytes per second. It controls packets so that your downstream connection bandwidth does not get saturated. Defaults to 10000 (10KB/s) for ISDN, 16000 (16KB/s) for ADSL/Cable and 25600 (25.6KB/s) for LAN.
·Increasing it :
-advantage : Free your download bandwidth capacity.
-Disadvantage : If your downstream connection bandwidth does get saturated it will result in Packet Loss (Although downstream connections being saturated with <30KB/s speed is rare nowadays).
-Advice : Set it to 25600, it'll be capped serverside anyway.



3) Some usefull binds :
All these binds have an ingame chat line, so you'll always know what you are doing.
It's up to you to bind them anywhere else of course.


4) Q4TV settings :
seta net_clientMaxPrediction 1500
seta net_predictionerrordecay "200" //default is 112
seta net_clientPrediction 0

decrease net_clientPrediction until you reach the limit where you are lagging like a 5 fps slideshow (it could be at -150), then increase it a bit (e.g. add 10ms, or more if you have some larger ping jumps) and you should have a smooth Q4TV.
Note that these settings worked fine with patch 1.4.1 beta, it may be different with next patches.


Personal overall conclusion :
-Jumping pings are Quake 4's evil.
-Melting netcode and frame rendering was a stupid idea.

Thanks to AnthonyJ for all his help about this.