Network Settings Guide
Buttery smooth Tremulous
Often players are unaware that they have incorrect settings for their graphics hardware or their network connection type. This causes visual, network, and movement input lag.
Follow this guide and see if your lag decreases, movement feels better, and things like hit registration with Dragoon chomp and Basilisk grab improve.
In Tremulous (and other games based on the ioQuake3 engine), your ability to render video frames also controls the network data that your client sends and receives. If your video card is choking, you are unable to see precise player movements and so your client will cut the network resources in an attempt to 'catch up'.
Incorrect settings cause rounding errors and cause packets to be missed.
If your client is unable to render the game at the frame rate you have set with
com_maxFPSthe amount of data packets you send as set by
cl_maxPacketsgets cut in HALF and your input will lag.
ratesetting is too low you won't receive data fast enough from the server, causing lag, and if
rateis too high for your connection, you will get flooded, also causing lag.
Check your current settings
Run Tremulous, open the console by pressing the
~ (the tilde key AKA "the wavy line key" on QWERTY keyboards) and enter each CVAR (client variable) with no arguments:
Next, WRITE DOWN THE VALUES YOU HAVE, and then come back here. Don't worry we'll wait..
Okay! A quick look at what these do, easy one first:
rate (default 25000)
This setting was needed in the days of analog modems (dial-up). This limits the maximum downstream bandwidth you are able to receive from the server. The cvar uses "bits per second" so if you shave off three zeroes, this tells downstream Kilo bits per second (Kbps). This means data will be received at 25 Kbps.
For asynchronous DSL connection, cable modem or fiber optic, use the default of
This is probably too much for high latency servers, or players not in the same country as the server.
If you're playing over Wi-Fi or something silly (a satellite connection?), try half at
A good value for 33.6 Kbps analog modem connection (Dial-up) would be
Note: The server controls the maximum rate that it is capable of sending upstream to each client with sv_maxRate which is usually 25000. On a LAN connection to the server, the server ignores this for clients on the same sub-network and will send data fast as it can, possibly flooding them.
This is the maximum FPS the game will attempt to render. More is better, right? Wrong!
- Setting this too high will make the game visuals and network lag.
- Also, setting to an invalid value or bad combo with cl_maxPackets will cause movement lag.
- Your eyes can't see fast motion past a certain point.
- Setting FPS to higher than what your computer's display's fresh rate is will cause 'tearing' which is where the edges of things, like corners of walls, will be appear to be jagged when looking around.
What are valid values for com_maxFPS?
The game runs on a fixed tick rate of 1000 ticks per second. Valid values are calculated by taking 1000 and dividing it by an integer value (whole number) and then ROUND DOWN the result.
Example (1000 / n, rounded down): 1000 / 3 == 333.3333... = round down to 333. 1000 / 11 == 90.9090...= round down to 90.
Find your maximum (consisent) frame rate
Enable the frame rate display by enabling the cvar:
cg_drawFPS = 1
Also turn on the network graph with:
cg_Lagometer = 1
Connect to a server with some players and spectate someone.
Look at your FPS counter and see the maximum you are getting by setting
com_maxFPS = 0to disable the limit (alternately set to max of 1000). Spectate a player for a minute and watch the rendered frame rate that you are getting.
Note the highest FPS you can render consistently.
Now, set com_maxFPS to a valid value that is LOWER than what you can actually render consistently.
The maximum number of packets to send to the server every seconds. In general this should be 1 more than what you set com_maxFPS to, but has a maximum of 125. More is better, right? Wrong! Well, sort of...
You should set this to what your connection can handle.
Remember that if you are unable to render the frame rate that you have set with com_maxFPS, your maximum packet rate gets cut in half.
What are valid values for cl_maxPackets?
Set to 125 or lower. This should generally be valid value that is usable for your connection but 125 is probably going to be wrong unless your com_maxFPS is one of 125, 250, 500 or 1000.
Example (1000 / n, rounded up). 1000 / 13 == 76.9230... = round up to 77. 1000 / 18 == 55.5555... = round up to 56.
- If you need to lower it, take your com_maxFPS value, divide by an integer, add one if it's not a factor of 1000. Factors of 1000 that don't need one added are 10, 20, 25, 40, 50 and 100.
Example: com_maxFPS = 90
90 / 2 = 45. Add 1 and use cl_maxPackets = 46.
So what settings should YOU use?
There's no good default answer here. Ignore the people who say to use 125 for both. You have to see what works best for you.
Low latency connection (under 100 ms)
com_maxFPS = 125
cl_maxPackets = 125
Medium latency connection
Ping 100-200 ms or video card can't achieve 125 FPS
com_maxFPS = 76
cl_maxPackets = 77
Ultra l33t player
com_maxFPS = 333
cl_maxPackets = 112
Best settings for VSYNC @ 60 Hz
(Vertical synchronization on LCD display / TV)
com_maxFPS = 58 (The display refresh rate / frequency, see note below. Default 0)
cl_maxPackets = 59
r_displayRefresh = 60
r_swapInterval = 1 (Swap interval turns VSYNC on/off. Default 0)
Note: r_swapInterval and r_displayRefresh need fullscreen mode (r_Fullscreen 1) and a vid_restart to work. Displayfresh is set to the same frequency as the display, so usually 60, 75, 100, 120 or 125. Most LCD monitors don't go higher than 60Hz (Even new HDTV claims of 120 Hz often only support 60Hz INPUT and then double each frame to be displayed). Most CRT monitors can't do high refresh rates at higher resolutions. Check your display settings and documentation to see what your monitor supports.
More things to look at
snaps (integer, default 20, maximum 999)
The maximum amount of data-frame snapshots you can receive from the server, per second. This is used on unstable or slow connections (modems) to set a limit that is LOWER than the server's sv_FPS, which controls the data-frame rate. Setting a value that is higher will still always use the sv_FPS so most players should set
\snaps = 999 and never worry about it again.
cl_packetDup (integer, default 1, maximum 5)
The number of duplicate packets to send to the server. Only players with very good connections and low ping to the server should attempt to disabling duplicate packets by setting to 0. If you have an unstable connection to the server, packets you are sending might be lost, so the number of duplicate outbound packets to send might need to be increased, so try sending an extra duplicate packet per second with
cl_packetDup = 2.
cg_Unlagged (boolean, default 1)
In an attempt to offset lag for laggy players, this client setting enables use of a server-side technique called "backwards reconciliation" to handle hit prediction for hit-scan weapons (and hit-scan attacks for aliens).
Almost everyone will want to leave this enabled. Only LAN players on a local server or players running tremded on their machine (or running from in-game where client is the server) might want to disable this - as you have no lag to the server in these scenarios.
Otherwise, players with unlagged disabled have to 'lead' their targets by aiming slightly ahead of them as they fire, because in real-time the guy you are shooting at is indeed slightly ahead of where the server can keep track of his movements and then relay to your client to display them.
Players with Unlagged ON should aim either right at their targets, or if lagging even 'trail' targets by firing right behind where you see them.
\rate = 25000which is 25 Kbps downstream - unless you can't for some reason.
- Use a good combo of
cl_maxPacketsor you are handicapping yourself.
- Don't use higher settings than what makes sense for your hardware or connection scenario or you will lag.
Here's a chart that shows valid value combinations for both com_maxFPS and cl_maxPackets:
Additionally, com_maxFPS values of 1000, 500, and 250 can be used with cl_maxPackets 125.
Thanks for reading! Let me know if this helps!