GPL (Grand Prix Legends) On-Line

Grand Prix Legends Online FAQ copyright 1998, Alison Hine http://www.nh.ultranet.com/~alison/gpl/faq-online.htm Racing in GPL over the Internet presents a special set of challenges. Because of GPL's bandwidth requirements, 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 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. 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? * 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. We expect that more players will be possible when hosting over an ISDN line or an ADSL connection. We've seen as many as 14 players in games hosted over a cable modem. * DUN upgrade and tuning. I highly recommend that you upgrade your DUN to 1.2 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.) * 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'll almost certainly 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 anomalies such as missing green buttons on the clients' race weekend screen, and clients getting booted when the host saves a setup or reply file. * 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. Also, there are certain other steps that you may find will help avoid certain strange behaviors in GPL multiplayer races hosted over the PC's 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." 2.1 Ok, how do I find other people who would like to race GPL online? Watch The APEX in the coming weeks for an exciting announcement regarding an automated online racing connection capability for GPL. In the meantime, there are several ways you might meet up with other people to race. The beta team has used a private email list to schedule times to meet, and then we meet on ICQ at the designated time. We initiate a chat, decide who will host, and whoever will be hosting informs us of their IP address. ICQ now has the capacity to initiate chat rooms, and I expect this will prove useful for finding other people who want to race in GPL. Basically any generic chat mechanism will enable you to chat with other people to set up a race. Internet Relay Chat (I recommend mIRC), AOL Instant Messenger, or Kali are other possibilities. You might try posting a notice on the rec.autos.simulators newsgroup regarding a time you'd like to meet at a designated chat location. 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.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. 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 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), 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 may well be possible to host more players over a cable modem or ADSL connection, 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 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! First, 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 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. 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 on a cable modem which is connected to a Linux box which is configured as a gateway. All of the machines on my LAN can access the internet thru this Linux gateway. I can't connect to anyone else running GPL as a server, and nobody can connect to me when I try to be the server. I think that if I can identify which port GPL uses, I can pass the packets thru to the Win95 machine that is actually running GPL. How can I find out a) what port GPL uses, and b) if my theory holds water? Eric Busch replies: "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 8.1 Will GPL work via null modem or direct dialup connection between two computers? These capabilities are in GPL, but I've never used either. If you try one, please let me know how it works. 8.2. Will GPL work over Kali? I've never gotten this to work, but it may be possible to make it happen by reducing GPL's IPX bandwidth. Please let me know if you succeed, and how you did it. However, even if you can't get it to work, don't worry. You can still use Kali for chatting, and get the host's IP address from the prospective host during the chat. Or if you are going to host, inform your client(s) of your IP address. Then simply launch GPL normally (from the Start Menu or from a shortcut you've placed on your desktop), and either host a race session via TCP/IP or enter the host's IP address and join. Remember that Kali is basically for games intended only for LANs, and which support only IPX for multiplayer gaming. Kali allows you to play such games over the Internet, which is almost entirely TCP/IP. Since GPL has TCP/IP built in, IPX to TCP/IP translation services like Kali are really superfluous. 9 All that stuff about ping times and routes and core.ini seems awfully complicated. Papyrus said that GPL was designed from the ground up for multiplayer play. Why isn't it simpler to race on the Internet? When Papyrus said that GPL was designed from the ground up for multiplayer play, they were talking about LAN-based multiplayer racing, not Internet-based multiplayer play. GPL was really never intended to work over the Internet. During most of the development period, Papyrus believed that current Internet technology is simply not capable of supporting GPL's bandwidth requirements. GPL's sophisticated physics, detailed cockpit, and three dimensional positioning require twice as much data to be transmitted between client and server as other racing sims such as NASCAR 2 on NROS. When I joined the beta team in January, GPL was essentially unplayable over the Internet. I inquired about this, and Papyrus told me bluntly that Internet play was not going to work in GPL. There simply wasn't time to address the host of issues raised by the bandwidth limitations and latency issues inherent today's Internet environment. However, several of the beta team members were highly motivated to find ways to get GPL to work over the Internet. We identified a number of separate issues, and proposed solutions. We were very fortunate that a key engineer, Randy Cassidy, was also very motivated to make this happen. Randy worked overtime to make a variety of modifications which addressed the most severe issues and made GPL very workable over the Internet. Were it not for Randy's dedication, and the persistence of the beta team, we would not have the capability to race GPL online at all. There are a number of additional changes that might have been desirable, such as reworking the way in which the clients' internal clocks are synchronized with the server's, or adding some sort of bandwidth adjuster to the UI. However, at the late stage in the development process at which Internet issues were addressed, it was judged imprudent to make major changes, since such changes might have destabilized GPL in other ways. Adding further refinements would have delayed the release of GPL, and no one wanted that!