The following is a copy of file sent to me by TA FA player. If admins think it bad idea to mess with these console commands to change FA net use "cvars", then I apoligize and understand if you take this post out. It has some surprising/interesting info. I wonder if some already using these mods may casue others that are not, net performance probs...I've put this off too long Over 4000 words and its done (or rather ive got bored of adding to it, youll have to do without the troubleshooting section). It would be nice if you could move this to teh support forum o?nce it becomes inactive. This is my long-awaited netcode guide for Half-Life in general and Firearms in particular. It is not specifically designed for a single connection type, nor will I give you any specific values, since the best value depends o?n almost every aspect of your system and connection. I will, however, often refer to modem or broadband since these are so wildly different despite their many types. ISDN users will just have to consider themselves as being between the two I also a section of tweaks for server admins. And no, I wont tell you how to produce fake lag (its easy to do though). And anyone else who has a cached LAN, you're buggered. Just accept it, theres not much you can do except act like you have a modem. Remember that Half-Life is a single player game, and was designed as such. Anything that seems a stupid way for a multiplayer game to work probably is, but is there because it is a good way for a single player game to work. So this time, please no they would never do it that way comments. Many of you will wish to skip the next few paragraphs, which explain how the game works, and go straight to the cvars later o?n. However, reading the explanation will make it easier to understand what you are doing, and will help to find the best values. And you will have to follow the cvars in order, as most of the tweaks I give wont help unless the previous o?nes have been done. In a single player game, there is no point in the game working out what is happening between frames, since the gamer will o?nly be affected by what they can see and hear. Half-Life therefore proceed in game frame. In single player these are simply the same as the graphical frames (as in fps - frames per second). Whilst the graphics card renders the next frame, the processor calculates what is happening in the game (damage levels, movement, AI etc.), and the next frame does not start until both tasks have been completed. In a multiplayer game, this works slightly differently depending o?n whether a listen or dedicated server is being used (dedicated servers are indicated by a small server icon next to them in the server browser, others are listen servers). For a listen server, the network frames (the frames in which the network game proceeds) are the same as the hosts game frames, and therefore the same as their graphical frames. For a dedicated server (and all good servers are dedicated) the rendering task is stupidly easy, as a dedicated server merely displays the console, which can be rendered extremely quickly as there are no 3d calculations to be processed. Therefore the servers frame rate will depend only o?n how fast it can process the game information (calculating movement etc.). Dedicated servers typically run at 80 fps or higher, and during lulls in the fighting often hit the HL framerate limit of 100fps. They would run at 100fps all the time except for having to handle all the requests for data and client updates. Try setting up your own server, o?nce a few players join then your framerate will drop markedly. In the current version of Half-Life, Valve claim that network and graphical framerates are completely separate, allowing modem users to run at 100fps without degrading their network performance. In a way this is true, so long as graphical framerates are far (at least 3 times) higher than network framerates. However, a new network frame still cannot be started until the concurrent graphical frame is finished. This means a graphical framerate which is close to the network framerate can cause irregular network frames. Because of the way in which both the internet and Half-Life work, network problems such as high latency and packet loss are minimised by having a regular stream of updates. This is because of synchronising with the servers framerate, setting up virtual circuits o?n the PoPs, and modem time-switching algorithms, amongst others. Thus irregular network frames lead to the things we all hate, the several phenomenon which are categorised as lag. I feel I had better describe what these are before I tell you how to minimise them. Ping - Don't ask me what it stands for, I can't remember. The P is for packet though. This is the amount of time (in milliseconds, or thousandths or a second) between a packet being sent by your computer to the server and the reply (the ping) being received. This is the o?ne which is most dependant o?n your connection type, most modems will take around 150ms to even get to their ISP, so pings rarely get below 200. An ADSL user will probably o?nly have 10ms or so to their ISP, so they start hitting the fundamental speed limits of their part of the internet, and these are the players who are most affected by server location (if you can call the difference between 30 and 80ms an effect). Packet Loss - This is probably the most important and most tweakable effect, but o?ne which is often ignored in favour of ping. A lost packet is o?ne which at some stage of its journey is discarded, either because it is too old (the most usual o?ne) or because bandwidth limitations prevent it being forwarded. Those annoying Connection Problems? Those are when your packet loss hits 100% (ie nothing is getting through) for a few seconds at a time, or even permanently (which is why you drop after a while if your not tweaked correctly when these awful problems occur). Choke - This is the average time (in milliseconds) between a packet being generated o?n your computer and it being sent to the server. It is o?ne of the major goals during tweaking to get this to 0, or at least as close as possible. Broadband Slowdown - High pingers DO NOT cause lag. How that stupid myth got around I don't know, but it's complete nonsense. In fact, as you probably now guessed, broadband connections slow servers. Broadbanders ask for many updates a second, each of high accuracy (packet size), whilst sending large numbers of updates themselves, again each of large packet size. All that bandwidth gets used up (the server bandwidth used by a single broadband connection could support five to ten modemers) and all the packets being sent place a drain o?n the servers processor and RAM usage. The most unfair part of this is that its actually the modemers who feel the attendant drop in performance the most, in a way paying for the sins of the broadbanders. Maybe that's why the myth grew, whenever there's a slow server, any modemers will have a high ping, so broadbanders just assume that is the cause of the slowdown, not its affect. Not o?nly is it vastly unfair to kick modemers when a server begins to slow down, it also will probably make no noticeable difference. It is also worth bearing in mind that all of these are affected by the netcode of the mod being played, for example CS and to a lesser degree DoD are built to get the players pings as low as possible, without even thinking about packet loss or choke. This is all well and good for those with broadband and good graphics cards, but the teams obviously don't give two shits about anyone with a sub-standard graphics card or a modem. Thankfully, Firearms is built with a good mix of these, with such things as client side accuracy immensely helping reduce network traffic and therefore helping those with restricted bandwidth (ie, modemers). How do you find out what these values are for you? Well, Half-Life has a wonderful little tool called the netgraph. You turn it o?n by typing net_graph 1 in the console. Values 1-5 are valid, each showing slightly different things, whilst 0 turns it off. I use 3 personally, but find the one which you use the most. The netgraph can cause a strain o?n graphical fps, but I find it minimal. only those with significantly higher graphical fps than network fps should see a big drop. If so, you can decrease its size or turn it off altogether o?nce you have tweaked your netcode. The following is an explanation of net_graph 1: <see above for the pic> 1. FPS Counter - Your current frame rate. 2. Network Latency - This is your current network latency. (ping) 3. Your downstream bandwidth use. 4. Your upstream bandwidth use. 5. This is an animated graph displaying your ever-changing ping. The higher your ping, the thicker this graph gets. This also displays your lost packets in red, and mismatched entities in blue. 6. Your current server update (incoming) rate. 7. Your current client update (outgoing) rate. A CVar is a client variable (or a server variable), a value governing some operation of the engine which can be changed by the client (or server administrator). For example con_color can be used to enter an RGB value for the colour of the text in the console. I am going to examine each relevant cvar, explain its use, and give guidelines o?n its best settings. I will inevitably miss some of them (there are hundreds, although most don't really affect the network performance). In each case, x is a number, and they should be entered in the console (although they can also be entered in the command line). Netgraph CVars net_graph x - as noted above, enabled the netgraph. 0 is off, whilst 1-5 display different combinations of information. 0 is default. I like 3. net_graphpos x - determines the position of the netgraph o?n the screen. 1 is bottom right, 2 bottom centre and 3 bottom left. 1 is default. I happy with 1, but some set it to 2 and then move the compass to the top of the screen. net_graphwidth x - the width of the graph in pixels. o?ne pixel is used in the graph part for each packet sent. 192 is default. Remember to keep it large enough for the text to be readable. Net_graphheight x - the height of the graph in pixels. 64 is default. Again, keep it large enough to be readable. Ever wondered why the ping displayed o?n your netgraph is usually less than the latency displayed o?n the scoreboard? Well, the netgraphs ping is purely the network ping time. The latency in the scoreboard is more representative of the time obstacles against the player, as it includes the time each packet takes to be rendered and displayed on the clients computer. They are both useful, but in different ways. FPS Related CVars fps_max x - Sets the maximum graphical fps. Any integer between 1 and 100 is valid, whilst 72 is the default. Half-Life will attempt to divide each second evenly into this many slices. If the rendering process ends before the slice, then it will begin rendering the next, but it will never go more than one frame ahead, to conserve memory usage and stick to the framerate. If the frame isn't rendered before the slice ends, then the next slice is allocated to that same frame. No-one ever believes me, but this is the single most important variable for adjusting the netcode. Since everything in Half-Life is linked to frames, and all frames depend o?n the graphical frames, this is extremely important. The advice I see all the time is to set this to 100 (the maximum value), so that as many frames as possible are rendered meaning the minimum time between a packet being received and it being rendered. This is completely and utterly WRONG. As noted earlier, netcode revolves around predictability, and regularity is the most important thing. It is better to have a regular fps of 20 than o?ne which jumps between 20 and 30. In fact, often setting a lower fps_max can raise the average framerate, because the renderings are fitting nicely into the time slices, which eliminates the inevitable wasted time when a frame requires just over one slice to render. In fact a value which is close but not quite right is worse than o?ne wildly off, since each slice is bigger, wasting half a slice is more harmful. You need to gradually decrease this value until you find a point at which your fps is almost constant at the limit. There will be areas of some maps or large firefights in which it may drop, but it needs to be constant in normal play. If it isn't, drop it. It may start to look bad as you get closer, but when you have the correct value it will look better than you would've thought, since the frames will be regular and therefore easy for the brain to interpolate to a moving image. This is why TV looks better than a game running at an average of 24fps, since TV is always regular. As detailed below, correctly adjusting this single setting can reduce ping, packet loss and choke all in o?ne. Still don't believe me? Then stop reading this guide, the rest of it is pointless if you haven't done this step. If you end up with a framerate which is too low (ie under 20) then you should consider dropping detail levels to improve rendering speed, some tweaks for which are included at the end of this guide. fps_modem x - don't be mislead by the name, this is equally valid for all connection types. Sets the maximum number of graphical frames per second for an internet game. This or fps_max is used, whichever is lower. Any number between 1 and 100, 100 is default. This is o?nly of any use for those who play both o?n LANs and the internet, since they will run at fps_max during their LAN game, and at this in their internet games. If you didn't think fps could affect network performance, then why would there be different cvars for different network types? I bet some people still don't believe me. It is probably worth reducing detail levels and getting a higher fps during LAN games, to take advantage of the extra bandwidth. If your running over 50fps anyway its not worth it though. fps_lan x - sets the maximum number of graphical frames per second for a LAN game. This or fps_max is used, whichever is lower. Any number between 1 and 100, 100 is the default. This is irrelevant for almost any HL mod, since it o?nly matters if the mod is being played in single player (where fps_max will be used), LAN (fps_lan) and internet (fps_modem) play. I know of no such mod. The o?nly other situation I can think of this being used is if the same machine is sometimes used for running a dedicated server, and at other times playing o?n both a LAN and the internet. In this case, the fps_lan and fps_modem values would set the values when playing, whilst fps_max would be set at 100 to allow the dedicated server to run as quickly as possible. Again, rather unlikely. Idiotic Lag-Compensation CVars I say idiotic, because I fail to understand why anyone would want to change them, but when lag comp first came out everyone o?n broadband wanted to know them so some people must somewhere. cl_lc x - 1 or 0, 1 being default. 1 tells Half-Life to use the lag compensation (assuming the mod and server support it), whilst 0 turns it of. Lag compensation is the system whereby you hit what you were aiming at when you fired, instead of having to fire ahead of the target. Why you would want it off is beyond me, unless you have a ping of less than 10. Maybe o?n a fast LAN, where it would reduced required bandwidth, but since LANs have tons of bandwidth to spare anyway there's really no point. Leave it o?n. cl_lw x - 1 or 0, 1 being default. 1 tells Half-Life to use client side accuracy and recoil. If turned off, when you click fire you wont see the gun fire for a pause equal to your ping time, because it will wait for the server to tell it how much recoil there was and where the bullet went. This may make a bit of sense in mods which have server side accuracy and recoil (CS being the most obvious and heinous one), but since Firearms uses client side prediction for these anyway, and the server lines up with what the clients tell it rather than the other way around, there's no point and it actually makes the game harder, since you can't adjust for the recoil. It makes no difference to bandwidth usage, since 1 sends it to the server, whilst 0 sends the same data the other way. Leave it o?n. cl_lb x - 1 or 0, 1 being default (0 used to be, and is listed in some guides). 1 tells Half-Life to place blood sprites if the client thinks you've hit your target, whilst 0 will wait for confirmation from the server. This can look weird, and o?nly serves to indicate if you really did score a hit with highly inaccurate guns in server based accuracy and recoil mods, like CS. In Firearms its pointless. Leave it o?n. Direct Netcode CVars These cvars directly affect the network packets, so can make a large difference to performance. Setting them wrongly can make the game unplayable, or even lead to constant connection problems once you join a server. Make sure you make a note of your previous values before changing them (to find this, type the cvar without a number after it. Half-Life will list the current value). cl_updaterate x - Any integer value between 1 and 100. 20 is default. This is the number of updates the client wants to receive from the server each second. Barring something going wrong with the server (eg its fps dropping right down due to a large amount of fighting, or too many broadbanders being connected) the server will indeed send this many. The client doesn't actually send this many requests, just when you join the server (or change the value) it sends the server a packet saying please send me this many updates a second. The server will attempt to send these. The best value is equal to fps_max, but don't go over about 30 (even 25 is pushing it). If your fps_max is higher than this, then choose a value which is a simple multiple of it. Eg. if fps_max is 42 then use 21. The game o?nly really begins to look jerky around 13, so don't be afraid to try values down to about 15. This sort of value will only be noticeable when things move very quickly ingame, eg grenades from the m79, gp25 or m203. Since it's only telling you what's already happened o?n the server, there's no need to have a really high value, higher values o?nly place unnecessary strains o­n the server, leading to broadband slowdown. Oh and set this to 50 for LAN games. cl_cmdrate x - Any integer between 1 and 100. 30 is default. Basically the opposite of cl_updaterate, this sets the number of outgoing packets sent each second. There is absolutely NO reason to set this any higher than fps_max, since it will just be sending the same data twice during some frames. Since outgoing bandwidth varies less than incoming bandwidth, you can generally get away with values up to about 40 (modems up to 30). Set this to the same as fps_max, or a simple divisor (eg. half of it) if your fps_max is higher than these limits. cl_rate x or just rate x Any integer from 0 to 99999. Default is set by which connection u chose o?n install. This is that amount of data in bytes allowed to be sent every second (total of up and down stream). Basically there is a trade-off here between bandwidth and smoothness. The higher this is, the more data gets send each second, and the better the client can keep track of what is happening o?n the server. However, at the same time it takes up more bandwidth, both o?n the client and the server. As a client you will want to set this as high as you can o­n your connection, for optimum smoothness. Setting this too high will result in package loss, as there physically will not be enough bandwidth to send some of the packets. Try a bit higher than the values below and then drop it until your packet loss disappears (or reaches a minimum, it may be the server). When changing this setting, it is important to realise that it makes a difference to connection reliability, so you should try each setting for 5-10 minutes before deciding whether to drop it again. These are approximate values for the rate, although since this is the most variable setting of all your connection could be wildly different. 56k modem or 64k ISDN 2500-3000 128k ISDN 4000-5000 cable modem 6000-8000 xDSL or T1 7000-10000 LAN 10000 cl_resend x Any integer between 0 and 16. 6 is default. This sets the maximum number of times to resend any lost packets. If you have followed the above tweaks u should really get much pl, but setting this to 1 will reduce pl without affecting performance and flush too much. cl_timeout x Any integer between 0 and 1000. 30 is default. Sets the number of seconds after which the connection is given up for dead if no packets have been received. Often it is recoverable, especially if you can see the in and out rates fluctuating. Setting this to 90 works for me. Download CVars cl_allowupload x - 0 or 1, 1 default. When set to 1 this will upload any custom spray-paint you may be using. Since this causes hardly any lag, o?nly for the first 20-30secs, and since it lets other players see your spray-paint, you should leave it o?n. cl_allowdownload x 0 or 1, 1 is default. When set to 1, HL will download any sounds or maps form the server needed for the next round. For sounds this is best left o?n, since they probably rent available in a pack, and if they are by the time you've found them u would have downloaded them already. However, you should NEVER download a map this way! The map wont be zipped, and the HL connection is slower than an ftp, so you are probably trebling the time it would take you to download the map anyway. Take a look in the mapping forum here, there's a map releases thread that has links to all the custom maps I've ever needed. cl_download_ingame x 0 or 1, 1 is default. When set to 1, this will allow HL to download other players spray-paints during the game. For eh same reason as cl_allowupload, you should leave this o?n. However, the images downloaded are stored in a file called custom.hpk in your firearms folder, and I recommend deleting this periodically (every two weeks is about right) since it can get quite big and take up a large chunk of your RAM and loading time. HL will create a new o?ne as necessary anyway. For Server Admins These are tweaks a server admin can use to optimize the networks performance whilst playing o?n their server. I'm not absolutely sure about any of these, since I haven't had a server to test them o?n. sv_maxrate x Any integer from 0 to 99999. 99999 is default. Sets the maximum rate for any o?ne client. This multiplied by the max players should be about two thirds of your total bandwidth (as its not 100% efficient and u want to leave some over for spray downloads and stuff). However I often see it higher than the max bandwidth, which is stupid because everyone starts having their rate automatically reduced. This not o?nly messes up carefully set up netcodes, but it also means the modemers suffer at the expensive of broadbanders and causes broadband slowdown. I would actually like to see a server which sets this to 3000 so everyone gets the same performance, no matter their connection type, but I don't think it will happen. sv_minrate x - Same as sv_maxrate, but sets the minimum rate instead of the maximum one. a bit pointless, people should be allowed to set their rate as low as they like. Set to 0 sv_dlmax x Any integer from 0 to 99999. 99999 is default. Sets the maximum volume of downloads to send to any client in kB. MAKE SURE YOU SET THIS CORRECTLY. The absolute best value is 500. This is large enough for the client to get any sounds, but smaller than almost all maps. This mean the clients will not be able to DL maps off your server, which is horribly inefficient and really lags the server badly, especially if they are o?n broadband. Well thats all i can be bothered to do, its possible ill edit in a troubleshooting section and some more admin stuff. Sorry it took so long people

Different combinations of those commands are why certain players seem to warp all over the place, or seem hard to hit.

 

At least thats how it was explained to me...

 

PUNISHER

ok, thanks, PUNISHER ... the reason I've been exploring the setup of both pcs here for me and Tigerhawk is ... I've been trying to figure out if there may be problem with high-speed cable at our end ... or, software setup ... or anyhing else ... all been checked out to be good ... THE PROBLEM FOR LAST FEW WEEKS HAS BEEN ... when you play as PUNISHER or JOBU, as well as another player named PARABOLA ... we get major lag/fps drop when either of you come near ... no problem with any other palyers or in other servers ... we.ve heard and seen on screen as well, other players complaining of same lag when you around ... stuff like 2 fps and gun clicking but not shooting at you ...

 

so we're wondering if you have any idea, like "modifications" / "tweaks" / etc ... ?

 

not accusing you of anything ... just wondering if you or anyone has any idea why this happening ?

 

it's frustrated Tigerhawk to point of not playing with her usual name if you there ...

 

i've explored all possibilities that may cause it at this end and found nothing to explain or improve it .

 

has anyone else noticed anythiong similar with gameplay at TA when these 3 names are there ?

 

we not pointing fingers :wink: just trying to figure out why it only happens to us and others when you 2 are there.

if you just want to know your fps (netgraph can slow system) you could usecl_showfps "1"

No.My rate is 30000 that's all I changed.I've also heard players can warp if they have an extremely high upload capacity.I tested my DSL and it uploaded like 4 times faster than normal DSL. I'm not sure if that has anything to do with it or not.On a side note, If you are being hit alot it will seem like you are lagging.I use the m16 a lot to make sure I'm always hitting the target and not just spraying full-auto.----------------------------------------------------I've also heard that changing those settings can help bullet register. Last night on TAC I tried using almost everygun and nothing would register for me, it was really freakin' weird.I went to the stars server to see if it was just my aim but it wasn't. All my shots were landing and killing so there must have been something messed up between the communication of my computer and the TAC server.I don't really know much about this stuff but I know what I observed and I'm convinced there are times when bullets just don't register for some people.PUNISHER

I've also heard that changing those settings can help bullet register. Last night on TAC I tried using almost everygun and nothing would register for me, it was really freakin' weird.

 

I went to the stars server to see if it was just my aim but it wasn't. All my shots were landing and killing so there must have been something messed up between the communication of my computer and the TAC server.

 

I don't really know much about this stuff but I know what I observed and I'm convinced there are times when bullets just don't register for some people.

 

PUNISHER

I noticed this also.. Last night, I would put my trusty crosshair on someone's head, pull the trigger, see blood splatter, but their health wouldn't change (I use med, and I look at people's health as I am dying :wink: ) Not sure what's up, but it not consistent. Some nights I can tag people in the head, full-auto, while running and drop them with 3-4 rounds. Other nights, like last night, the ak-47 with nomenclature couldn't seem to take people down in 2-3 clips. I know I don't have great aim, but I know I am good enough to kill 1-2 people before having to reload, not reloading 3-4 times per kill :shock:

well it looks like you copied this guide from a very old source. alot of the numbers are far too conservative and out of date as well as the definitions.

 

 

for optimum performance set the cl_cmdrate and cl_updaterate to 101 and 100 respectively. the cl_cmdrate should match your average fps exactly, not a division of.

 

your rate values are off as well. you should set this value depending on what the server is running and how much bandwidth you can handle. i personally use 25000 rate and 20000 cl_rate. rate was not mentioned but is also a very important command. cl_rate and rate ARE NOT the same command. one controls upload amount and the other controls download. cl_rate is the upload one if i remember correctly.

 

server side the sv_maxrate is default to 20000, not 99999. also using minrate is a very good idea. helps hte people who dont know these settings stay within a solid range.

 

 

i like that you did this but your stuff is way to far out of date. here is a far better guide. mainly server side but will explaing alot and is current.

 

 

*********

 

 

INTRODUCTION

 

This is not a rant, correction or otherwise, just clarification of a few omissions and minor ones at that. The original article is very well written and intrinsically accurate. I consider this a technical enhancement to McClanes original article with a few additions.

 

McClane's original article does overlook (probably intentionally) three things though in my opinion:

 

1) The affect of server side fps on high cl_updaterate values 2) Server side restriction of the cl_updaterate via sv_maxupdaterate 3) Cl_cmdrate inaccuracies due to server side fps.

 

Although both server side fps and sv_maxupdaterate affect the accuracy of cl_updaterate, these can only be affected by the server admin. Again although server side fps affects the accuracy of cl_cmdrate usage, players are again powerless. Therefore the information below is (mostly) for clarification purposes only and of no real use to players except to pester server admins I do provide an alternate (not better or worse) method of tuning your rates for smooth play on individual servers.

 

1) CL_UPDATERATE

 

This is a "request" value and often not the "actual" number of updates received by the client from the server. The actual number is capped by the server side frames per second (fps). This is due to an update only being available for each frame the server generates. I won't got into why this is the case but it was confirmed by a Valve software engineer a long time ago.

 

Server side fps fluctuates rapidly depending on many factors which include, number of players on server, map complexity, host cpu cycles available and a multitude of server and client vars. The server admin has by far the largest level of control over the effective server side fps with several configuration options available which directly affect it. The sad news is that most default server setups and config files (host os and cs software) do not include the most useful ones (or poor defaults) leading most servers to run at sub 100fps levels off the shelf so to speak. Another reason why servers are not configured to run in excess of this is cpu cycles, more fps = higher cpu usage. Trade offs are therefore often made even by experienced server admins.

 

So how does this affect players? Well, average servers run between 20 and 60 fps and as previously explained can only provide that many updates per second. This leads to inaccurate reports of choke level in certain scenarios. How? Well, during normal play with a cl_updaterate setting of 100 you may not be receiving that many updates, leading you to believe you are handling 100 updates per second fine. To ensure you are handling that many updates you would need to be playing on a server you KNOW is generating more than 100fps server side. Players cannot query the server side fps but it can be obtained via rcon using "rcon stats". Most good broadband connections can handle this level though (info from my own clan and customers). Slower speed connections (ISDN / Modem) certainly can't though.

 

Steam 1.6 servers do seem to send noticeable more information is updates compared to 1.3 figures. From my own personal experience as a 64Kbits ISDN user I can verify that a reduction from 42-45 max to 32-35 max is needed between the 2 versions to prevent choke. This also affects adsl users and can lead to choke on servers running higher fps if they use high cl_updaterate values. I won't go into the maths as McClane's article does this amicably and can be adjusted to suit. Also, my own method (later in this missive) is an alternative to the maths approach.

 

2) SV_MAXUPDATERATE

 

This is a bit simpler to explain at least. This caps the number of updates sent to the client regardless of what the cl_updaterate of the client is set to. The primary usage of this setting is to allow server admins to prevent flooding of the host servers connections (can happen on hardware running large numbers of ports on a 10mbit connection for example). It is more often used to clear up choke due to server side restriction of maxrate. As with above, the bad news is that by default this value is set to 60 (or in some cases undefined and defaults to 60).

 

Again, although this setting can be reported via rcon using "rcon sv_maxupdaterate" (note without a subsequent value being set), it cannot be seen by a standard client/player.

 

3) CL_CMDRATE

 

This is the number of updates clients send to the server and can contribute to choke as stated in McClane's article. However, due to server side fps all of those updates may not be used. If you are sending 100 updates a second and the server is only generating 50fps obviously some of your updates are not being fully used. As the hlds code is closed source I cannot document how the excess updates are handled but it's reasonable to assume they are used to some degree.

 

Saying this it is best to send as many updates as possible. This gives the server a larger data sample to select the most accurate updates from.

 

NOTES ON SV_MAXRATE

 

I've deliberately not touched on restriction of the "rate" client side var using the server var "sv_maxrate". This is because sv_maxrate is reported by hlsw/gamespy/ase and the likes. Needless to say most clanservers and publics don't run at 25000 which does negate some of McClane's comments to a degree. His principles however is sound and can be used to work out accurate rates (cmdrate/updaterate) for servers running lower maxrates (eg. 10000 which is common). The main thing to note about this is at lower server maxrates, client rates have to be reduced accordingly to account for the lower bandwidth available for transmission and reception of updates.

 

CORRECTING A MISCONCEPTION

 

Choke is caused by crap servers? ABSOLUTE RUBBISH.

 

Bear in mind what choke is, to quote McClane "the number of updates not sent in either direction because the communication link is saturated". Basically it's nearly always a combination of your client settings and your connection.

 

NOTES ON SERVERS AND CHOKE / LOSS

 

It is true however that extremely bad server configuration can cause choke by restriction of your client side settings. This is however very rare. I'm confident in saying that if the server is hosted by a reputable provider you will not see either of the 2 main reasons (see below).

 

1) Using a low sv_maxrate (usually to reduce bandwidth usage) but still using a high sv_maxupdaterate. Usually a sign of EXTREME inexperience and cost cutting combined.

 

2) Poor server connection compared to load eg. a high number of ports (and therefore players) on a connection not capable of handling them. This scenario is easier to spot as packet loss is usually seen as well as choke.

 

There is a third server setup scenario you should watch for which is a little harder to spot. I won't name names but many of you will be aware of a few clanport providers who run ports with quite low sv_maxrate's (sometimes as low as 6000). These ports often show no loss and in most cases very little or no choke. Experienced admins are more than capable of configuring such servers and usually do so as an extreme cost cutting exercise. A low sv_maxrate combined with a low sv_maxupdate rate is used to cut bandwidth costs dramatically. Spotting the low sv_maxrate is easily done in hlsw etc. lower than 10000 - avoid them. Ramping up your cl_cmdrate will cause choke on these servers as this cannot be restricted server side. Secondly bullet reg and general in game accuracy are greatly reduced.

 

QUICK GUIDE TO OPTIMISING RATES WITHOUT THE MATHS

 

Knowing and understanding the above does allow us to more rapidly tune our rates on the fly according to the server we are playing on. In a perfect world we would be able to find out all of the servers rates and settings and work out the optimal client side rates for our own connections before even joining the server. However, a simple bit of on the fly trial and error can be much faster. As most players are broadband users, details below only apply to that connection type.

 

1) Use net_graph 3 to view your choke level. Make sure to pay attention during heavy fire fights when large numbers of players are still alive as these are the heaviest info moments (bullets flying everywhere, a player movement, deaths, weapon drops etc.) The first 1-2 seconds after spawn are also heavy info moments so watch then closely too.

 

2) For broadband users I recommend using 25000 rate (unless using external comms when 20000 is more appropriate). If my notes serve me accurately 25000 is a hard coded max rate of steam hlds servers so even though you can set higher it has no effect. If the server has a lower maxrate you need not worry, it will abide by it's setting and you need not change yours.

 

3) Start with cl_cmdrate and cl_updaterate at 100. Watch for choke, if 0 then play on, no changes are needed. This happens either if your conn can handle the 100 updates per sec or server side restrictions (as described above) have limited updates to a level your conn can handle. In either case you need make no changes.

 

4) If choke is seen, lower both cl_cmdrate and cl_updaterate equally by increments of 5 until choke returns to 0 during both situations outline in point 1. I then recommend lower both an additional 3 to account for heavier fire fights or moments busier than those you noted your choke level from.

 

This method can be used on each server and ensures you as the client are providing and receiving as many updates as possible to/from the server without losing any. This leads to more accurate and responsive game play. Remember, server configurations differ wildly so it's best to do this EVERY TIME you join a different server. I personally have a set of aliases bound to 2 keys which allow me to increase or decrease such settings very quickly in game. Not essential but useful at times (see below).

 

ADVANCED NOTES/TIPS

 

The following notes are primarily for ISDN or slower connection users. They may be of limited or no use to other users.

 

There are a couple of situations in game when adjusting your cmdrate and updaterate on the fly can aid responsiveness. To be of any use however you do need to know the servers sv_maxupdaterate and be sure it's running at more frames per second than that value. Both of these tweaks should be used with care as they can induce massive choke if set poorly. It's all trial and error so keep a VERY close eye on your net_graph 3 choke level.

 

It is also very hard to perform these tips successfully without having a good knowledge of writing aliases which are then bound to keys. I personally have 4 keys in a cluster on my keyboard bound to aliases which when pressed either increase or decrease my cl_cmdrate or cl_updaterate by increments of 3 on the fly. DO NOT BOTHER ASKING FOR MY SCRIPT TO DO THIS. If you are not proficient enough to code it yourself stop reading here.

 

TIP 1

 

This first tip is theoretical as I've not been able to prove it myself. But I have had reports from friends and colleagues with faster connections and keener eyes that it can work. As we know sv_maxupdaterate caps the clients cl_updaterate. We also know that there is no server side option to cap the clients cl_cmdrate. Well, on servers running as a high fps you can increase your cl_cmdrate individually and as high as your connection will permit before choking. I am told this can increase the accurate of bullet reg. This tweak is most useful when the servers sv_maxupdaterate is lower than your connection can handle giving you spare capacity (eg. servers running default 60).

 

TIP 2

 

This second tip is only useful if on a specific server you can choke your connection and have to use lower cmdrate and/or updaterate to prevent choke in heavy fire fights etc. The easiest way for me to describe this is by way of example. I know that in heavy fire fights on ISDN I need to use cmdrate and updaterate of around 32-35 to prevent choke. But in situations when a lot less is going on I know I can get away with much higher settings See where I'm going here? Well, consider a 5v5 match - 10 lots of player info are being sent to all clients but as each player dies the amount of information required for each update reduces. So, using a little care and experience I gradually increase my cmdrate and updaterate on the fly as players die (checking for choke regularly). This increases the accuracy and responsiveness of my game play bit by bit. Should I be left in a last standing 1v1 standing scenario my cmdrate and updaterate can be as high as a broadband user on certain maps.

 

TIP NOTES: The above tips are NOT cheats. At the end of the day I am merely leveling the playing field a little due to only having an ISDN connection. Remember that ADSL users will probably be using the settings I end up at all the time whereas I only achieve them during 1v1 battles on the simpler maps. Also, I'm a bit crap and need every "edge" I can get

 

===

Content publication granted by the original author, TAA|Vapor on behalf of TAA|Gaming - Original article available at http://www.taa-gaming.com/servers/advanced.php

sorry i just really wanted to get the correct info out there. that first guide is so old. its like someone copied it a 1000 times and sent it out to everyone on the net. i have seen it used since FA/HL first came out. obviously it is horribly out of date.

That guide is still on the FA forums and hasnt been updated, Thanks for the Update BTW..... Stickied in the FA forum and locked, there is no real need to post in this topic...you are welcom to Reference to it if you are having a specific problem...A few things to consider when you ARE posting a problem, include your RATEFPS_MAX and MODEMYour actual connection speed.ANY new Driver updates. and anything else you changed or know of.. Specs of your machine if you think they are relevent.