Grand Prix Legends Online Frequently Asked Questions

Grand Prix Legends Online FAQ copyright 1998-1999, Alison Hine http://simracing.com/alison/gpl/faq-online.htm Racing in GPL over the Internet presents a special set of challenges. Because of GPL's bandwidth requirements and the high CPU resource demands of its physics engine, we're pushing the envelope, running on the ragged edge of what's possible with today's Internet technology. When things are set up correctly, the experience of racing in GPL with people hundreds or thousands of miles away is unparalleled. However, to optimize the online racing experience, certain preparations must be made, and familiarity with the issues surrounding Internet play is a useful prerequisite for the would-be online racer. To help GPL racers get the best possible online racing experience, I've compiled an extensive discussion of issues and solutions involved in online racing in GPL. For still more information about GPL online racing issues and solutions, see the VROC Technical Notes page. 1.1 Is racing in GPL over the Internet the same as racing over a LAN? It's essentially the same, but with certain limitations. See the next question. 1.2 What limitations and requirements does GPL have when racing over the Internet that it doesn't have over a LAN? The ancient serial port architecture places the most serious limitations on online racing in GPL, although wildly variable latency on the Internet also introduces difficulties. Cable modems, ADSL, or ISDN (when not connected to the computer through a 16550-based serial port) all avoid the serial port limitations, as do Universal Serial Bus modems. Here is a list of constraints you are likely to encounter in racing GPL over the Internet: * Fewer players. On a LAN, you can have up to 20 players. Over the Internet, you're most likely going to find that you are limited to four or five players when hosting over an analog line, fewer unless you make adjustments to certain default settings in Windows and GPL. If you try to connect too many players, one or more will get booted from the game when the excessive player joins. This is due to limitations of the serial port. Many more players are possible when hosting over a digital connection. We've seen as many as 20 players, with 10 to15 typical in games hosted via digital connections, including cable modem, ADSL, T1, or ISDN (that is, ISDN where no serial port is involved). * DUN upgrade and tuning. If you're racing over a serial port, I highly recommend that you upgrade your DUN to 1.2 or later unless you have Windows 98. This is because DUN 1.2 is more efficient than the DUN that came with Windows 95, and using it tends to reduce the impact of the use of the serial port on gameplay. It also can reduce ping times by as much as 50 to 80 ms, which is highly desirable. Also, we've found that altering certain settings in Windows' Dialup Networking Connection can yield great improvements in certain aspects of online play, including a significant increase in the number of players which can join a game. See here for details on downloading and installing DUN 1.2 and tuning your DUN and serial port settings. * Frame rate recommendation: solid 36 fps. For racing on the Internet, you need more CPU power than you need to run solo or over a LAN, again due to serial port limitations. Alternatively, you can turn down graphic detail, but if everyone is not running at a solid 36 fps, things can get very weird. (Randy Cassidy disagrees with this; see below.) Note that you can sidestep this issue and eliminate a lot of online racing's most common problems by using a Universal Serial Bus modem instead of a serial port modem (or better yet, a digital connection such as ADSL or cable modem). If you already have an analog modem or external ISDN device, you can use a USB to Serial Converter. * Ping times. You want to have ping times below 500 ms from client to host, and if there are multiple clients, you'd like it even lower. Actually, the lower the better, and if it's under 280 ms or so, it begins to look like you're on a LAN. * Warping. In Internet play, you're likely to see warping, which is the bane of online racing. However, if your ping times are low enough and stable, this goes away. When it occurs, it's dealt with as well as I've seen in any online racing game. * Full install of GPL. It's important when racing online, particularly when hosting, to do a full install of GPL. This avoids certain anomolies such as missing green buttons on the clients' race weekend screen, and clients getting booted when the host saves a setup or reply file. * Full-function modem. Many people have Winmodems or other modems which offload some communications functions to the CPU, as a cost- saving measure. This may work fine for Web surfing, but it's death for online racing in GPL. You must have a real modem to participate effectively in online races! Although a conventional serial port modem will work, a Universal Serial Bus modem is generally far superior to a serial port modem for GPL. Another alternative is an external serial port modem connected through a USB to Serial Converter. * Assorted anomalies. There are several odd things that seem to happen only during Internet-based multiplayer races. These are the two most severe: o Giant warps. Sometimes an opponent's car may disappear and then reappear a great distance away, and then keep on going. If you are running as a client, this may be accompanied by a screen flash and/or a warble in the engine sound. o Irregular frame flow. Sometimes the action on your screen may seem to be moving jerkily, or speeding up momentarily, even if you are seeing 36 fps on GPL's frame rate counter. See the section on bizarre behaviors for details on how to eliminate these anomalies. There are also some less severe anomalies, none of which are showstoppers. I mention them so if you see them you won't think you're hallucinating. The most common: o Missing green button. Sometimes a client may not get a green button to proceed to the track after arriving at the weekend screen. The workaround for this is to exit and rejoin the game. If the connection quality is poor, it may take a couple of tries. Note: this problem can be very common if the host is running on a system which had a partial install of GPL, even if a full install was done later. See below for details. o Missing lap times. Sometimes your lap times don't get reported right away. Sometimes you may not get any lap times for an entire session; if this is the case, ask the player hosting the game if they have done a full install of GPL. If they did a partial install, even if they followed it with a full install, you are likely to have this problem. See below for the fix. o Remote cars don't fly. If your ping times are high, you will find that remote players' cars never leave the track surface, and don't move up and down on their suspensions, either. In a crash, parts of a remote car may appear to go below the track surface as it tumbles. o Bogus DQ's. Occasionally, you may get disqualified for going backwards on the track even if you know you didn't. If everyone is getting 36 fps all the time, this is fairly unlikely. o Replay anomalies. Replays may have periods in which some remote cars disappear. Also the screen will appear jittery when viewing a remote car if warping occurred while the replay was being captured. o Random disconnects. Sometimes, if the connection quality is poor (high ping times or an intermittently busy router on the route) you may find that one or more clients get disconnected from a session. In a practice session, it's no big deal, because you can simply rejoin, but in a race it can be frustrating because if it happens, you're out. Despite these issues, when you've got things set up right it works great. Sometimes it's so good that it's hard to tell you're not on a LAN. 1.3 What exactly do I need to do to prepare my machine for racing online? You don't necessarily need to do anything special to host or join a two-player race. However, for races hosted over a serial port, if you wish to have more than two players, it's important to tune your DUN and serial port settings. Click here for details, and review the Maximum Players section for more information. If you have a Winmodem, you must take special steps to prepare your computer for serious online racing. Get a screwdriver, and open your computer's case. Locate the Winmodem, and disconnect the phone line. Remove the screw holding it into its slot, and carefully remove the Winmodem. Now, go over to the nearest window, or, better yet, climb up onto your roof. Taking care to avoid innocent bystanders, grasp the Winmodem firmly in your throwing hand, and heave it as far as you can. If possible, ensure that the Winmodem strikes a solid object on the descent portion of its trajectory, thereby destroying it and preventing some hapless passerby from putting it in their computer and potentially joining and ruining your future online races. Now go buy a real modem. By far the best analog modem solution for GPL is a Universal Serial Bus modem rather than a conventional serial port modem. An alternative is an external serial port modem connected through a USB to Serial Converter. Note that there are some caveats with USB modems, mainly a possible degradation in frame rate on slower machines running Voodoo 2 cards. A digital connection such as ADSL, cable modem, or ISDN is much better than any analog modem, if you have such a connection available. If you go with ISDN, avoid an installation based on the serial port (i.e. an external ISDN modem) in favor of an ISDN router and Ethernet card (the best ISDN solution), a USB-based ISDN modem, or an internal ISDN Terminal Adapter that uses a serial controller that is more intelligent than a 16550 UART. An external ISDN modem connected through a USB to Serial Converter might be another good alternative. If you have a cable modem, check out PH Net's suggestions for cable modem setup. You might also want to look at this page if you have an ADSL or other DSL connection. Also read Paco Skiinoff's comments on MTU value in the GPL Reader FAQ. There are certain other steps that you may find will help avoid certain strange behaviors in GPL multiplayer races, particularly those hosted over the PC's standard 16550 UART-based serial port. You may find it helpful to switch to the DirectInput joystick driver if you are currently using the Generic driver for your controller. You'll find this on your Options screen in GPL. I've also found that reducing graphics options and/or upgrading hardware to get 36 fps helps eliminate the bizarre behaviors which can occur in GPL if the CPU is saturated and you are connecting to other players through the serial port. See the section on bizarre behaviors for more details. 1.4 Do I really need to get a frame rate of 36 fps? The beta team's empirical testing suggests that 36 fps is important to avoid certain strange behaviors in GPL multiplayer races hosted over the PC's serial port. However, Papyrus engineer Randy Cassidy, key developer for the multiplayer components of GPL, comments: "It really should not be the case that either the client or the server must run at 36 fps for a multiplayer game to run smoothly. We have run many a smooth multiplayer race here at the office with our P-200's never seeing the light above 20 fps, never mind a constant 36 fps. "Perhaps when the machine is saturated, it's not servicing the serial port in a timely enough fashion. I suggest all players run with their 16550 sliders for the port settings of your dialup connections (and modem connections if you ever run modem-to-modem races, and serial port settings if you ever run null-modem cable races) at the second click from the left. If you don't, this could have a profoundly negative effect since incoming packets will be lost, and outgoing packets will either be lost, or delayed. [See here for details on how to make this important adjustment.] "Also, I suggest all players use DirectInput, instead of the Generic driver. We disable interrupts during the joystick read in the Generic driver, which will more than likely cause bad things with the serial port." VROC went live in mid October 1998, providing a place for online racers to connect with each other. As a result, now have fairly extensive experience with online racing, with a wide variety of hardware and connection quality. This experience seems to confirm that, as Randy suggests, the serial port is a serious bottleneck for online racing. When the CPU is saturated, packets get lost. Re-send attempts quickly saturate the available bandwidth, and people start dropping like flies, while others get clock smashes or frame stuttering. The involvement of the serial port and its special requirements for frequent interrupts makes the online environment quite different in this regard than a LAN environment such as the office LAN at Papyrus. Experience shows that some people can participate in online races fairly effectively with frame rates below 30 fps. However, if you are getting disconnected, or are getting frequent screen flashes accompanied by giant warps, get your frame rate to 36 fps. For some reason, this seems to be even more important on fast computers (P2-300's and above) than on slower ones. I suspect that this is because on older machines, which are more likely to be running older 3D cards, fill rate, rather than CPU occupancy, limits the frame rate. In this case, there still may be CPU power left to properly service the serial port. The best solution is to elminate the serial port in favor of a Universal Serial Bus modem. A digital connection such as ADSL, cable modem, or ISDN is much better still, if you have such a connection available. If you go with ISDN, avoid an installation based on the serial port (i.e. an external ISDN modem) in favor of an ISDN router and Ethernet card (the best ISDN solution) or an internal ISDN Terminal Adapter that uses a serial controller that is more intelligent than a 16550 UART. 2.1 Ok, how do I find other people who would like to race GPL online? The place to go is the Virtual Racers' Online Connection. Here you'll find lots of folks eager to race online, and during peak periods (evenings and weekends) there are typically several people hosting races on cable modems or other high speed connections. It's free, and there's an integrated chat to help you get acquainted with other racers. There are also pages with detailed help and technical information about racing online. You can also connect over the Interenet wth other people who you might already know, or meet through ICQ, Kali, or some other method. 3.1 What do the players need to know in order to join an online race that I'm hosting? All they need to know is your IP address. Give this to them via a chat or email, or even over the phone, and then run GPL and select Multiplayer on the main menu. Once at the Multiplayer screen, click on the Host button. Then choose the connection(s) you would like to host over, and click the green button to proceed to the Track Selection screen. Once you do this, other players can join your session. At the Track Selection screen, click the Chat button or hit the tilde (~) key to turn on the Chat Pad to see messages announcing when players join or leave your race session. Type into the Chat Pad to send other players messages. When you've agreed on where to race, choose the track, set the race type and practice length, choose the number of AI cars (I recommend you try it without AI cars at first) and then click the green button to proceed to the Weekend screen. Randy Cassidy has made available a program which will ping a GPL server and return a string containing all the essential information about the current session. You can download the source and executable for this program here. 3.2 How do I get my IP address? I think it changes every time I dial in to my ISP. Because of the shortage of IP addresses, most ISP's assign you a new IP address dynamically, from a pool of available addresses, each time you log in. This is a nuisance, but easy to deal with. In your Windows folder, there is a program called Winipcfg.exe. I recommend creating a shortcut to it on your desktop. Just run this and it will tell your your IP address. Alternatively, you can download a nifty little utility called MyIPAddress from Outlandish. This does the same thing, but it's a little more convenient. Also, if you are logged into ICQ or Kali, you can find out your IP address from them. See their documentation for details. Also, once you're in GPL, you will find your IP address on the Multiplayer screen, but this isn't very helpful for telling other people who'd like to join you unless you have some external way of communicating with them, such as via telephone. 3.3 Ok, I have the IP address of someone who is hosting a race. What do I do? Run GPL, select Multiplayer on the main menu, and then in the Multiplayer, click on the Join button. Select the IP address for your dialup connection from the Connect Via drop down list. Then enter the address of the machine you're joining in the IP Address field. Now click the green button to proceed to the Track Selection screen. At the Track Selection screen, click the Chat button or hit the tilde (~) key to turn on the Chat Pad to see messages announcing when players join or leave the race session you've joined. Type into the Chat Pad to send other players messages. When the green button appears on the Track Selection screen, you can click it and proceed to the weekend screen. Note that you will not be able to join if the practice is over and the race has begun. Also note that if your ping time to the host is above 400 to 500 ms, you are not likely to have very good game play. You'll probably see a lot of warping, and you may also have trouble staying connected. You may also experience a variety of bizarre behaviors. 3.4 What special keys are active and/or useful during a multiplayer session? ~ (tilde) - while in the menus, toggles the Chat Pad off and on. Alt-F - shows frame rate. Alt-L - shows latency (ping time) to the server. Note that while in the menus, the Chat Pad must be off to retrieve the ping time, but on to display it. Simply hit the tilde key, Alt-L, and then tilde again. Enter - while in the car, this allows you to enter a line of chat text. Press Enter again to send it. V - while in the car and stopped, this allows you to jump to the next car and view the action from its cockpit. Be careful; if your car is stationary too long, it gets yanked from the world and returned to the Weekend screen. Shift-V - same as "V", but jumps to the the car behind. Shift-R - repairs your car, if damaged, and sets it upright on the track, with fresh (cold) tires and fuel tank refilled to the level specified in your setup. This is not available in all sessions; see the Damage and Repairs section of the general FAQ. See the F1 key (Function Key 1) for a help menu with some other keys. See my keys help page for a list of other useful keys. Also see the readme.txt file in your GPL folder for information about the replay keys; these are mostly alternatives to the buttons on the screen under the replay window. 4.1 How do I measure ping time to the GPL host? If you are in Windows, open a DOS prompt and type: ping 123.123.123.123 where 123.123.123.123 is the IP address of the potential host. If you are in GPL's menus, turn off the chat pad, type Alt-L, and then turn on the chat pad. If you are in the car in GPL, just type Alt-L. 4.2 How do I measure ping time to my GPL clients? If you are in Windows, open a DOS prompt and type: ping 123.123.123.123 where 123.123.123.123 is the IP address of the potential client. You can't measure ping time to clients within GPL, but you can ask them to measure the ping time to you and then tell you via the Chat Pad. 4.3 How can I improve my ping times? Ping times are dependent on the quality of the route (i.e. the number of hops) between you and the other machine, the efficiency of the DUN software on your computer, the speed of your modem, and a vagary which might be called "Internet Weather". This refers to the state of the Internet backbone at any given moment. Factors affecting Internet Weather include the density of traffic on the Internet at the moment, how many important routers are overloaded or down, and probably the phase of the moon. Your best bet is to go to a digital connection, either ISDN, ADSL, or, most preferably as far as I can tell, a cable modem. Unless, of course, you are already on a T1 line, you lucky dog! A digital connection typically knocks about 100 ms off ping times. If you're stuck with an analog dialup connection (i.e. a 33.6 or 56 k modem), I highly recommend that you consider a Universal Serial Port modem. If this is not feasible, see Dun and Serial Port Settings for complete details on optimizing your DUN connection, including downloading and installing DUN 1.2. Read this if you have ISDN as well. 4.4 What is this stuff about Internet routes, and how do I find out if I have a good one? The route refers to the series of nodes (called "routers") which forward the packets of data from your machine to a remote machine, and back again. The fewer the number of routers, or hops, between you and the remote machine, the better your gameplay is likely to be. I've found that we can play even with over 20 hops, but it's likely to be a lot better with 11 or 12 hops. If you want to check the number of hops in the route between your machine and another machine somewhere else on the Internet, all you need is the IP address. Open a DOS prompt, and type: tracert 123.123.123.123 where 123.123.123.123 is the IP address of the other machine. This will trace the route and display information about each node on the route. Note that this does not tell you if one or more of the routers on the route is busy, which could seriously affect your game play. If you want to find out more about how the routers are performing, try a program called UOTrace, available at http://www.primenet.com/~simpson, or PingPlotter, at http://www.nessoft.com/pingplotter/ Note that there is most likely a different route from the remote computer to your computer than the route from yours to the remote. To trace the route from the other computer to you, the person at the other end will need your IP address, and will need to run tracert or one of the other trace programs from that end. 5.1 We tried to run an online multiplayer race with three/four/nine players, but everyone kept getting disconnected. Why is this? Over the Internet, with the default Windows Dialup Networking Connection and modem settings, you're limited to hosting one player over an analog line, or two or three over an ISDN line. If you try to connect too many players, one or more will get booted from the game when the excessive player joins. This is due to limitations of the serial port. It is possible to host many more players over a digital connection, such as cable modem or ADSL, since these don't involve the serial port. Randy Cassidy comments: "You can't shove a watermelon through a straw, either. By default, a GPL server requires about 17,000 to 29,000 bits per second of bandwidth to each client that connects to it. If you're running a GPL server connected to the Internet with a 33.6 modem, you're pushing the envelope even trying to get two clients connected to it." 5.2 Is there any way I can host more than one client over an analog dialup connection? Yes. You can host more players over a dialup connection if you adjust the Windows Dialup Networking Connection and serial port FIFO settings (see here for details) and reduce GPL's bandwidth from the default. With GPL's default dialup bandwidth settings, we've found that you can usually host only one client. If you over-ride GPL's default bandwidth, you can most likely host two clients. The same is true for hosting over an ISDN connection, except that it seems to be possible to host two clients with the default bandwidth and three with a smaller bandwidth. The good news is that by tuning the DUN and FIFO settings and reducing GPL's bandwidth, we have hosted as many as four players over a 33.6 connection! 5.3 What is the tradeoff when lowering GPL's bandwidth? Reducing the bandwidth can increase warping, and can also aggravate the strange things that can occur if you or the other players are running at less than 36 fps. Also, it is necessary that everyone be using bandwidth settings compatible with those being used by the host, or else they will not be able to connect to the host. In practice, the beta team has run many races with reduced bandwidth, and has found gameplay to be quite acceptable. 5.4 Ok, I want to try this. How do I tune my DUN and FIFO settings? Simply click here and follow the instructions. 5.5 Ok, I did that. Now how do I reduce GPL's bandwidth? Simply open the folder in which you installed GPL (by default, C:\SIERRA\gpl). To make sure you have the right folder, check to see that it contains the GPL executable, a file named gpl.exe. In this folder create a file called core.ini. Using a text editor such as Notepad, open this file and insert the following lines: [ Communications ] net_mdm_client_send_every = 3 net_mdm_client_send_size = 84 net_mdm_server_send_every = 3 net_mdm_server_send_size = 84 Send a copy of the same core.ini file to everyone who will be joining the GPL session and have them put it in their GPL folder. Everyone must have compatible settings, or they won't be able to connect to the GPL server! Remember to remove this core.ini file, or rename it, before you try to connect with someone who is using the default settings. 5.6 What do the numbers in this core.ini file mean? The net_mdm_*send_every parameter determines how frequently a packet is sent across the connection to the remote player's GPL. The default is every 2 ticks (1/18th of a second). By changing this value to 3 ticks, we send information less frequently, giving the CPU a chance to empty the serial port's buffer before an error is generated. A value of 3 seems to allow one additional player to join over a dialup connection. I've tried a value of 4, but this generated numerous clock smashes. However, it might work if everyone has a very fast computer and ping times are very low. Let me know if you have success with this. The net_mdm_*send_size parameter determines the size of the packets being sent. It is best to use a number calculated from the formula (16 * n) + 4. The default setting is 84 bytes. I have tried reducing this value but it didn't seem to help. I'm including it so ambitious people can experiment. If you find that using smaller packets allows you to connect additional players, please let me know! Note that the client and server can use different values; for example, theoretically the server could send 84 bytes every 3 ticks, while the clients could send 68 bytes every 2 ticks. I'm not sure there is any advantage to this, but again if you have success, please let me know. 5.7 Where can I get more information about GPL's bandwidth requirements? For a very detailed in-depth analysis of GPL's bandwidth requirements and latency issues, see Bart Westra's "Tips, Links, and Files for Grand Prix Legends". Go to the GPL Online Facts page and click on What Really Happens. Also see the Tech Notes, Troubleshooting, and Cool Stuff pages on VROC, and the Other Sources section below. 5.8 I did a partial install initially, then a total install later on top of it. Now if I host a multiplayer race, when I save a setup or replay, all my clients get booted. Also, often they don't get a green button on the weekend screen. The problem is that when you've done a partial install, GPL goes to the CD-ROM drive whenever you save a replay or setup, or when you load a track. During the time when GPL is waiting for the CD-ROM drive to respond, it can't service the communications, and critical packets get lost. Randy Cassidy says: "If you've already done a full install over a partial install, you don't need to reinstall the game, just open up the folder that contains gpl.exe, and remove a file named lib.cfg (if you first look at its contents, you'll see that it's pointing at your CD-ROM drive). The presence of this file is what makes the game think that it's a partial install, and is thus causing it to mess with the CD-ROM." I believe some of these issues might also occur if you have a very slow hard drive and your clients have faster drives and can load their tracks before you can. Adding a second hard drive and arranging for Windows' swap space to be on a different drive (physical drive, not partition) from GPL might help with this. 6.1 Bizarre stuff happens on my screen when I try to race over the Internet. My frame rate is really choppy, or the screen flashes and then the other players' cars jump huge distances and keep going. This is most likely due to either the clients or the server's CPU being saturated; in other words, someone is not getting a solid 36 fps, as measured by GPL's frame rate meter (Alt-F). When the CPU is saturated while racing online, there are two major anomalies that occur: * Frame stuttering. This occurs only on the clients. You will appear to be getting poor frame rate, but if you turn on the frame rate meter (just hit Alt-F) you will see that you are getting 36 fps. You may also find that the action suddenly speeds up. If you watch closely, you will see that it is not poor frame rate, but rather a kind of erratic hesitation, or stuttering in the flow of painting the frames. * Clock smashes. These show up as screen flashes followed immediately by major warps; your opponent's car may suddenly disappear and reappear some distance ahead of or behind where it was. This can occur on both client and server. There are several other less significant things which occur, such as not getting a green button, or not getting your correct lap time right away, or getting disqualified for going backwards on the track. Randy Cassidy comments: "Clock smashes can only occur on clients. A server will never adjust its clock for any reason. During the period when a client's clock is smashing, the server may see anomalous gunk from that client, and that client's car may jump around on the server (and, in turn, all other client machines as well), but this is not (in our parlance) a clock smash. If the server begins paging, this will throw timing off, and cause clock adjustment on all clients." 6.2 Why do these strange things happen? Both issues have to do with the way GPL keeps its clients' internal clock in synch with the internal clock in the server, who is hosting the game. Randy Cassidy explains: "In order to accurately reflect the movement of the cars in the game world, all machines participating in a game must have the same notion of time. The timer chips on PC's can vary by a few percent, so a game can actually run a bit faster, or a bit slower from one machine to the next. If two machines whose timer chips tick at different speeds are connected in a multiplayer game, this must somehow be reconciled, or the two machines will very quickly diverge. "If a GPL client believes it is running at a different speed than the GPL server to which it is connected, it will either speed up or slow down slightly to compensate. When the latency (ping time) between a GPL client and a GPL server varies wildly (which can happen if a router suddenly becomes busy), or if a lot of transmitted data is lost (which can happen if a router's packet loss spikes up), this can fool the GPL client into thinking it's not running at the right speed, and cause it to speed up and slow down continuously, causing frame stuttering. "If a GPL client ever thinks its clock is way out of synch with its server, the client will reset its clock, causing a clock smash. When the latency between the client and server is both very high, and varying wildly, clock smashes are more likely to occur." See the ping section for more details on measuring and improving ping times. I have also observed that taking measures to reduce CPU occupancy, such as by reducing graphic display options, can also help reduce or eliminate these problems. I've found that when all GPL clients and the GPL server are running at a solid 36 fps, clock smashes and frame stuttering occur infrequently or not at all. 6.3 Am I going to have to live with this stuff whenever I race online? Absolutely not! If you can, switch to a digital connection (cable modem, ADSL, T1, or ISDN). If none of these connection types are available in your area, I strongly recommend you get a Universal Serial Bus modem. Failing all of the above, and you're stuck with a serial port modem, make sure you have "tuned up" your DUN and serial port settings. Also try switching to the DirectInput driver for your controller. The Generic driver for the controller disables interrupts, which can play havoc with the serial port. If you are still experiencing clock smashes when running as a client, you can make GPL resynchronize with the remote GPL server more frequently. To do this, simply open the folder in which you installed GPL (by default, C:\SIERRA\gpl). To make sure you have the right folder, check to see that it contains the GPL executable, a file named gpl.exe. In this folder, if you haven't already, create a file called core.ini. Using a text editor such as Notepad, open this file and insert the following lines: [ Communications ] clock_adj_delay = 10 This will make your machine resynchronize its clock with the server's clock a little more often, which should help it stay in step and avoid clock smashes. The default value is 12; if you still get clock smashes with a value of 10, try reducing it further. If you go too far, you may begin to experience frame stuttering. The next measure to take is to ensure that all players' machines (or at least those connected to the Internet through a serial port) are running at a steady 36 fps, as measured by the frame rate meter (Alt- F). If you are a client, and are experiencing frame stuttering, ask the host to cut graphics detail till he or she is getting a solid 36 fps. If you are a host, and see clock smashes, ask your client(s) to cut graphics detail till they see a solid 36 fps. Note that a steady 36 fps gives the most benefit; if it's dropping to, say, 32 fps at a certain corner on the circuit, or when there are a lot of cars around, then you or your clients may still experience the bizarre happenings. 6.4 Which graphics details should I cut back first? On a Rendition card, I always turn off anti-aliasing; I just don't like what it does to stuff on the horizon. When running online, I turn the mirrors down to Cars Only, and eliminate car textures in the mirrors. If I need more CPU power (i.e. my frame rate is still below 36 fps, or I'm a client and am getting clock smashes, or I'm hosting and the clients complain of frame stuttering) then I eliminate beveled tires, everything in the cockpit, all lighting effects, and all special effects. I also cut detail bias to 50% or less if necessary. That usually does it, but if not, I can also eliminate terrain textures, tire textures, and then start cutting other textures. 6.5 Ok, I reduced my graphics detail, but now things are really ugly. What are my alternatives? Assuming you've installed DUN 1.2, tuned your DUN and serial port settings, and are using the DirectInput driver for your controller, your remaining option is to upgrade your hardware. See my GPL Hardware FAQ for details. Also see Universal Serial Port modems. 7.1 Can I host players simultaneously over a LAN and over a dial-up connection? Yes. GPL allows you to designate any or all of the available connections for hosting players in a multiplayer game. For example, I have a LAN at home, and I have the usual dialup connection to the Internet, via a 56 kb modem. My LAN is set up for both IPX and TCP/IP. I can dial into the Internet, and then run GPL. When I get to the multiplayer screen, I can choose to host over the Internet TCP/IP connection, the LAN TCP/IP connection, and the LAN IPX connection, all at the same time. 7.2 If I'm on a LAN, does it matter if I use IPX or TCP/IP? Yes. To accommodate hosting dialup-based clients when the host is on a high speed TCP/IP connection such as a cable modem, GPL's default bandwidth for all TCP/IP connections is the same as that for analog dialup connections. The default bandwidth for IPX in GPL is higher than that for TCP/IP, to allow for greater efficiency over LANs. If you use TCP/IP on a LAN, and there are a lot of players in the race, some of the players may wink out, especially in replays. It's best to choose IPX if you have the option. Note that you can over-ride the default bandwidth for any connection type, and also over-ride the default behavior of having ethernet TCP/IP connections use dialup bandwidth. Instructions for doing the latter are in the readme file that comes with GPL. I will post more complete instructions for adjusting bandwidth in the near future. 7.3 I'm running GPL on a Windows 95/98 LAN workstation, using a Linux gateway machine to allow access to the internet. How do I host/join races? I don't have any experience operating GPL behind a Linux gateway. However, John Simmons and Andrew Lavigne have figured out how to both host and join races in GPL from behind a Linux gateway. The 2.2 Linux kernel is required to join from behind the Linux gateway. John has documented documented their findings here. This is the essence of their recommendations: From John Simmons: Hosting A Remote Race Behind a Linux Gateway If you want to host GPL races through a Linux gateway, you must be using a recent kernel, you must have IP masquerading and IP forwarding enabled, and you must download and compile a program called ipautofw. First, get the latest stable version of the kernel that is currently available. You'll need 2.0.33 or later; the latest version at the time of this writing is 2.2.0. Next, turn on the necessary features and re-compile your kernel (if you updated it or need to turn on features). Things you may have to reconfigure: * Enable experimental features (you need to do this to enable IP forwarding) * Enable IP forwarding * Enable IP masquerading I've enabled anyhing having to do with IP forwarding, masquerading or aliasing. It may not have been needed but I hate compiling the kernel over and over again. Download and compile the ipautofw program. To find it, do an Alta Vista search for "ipautofw" and you'll get several hundred references. Lastly (and don't forget, we're assuming IP masquerade is already properly enabled/configured/implemented), add this lines to your rc.local file AFTER the ipfwadm lines: ipautofw -A -r udp 32766 32766 -h X.X.X.X -v -u ipautofw -A -r udp 6971 6971 -h X.X.X.X -v -u Replace the X.X.X.X with the internal IP address of the machine you're running GPL on. For instance MY machine's internal IP is 10.10.0.1, so I would change the line to read like so: ipautofw -A -r udp 32766 32766 -h 10.10.0.1 -v -u ipautofw -A -r udp 6971 6971 -h 10.10.10.1 -v -u You can now host GPL races, even on VROC. Joining A Remote Race Behind a Linux Gateway This section was added on 04/23/99 Update your kernel to 2.2.x. Discussing downloading, updating, and compiling the kernel is beyond the scope of this web page. I also assume that while updating your kernel, you will already know how to setup a Linux gateway and all of the basic configuration stuff will already be performed by you. Use ipchains for your basic masquerading duties (this won't work otherwise). Include this line before your first ipchains statement: echo 1 > /proc/sys/net/ipv4/ip_forward Download and compile the ipmasqadm tool. Add these lines to your rc.local file: # Flush the ruleset /usr/sbin/ipmasqadm autofw -F # Be a GPL server /usr/sbin/ipmasqadm autofw -A -r udp 32766 32766 -h X.X.X.X -v -u # Be a GPL server for VROC too /usr/sbin/ipmasqadm autofw -A -r udp 6971 6971 -h X.X.X.X -v -u The GPL 1.1.0.0 patch is about to hit the streets. When it does, replace the lines above with the following: # Flush the ruleset /usr/sbin/ipmasqadm autofw -F # Be a GPL server /usr/sbin/ipmasqadm autofw -A -r udp 32766 32786 -h X.X.X.X -v -u # Be a GPL server for VROC too /usr/sbin/ipmasqadm autofw -A -r udp 6970 6971 -h X.X.X.X -v -u For all of the lines above, substitute your workstations IP internal address wherever you see "X.X.X.X". Please check John's Web page for more details and the latest information: http://members.home.net/jms1/gplmultiplayer.html Prior to John and Andrew's research, Eric Busch noted: By default, a GPL server will listen for UDP connections on port 32766, though it opens a new socket with a host-assigned port number over which it actually communicates with the client (this may hamper what you're trying to do). You can change the listening port number by placing a file named core.ini in the same directory as gpl.exe that contains these two lines: [ Communications ] net_server_port = <whatever> Or, you can define a service in the services file (c:\windows\services, generally) as such: papy_mpy_ip <whatever>/udp # Papyrus multiplayer games I believe John and Andrew's suggestions supercede Eric's comments, but I include these here anyway in case they might be of use to someone. 7.4 I'm running GPL on a Windows 95/98/NT machine on a LAN, using a Windows 95/98/NT gateway machine running Sygate to allow access to the Internet. How do I host/join races? Using GPL 1.0, I believe it is possible to join races from behind a Sygate gateway without making any changes to Sygate's configuration. I don't believe it's possible to host using GPL 1.0 and Sygate. GPL 1.1 (the patch) allows both hosting and joining races from behind a Sygate gateway. I have tested this on my LAN, using Sygate to provide access to the Internet through a cable modem and MediaOne cable service. The gateway machine has two Ethernet cards, one connected to MediaOne's NetGear cable modem and the other to the LAN. Sygate is installed only on the gateway machine. If you have a similar configuration, you should be able to do the same. First, disable DHCP in Sygate and manually assign each machine its own IP address. I suggest you use addresses from the range 192.168.0.1 through 192.168.0.255. Reboot each machine after making the address assignment. Now you need to tell Sygate to allow connections through the ports used by GPL and to forward communications from the outside to the machine which will be running GPL. To do this, add the appropriate rules to the Apprule.cfg file (typically in C:\Program Files\SyberGen\SyGate\Apprule.cfg) and restart the Sygate service. For example, to run GPL as a server on machine 192.168.0.14, I have added the following lines: # GPL Server definitions # For running GPL on Local Machine 192.168.0.14 :INIT "GPL Client/Server connections" IN UDP 32766 32766 192.168.0.14 0 0 - :SUB OUT UDP 32766 32786 0.0.0.0 0 0 - IN UDP 32766 32786 0.0.0.0 0 0 - :END Substitute the IP address of the machine which will be running GPL on your LAN for the address "192.169.0.14" in the lines above. The following lines are not necessary but document the port on which GPL will broadcast its status reports when requested to do so by VROC. :INIT "GPL Server Status Broadcast" OUT UDP 6970 6970 192.168.0.14 0 0 - :SUB :END If you're not hosting via VROC/GPL Spy Boy, you may wish to add these lines to enable requests for GPL status reports by a remote machine. :INIT "GPL Server Status Report" IN UDP 6971 6971 192.168.0.14 0 0 - :SUB OUT UDP 6971 6971 0.0.0.0 0 0 - :END If you will be hosting GPL on multiple machines behind the gateway, use GPL Spy Boy's Server properties sheet or GPL's core.ini (see the GPL 1.1 readme file) to assign a different port to each machine. For example, to host on another machine on my LAN (say, 192.168.0.11), I would specify to GPL on the second machine that it will listen for clients on port 32787, and I'd add these lines to Sygate's Apprule.cfg: # GPL Server definitions # For running GPL on Local Machine 192.168.0.11 :INIT "GPL Client/Server connections" IN UDP 32787 32787 192.168.0.11 0 0 -:SUB OUT UDP 32787 32807 0.0.0.0 0 0 - IN UDP 32787 32807 0.0.0.0 0 0 - :END Note that you must leave 19 ports free between each GPL server's client listening port (thus the gap between 32766 and 32787). GPL will use these ports for communications with its clients. 10 Where can I learn more about the nitty gritty of racing GPL online? Here are some other sources: * The online section of my GPL Reader FAQ * Michael Carver's comments on MTU/RWIN and related issues * The VROC Technical Notes * The VROC Tech Support Page * Bart Westra's detailed analysis of online issues in GPL