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)
ClientPrediction is like predicting weather in real life : "this cloud has gone this way all day long, we predict it'll continue in the same direction tomorrow". Sometimes it fails to predict right, especially if it's a one week prediction instead of a few hour one. So the more you increase net_clientPrediction, the more you'll possibly see on screen some weird things :
"woops.. guess what, the cloud's way that we are predicting since 5 hours, we have just received his exact position from our satelite ; Actually it isn't where we were drawing it all this time.
-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.
bind kp_uparrow "dec net_clientPrediction 1; addchatline '^1clientPrediction:';addchatline $net_clientPrediction"
bind kp_pgup "inc net_clientPrediction 1; addchatline '^1clientPrediction:';addchatline $net_clientPrediction"
seta net_clientMaxPrediction 150 //you'd better start from 150 than 1000 or else it's gonna take forever to lower
bind kp_5 "dec net_clientMaxPrediction 1; addchatline '^2clientMaxPrediction:';addchatline $net_clientMaxPrediction"
bind kp_rightarrow "inc net_clientMaxPrediction 1; addchatline '^2clientMaxPrediction:';addchatline $net_clientMaxPrediction"
bind kp_downarrow "dec net_clientUsercmdPacking 1; addchatline '^4clientUsercmdPacking:';addchatline $net_clientUsercmdPacking"
bind kp_pgdn "inc net_clientUsercmdPacking 1; addchatline '^4clientUsercmdPacking:';addchatline $net_clientUsercmdPacking"
bind kp_slash "dec net_clientUserCmdBackup 1; addchatline '^6clientUserCmdBackup:';addchatline $net_clientUserCmdBackup"
bind kp_star "inc net_clientUserCmdBackup 1; addchatline '^6clientUserCmdBackup:';addchatline $net_clientUserCmdBackup"
bind kp_home toggle net_clientLagOMeter
bind kp_leftarrow toggle com_showAsyncStats
bind kp_end toggle com_showfps
bind kp_ins toggle hud_fps //works only in Q4MAX
seta net_clientMaxRate 25600
Map of these binds :
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.
Uploading from a Q4TV server to a client can take up to 6-8kB/s of bandwidth for a 4v4 game, and up to 3kB/s for a 1v1 game (that's what I've noticed with AsyncStats in rate value while spectating some Q4TVs), therefore cap the number of viewers or it will lag (and will be unwatchable for all viewers) when exceeding your bandwidth capacity ; e.g. if you have a 300kB/s bandwidth, you should cap the number of viewers of a TDM game at 300/8= 37 viewers max.
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.
UpsetChaps'Guide, a good site for general information about q4, although it may contains some errors (e.g. erroneous lagometer's definition)
Quake 4's patches readme
Q4MAX changelogs
![shaftwhores only by [EXE]dann](/files/avatars/2007/51852-shaftwhore.gif "shaftwhores only by [EXE]dann"){kind=small}
