|
GPL Online FAQ |
|
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.
Notes: For optimal racing with GPL online, you'll need GPL 1.2, available from Papyrus, and the GPL Disco Fix. These two patches address many of the Internet racing issues discussed here. Together they provide the state of the art online racing experience.
If you're connected via an analog (telephone) modem, see also DUN and Serial Port Settings for GPL and Thoughts on How to Improve On-line Connections.
For still more information about GPL online racing issues and solutions, see the VROC Technical Notes page.
It's essentially the same, but with certain limitations. See the next question.
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:
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:
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.
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.
Winmodem Update: At least one reader has had Winmodem experience precisely the opposite of what I suggest above. Gary Johnson says, "I have been enjoying the on-line races at VROC for about two weeks now and have very acceptable connections." His system:
Gary says, "Both on and off line I get a solid 36fps inside and outside the car." Clearly, with enough CPU power and the system tuned so that the CPU does not become saturated (see my CPU section for details), a Winmodem can work.
My experience suggests that 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 cards.
A digital connection such as ADSL, modem, or ISDN is generally 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 modem, check out PH Net's suggestions for 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.
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 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, 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.
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 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.
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.
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.
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.
~ (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.
This typically occurs if you have an ISP (Internet Service Provider) who assigns you an IP address dynamically, but doesn't report it to your machine in the most common way. Such ISPs include AOL and certain providers of modem service, including MediaOne.
The fix is simple. From the GPL 1.0 readme:
If you have a local area network, and your network card is dynamically assigned an IP address (using DHCP), you must tell GPL to use an alternate method of determining your machine's IP address.
Using Notepad, create a file named core.ini in the same folder in which gpl.exe exists containing the following two lines:
[Communications] alternate_ip_addr_lookup = 1Note, however, that if you use this alternate method, and your only TCP/IP connection is via a modem, and you have your Internet properties set to automatically connect to the Internet, and you're not connected to the Internet when you start GPL, Dial-Up Networking will start up when you launch GPL. This may cause GPL to not function properly, and/or your machine may connect to the Internet.
Special Note: A number of people have written that their core.ini settings have no effect in GPL. The problem is that they've used the sample file, core.ini.sample, which comes with GPL 1.2, instead of core.ini. The fix is easy. Go here.
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.
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.
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 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.
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.
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 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."
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!
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.
Simply click here and follow the instructions.
|
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.
Special Note: A number of people have written that their core.ini settings have no effect in GPL. The problem is that they've used the sample file, core.ini.sample, which comes with GPL 1.2, instead of core.ini. The fix is easy. Go here.
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.
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.
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.
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:
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."
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.
Absolutely not!
If you can, switch to a digital connection ( 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.
Special Note: A number of people have written that their core.ini settings have no effect in GPL. The problem is that they've used the sample file, core.ini.sample, which comes with GPL 1.2, instead of core.ini. The fix is easy. Go here.
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.
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.
Does this condition persist through the race? When people join when you are already on the track, an anonymous detxture gets assigned so that the comouter doesn't have to go to the hard drive for textures while you are driving. However, before the race, numbers should get assigned and the textures should get loaded.
I'm not sure what happens when you go back to the pits during practice; theoretically, they should get numbers and load textures then, but I'm not sure that always happens.
I believe that disconnects are typically caused by periods of interruption in packet delivery. This is connection quality, commonly measured by percent packet loss, and it does not always coincide with good latency (low ping times).
Assuming you've already optimized your DUN connection as I suggested above, the most likely source for these interruptions are the following:
If you're getting 36 fps all the time (and so is the host), that should rule out item 1. Most experienced hosts on VROC know to keep their frame rate at 36 fps (assuring that the CPU is not too busy) and to limit the number of players appropriately. I assume you've tried joining races in which the host has limited the number of players to a quantity which can be handled by their connection's upload bandwidth. (See Bart Westra's detailed analysis of online issues in GPL for details about this.)
Since you've previously had good connections, it seems likely that one of the other two items is the source of your problem.
Connection problems are often aggravated by DUN modem-related issues. Some people have had big improvements by tweaking their DUN and modem settings. It can be very worthwhile to reduce modem retraining by running your modem at a slow speed to start with (26.4 or 24.6). You can do this by setting up a second DUN connection and a second copy of the same modem in Windows to be used purely for racing.
See DUN and Serial Port Settings for GPL and Thoughts on How to Improve On-line Connections for more information about tuning and optimizing your DUN connection.
You can look for busy routers by using WinVROC's Inspect feature to trace the route to the various servers at any given time. Look for routers that drop a significant number of packets. If it turns out to be problem routers in your ISP's part of the network (this should be fairly obvious from the names shown in the Inspect window) then copy the Inspect report(s) to a text file and send it to your ISP along with a complaint. Another possibility might be to try a different ISP, if one is available, or ISDN, ADSL, or modem if you are lucky enough to have access to any of these.
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 previously had the usual dialup connection to the Internet, via a 56 kb modem. My LAN is set up for both IPX and TCP/IP.
I could dial into the Internet, and then run GPL. When I got to the multiplayer screen, I could choose to host over the Internet TCP/IP connection, the LAN TCP/IP connection, and the LAN IPX connection, all at the same time.
Now that I have a cable modem connection (through a Linksys BEFSX41 hardware router) I can host races via the Internet and join the same races from other machines on my LAN.
Yes. To accommodate hosting dialup-based clients when the host is on a high speed TCP/IP connection such as a 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.
Update, February 2003: The following discussion applies to Sygate gateways but the principles apply to any software or hardware router/gateway that you are using to connect your LAN to the Internet. For example, I am now using a Linksys BEFSX41 hardware router (instead of my old Win98 computer and Sygate) to interface between my cable modem (a Toshiba PCX2200) and my LAN. All of the settings in GPL's core.ini stay the same; the only thing that changes is that I forward the necessary ports in the Linksys router that I previously forwarded in Sygate.
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.
The GPL 1.2 patch (available from Papyrus) 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 modem and MediaOne service. The gateway machine has two Ethernet cards, or NICs, one connected to MediaOne's NetGear 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. Also make sure that each machine points to the LAN IP address of the gateway machine for its gateway and its DNS server. Reboot each machine after making the address assignment and any changes to the gateway and/or DNS server assignment. (For more details about IP address assignment on a LAN, see the LAN IP Address section.)
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. This is called "port mapping".
To do this, add the appropriate rules to the Apprule.cfg file (by default, this is 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" # Prtcl DestLo DestHi ClientIP Port Idle Options IN UDP 32766 32766 192.168.0.14 0 0 - :SUB IN UDP 32766 32786 0.0.0.0 0 0 - OUT UDP 32766 32786 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.
Note: The examples in this section previously had an error in them. They had a second zero in the OUT line but this was incorrect; there should be only one 0 between the Client IP address and the Options flags. OUT rules have no Port parameter. Earlier versions of Sygate will accept the second 0 but I believe that later versions will reject it.
If you're hosting via VROC, you'll also want to enable VROC's Ping port, which is used by the JavaVROC applet for determining ping times to your server from potential clients. For example, I have:
:INIT "VROC Ping Port" # Prtcl DestLo DestHi ClientIP Port Idle Options IN UDP 6969 6969 192.168.0.14 0 0 - :SUB :END
Note that the port number must be consistent with the Ping Port which you declare for that machine in the JavaVROC applet or in WinVROC. The default is 6969; avoid ports 6970 and 6971 since these are used by GPL.
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" # Prtcl DestLo DestHi ClientIP Port Idle Options OUT UDP 6970 6970 192.168.0.14 0 - :SUB :END
If you're not hosting via VROC (and you're not running a VROC External server) you may wish to add these lines to enable requests for GPL status reports by a remote machine.
:INIT "GPL Server Status Report" # Prtcl DestLo DestHi ClientIP Port Idle Options IN UDP 6971 6971 192.168.0.14 0 0 - :SUB OUT UDP 6971 6971 0.0.0.0 0 - :END
If you will be hosting GPL on multiple machines behind the gateway, use WinVROC's Server properties sheet, JavaVROC's Host Port field, 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" # Prtcl DestLo DestHi ClientIP Port Idle Options IN UDP 32787 32787 192.168.0.11 0 0 - :SUB IN UDP 32787 32807 0.0.0.0 0 0 - OUT UDP 32787 32807 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, which is why we open them with the SUB IN and SUB OUT rules.
If this machine will be hosting on VROC, I'd add the following lines so JavaVROC will ping this machine on port 6968:
:INIT "VROC Ping Port" # Prtcl DestLo DestHi ClientIP Port Idle Options IN UDP 6968 6968 192.168.0.11 0 0 - :SUB :END
Note that the port number must be consistent with the Ping Port entered in JavaVROC or WinVROC on this machine, and each machine on your LAN should use a unique Ping Port number. Avoid ports 6970 and 6971, because they are used by GPL.
Here are the relevant sections from the apprule.ini file.
For inbound:
# ClientIp:
This field tells SyGate where to pass the incoming packet with the destination port in the range defined by DestinationPortHigh and DestinationPortLow.
# This field has to be set to 0.0.0.0 for Sub-trans-x. For Triggering Transactions, this field must be set to the IP of one of the clients.
For outbound:
# ClientIp:
This field tells SyGate which client can trigger the rule. In Trigger Tansactions, 0.0.0.0 means any client can trigger. In Sub-Trans-x, ClientIP has to be 0.0.0.0.
To try to explain, in the OUT rule, the IP of 0.0.0.0 is essentially a "wild card" which allows any IP to match, while in the SUB IN rule it says to use the same IP as in the initial, or "trigger", IN rule.
In other words, the first, or INIT, IN rule says that the trigger transaction is an inbound request on port 32766, and it is routed to the computer at 192.168.0.14, which happens to be the machine I generally use for hosting GPL events.
The second, or SUB, IN rule says that any subsequent inbound packets from the same outside client to ports 32766-32786 are routed to the same machine, 192.168.0.14.
As for outbound packets, the rule says that any machine on my LAN is allowed to route packets out through ports 32766-32786, but obviously in practice only the computer at 192.168.0.14 will ever do so (assuming I've configured my GPL servers correctly). Still, the documentation says that this has to be set to 0.0.0.0 for all SUB transactions.
Yes, Sygate is quite happy to accept a dynamic IP address for the NIC (Network Interface Card, or Ethernet card) to which your modem is attached.
See the next question for a diagram of IP address assignments on a LAN which shares a modem or other high speed connection.
Note: See my Update at the beginning of the Sygate section for information on using a hardware router instead of Sygate.
Remember that IP addresses are assigned to NICs, not to computers, so a machine can have more than one IP address. Such machines are called "multihomed". The gateway machine will be a multihomed machine.
Sygate has its own DHCP server which can dynamically assign IP addresses to each computer on your LAN. However, this will make it impossible to use the port mapping rules explained in the Sygate section, because the IP addresses on the machines on your LAN can be different each time you reboot.
Therefore, it's best to turn off DHCP in Sygate and manually assign an IP address to each computer on your LAN, using an IP address from the range of nonroutables, 192.168.x.x. Remember to reboot each machine after making an address assignment and any changes to the gateway and/or DNS server assignment.
Here's my LAN configuration:
|
[ modem]
|
| ---PC 2 --
o-------- NIC 1 | Dynamic IP address
|
o-------- NIC 2 | 192.168.0.11
| ----------
|
o--------[ PC 1 ] 192.168.0.14
|
|
o--------[ PC 3 ] 192.168.0.12
This allows me to specify port mapping rules in Sygate (on PC 2) for hosting GPL on any of the computers behind the gateway.
Note that you don't need any port mapping rules for hosting GPL on the gateway machine, PC 2. In fact, if you do put port mapping rules for this machine in Sygate, GPL won't see clients who try to connect. This is presumably because their incoming connection requests are getting forwarded to the NIC on the LAN (192.168.0.11) and getting lost.
Note that the same principles apply to any multihomed machine, whether the Internet connection is through a modem, xDSL, ISDN, a T1 line, or even an analog modem.
I tried doing this and quickly realized this configuration was a bad idea.
Here's why: GPL tells the operating system to give its physics and other stuff very high priority. This makes GPL have higher priority than the gateway software, which forwards the clients' packets from the Internet to the server and back again.
Therefore, if you race on the gateway machine, clients whose packets are routing through your gateway (ie anyone joining from the Internet) may get high and/or variable latency, especially any time GPL is very busy (coping with a crash, generating smoke, etc.)
Also, any time the gateway machine accesses the hard drive, packet forwarding gets interrupted for a moment. This can cause GPL clients to disconnect. Launching GPL on the gateway machine is almost certain to disconnect many of the clients who have already joined the server. Saving a replay or even a setup can impact clients.
I originally was using a configuration like this:
|
[ modem]
| ---PC 1---
o-------- NIC 1 | Sygate
| GPL client
o-------- NIC 2 |
| ----------
|
o--------[ PC 2 ] GPL server
Note: NIC = Network Interface Card, or Ethernet card
I raced on PC 1, a P2-392, and ran the server on PC 2, a P-233. Every time I hit the hard drive on PC 1, people got discoed because their packets stopped getting forwarded for a little while. And they had really variable latency any time I was racing. It was bad.
I switched to this configuration:
|
[ modem]
| ---PC 2 --
o-------- NIC 1 | Sygate
| GPL server
o-------- NIC 2 |
| ----------
|
o--------[ PC 1 ] GPL client
Now the server on PC 2 works great, and anything I do in GPL on PC 1, such as save replays or setups, has no adverse effect on PC 2.
While I'm hosting, I'm careful not to do anything that accesses the Internet, like Web surf or retrieve email. These would affect the clients on PC 2's server because I'd be using some of its bandwidth to the Internet.
To make sure I don't inadvertantly use any bandwidth and degrade the clients' connections to my server, before I host a race, I always shut down GPL Spy Boy, the VROC Java race room, and any other chats or anything else I might have running on PC 1 or any other PC on the LAN which might access the Internet.
Yes. This works just fine. We've had two computers join races on the Internet through an analog modem connected to a machine running Sygate.
According to Bart Westra's calculations (see the Bandwidth page under Help on VROC), each client needs about 13.2 kb download and 9.9 kb upload. Since a 56k modem has a maximum upload speed of 33.6, the limit is probably three clients on an analog modem.
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:
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:
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:
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:
You can now host GPL races, even on VROC.
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:
Download and compile the ipmasqadm tool.
Add these lines to your rc.local file:
The GPL 1.1.0.0 patch is about to hit the streets. When it does, replace the lines above with the following:
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:
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.
I'm using a modem too. I haven't done anything special to the default Windows settings for the NICs that attach my GPL server, GPL client machine, and gateway machine to my LAN, nor to the NIC on my gateway machine that attaches to the modem.
The only thing I've done is to install Sygate on the gateway (that's what makes it a gateway), and point the other machines to the gateway as their gateway and DNS server. I also set all the machines on my LAN to have static IP addresses in the 192.168.0.x range. That way I can tell Sygate to open ports to each of them for hosting on any one or more of them. Details about this are above.
Also I recently made a big effort to eliminate various problems that were occuring with GPL both hosting and joining races from various machines on my LAN. Details are in the answer to the next question.
Basically you need to make certain that any machine that's hosting GPL is always getting 36 fps. Anything less, and packet delivery to your clients will be slowed, which can seriously compromise the quality of their racing or even cause them to disconnect. See the frame rate section of the Hardware FAQ for details.
If you can put together a separate machine for hosting, I think you'll be a lot happier. It doesn't have to be very fast; I'm using a Pentium 233 with Stealth II S220 (Rendition 2100) and 64 mb and that works fine as a GPL server. I use a couple of lines in core.ini to allow longer replays:
[ Replay ] replayMemoryOverride = 30000
Special Note: A number of people have written that their core.ini settings have no effect in GPL. The problem is that they've used the sample file, core.ini.sample, which comes with GPL 1.2, instead of core.ini. The fix is easy. Go here.
GPL seems to have a bug which causes the host's car to be a lot more fragile than it should be. Also, offloading the GPL server tasks to a seperate machine allows your racing computer to focus on running your car's physics and 3D display. This way, momentary peaks in CPU utilization due to skid marks, smoke and/or crashes involving or near your car won't affect the clients as they might if you were driving and hosting on the same machine.
See above for information about configuring GPL and a LAN so you can join races on your own server across your LAN.
Update Feb 2003: See also my note below about cable modem problems I had in recent months and the resolution.
I had great luck with my modem at first. I could host and people had great connections, and I rarely got disconnected from races. However, after a few months I began having terrible trouble with people disconnecting from my GPL server. Disconnects also began to occur fairly frequently when I joined other peoples' races.
Also, GPL would sometimes exit to the desktop spontaneously when I was driving, right in the middle of a practice session or a race. This happened on my client and on two different machines that I used as servers. I also had trouble using IPX to connect in GPL between the machines on the LAN.
This prompted a concerted effort to find the source of my problems and eliminate them. My LAN is working great now and I have hosted a number of races with excellent results.
The things I did that helped were:
1. Replaced all cheap NICs (Linksys, D-Link, Addtron) with 3COM 10/100 NICs (this appears to have stopped the problem I had with GPL exiting to the desktop in the middle of races, knock on wood!)
2. Replaced my inexpensive Linksys 10Base-T hub with a Netgear DS108 10/100 hub.
3. Rebooted the modem (a Netgear LCP100) by unplugging it and leaving it unplugged for 90 seconds. I did this after the MediaOne tech support guy ran some diagnostics on my modem from his office and found it had very poor throughput and was losing a lot of data.
The reboot dramatically improved throughput and reliability. The tech support guy said sometimes modems get confused and need to be rebooted. This can happen if someone else in your neighborhood is using, say, an old box that is making noise in the frequency range that the modem uses.
If you have a Netgear LCP100 you have to leave it unplugged for at least 90 seconds to make it forget its settings and start fresh. This is the only modem I have experience with, so if you have another type, you'll have to check with your tech support to find out how to reboot it, or if that's even a good idea.
4. Made registry changes recommended in a Microsoft document on my GPL client (this is only relevant if you have a V3 3500). The Microsoft document is:
http://support.microsoft.com/support/kb/articles/q230/2/43.asp
More details and the guts of the Microsoft document are here. Note: This problem can affect any computer that has Microsoft WebTV installed, whether it has a Voodoo3 card in it or not!
This fix eliminated a performance problem that had been occuring on my GPL client since I installed the V3. This problem wasn't too apparent when I used it as a client, but it cause frame rate degradation when I used it as a GPL server. The degradation was even more apparent in some other sims (NASCAR 3 and Dirt Track Racing) when running as either a client or a server.
I now suspect this problem was also causing the excessive disconnects I was experiencing as a GPL client, and I wonder if it may have caused or contributed to the corruption that occurred in the modem.
At any rate, things are working much, much better now!
Update Feb 2003: I got a cable modem in 1999 and had very good luck with it at first. However, during 2000 it deteriorated until racing was very difficult and hosting impossible. Extensive testing showed I was losing many packets and was frequently losing the connection entirely, sometimes for many minutes.
The symptoms in GPL were intermittent warping of remote cars, frequent winking out of other cars, clock smashes, and frequent disconnects from servers. I experienced these problems whenever I joined any remote server, and other people experienced them whenever they joined my (previously excellent) server.
The problems turned out to be due to a weak cable signal from the street, apparently because my house is located farther from the street than all of my neighbors. This required my ISP, AT&T, to turn down the strength of the signal to avoid overpowering my neighbors. Unfortunately, this left the signal too weak for me, and caused many dropped packets and even intermittent total connection loss.
AT&T replaced all the cables coming into my house and reconfigured various things, but I still had severe problems, especially in cold weather, which apparently reduces the output of the "plant" - the equipment on a pole down the street that communicates with the homes in the neighborhood.
The fix turned out to be a Motorola Signal Amplifier Drop Amp from Best Buy.
Yes. Read what Tore Hansen has to say about his Netgear Internet gateway router in my Reader FAQ.
Update, February 2003: I am now using an inexpensive hardware router, a Linksys BEFXS41. This works fine for hosting GPL on one or more computers on my LAN while joining local or remote races on other computers. It uses very little electricity so I don't mind leaving it on all the time, and it requires less maintenance and fiddling than a computer running Windows and a software router like Sygate or a Linux gateway.
My brother Nate Hine has been using a 3COM OfficeConnect 56k LAN Modem to connect the computers on his home LAN to the Internet. He says this is working out to be a very satisfactory solution.
The OfficeConnect LAN modem combines a modem, a router, and a hub. It uses Network Address Translation (similar to Sygate) to allow all the computers on the local LAN to share a single IP address.
A big advantage of using this approach for racing GPL on the Interent is that it completely eliminates the serial port (or the USB port) from your computer's Internet connection. Your computer only needs to have an Ethernet card in it, which presents much less overhead to the CPU than does handling a serial modem. The LAN modem handles all the serial communications overhead that is such a drain on the CPU when you are connecting to the Internet via an ordinary modem, so you should get smoother frame flow and less warping.
Another advantage, if you have more than one computer at home, is that all of the computers in your home can connect to the Internet through the same LAN modem. They can even connect all at once if you like (although you wouldn't want to have people surfing or downloading big files while you're racing).
As of this writing (February 2000) the 3COM LAN modem is available at Buy.com for under $250. Go here.
Netgear also makes a LAN modem, the RM356, which is available at Buy.com for under $200. Go here.
These capabilities are in GPL, but I've never used either.
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.
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!
Update: Many of the changes we would have liked to have in GPL 1.0 were implemented in the GPL 1.1 and 1.2 patches. GPL 1.2, an upgrade which can be downloaded for free from Papyrus, incorporates many refinements and enhancements, including vastly improved client-server synchronization, improved player-to-player collision detection, numerous extensions for hosting, and many other improvements and bug fixes. As of early 2000, GPL 1.2 represents the state of the art in Internet-based multiplayer racing.
Here are some other sources: