Network Settings Guide

Tremulous Tactics & Tutorials
1

##Buttery smooth Tremulous :granger:

###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.

###Key points

  • 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_maxFPS the amount of data packets you send as set by cl_maxPackets gets cut in HALF and your input will lag.

  • If your rate setting is too low you won’t receive data fast enough from the server, causing lag, and if rate is 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:

\rate \com_maxFPS \cl_maxPackets

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 25000.
    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 12500.

  • A good value for 33.6 Kbps analog modem connection (Dial-up) would be 3000.

####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.

com_maxFPS
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

  1. Enable the frame rate display by enabling the cvar:
    cg_drawFPS = 1

  2. Also turn on the network graph with:
    cg_Lagometer = 1

  3. Connect to a server with some players and spectate someone.

  4. Look at your FPS counter and see the maximum you are getting by setting com_maxFPS = 0 to 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.

  5. ###Note the highest FPS you can render consistently.

  6. Now, set com_maxFPS to a valid value that is LOWER than what you can actually render consistently.

cl_maxPackets

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 cl_maxPackets = 59 r_displayRefresh = 60 (The display refresh rate / frequency, see note below. Default 0)
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 \cl_packetDup \cg_Unlagged

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.

Read all about Unlagged in detail here.

##TL;DR

  • Use \rate = 25000 which is 25 Kbps downstream - unless you can’t for some reason.
  • Use a good combo of com_maxFPS and cl_maxPackets or 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!

1 Like
3

you used r_swapInterval but you haven’t described what it does

4

Updated! r_swapInterval turns VSYNC on/off to limit rendered frame rate to match your set r_displayRefresh frequency. Most players should leave these alone, and instead just use sensible com_maxFPS/cl_maxPackets combo - unless you desire settings that give good visuals instead of worrying about real-time performance (e.g. visual tearing is really bad, you’re playing back demos to be recorded for video).

Additonal note to self for demo playback: cg_smoothClients = 1
… Will work this in later.

5

Minor updates all around for clarity, updated TL;DR and updated info about Unlagged. Tell us here what settings you decided on. It will be interesting to see what worked best for everyone.

6

Btw the unlagged article isn’t perfect (there are some false claims such as its perfectness on stable connections) but I guess it’s okay since there’s nothing better.

Also I hardly ever get packet loss on my connection although my test with you clearly showed that my connection cannot handle 125 packets/second.

Do you think it’s okay if I used 100 packets/second and set maxfps to 200 even though I may not always be at 200 fps on my new hardware? (I added a few attractive rendering things to it like 3-D rendered shadows and stuff which suprisingly gives it lower framerate than proper nvidia supported modern day games)

Also what does packet dialup cvar actually do between values 0 and 1?

7

I sit at around 100ms with an excellent PC and internet speed.

I find 42mp/125fps to be most comfortable.
I haven’t touched packetdup.

You can always tell if people are running 77/76 their movement looks very strange.

Thanks for the in-depth post, there’s a lot of misunderstandings on these values.

8

@ViruS if you can’t sustain 200 FPS try com_maxFPS 166 and cl_maxPackets 84.

cl_packetDup is short for duplicate - not dialup. 1 is probably fine.

@Ckit cl_maxPackets 42 isn’t a valid value combo for com_maxfps 125. Either use 63 for that maxfps or adjust maxfps to be lower to 111 and maxpackets 56 - or try maxfps 90 and maxpackets 46.

9

The question is, does it matter if maxpackets being a dfactor of maxfps?

10

Yes. It does. Generally you want 1:1 (+1) maxFPS/maxPackets but because 125 is the limit for maxPackets, sometimes you need 2:1 (+1) if maxFPS is high.

11

WRONG.

WRONG.

WRONG.

in modern connections (ie., unless u’re tapping in from an entryphone), a rate setting of 99999 is still not too high.

also, flood-time lag is really no worse than rate-limit lag.

WRONG. „rate” is measured in bytes per second.

WRONG. the default should be infinite.

WRONG. first of all, there is hardly any notion of „rate” being „too high”. but even if there is, the latency between the client and the server has nothing to do with how much is „too high”.

WRONG. it is usually the default: 0 (meaning infinite — however, a „rate” setting of 0 doesn’t mean infinite !).

WRONG.

irrelevant. vision benefits from seeing the most up-to-date snapshot of the game-world as early as possible.

WRONG. that used to be the case in 1900-era hardware setups.

u mean VALID™. there’s no inherent handicap associated with having a non-(1000/integer) setting (other than perhaps u won’t get exactly what u set).

furthermore, special values r good for the current physics engine: 125 is the best for strafejumping as an alien (to gain high speeds), 333 is the best for jumping as a human (to reach high), 43 is also kind of good (but, eg., 250 sux). (however, the benefits will only appear at times when the client is able to handle the settings.)

WRONG.

WRONG.

life sux. need to remove that crappy limit some day.

which is usually infinite.

life sux. need to fix that crappy behavior some day.

no shit, sherlock. also, prefer 125.

WRONG.

WROOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONG !!!1111111111!!11!1!!!1

WRONG.

more precisely, there real maximum is 1000 (but only applies when sv_fps is 1000).

WRONG. the number times each „user input bundle” (consisting of: time, view orientation (sort of), keys pressed, weapon being used (!), etc.) gets duplicated in subsequent packets. this does not increase the number of packets sent, it only slightly increases the size of the packets.

WRONG.

WRONG.

WRONG.