|
|
 |
Here is some basic and advanced info on the connection-related variables in the Quake3 engine.
To view the current value of a variable use this console command:
\variable
eg. \rate
To change a variable's value use this console command:
\variable value
eg. \rate 25000
rate
Measured in Bytes per second. This is the maximum rate at which you
will be able to receive data from the server. You should set this to
the highest downstream rate your own connection can achieve
consistently. This should not be set higher than 25000. For most of you
this will be set at 25000, but for others with slower connections, you
can take the rate at which you connect at and divide it by 10 to get
your rate value.
Now for those of you who like to tell me my rate is too low, LISTEN
UP. If you set your rate higher than what your connection can actually
achieve, this is what will happen:
When there are more players on the server (or just players
constantly shooting) there is more data that needs to be sent from the
server to the clients. If you have your rate set too high, the server
will try to take advantage of your extra bandwidth. So when the server
tries to send you 250Kbps down your 36Kbps connection, you will be
flooded, your ping will 999, you will get mass packetloss and your
connection will either hang or you will get kicked by the server.
There, so no one tell me to set my rate to 25000 ever again haha.
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 framerate.
This setting should be set equal to the server's sv_fps setting
(default is 20). Some servers (especially Threewave servers) use sv_fps
30 and I have seen some sv_fps 40 servers. I have never seen a server
using a sv_fps greater than 40. Regardless of how high you set your
snaps setting, you will not be able to receive more than the rate at
which the server runs which is defined by its sv_fps setting. So you
can set your snaps to 40 and play on a sv_fps 30 server without needing
to adjust your snaps - it will run at 30 anyway.
If you have dialup you will probably be better using snaps 20. The
higher the snaps the more bandwidth will be needed, so snaps 30 or 40
may cause a dialup connection to be less stable.
cl_timenudge
This affects how your client processes the snapshots it receives.
Normally the client compares one snapshot with the next and
interpolates between the two. If you set this to a negative value, you
can adjust the interpolation of snapshots to compensate for lag.
The more negative timenudge you use, the more unsmooth other players will appear, but the less latency you will have.
the greatest values are +/- 30, which is a hard-coded limit.
There is also another side to the timenudge story. You can use
positive values of timenudge to affect snapshot interpolation with an
opposite effect, making the game much smoother, although deliberately delayed.
Btw using timenudge will not affect your ping on the screen, simply
because your ping has not changed. Timenudge has nothing to do with
your actual ping, but it has everything to do with your latency. I would
like to add that timenudge only directly affects the latency of the
incoming data and does not directly affect the data that you send to
the server. Whether timenudge indirectly affects your outgoing data is
unlikely but that issue is best being left for a timenudge-specific
topic.
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 as your actions (run, shoot, jump etc.) will be updated more
frequently. Broadbanders will be able to go up to 125 (but not higher)
but this depends on your individual connections. Dialup users will just
about be able to manage 30, so 20 is more of a stable setting.
Also if you set your MaxPackets too high, your ping will start to
rise. This is due to the increase in upstream bandwidth usage. So you
should set your MaxPackets as high as you can without it affecting your
ping (and without going over 125).
com_maxfps
This is the maximum graphical framerate permitted. You can not use
any MaxFPS value. 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 valid Values for MaxFPS:
1000/3 = ~333
1000/4 = 250
1000/5 = 200
1000/6 = ~166
1000/7 = ~142
1000/8 = 125
1000/9 = ~111
1000/10 = 100
1000/11 = ~90
1000/12 = ~83
1000/13 = ~76
1000/14 = ~71
1000/15 = ~66
1000/16 = ~62
1000/17 = ~58
1000/18 = ~55
etc.
cl_maxpackets and com_maxfps
This is where your graphical framerate 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.
Most of you will use MaxFPS 125. If so, your valid MaxPackets
values will be as follows (assuming your PC can achieve its MaxFPS
value constantly):
(always round up these calculations to integers)
125/1 = 125
125/2 = 63
125/3 = 42
125/4 = 32
125/5 = 25
etc.
You should choose the largest value that your connection can
handle. If your MaxPackets is not set to a valid value, it is a
potential waste of bandwidth and therefore potential lag/instability.
For example, if your framerate drops to 100 then your valid MaxPackets values will change to:
100/1 = 100
100/2 = 50
100/3 = 34
100/4 = 25
etc.
So if you have your cl_maxpackets set to 100 and are using 125fps
then mostly your MaxPackets will be at 63 (highlited in yellow above)
(this is the largest value not exceeding the input cl_maxpackets
limit). However, when the framerate drops to 100fps, the MaxPackets
will change to 100 as this is now the largest value that does not
exceed the input cl_maxpackets limit (highlited in yellow above). If
your connection cannot handle 100 packets it will cause your ping to
rise or spike. Even if it can handle the jump from 63 to 100 packets,
this may well cause your ping to fluctuate more than if your actual
MaxPackets were constant.
|
|
