Hey David, there's no bad blood between ourselves and Papy. ;)
David L. Cook <dlc...@mediaone.net> wrote in message
news:MPG.125ae694ac66ffbe9896d9@news.pompano.net...
> These fixes are really appreciated - but if an add-on like the Act Labs
> RS Shifter is so easily implemented by other game developers, why don't
> you take advantage of this opportunity to include support for it in the
> forthcoming patch? I don't understand. It would be such a perfect fit.
> Is there bad blood between Papyrus and Act Labs?
> David Cook
> In article <01bf09c8$0fa76100$9f101d81@randy_c3.internal.papy.com>,
> rcassidy@remove_this.aloha.mv.com wrote...
> > 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
...
