Somedude
August 5th, 2005, 09:00 PM
Saved from the FA forums.
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 the support forum once it becomes inactive. (well looky where it is!)
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 on 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 :P 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 ISDN. Or bypass the cache and invalidate your terms of use and run the risk of having your connection removed.
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.
phides really got the idea here, and thats a philosophy youll do well to follow.
Many of you will wish to skip the next few paragraphs, which explain how the game works, and go straight to the cvars later on. 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 ones 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 only be affected by what they can see and hear. Half-Life therefore proceed in ‘game frames’. 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 on 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 on 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, once 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 on 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 - [Packet Information Groper (they worked out what the accronym would be before deciding the terms). 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 ‘pong’) being received. This is the one which is most dependant on 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 only 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 one which is often ignored in favour of ping. A lost packet is one which at some stage of its journey is discarded, either because it is too old (the most usual one) 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 on your computer and it being sent to the server. It is one 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 larger 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 on 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 only 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 on 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 on 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 once you have tweaked your netcode. The following is an explanation of net_graph 1:
<see attachment 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 higher the green/yellow/orange/red line 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 on 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).
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 the support forum once it becomes inactive. (well looky where it is!)
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 on 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 :P 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 ISDN. Or bypass the cache and invalidate your terms of use and run the risk of having your connection removed.
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.
phides really got the idea here, and thats a philosophy youll do well to follow.
Many of you will wish to skip the next few paragraphs, which explain how the game works, and go straight to the cvars later on. 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 ones 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 only be affected by what they can see and hear. Half-Life therefore proceed in ‘game frames’. 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 on 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 on 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, once 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 on 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 - [Packet Information Groper (they worked out what the accronym would be before deciding the terms). 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 ‘pong’) being received. This is the one which is most dependant on 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 only 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 one which is often ignored in favour of ping. A lost packet is one which at some stage of its journey is discarded, either because it is too old (the most usual one) 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 on your computer and it being sent to the server. It is one 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 larger 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 on 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 only 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 on 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 on 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 once you have tweaked your netcode. The following is an explanation of net_graph 1:
<see attachment 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 higher the green/yellow/orange/red line 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 on 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).