|
Updated
on March 19, 2001 by Thomas
McGuire
Netplay
With the latest
Half-Life patches came new netcode, which removes visible signs of lag
(i.e. There is no more need for frame rate caps). However, this in no way means
that there's no more need to tweak your netplay settings. Counter-Strike &
other mods have also been updated to take advantage of Half-Life's new netcode.
Add/Edit the following lines to your config file as
necessary. Begin by enabling the Netgraph, this will show information on
your connection & allow you to fine tune the connection variables for a
better online game.
net_graph "x".
For x there are 3 different types of Netgraph you can use. A value
of 1 enables the standard netgraph.
2 enables a more detailed netgraph, while a setting
of 3 displays a cut-down netgraph. I'd recommend setting
this to either 2 or 3. You should note
that using net_graph "3" will have no adverse effect on
frame rate (1 or 2
can).
Open your
config.cfg file search for rate “xxxx”. The default value for this
may not be correct for you. Depending on your connection, try changing the value
depending on your connection. You can also change this variable during gameplay
to suit your needs. If your ping is high you may want to lower your rate.
Try adding/editing the following to your config file.
bind "x" "rate
xxxx"
bind "y" "rate
xxxx"
You can substitute in your own keys &
rate values, I use 2600 & 3000. Set one low in case your ping
starts to rise, this is a sign you may have set it to high for the current
server, try increasing it for better results whenever possible. You can vary the
values, depending on your connection.
The red progress bar on the left hand side indicates a download in
progress. On the right hand side you can see your current frame rate, ping &
other info. When your ping is high/climbing try
lowering your rate setting, & whenever possible try
increasing your rate setting so you can receive more
data.
Reading the
netgraph
The following information was sent to me by Yahn
Bernier of Valve Software regarding the new
netcode. Some of this has been modified
for readibility of course. NOTE – If you use net_graph "1" an extra
graph will be displayed above the Framerate/Latency counters. This displays
different types of data which you are receiving & isn't
really.
1: This area
shows numeric information about the performance of your computer & its net
connection. The numbers registered are as follows (based on the above snapshot).
As shown, the client is rendering frames at 41.2 frames per second. The client
believes that it has a 332 millisecond round trip message time to the server
(this is a latency reading, rather than a pure ping, since it includes
processing overhead on both ends). The last packet the client received ("in")
from the server was 32 bytes long. The average data rate over the last second or
so from the server has been 1.05 kilobytes/second & the last packet had 3
bytes of "player" data in it. On the other hand, the last command issued by the
client was only 29 bytes long & the client is generating 1.31
kilobytes/second of upstream data right now.
2: Below the
numeric readout is the well-understood green/red/yellow/blue readout that most users are familiar with. In
particular, the height of the green line indicates
how much latency exists in the connection for the specific packet received. The green lines max out at around 1000ms of latency, so
our player here with 332 ms of latency has a green
line that goes about 1/3 of the way up the area. The red vertical lines you see indicate dropped packets. In
addition, if the client & server encounter severe connection problems, they
can become so out of date that you will see blue
lines similar to the red ones. Finally, if the
bandwidth choke is active (your rate setting is holding back packets at the
server because your connection can't handle them), then the green dot for the next packet you receive will be drawn in
yellow instead.
3: Area 4 is
correlated to how quickly the client is rendering frames. For each frame
rendered, the graph indicates how much interpolation was used in drawing objects
in the world. If you are not getting a sufficient number of server updates
(Less than 10/second) or you drop enough packets, then the client won't be able
to interpolate any more & will have to extrapolate instead. In that
case, you'll see the lower part of the graph go above the grayish line (above the
dark
blue area) & turn yellow to orange/red depending upon how far out of date your data
becomes.
4: The number
here is the number of updates per second you are currently requesting from the
server. The default is to receive 20 updates/second from the server. You
can change this value by setting the cl_updaterate "x" cvar from the
console.
5: This number
is the maximum number of command packets you will send to the server per
second. By default you send up to 30 command packets per second up to the
server. If you are running faster than 30 frames per second, then multiple
commands will be put into some packets. You can change the rate of sending
command packets to the server by setting the cl_cmdrate "x" cvar. In
addition, with each command, we re-send the last few previous movement commands
(in case there is packet loss) so that we can keep moving smoothly in the face
of minor network problems. The default number of "backup" commands that we send
is 2, but you can change this number by setting cl_cmdbackup "x" to
another number. You can send more than 8 backup commands & you should note
that sending backup commands will increase your outgoing bandwidth
usage.
6: The final
area is the light blue & (sometimes) red line at the very bottom of the
netgraph. This line is
based on your framerate & your cl_cmdrate "x" setting. For every
frame where a command packet is actually send out onto the wire, a light blue dot is placed on the graph. If commands are
accumulated for deferred sending, you'll see a red
dot instead. Try setting cl_cmdrate "x" to half your framerate to see the
effect.
|
