Team Fortress Classic | TFC Tech | Networking

TFC Tech: Networking

Please note that this section will be updated soon to reflect recent changes to the netcode, for now some notes are listed with the sections to which they pertain.
When I try to connect to a TFC server, it hangs on initializing and downloading, or disconnects after this message, how can I get this to stop?
This is most often caused by an antivirus program or some other program that you are running in the background that interferes with Half-life in some way. The best recommendation is to disable virus scanner/antivirus programs and shut down any other programs that you may be running before you play Half-life. To the best of my knowledge, IRC clients, ICQ, and GameSpy do not cause this to occur, but you may want to shut those down as well (in GameSpy go to Tools->Options->'When launching a game'->'launch game and terminate GameSpy' if you want GameSpy to close when you try to join a server).

What can I do to reduce my latency?
Note: The TFC1.5/HL 1.1.0.0 update has changed a few of the commands used for this. Framerates are no longer taken into consideration for networking, so the fps_modem and fps_lan commands were removed, and replaced with fps_max. Set fps_max according to what your video card can handle, and then you're left with tweaking rate and pushlatency. The r_netgraph command has also been removed, and been replaced with net_graph. Use net_graph 1, 2, or 3, according to whichever you prefer. Also, netgraph_pos can be set to 0, 1, or 2 to determine it's location, left, right, or center. netgraph_width will set the width of the graph. There are a few things you can do to reduce your latency, but the determining factors on how low your latency can get are your ISP(Internet Service Provider), your modem, your phone lines(if using a phone modem), and the route to the server you're playing on (the path the signal takes from you to the game). The only things you can really do about your ISP are complain to them or change ISPs. As far as your route goes, right click on the server you want to join (in GameSpy) and choose traceroute, it will then tell you how many hops your signal is going through. Fewer hops usually means that you're going to cover less distance and have a better connection, there are a number of traceroute programs available on the internet that can go into more detail on what your route is and where any problems may be, which could help in determining if your ISP is causing your latency to be higher than it should be. Basically, a better route equals better ping, and better ping equals better latency. Try to join the servers that give you the best ping and route if you're concerned about latency. You can usually call your phone company and have them test your phone lines if you think they may be causing data loss. The most common symptoms of bad phone lines are a definite hiss during voice conversations (on your telephone) or interference of any type (I used to be able to hear local radio stations on my phone when the line was quiet, definitely a sign of bad lines). Make sure you have the latest drivers for your modem, they may have found some problems with the drivers you are using and fixed them, and those problems may have been causing some of your lag. A great resource I have found for tweaking all aspects of your game is Tweak3d.net They have a modem tweak guide and an Half-life Internet Tweak Guide that could be very useful for reducing your latency. They also have a number of tweak guides for the rest of your hardware, including 3d cards, and some tweak guides for other games. You may also want to try the Half-life Autoexec Creator which will build an autoexec.cfg file for you that may increase your game's framerates and also your internet performance. Adapting your rate and pushlatency settings to your connection may also help. I would recommend setting pushlatency to -1000 (type pushlatency -1000 in console), which will effectively give full prediction of the actions of other players should your connection not receive proper updates from the server. Prediction (and therefore pushlatency) hides the appearance of latency and lag problems, -1000 basically sets it to a value of negative your ping, a value of 0 turns off prediction. As for rate, I would set rate to a value of 5000 (type rate 5000 in console), and then reduce it by about 500 at a time(rate 4500, rate 4000, rate 3500, etc), while paying attention to your netgraph (type r_netgraph 1 in console to view netgraph) to try to clear any blue, red, or yellow lines from your graph. Note that you may not be able to get rid of the yellow and red lines entirely, but you want to get as few of them as possible.

What are rate, pushlatency, and netgraph? How do I use them?
Note: The TFC1.5/HL 1.1.0.0 update has changed a few of the commands used for this. Framerates are no longer taken into consideration for networking, so the fps_modem and fps_lan commands were removed, and replaced with fps_max. Set fps_max according to what your video card can handle, and then you're left with tweaking rate and pushlatency. The r_netgraph command has also been removed, and been replaced with net_graph. Use net_graph 1, 2, or 3, according to whichever you prefer. Also, netgraph_pos can be set to 0, 1, or 2 to determine it's location, left, right, or center. netgraph_width will set the width of the graph.

Netgraph:

Netgraph is a visual representation of the networking data that Half-life/TFC is receiving while you play. In the default mode that most people use (r_netgraph 1) it shows whether you are having delayed packets (yellow lines in netgraph), which usually mean the server is sending more information to you than you can handle, dropped packets (red lines) which could be the result of the server sending too much information or a bad connection, or corrupted packets (blue lines) which show that there's definitely a problem between you and the server. Halflife.org's Yappin with Yahn section, brought up the question of netgraph with Yahn Bernier (Valve software's netcode guru) which shed some light on the uses of r_netgraph 2 and 3, which is where I got any of the info in this section relating to those two portions of the netgraph. When using r_netgraph 2, there are a series of green hashes up the side of your screen, each represents 50 bytes of data. As the graph moves from right to left (this would be the standard r_netgraph 1 display), each column is a presentation of a server message that your computer received (or didn't receive, refused, or found invalid). r_netgraph 3 adds a white divider to your screen above which is player data (yellow), non-player entity data (purple), temporary entity data (blue), and sounds (green). So, basically, r_netgraph 2 and 3 will show you what the information is and how much of it is being sent, while r_netgraph 1 simply tells you whether or not you're receiving all of the information being sent to you correctly. In most cases, r_netgraph 1 is the only one of these options that will concern you, and r_netgraph 0 turns it off. Pushlatency: Pushlatency is a variable used by Half-life/TFC's netcode to guide the prediction code in the game. The prediction code hides your latency by replacing any lost or delayed packets with a prediction of what the other player(s) may be doing. According to Yahn Bernier (again from Halflife.org's Yappin with Yahn) setting your pushlatency to a value that is a negative number, with the absolute value of the number being higher than your latency, will cause the game's code to dynamically change the pushlatency value to a value that is negative your current latency. This means that a value of -1000 for pushlatency will automatically enable full prediction so long as your latency is below 1000. If for some reason you don't want prediction to be used, set pushlatency to 0.

Rate:

Rate is the speed at which the server will send information to your computer. The basic idea is that you want your rate to be high enough to get the necessary information, but not so high that it causes your computer to turn away information or drop packets. Overall, I have found no reason for anyone to use a rate higher than 5000 (which is the rate limit in many leagues and is more than adequate for the information normally sent in a game of TFC), though TFC will allow rates as high as 10000. When trying to adjust your rate for the best performance for your connection, I recommend starting by setting rate to 5000 (rate 5000) and turning on netgraph (r_netgraph 1). Look at the netgraph for yellow and red columns. If you're having a lot of red and yellow appear, reduce your rate by 500 (rate 4500), and look for the red and yellow columns again. Continue to do so until you find that your red and yellow columns are significantly reduced (as few of them as possible), stop if you get below 2500, and try looking at other ways to improve your connection. Once you find a value that seems to work for you, you may want to tweak it a little more (change the value by intervals of 50 or 100 instead of 500) to find a setting you like. Remember that you can't do this in a LAN game or on a server that you are running, as it will have little effect. Try to do it on a server with only a few people (an empty server may work as well for a baseline) that you have a good ping to, so that you can get a 'best case' situation for your rate, and work from there.

Note: to adjust your rate, type rate # where # is the value you would like to use in the console.

How do I get Half-life and TFC to work in multiplayer when I'm using a proxy to connect to the internet?
I found this answer with the help of the great people over at our own PlanetFortress Forumsand would like to thank them for posting and reposting this for me.

This pertains mostly to people using a proxy that they have control over. In other words, you will be able to configure the proxy yourself. If the proxy is controlled by your ISP (Internet Service Provider), the you'll have to contact them to see if they will do this for you.(also note that some of this must be done on the proxy, and some of it must be done on the computer you will be using to play TFC)

  • Disable the CompuServe and AOL proxy functions. The ports they use conflict with the ports HL uses.

  • Create a mapping with the name Auth Server, TCP, proxy port 7001, IP 209.67.28.140 (or half-life.east.won.net), outbound port 7001.

  • Create a mapping with the name Auth Server2, TCP, proxy port 7002, IP 209.67.28.140 (or half-life.east.won.net), outbound port 7002.

  • Create one named WON Server, proxy port 6003, TCP, IP 209.67.28.140 (or half-life.east.won.net), outbound port 6003.

  • Create one named WON Master, proxy port 27010, UDP, check "bi-directional", IP 209.67.28.140 (or half-life.east.won.net), outbound port 27010.

    At this point, you have mappings for everything but the game servers; You can get a WON authorization, and you can get the master list of servers showing what games are running, but you CAN'T get into a game. You need to create a separate mapping for EACH game server that you want to play on.

  • Get into GameSpy or HL and write down the IP addresses of your favorite servers (good pings, always running, whatever).

  • Create a new mapping for EACH game server.

  • The first one will look like this. Name "Some Cool Server", proxy port 27015, IP 123.456.789.012 (uh ... I made that number up :), UDP, bi-directional, outbound port 27015.

  • For the rest of the game servers, you need to increment the "proxy port", like this: Name "Some Other Game Server", proxy port 27016, IP 123.456.789.012, UDP, Bi-directional, outbound port 27015.

  • Name "Yet Another Game Server", proxy port 27017, IP 123.456.789.012, UDP, Bi-directional, outbound port 27015.

    You get the idea. Each port ON THE PROXY SERVER changes, but the outbound mapping always points to the "real" port at 27015.

    Now to connect to a game, start from the HL console.

  • There's a variable (cl_timeout) that tells Half-Life how long to wait (in milliseconds) for a response from the server before failing, and it's normally 1/3 of a second. Your connection will usually take longer than that, and ALWAYS will if the proxy needs to dial, so change the value to make it wait long enough for a dial and login, maybe 30 seconds (cl_timeout 30000) or 45 seconds (cl_timeout 45000).

  • Now connect to the first server you mapped with "connect your.proxy's.ip.number:27015". Connect to the second with "connect your.proxy's.ip.number:27016", and so on.





IGN.com | GameSpy | Comrade | Arena | FilePlanet | GameSpy Technology
TeamXbox | Planets | Vaults | VE3D | CheatsCodesGuides | GameStats | GamerMetrics
AskMen.com | Rotten Tomatoes | Direct2Drive | Green Pixels
By continuing past this page, and by your continued use of this site, you agree to be bound by and abide by the User Agreement.
Copyright 1996-2009, IGN Entertainment, Inc.   About Us | Support | Advertise | Privacy Policy | User Agreement Subscribe to RSS Feeds RSS Feeds
IGN's enterprise databases running Oracle, SQL and MySQL are professionally monitored and managed by Pythian Remote DBA.