Basics in Quake 3 Connection
•
12 May 2007, 01:43
•
Tutorials
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.
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.
- 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?
things that might help:
- r_finish 1
- using a lower prerender limit
The graphic card doesn't render a new image until the monitor read the complete current one.
I got another question:
Are r_displayrefresh and com_maxfps related?
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.
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.
Syncing fps with the monitor refresh on a TFT is quite useless. The reaction time and update frequency add up.
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?
Insofern dein TFT eine feste Updatefrequenz hat, was soweit ich weiss die meisten haben, wäre dieser Wert natürlich der beste (meist 60Hz).
:-))
:) one hell of a guide helped me a lot
oh and btw -> http://www.funender.com/quake/info/fps.htm
i thought its about q3 ;>
my fault =)