rec.autos.simulators

There is currently a thread running where a race at WG had a guy turning
59s laps which appeared to be rather odd, but was put down to possible
warping as opposed to cheating, although I'm still not sure whether that
was agreed by everyone.  Anyway, could someone explain to me how warping
would cause this anomaly.

Was the guy actually doing 59sec laps on the client side, but the
connection was just unstable?

Was the guy doing 1.06 - 1.07 laps but the server was somehow
interpreting these as 59sec laps?

Both of these possibilities just don't ring true.  If he was doing legal
59sec laps on his machine then how come we've never seen laps like this
before?  

If he was doing only 1.06 - 1.07 sec laps then how could the server and
client get so out of sync?  I was in that race and doing 1.06 laps and
got lapped by this guy after about a dozen laps.  Surely if he was doing
1.06/7 laps then the client side would be able to update the server side
as to his correct track position and he would have been on the same lap
as me and not 1 lap ahead.  Yet this guy's car just winked out from
being some way behind me to then just reappear ahead of me on the track
a second later.  In other words, the server side was actually moving his
car round a lap at 59sec a lap.  

Surely then if this was a warping problem then what the driver would
have thought was his position on the track would have been completely
different to where the server interpreted his car's position.  How could
someone manage to stay on the track like that?  The server would have
had him turning when he should be going straight and going straight when
he should be turning.  This just doesn't seem possible.

Please, can someone explaing this.
--
Peter Ives
(AKA Ivington)

Ive had a case of someone doing a 4 second lap at Monaco.... thats just the
internet for ya, I accept it for what it is. Though, all it really takes is
for the server and client to not be able to communicate for a few seconds
for everything to be outta wack, including timing and scoring.

I noticed something earlier tonite while messing around at Spa with a friend
using TCP/IP not through VROC, I just joined with his IP address... it might
be part of how the magic 59sec laps were ran...

Our connection was bad to begin with - I lost my ISP connection twice and
while on the track there was LOTS of weird ***happening, but the most
curious was the way the warping would happen sometimes...  I would be
driving (as the client) and every now and then things would slow down...
after a few disconnects and watching my buddies car blink on and off like a
Christmas light, I turned on the frame rate display. Normaly, I have NO
problem keeping a solid 35 to 37 fps - not tonite, and this is the weird
bit: my frame rate would drop as low as 17fps at times. Any other program
that = slide show video, but my video was staying as silky smooth as ever
but SLLOOOOOOOWWW - like driving in slow motion... but no problem otherwise.
Then, all of a sudden I would go up to 58 or 63fps and the video would click
right along with it - like driving in fast forward.....  I mean, I could
barely stay on the road, because it was like I found another 800 horsepower.
If the guy at Watkins Glen was experiencing something like this and was able
to keep control of the car, a 59 second lap would be very doable. I never
got to see if it affected my lap time cause I never made a lap with it doing
that - hard to stay between the ditches with the frame rate/video going 35,
43, 15, 26, 58, 17, you get the idea... I have never seen anything like
this. We are using version 1.1 and I noticed on VROC something about the
method GPL uses to keep each end in sync is different and that 1.0 works
better.(?) Since we were'nt using VROC, we would not be using the old
method, is that what caused the boost....?

The answer is the guy drives the lap on his PC and to him everything seems
normal. The server does not tell the client where it thinks the player is on
the track. The client reports it's position to the server and, in return
gets info on where the server thinks the player's opponents are. The client
uses this info for drawing them on screen, or in the mirrors and calculates,
if applicable, collision detection between the local car and the remote
opponent. We see that each client thus calculates it's own version of a
crash (it works both ways, you're the remote on the other guy's machine),
which it corrects with info from the other (and different) crash. This is
the reason why crashes get out of hand on warped connections, but that's
besides the point.

To return to the problem at hand... if your data gets garbled on the way to
the server, you don't notice a thing, but, to the server, your car may
appear to jump forward a fair number of yards (which it thinks nothing of,
it's a computer program)... the server then forwards this position change to
your opponents, who scratch their heads at how you managed to magically
"warp" past them. To the client's machine you never traveled the stretch of
road it's local car occupies so there's no crash. One moment you're behind,
the next ahead, simple as that. Again, it is a program, it does not
interpret the data it gets, it just reads the position (and attitude info)
on the opponent from a buffer somewhere, models, scales and shades the
representation of the car and displays it at the appropriate position on
screen. To the client, there's nothing weird about a car being in one spot
in one frame and in another in the next. The car exhibits this behavior
EVERY frame. It's just us who interpret the distance "traveled" as being
impossible.

IMO there's three ways for such an anomaly to occur. Data may be lost, data
may be received in the wrong order or a combination of both.

A typical example of lost data is the "jump pass". I am racing you at The
Glen and I'm faster, but a lot of my data gets lost. I close up to you in
the Outer Loop and get the power down nice and early. At this point the host
loses track of me... your client, because it's important to you to be able
to see/hear where I am, will try to predict my position but keeps me moving
at roughly the speed I exited the turn at. I.e. you seem to pull ahead on
the straight... phew! -NOT!!! -In fact, locally, I've got the pedal to the
metal and I'm steaming down the back stretch. By the time the next "hard"
position update from my machine reaches you, I have covered more ground than
you and am actually ahead of you on the track. Your client doesn't bat an
eyelid and shows me there... I have just magically jumped over your car.

Wrong order can explain the fast laps as reported by Andre. I can only
assume (and what follows is guesswork) GPL somehow timestamps the position
info it receives and then calculates your lap time based on where you were
first spotted across s/f and were last reported before s/f on each lap, with
corrections for how far you were actually from the line in each case. If, by
chance, 10 seconds after you actually crossed s/f GPL receives a delayed (or
garbled for that matter) packet that shows you closer to, but not before,
s/f than any other it has received yet, it may use this later timestamp to
calculate lap time.... you gain a magic 10 seconds elapsed time, because at
the next update, you shoot back up the track to where you actually were when
the faulty packet was received.

It might also be a case of data "overtaking" a delayed bunch, with that
bunch later being lost and/or ignored. Again a magic time gain is the
result. One stream of updates is almost immediately replaced with another,
but with a much later starting point, i.e. the track is effectively
shortened for you.

Let me take a moment to stress once again that this is just speculation on
my part. I certainly don't know how GPL works and I don't really know how
TCP/IP works: the only thing they ever told me was how the theoretical model
(the so called 7 layer OSI model) is supposed to work. In theory packets can
only get garbled and lost, they should arrive in the right order, but I also
know this is not the case in the real world. Whether I've hit the nail on
the head or whether I'm talking rubbish... I don't really know (sounds
plausible to me though) and I don't care. I wrote this to amuse myself and
maybe be of service to some others.

Cheers,

Jan.
----

Benjamin,

This smells like being the good old warping/slomo problem a lot of people
experienced with 1.1. This is the main reason why the 1.2 patch was released
this fast (at least in GPL terms it is fast, MGPRS needs a bit higher patch
refresh rate :8) ) . Anyway these problems should be solved by now. I don't
think this is the explanation for the mysterious 59sec laps Andre was
describing.

Jan.

<Big snip -- see previous post>

Cheers for your explanation Jan.  As I stated in my original post, there
seemed to me to be 2 possibilities - neither of which seemed feasible -
and your explanation eliminates the second one.  However this would
leave the possibility that he was turning 59 second laps which is some
going.  If he wasn't doing so then eventually the server would have
received the correct data packet telling it where his car was "really"
positioned.  As I said, he managed to lap me after about a dozen laps
even though I was doing 1.06s and for him to be 1 lap up on the server
side would indicate that he was 1 lap up on the client side doing 59
second laps.  Surely not possible considering the known world best time
at Watkins.

--
Peter Ives
(AKA Ivington)

You're right, it does not explain his track position, which, at least in
theory, would have to be consistent with him doing 1m05s (or something) laps
on his local PC.  I wonder if it's possible this guy was merely passing you,
but the scoring (because of his warped laptimes), assumed he was lapping
you?

Also, my view is slightly oversimplified as the client does make an effort
to keep the passage of time "in sync" with the server. However, if it gets
too bad, it's the client who adapts to the server. So if the server has a
misconception, it becomes the truth once the client adjusts itself.

Again, I don't know how GPL works, but as with all unexplained phenomena,
it's human nature to try and reason them out, so consider this an effort to
stay sane. ;-)

Jan.
----

<snip>

It's a possibility.  I do remember at one stage, I think about 6 or 7
laps into the race, that my pit board suddenly showed me leading.
Though next time round I was back in second again without actually being
passed.  So something was definitely screwed up.
--
Peter Ives
(AKA Ivington)

This is all well and good, but I can't see how the dude in question managed to
lap :59 laps consistently!

I'd say that packets out of order would cause chaos on the server as well as on
the clients. You'd see the effects we are talking about, a driver disappearing
and reappearing in front of you. If he is in front of you, and the server
constantly gets old packets, it would seem like the driver was behind you. When
that driver appears in front, his "true" (but still subject to GPLs prediction
naturally) position is shown. AND the reason for you seing this phenomenon
during turns might be that GPL needs more packets to predict your position well
because you are turning. Predicting the next position on the straights is easy,
but very difficult in turns or combination thereof.

That might be the reason for us discoing more frequently in turns than on
straights? Has anyone thought about that?

The reports say that this occurs on one or a few servers, and this might prove
the packets out of order. If the connection to that server is fishy, and packets
are rearranged on their way from client to server, you'd see frequent anomalies
like this. If this was somehting that happened all the time at random servers,
this explanation would be harder to accept.

And anything might happen if you get a discrepancy between the server clock and
right before and right after you cross the line. I have done 4 second laps at
Monaco for instance. And this was not because I found a good setup, far from it.

If this particular client (I refrain from calling him perpetrator ;-) got a
regular and consistent clock smashes (with new or old synch method) right before
the start/finish line, the time registrered by the server would surely be wrong.
If this happen at the same point on every lap, I guess the server is capable of
producing wrong times consistently. And if the client misinterpret the server
time, and is accelerated (clock smash) to match that time, you'd get faster
laps.

I am pretty sure this phenomenon has to do with:
1) Packets getting to the server out of order
2) Clock smashes.

I know little more than Jan about this, but together we might say something
fruitful... :-)

---Asgeir---

I'm no networking expert, but it seems to me that the possibilty of
TCP/IP packets reaching GPL out of sequence is nil. TCP/IP, meaning the
entire Internet and every other TCP/IP network, relies on the TCP/IP
network layer being able to manage the out-of-order receipts of packets
without causing the slightest problem. The server itself might receive a
packet out of order, or damaged, but any application-layer program would
never receive them in that condition.

John