rec.autos.simulators

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!