Cheers Randy! Glad to know its on its way. This disabling my modem so I dont
get slow down everytime I run GPL is becoming tiresome! I can look forward
to making snide comments about other drivers behind their backs too : )
(although probably more likely they'll be doing that to me)
--
Cheers,
Robin Lord - Trance DJ & Sim Racer.
http://www.oppositelock.freeserve.co.uk
Nurburgring and Grand Prix Legends
Randy Cassidy <rcassidy@remove_this.aloha.mv.com> wrote in message
news:01bf09c8$0fa76100$9f101d81@randy_c3.internal.papy.com...
| Rick Sweeney <rs...@carolina.rr.com> wrote in article
| <37F02543.5D703...@carolina.rr.com>...
| > Or maybe fix the online problems that the 1.1 patch caused. I use
| cable,
| > and before 1.1 my online connection was awesome. I could host with
| 19
| > drivers easily. Now it just gets so frustrating with the bad conn,
| > Slo-Mo's as they call it, its just not worth going on-line anymore.
| Yea
| > I have the latest greatest INI allison file, and have tried numerous
| > variables upon that, and just gave up.
|
| The localized versions of the GPL 1.2 patch are currently being tested.
|
| I must apologize to all of you for the non-real-time gaff in 1.1. I
| don't know how we missed this. It is fixed in 1.2, along with several
| other bug fixes and improvements (slow-mo/turbo is no more).
|
| Here's the readme12.txt. GPL 1.2 is NOT yet released. I'll be sure to
| let y'all know when it is.
|
| Randy
|
| -------------------------------------------------
| Grand Prix Legends PATCH README
| Version 1.2
| 8/18/99
|
| [ To read this file, select Edit/Word Wrap from the menu above ]
|
|
| TABLE OF CONTENTS
|
| 1. GENERAL
|
| 2. MULTIPLAYER
|
| 3. CONTACTING SIERRA
|
|
| 1. GENERAL
| ----------
|
| This patch will upgrade GPL version 1.1.0.3 to version 1.2.0.x.
|
|
| GPL 1.1.0.3 introduced a bug that could cause the game to run slower
| than normal. This lead to numerous problems, most of which were even
| worse when running multiplayer races. This is now fixed.
|
|
| The driver selection list on the race weekend screen could contain
| blank entries. Also, when selecting a driver from the list, the program
| might focus the camera on the wrong car. This is now fixed.
|
|
| If you miss the start of the race, you must now join the race within
| about two minutes, or the green button is taken away and you will not
| be allowed to join.
|
|
| If you have installed replays from many different players, the <Player>
| drop-down list on the Load Replay screen would expand off the bottom of
| the screen, instead of turning into a scrollable list of players. This
| is now fixed.
|
|
| If you had any saved replays from players that did not enter a driver
| name, the <Player> dropdown list would default to showing only replays
| created by these players, instead of showing replays created by "All
| Players." This is now fixed.
|
|
|
|
| 2. MULTIPLAYER
| --------------
|
| GPL 1.2.0.x clients and servers will not connect to GPL 1.1.0.3 clients
| and servers (and vice versa). If you try to connect, you will be told
| that the server is incompatible.
|
|
| If you disconnected from a race server, and then reconnected to the
| server, the server would no longer score laps driven by you during the
| practice session. This is now fixed.
|
|
| A new chat command has been added. Any Boss may now tell the server to
| stop the current race (if any), disconnect all clients, and exit by
| issuing the "!shutdown" command as a chat message.
|
|
| It was possible, particularly when connected to a fast dedicated race
| server, that your pit stall placard and lap time board would be
| positioned incorrectly when transitioning from one race to another.
| This is now fixed.
|
|
| You can now issue private chat messages to any one of the players
| connected to the server. Begin your message with "/", followed by the
| name of the player (or #car_number), followed by the message. For
| example
| /#16 Hey, John. What's up?
| /smith What's up?
| /j.smith What's up?
| /jo.smi What's up?
| /john.smith What's up?
|
| The message will only be sent to the person you identify (or you will
| be given an error message if the program couldn't figure out who you
| meant).
|
|
| GPL 1.1.0.3 added a new method by which a client would try to stay in
| step with its server. When latencies were fairly stable, it was
| smoother than the original method employed by GPL 1.0. When latencies
| were unstable, however, the game could speed up or slow down rather
| excessively, making it very difficult to control the car. We've
| reworked this synchronization method to make it less sensitive to
| fluctuations in latency, and to prevent it from applying excessive
| adjustments. It should now be much smoother than the GPL 1.0
| synchronization method, even when the latency is very high and very
| unstable. The new synchronization method is used by default. However,
| if you had switched to using the old synchronization method with GPL
| 1.1.0.3 because the "turbo/slow motion" effect was destroying gameplay,
| please give the new method a try (just remove the synch_method=0 line
| from core.ini, or change it to read synch_method=1).
|
|
| The Internet can be a harrowing medium through which to race. Gameplay
| is directly affected by the latency, reliability, and consistency of
| the connection between you and the game server, so it's important that
| the program give you a good sense of these factors. GPL 1.2.0.x now
| has graphical displays that allow you to monitor the status of your
| communications with the server when you are a GPL client. These meters
| can only be displayed while in the car. They can be toggled on/off by
| pressing Alt-M while in the car. They can be distracting while
| driving, so they are turned off by default. You can request that they
| be turned on by default by adding the following two lines to core.ini
|
| [ Communications ]
| show_meters = 1
|
| The bar graphs are as follows...
|
| (L) Instantaneous latency from 0.0 seconds (the bar is empty) to
| 1.0 seconds (the bar is full height). This is the amount of time that
| it takes for a message to go from the server, to your client, and back
| to the server. Note that Alt-L shows average latency, not
| instantaneous latency.
| (Q) Quality from 100% (the bar is empty) to 0% (the bar is full
| height). The more data that is lost or garbled during transmission
| from the server to you, the lower the quality of your connection, and
| the higher this bar will go.
| (S) The time skew (difference) between your GPL client and the
| server. If your current time is behind where you expect the server to
| be, this bar will be below center. If it is at the bottom, then you
| believe that you are 1.5 seconds (or more) behind the server. If your
| current time is ahead of where you expect the server to be, it will be
| above center. If it is at the top, then you believe that you are 1.5
| seconds (or more) ahead of the server. If the bar reaches the top or
| bottom, then your client will resynchronize itself with the server (it
| will smash its clock).
|
| Ideally, no red bars should be visible whatsoever. That is, you
| have 0.0 seconds of latency, 100% of data from the server is getting to
| you, and your client believes that it is at the same point in time as
| the server. In practice, this will not happen.
|
| The (L)atency bar will almost always be visible since it is not
| possible for data to get from the server to you instantaneously. The
| higher the latency, the longer it takes for data to get from the server
| to your computer, and so the older it is when it gets there. The older
| the data is, the more "predicting" your client has to do about the
| positions of other cars on the track. The more that it has to predict,
| the more likely that it will predict incorrectly, and the more the
| other cars will jump around when it realizes its error.
|
| It is not uncommon for the (Q)uality bar to be completely empty
| (indicating little or no data loss), but it is also not uncommon for a
| few percent of the data to be lost or garbled during transmission,
| showing as a small (Q)uality bar. If the bar starts to grow steadily,
| then something bad has happened on the route through the Internet
| between you and the server (or the server has crashed). If the route
| doesn't clear up quickly, you will soon be disconnected. If it does
| clear up, there will probably be short period of mayhem as the route
| settles down, and old data that has been stuck in transit is flushed.
|
| If the latency is varying a bit, it can be difficult for your client
| to determine what point in time the server is currently at, and a small
| (S)kew bar is likely to appear. If the (S)kew bar grows continuously
| until it hits the top or bottom, your client will smash its clock to
| resynchronize itself to the server. If it does this, then either the
| connection between you and the server is very poor, or either your
| machine or the server machine is extremely overloaded, and your client
| can no longer stay in step with the server.
|
| -------------------------------------------------
|
