Basics in Quake 3 Connection

Here is some basic and little advanced info on the connection-related variables in the Quake3 engine based games like ET and COD.

Quake3 engine is somehow different from other engines. Its netsettings are not just dependable from one thing but sum of many like FPS, MaxPackets and so on and so on.

I've tried to explain basics on cvars that affects your playing. Cvar restrictions are from CB's configs.


Rate:

Measured in Bytes per second. This is the maximum rate at which you will be able to receive data from the server. This cvar is limited IN 15000 to 25000. For most of all players this should be set at 25000, since almost all has a decent internet connection. But if one happens to play with crappy ISDN/modem connection then one should take the rate at which you connect at and divide it by 10 to get your Rate value.

So what would happen if one has crappy connection and sets rate too high? The server thinks that it has 25 000 bandwidth to your machine and sends packets more than your connection could possibly handle. Then your ping will go to 999 and you'll get packet loss.


Snaps:

This setting is the number of 'snapshots' that you receive from the server per second. A snapshot is a "picture" of what is happening in the game since the last snapshot. This is the data transmission equivalent of a frame rate. This cvar is limited to EQUAL to 20. It used to be 40 but then it lowered because there were a bug in it which hindered hitting.


Cl_PacketDup:

This cvar duplicates your packets amount of time your packetdup is set. Cl_PacketDup is limited IN 0-5 iirc. In theory if one has perfect connection with 0 % packet loss then this cvar should be set to 0 because there is no need to send same packets all over again. In practice this is good to be set to 1-2, it helps in many cases and set to 0 might be a reason for fps drops. (Since everything affects everything.)


Cl_MaxPackets

This is the maximum number of data packets that can be SENT to the server per second. The higher you set this, the smoother your game will feel because your actions will be registered more frequently. This cvar is limited to be IN 40 to 100. 100 should be the perfect with decent connection to have the best connection. Still if one sets this too high then ones ping will began to rise. Then lowering MaxPackets will help because game uses less upload bandwidth.


Com_MaxFPS:

This is the maximum graphical framerate permitted. You can use any value IN 40 to 125, but actually the only valid values are those which are equal to (1000/x) where x is an integer. So for example your 125fps comes from (1000/8 = 125). If you try and set MaxFPS to 120, you will still get 125fps. This is because any invalid setting is rounded up to the next (1000/x).

Some "magic" numbers:

1000/3 = 333
1000/4 = 250
1000/5 = 200
1000/6 = 166
1000/8 = 125
1000/10 = 100
1000/13 = 76
1000/14 = 71
1000/23 = 43

Remember that MaxFPS has more effect to everything than almost any other cvar in whole engine. For example with 71 FPS one has the lowest recoil and with 333 one used to go faster than lower fps guy. Also it's noticeable that guy with 333 fps is more unhittable than the other. (Atleast in RTCW :o))


Cl_MaxPackets and Com_MaxFPS:

This is where your graphical frame rate affects your connection. The actual MaxPackets sent to the server MUST be equal to (your_FPS/x), once again where x is an integer. If you set your MaxPackets to a value which is not equal to (your_FPS/x) then your MaxPackets will actually be rounded down to the nearest valid setting, and we don't like that.

Most of you will use MaxFPS 125 for now on. If so, your valid MaxPackets values will be one of followings:

125/2 = 63
125/3 = 42
125/4 = 32

You should choose the largest value that your connection can handle, but keep on mind that cl_MaxPackets is limited to IN 40 to 100. So if you set com_MaxFPS to 125 you will actually send less packets than with lower value of MaxFPS.

So let's change the MaxFPS to 100 and see what happens to the MaxPackets?

100/1 = 100
100/2 = 50
100/3 = 34


Personal recommendations:

We all want to have the smoothest game especially when ET's aiming is almost everytime hitscan tracking. Since CB has limited the MaxFPS IN 40 to 125 and no one is going to raise cl_MaxPackets limit to 125, I recommend using following settings to have the smoothest touch to the game:

rate 25000
snaps 20
cl_MaxPackets 100
com_MaxFPS 100
cl_PacketDup 2
pollingrate 250 to 1000 whatever your hardware can handle and you feel the best.
r_displayrefresh 100, but r_svapinterval 0 because it's bugged and sucks. If you are playing with flat monitor like LCD or TFT... well... I can't help you.

Please feel free to comment and add toughts.
Comments
23
nice read, and helpfull for the players who start tweaking their CFG
- rate and snaps are connected: the packets you described in the rate part are the snapshots.

- snaps is connected to sv_fps, which is forced to 20. setting it to a higher value would result in less lag. however parts of the gamecode are highly dependent on sv_fps set to 20, so using any other value might an will result in bugs.
you can't receive more snapshots than the server renders.

- "r_displayrefresh 100, but r_svapinterval 0 because it's bugged and sucks."
what's bugged about it?
It's bugged about that cursor movements are not as sharp as without it and cursor somehow "lags"... Moving like in oil.
Parent
That's no bug. That's vsync.
things that might help:
- r_finish 1
- using a lower prerender limit
Parent
It is bugged if it won't work properly.
Parent
It works properly / as intended:
The graphic card doesn't render a new image until the monitor read the complete current one.
Parent
Very good guide, made some things clear to me.
I got another question:
Are r_displayrefresh and com_maxfps related?
Parent
Displayrefresh is just the frequency in which your monitor refreshes itself (hardware) and maxfps is in which your game refreshes itself (software). The best solution is when these two are syncronized. Ofcourse one can raise these both values so high that the eye won't notice the difference becouse time between those becomes so insignificant. I mean the settings like r_displayrefresh >140 and com_maxfps >200 for example.
Parent
aha, but iam using a tft which means that my displayrefreshrate is "locked" at 75 (is it?).
So would it make sense to lower displayrefresh to 50 (because my maxfps is 50, crappy pc :<), so the values of displayrefresh and maxfps are equal?
thank you already btw.
Parent
TFT's techonology is so different that you should just use r_displayrefresh 0 and maxfps <what you want>.

I don't want to explain the differences here becouse I'd had to do another article. If you want to know then find it out yourself using wikipedia and google.
Parent
On a TFT it's a compatibility setting, BUT setting it to the wrong value might/will result in a worse performance. (e.g.: not displaying a frame in order to resynchronize to the default update frequency)

Syncing fps with the monitor refresh on a TFT is quite useless. The reaction time and update frequency add up.
Parent
Thanks for bothering/helping man, i got another 2 questions:
Quote by wipeoutSyncing fps with the monitor refresh on a TFT is quite useless.

Also dass heisst, dass man, wenn man einen TFT benutzt den CVAR r_displayrefresh bedenkenlos auf 0 setzten kann? Oder müssen es die Hz des Monitors (75) sein?
Parent
0 hiesse, dass man die derzeitige Windows Einstellung benutzt.
Insofern dein TFT eine feste Updatefrequenz hat, was soweit ich weiss die meisten haben, wäre dieser Wert natürlich der beste (meist 60Hz).
Parent
Vielen Dank für die Info.
:-))
Parent
Some nice info thx for this link i was shocked at 125fps jumps good as 250 :O
Parent
great info thanks
Parent
cl_maxpackets is limited in 40-125 in cpma
We are talking about ET now mister :)
Parent
wattafack?
i thought its about q3 ;>
Parent
Well about q3-engine, but the examples are from ET :)
Parent
i didnt read everything
my fault =)
Parent
Back to top