Here's some of the Q3 console commands that may help your connection online.
1) Client FPS. (com_maxfps "x" x = your average FPS from the cg_drawFPS setting)
Don't intentionally set your client-side FPS too high. Doing so will force your PC to request more information from the server, saturating your connection and skipping packets when your connection can't keep up with what it's being sent. In Quake2 your FPS governed how many gameworld updates you sent to the server, in Quake3 this is no longer the case. While this setting will not usually* improve your connection it does help stop the confusion between connection lag and graphics related lag when, for example, jumping from 85 FPS to 23 FPS. Set this by monitoring your FPS while playing using cg_drawFPS "1" and set com_maxfps to your average steady FPS rate.
2) Client-side Snaps. (snaps "x" ... x = 10, 20, 30, 40)
Difficult to explain, but related to what the Server's FPS is set to. Our Server's FPS is currently at the Q3 default, which is "20." As most people aren't aware of this setting, or how to change it client side, I don't screw with it. If I did, everyone connecting would have to alter their client side snaps setting to match, or suffer severe gameplay issues.
The snaps setting is used to calculate how many gameworld updates you receive from the server. Usable range is 10 to 'server sv_fps setting' and defaults to 20. The network code works in such a way that snaps should always be set to match or be above the server's sv_fps or a divisor of it (e.g. our Server is at "20," you could set your snaps to "40.")
In your console, you could simply "set snaps 20" to force it to match, or paste this script into a text file, call it somename.cfg and do an "exec somename.cfg" in the console to enable it. The current bound key in this script is "s," meaning once you've loaded the config, press "s" to see it cycle through the different snaps settings to note the effect.
set SetSnaps1 "set snaps 10;wait;set SetSnaps vstr SetSnaps2;wait;echo Snaps 10"
set SetSnaps2 "set snaps 20;wait;set SetSnaps vstr SetSnaps3;wait;echo Snaps 20"
set SetSnaps3 "set snaps 30;wait;set SetSnaps vstr SetSnaps4;wait;echo Snaps 30"
set SetSnaps4 "set snaps 40;wait;set SetSnaps vstr SetSnaps1;wait;echo Snaps 40"
bind s "vstr SetSnaps"
3) Client Time Nudge (cl_timenudge "x" ... x = 5, 10, 15 or 20)
This is similar to pushlatency in HalfLife, defaults to 0 which is the suggested setting for online play. In Quake3 it is normally used for offline bot practice by using a positive value that is the same as average ping. However, a positive value can also be used to stabilize displayed frames with gameworld updates(snaps) and negative values are reported to adjust client side prediction.
It is suggested you leave cl_timenudge at 0 for online play. However If you do wish to alter cl_timenudge to adjust client side prediction then try a negative value that is 25% to 50% of your average ping. Example if you are currently pinging 100 to the server then experiment with a setting between -25 to -50 as your cl_timenudge value. Note that if you are using a negative value for cl_timenudge the top graph in cg_lagometer may be mostly yellow.
A positive value may help if you have problems with gameworld updates (snaps) not being rendered in time. Try a small positive cl_timenudge value of 5,10,15 or 20 never higher. See cg_lagometer for an explanation of how to determine if gameworld updates are not being rendered in time.
4) Client Max Packets. (cl_maxpackets "x" ... x = same as average FPS and/or Framerate, as the hope is all these match)
In all cases try to set cl_maxpackets to equal your average framerate or your com_maxfps setting or a divisor of it without saturating your upstream bandwidth. Use the FPS figure displayed using cg_drawFPS "1" as a guideline for actual FPS. For Example if you are currently at com_maxfps "76" then try a value of 38 or 76 for cl_maxpackets. If you have set your FPS above 100 then use a divisor of your FPS, for example if you are currently capped at 125 FPS then try 31/32 or 62/63 as a cl_maxpackets setting.
5) Client Packet Updates (cl_packetdup "x" ... x = 1 - 5)
This setting determines if duplicate commands are sent, range is 1 to 5 and is 1 as default. if a packet gets lost then a 'backup' command may still be received. Set to 1 as default which is recommended if you have packet loss. If you have an excellent connection with very little or no packetloss at all then this could be set to 0 and cl_maxpackets possibly raised. However, as with all settings experiment to see which is best suited for your connection - See cg_lagometer for a guide on how to determine if you need to adjust this setting.
6) Client Rate (rate "x" ... x = bytes per second rate)
Identical to the rate setting in Quake2 in that it controls packets so that your downstream connection bandwidth does not get saturated. Setting controls maximum bytes per second. Even though rate cap limits will be unchanged the actual amount of data sent in packets for a given rate limit will be greater as upto 5:1 compression is possible. In essence a 8000 rate cap limit could mean that after decompression on the Quake3 client you are actually receiving 12000+ bytes for a rate cap of 8000. Servers limit maximum rate so there really is no point in setting it higher than the server you are playing on allows.
7) The Lagometer (cg_lagometer "x" ... x = 1 or 0)
Set this to 1 to monitor your connection - The first line is related to your graphics card updating displayed frames in time with received gameworld updates from the server. It will be blue if frames are being rendered in time with the world updates. If it has a lot of yellow then gameworld updates are not being displayed and are being dropped. In this case reduce your snaps or tweak your visual settings to raise your average framerate so it is always above your snaps setting. Another option is to increase cl_timenudge by a very small value, note that if you are using a negative value for cl_timenudge the first line of the graph may be mostly yellow. See cl_timenudge section for more information.
The second line is similar to the Quake2 netgraph in that green means packets are being received okay, yellow that capping is causing your client to reject packets and red that the packet was lost. In the case of yellow increase your rate or try lowering your snaps. If you have a lot of red then change ISP or server. If you have to play on the server or use the ISP then make sure that your cl_packetdup is set to 1 and try adjusting snaps and cl_maxpackets to compensate for the lost packets.
Some settings you may want to try:
ADSL / Cable / Wireless
seta cl_maxpackets "100" (maximum)
seta cl_packetdup "1"
seta snaps "40" (maximum)
seta rate "25000"
seta cl_maxpackets "30"
seta cl_packetdup "1"
seta snaps "20"
seta rate "(See Table Below)"
50000 BPS: seta rate "5500"
48000 BPS: seta rate "5200"
46000 BPS: seta rate "5000"
44000 BPS: seta rate "4800"
42000 BPS: seta rate "4500"
40000 BPS: seta rate "4300"
38000 BPS: seta rate "4100"
36000 BPS: seta rate "4000"
Well, these commands/configs helped my ping a lot. 30-40 ping lost when I changed all those things. But I don't think it will help my actual gameplay as much as I would have hoped. For example, force still lags me like CRAZY...I was on the server will a lightning crazed bot and every time he used it it lagged me...uncontrollably ( I had to retreat to my hole in the wall to recover). I was not able to test all of these on a server packed full of people, but I imagine that it wouldn't have helped as much as I would have liked. The only reason that im thinking this is because that before the packets got changed back and I started lagging again, force and people would lag me about equally...I guess ill have to wait till April...and since Im having one of those 56k problems..(time limit BAH)..I guess ill go
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (WDYL-WTN Release)