Connection, Framerate and Visual Tweaks
Connection Tweaks
There are a few more settings available than
in Quake1/2 to fine tune your connection if you are having problems with the default
settings as set via the network menu. I will document them to the best of my knowledge
here so you can experiment to see which is best suited to your connection. To set the
variables use the syntax seta variablename value at the console or include in an
autoexec.cfg file. If you are using cl_timenudge to raise your ping for offline bot practice make sure that you read the cl_timenudge section in the
table below. Our thanks to [iQ]Strider for pointing out the snaps client cap. |
|
| com_maxfps | 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. Be sure to read the Framerate and
Visual Tweaks section about r_finish command which helps input device lag. Your FPS
has an affect on Quake3 physics - See Why Your Framerate
Affects Jumping! for more information. * NOTE: If you have an internal PCI modem or a USB modem port that shares an IRQ with your graphics card you may find reducing com_maxfps helps. Similarly if you have a modem that uses the CPU for majority of tasks such as a winmodem or softmodem reducing com_maxfps may help. In both cases com_maxfps is not the root cause of the problem, it is IRQ sharing or a modem that uses CPU for majority of tasks. It is also the case that as your FPS increases so does the data size of each packet sent to the server. In extreme cases with a very high FPS you could saturate your upstream connection. See snaps for another extreme case where reducing com_maxfps may help. |
| snaps | 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.
Version 1.17 of Quake3 forces snaps client side to a maximum of 25 or in some cases a
maximum of 30. However 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. If a game server's sv_fps setting is changed from id software's default setting you may have to alter your snaps setting to compensate. As the optimal setting can be server dependant we suggest you use a snaps setting cycle script such as the one in the Script and Alias Replacements section. Leave snaps at your default until you encounter a server that needs a higher/lower setting. Currently we have seen servers running sv_fps ranging from 20 to 40 so the script covers that range. Example, you will notice on some servers in the UK such as Wireplay and Jolt which use a server side setting of 30 for sv_fps that your ping appears to be double, try using snaps 30. Due to the way that Quake3 interpolates the gameworld updates in a snaps packet for display you may find on systems with a very high com_maxfps, very low downstream bandwidth, usually 28800 BPS or less and very high latency, 300+ ping, that reducing snaps to minimum of 10 or reducing com_maxfps helps. See cg_lagometer for more information on how to adjust snaps setting. |
| cg_predictItems | Toggles whether the server or the client decides if an item has been picked up. I dislike this feature and set it to 0 so that the server determines if I have picked up an item and not my client. With this set to 1 sometimes you may think you have picked up an item when you have not. |
| cg_nopredict | Best to leave this setting alone, defaults to 0 which enables client side prediction so that your client predicts gameworld updates such as player movement when information is lost or capped. Setting this to 1 disables all client side prediction. Quakeworld and Quake2 had prediction enabled by default and the suggested (and default) setting of 0 is recommended. |
| cg_smoothclients | This setting helps smooth out movement when other players have packet loss, very low rate or low cl_maxpackets. Normally you would see them stutter or warp on your screen in multiplayer. Setting this cvar to "1" adds extra prediction code for such clients and their movements as seen by you should be less erratic. One side effect of enabling this option is that prediction errors can occur. Do not use cg_smoothclients if you are using a negative cl_timenudge. |
| pb_sleep | This setting is related to Punkbuster, setting the period of time that PunkBuster "sleeps" between processing, defaults to 60. Players with faster connection should try lower settings (20 to 40) while those with slow (modem) to medium (ISDN) connections could try setting this between 300 and 500 to reduce 'lag spikes'. |
| pb_system | This setting is related to Punkbuster, setting the memory scanning method punkbuster uses to detect cheats. Setting this option to '1' will usually give the best in game performance, if you have crashes or lockups use setting '0' |
| pmove_fixed pmove_msec |
This setting is reported to be server side ( internet, dedicated, single
player ) only and is only included here for reference and explanation should you be
playing on an internet server that has it enabled. See Why Your
Framerate Affects Jumping! for more information on why pmove_fixed and pmove_msec
when enabled server side remove FPS dependant physics. Information on pmove_fixed and pmove_msec taken from id software's documentation:
|
| 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. Note that with 1.27 or above and a Stac/Microsoft compressed connection you can no longer use higher rates than normal for your connection type. In 1.29 and above data packets are compressed server side before being transmitted to the client. 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. Connection tweak tables have been adjusted to reflect changes in 1.27 and 1.29. Point release 1.32 added the sv_lanForceRate cvar whhich can force all clients on a LAN to use the maximum rate regardless of the client's rate setting. Servers limit maximum rate so there really is no point in setting it higher than the server you are playing on allows - See cg_lagometer for a guide on how to adjust this setting. |
| cl_timenudge | This is similar to pushlatency in HalfLife, defaults to 0 which is our
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. We strongly suggest 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. Do not use a negative cl_timenudge if you are enabling cg_smoothclients. |
| cl_packetdup | 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. |
| cl_maxpackets | In Quake2 your FPS governed how many gameworld updates you sent to the
server, a high FPS gave an unfair advantage over those with lower FPS. In Quake3 a high
FPS has no advantage. The cl_maxpackets setting restricts the number of packets being sent
to the server by your client and can be used to help connection bandwidth related problems
for those with low upload bandwidth. The default setting for cl_maxpackets
is 30, usable range is 15 to 100 on the Internet, maximum 125 under point
release 1.32 or above. id software force a higher
value when playing over a LAN *. NET_SendPacket: WASEINTR problems can be caused by cl_maxpackets or com_maxfps. As your FPS increases so does the data size of each packet sent to the server. In extreme cases with a very high FPS you could saturate your upstream connection. Note that 56K modems, while downloading at upto 56000 bps, only upload at 33600 bps or less. You may wish to experiment with a lower setting such as 20 for V34 modems setup for hardware compression and a higher setting such as 60 or more for a digital connection. 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. See the note about packetloss in the cl_packetdup entry. When playing on a Punkbuster enabled server you may need to reduce cl_maxpackets and/or adjust pb_sleep to reduce lag spikes. * NOTE: If you are playing a an ISP that allocates you a 62.x.x.x IP address and you play on a server with a 62.x.x.x IP address you may have problems with bandwidth flooding. Quake3 assumes you are on a LAN and forces your cl_maxpackets to a higher setting. The only workaround at this time is to lower your com_maxfps to 100 or below (cl_maxpackets will never go above com_maxfps setting). |
| cg_deferPlayers | Setting this to 1 will force Quake3 to only load new player model/skins when you are fragged or look at scoreboard. A setting of 0 should load new player models/skins as soon as you or another player joins the server. |
| cg_forceModel | Setting this to 1 forces every player to have the Sarge model in non point release version/your player model in point release onwards and will completely stop the model loading stutter when you or another player joins the server, when you are fragged or look at scoreboard. |
| cg_lagometer | 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. |
Suggested settings are in the table that follows. They are however guidelines, adjust them as needed by monitoring your connection using cg_lagometer and alter settings based on its information. See the description of how to use and interpret the information that cg_lagometer shows in the above table. It is very important that you read the cg_lagometer, snaps and cl_packetdup notes before you use these settings. If you do not see an exact connection speed setting then use the closest. Example, perhaps you connect at 53333 or 52000 on modem, use the 50000 setting from the table. * Note: The snaps settings shown in the table are the suggested maximum for your connection type. Default is 20 and is the suggested setting. See the snaps description in the table above for a link to a snaps setting cycle script and information regarding some servers deviating from id software's standard server setting for sv_fps. ** Note: The cl_maxpackets settings shown in the table are the suggested maximum for your connection type, other settings may be optimal for your connection. See the cl_maxpackets description in the table above for more information on setting this cvar. If you are using voice communication programs such as RogerWilco, Battlecom, Teamsound etc. then please adjust settings accordingly. Allow 1024 bytes for downstream and 512 bytes for upstream usage by the voice communication program. |
|
| LAN | ** seta
cl_maxpackets "125" |
| ADSL / Cable / Wireless | ** seta
cl_maxpackets "100" |
| ISDN Bonded | ** seta
cl_maxpackets "60" |
| ISDN Single | ** seta
cl_maxpackets "60" |
| 56K Modem | seta cl_maxpackets "30" |
| V34 Modem |
seta cl_maxpackets "25" |
| 28.8 Modem | seta cl_maxpackets "25" |
| Minimum Bandwidth Settings - Testing purposes or temporary settings while lag settles. | seta cl_maxpackets "15" |
Contact Us
| SavageUK
| UpsetChaps
All Rights Reserved. Copyright © 1999-2007 Aqua & Requ!em