Bloodwolf Posted August 23, 2005 Report Posted August 23, 2005 (edited) Para todos aquellos q gustan del online play... y sienten q no les esta corriendo bien la conexion manda no probar los commandos adecuados a ver si mejora. Los mas importantes y su descripcion: 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. 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_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. Tabla de Valores Recomendados: LAN seta cl_maxpackets "125" seta cl_packetdup "0" seta snaps "40" seta rate "25000" ADSL / Cable / Wireless seta cl_maxpackets "100" seta cl_packetdup "1" seta snaps "40" seta rate "25000" 56K Modem 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" Fuente:Upset Chaps Edited September 7, 2005 by Bloodwolf
Recommended Posts