rec.autos.simulators

It's only recently that I've gotten to play with big, multiple-CPU
iron. Single CPUs still have a good bit of life on the desktop. :-)

I worked at Papyrus for a while and this is the Papyrus model of physics
(constant timebase) contrasted with the MicroProse model (constant
framebase).

If you can maintain a constant (high enough) framerate, or are willing
to go slow-motion at times, there is no disadvantage to the MPRS
model, and it's arguably a good bit easier to code and debug and is
slightly more efficient. The problem is, you can't... :-)

3 seconds of latency is going to kill any chance of a head-to-head
motorsports sim... That's a whole straightaway on a some circuits. You
don't need constant latency, but you do need reasonably low
latency. (Praise cable modems, ADSL and ISDN, as they avoid some D/A
and A/D steps, which add latency to the link.)

It would seem that would work, and in theory would work. (constant
timebase physics systems have a simplicity advantage here) But,
there's a lot of chaos in the system, particularly when you consider
wind and draft effects that it's not totally clear that you could make
this system work easily. (Given enough effort, you could, but
cryptographically signing binaries might be a lower effort admittedly
less secure method to achieve better anti-hacking than currently exists.)

And of course, your proposed method still isn't hack-proof, as I could
envision a system that just doesn't allow (or subtly reduces) tire
wear or fuel consumption. That wouldn't be caught by your system,
since you'd need to rely on the client for the initial
world-configuration vector which would include the initial hacked tire
wear or fuel level.

(What do you want to bet that the number closely reading this thread
is now well under 10, perhaps as low as 2? :-) )

---Jim

% (What do you want to bet that the number closely reading this thread
% is now well under 10, perhaps as low as 2? :-) )

Well, it's at least 2-1/2 (I'm reading it, but it's a little over my
head).  However, I find it extremely illuminating and it is exactly the
type of discussion that this newsgroup was created for.  Besides the
more of this thread I follow the more I understand.  

Jim, I highly appreciate your contributions to this newsgroup, it makes
the signal-to-noise ratio worth filtering!

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

I'm lurking, but I am reading. So make that at least 3 ;-)

Cheers,
Richard

: % (What do you want to bet that the number closely reading this thread
: % is now well under 10, perhaps as low as 2? :-) )

: Well, it's at least 2-1/2 (I'm reading it, but it's a little over my
: head).  However, I find it extremely illuminating and it is exactly the
: type of discussion that this newsgroup was created for.  Besides the
: more of this thread I follow the more I understand.  

: Jim, I highly appreciate your contributions to this newsgroup, it makes
: the signal-to-noise ratio worth filtering!

I second this sentiment!  This thread is far more interesting than the
constant whining about patches and which $250 video card will get you
another 2 FPS.  To me, details about the simulation engine are as
important to driving a sim as knowing about vehicle dynamics.

--
Scott Willingham / Hewlett-Packard Laboratories

--
Wolfgang Preiss       \ E-mail copies of replies to this posting are welcome.
wopr"at"stud.uni-sb.de \ There is no "2" in my real e-mail address.
Uni des Saarlands       \ Sorry for the inconvenience. You know why.

Regards from 'spinning Neil'.

--
Neil Charlton      

http://www.charlt.demon.co.uk/  
--

1. set fps at x, thus having to make a frame in 1/x seconds.
2. collect driver input, calculate car positions according to current
frame rate, hence where the car will be after 1/x seconds.
3. draw the frame.
4. measure time it took, y
5. if y larger than 1/x, lower the frame rate. If y less than 80% of
1/x, raise the frame rate, else keep it.
6. do the necessary changes on x

But as you say, the switching between threads shouldn't be to many
instructions, but to calculate the car position correctly, dont you have
to know exactly how long it takes to make a frame? The frame can not be
made until the car positions are known. I think here's a little problem
with the thread solution?

Say your in a middle of a race, racing your dear friend on the other
side of the globe, and you have a latency for 3 seconds (pings around
6000 ms :o) ). In real time when you're at the finish of the straight,
so is he, but your simulator of course just got a packet saying where
your friend was three seconds ago (it has a time stamp :o) ). What your
simulator does, is to anticipate your friends car position if he drives
as he usually does for those three seconds, and then draws that
anticipated car position, which is very close to where he actually is,
unless he has made a mistake. Your friends car in your simulation is
updated graphically as often as your own car, so he looks very fluid.
Say your simulator only gets your friends car position, once every third
second, then the time in between your simulator draws him as if he's
driving those three seconds as he use to or according to some AI version
of it. Suppose your friend screws up in an exit of a corner and when
your simulator gets the car position, it notices that the car mirroring
your friends car is too far, so it slows it down to better match your
friends actual position. I would love to race this way against my friend
Ian Lake from Australia. I'm from Sweden.

This way of allowing latencies upto three seconds demands some
synchronization at the beginning, but that's not complicated at all :o).
A simple solution is also to let the cars pass through each other. I
have been starting to think on ways to simulate overtaking in this mode.
Not quite there yet, but who am I to give up :o).

It would be detected in the resimulation of his fastest lap. When he
drove his fastest lap he had his low tyre wear or/and low fuel
consumption. This means that when I resimulate his lap on my simulator,
which has the correct tyre wear and fuel consumption, his car would not
survive the lap. At the end of the lap the driver inputs are for a car
with better tyres that weighs more, and this should really***up the
resimulated lap. An even better solution is that these values are saved
in the saved lap, and are easily viewed inside the simulator. Then if
they edited those values with an editor before sending it for
verification, the resimulation of the lap wouldn't produce the same time
as the time made in the race :o). The car might not even survive the lap.

Earlier today, I was going for only 2, but now it seems as if there are more
:o).

/Christer

This is *much* harder to do than it sounds; not impossible, but a hard
problem. Think about the "soft" parts of your scheme: "if he drives as
he usually does" or "according to some AI version of it."

It would get the positions more often than once every three
seconds. The positions it would get would just be 3 seconds late.

And this latency makes realistic collision detection and modelling
impossible. That's right, impossible, not challenging or difficult to
implement: impossible. For hotlapping with ghost cars driving around,
maybe that's OK and it's certainly more fun than racing by yourself.

No, it's just not a deterministic simulation, but that's not really
what I was getting at. There's nothing wrong with a stochastic
simulator...

What I was getting at is that the initial state vector has to be
complete, and all inputs to the system perfectly synchronized for even
a deterministic sim to be re-creatable. Chaos theory lurks at every
turn. :-) Even a fractional degree difference in an initial tire
temperature, or a millimeter difference in the position of an opponent
car in a draft will render the sim non-repeatable. Of course, given
enough work, you could do it, but it wouldn't buy you much because of
the following:

Maybe not. The smart user could sandbag, with a cheat that permits
lower tire wear. So, he drives along for half the race, turns off his
cheat mode, sets his personal FTD and is scott-free. (Because he
turned the cheat off before starting his fast lap, and thus when the
initial state vector was recorded for the fast lap, the effects of his
hack were all in the past and dutifully recorded in something that
won't be checked.) No matter what scheme you devise, someone will
break it if they are so motivated. Creating robot drivers for N2 isn't
trivial, but someone did it. Cryptography probably has part of the
answer here, but the best answer is to run on fixed hardware and
software or run against people you believe to be honest. Neither
condition is terribly hard to achieve.

Unless he's turned off his hack *during* the recorded lap. :-)

I hope it's as enjoyable for the rest of r.a.s. I'm certainly enjoying
it.

---Jim

First order non-constant step integration is trivial, but
not terribly accurate (at least with steps near graphics frame rate).
Integration accuracy may not be a major concern with
driver-in-the-loop or automatically controlled sims where the
integration errors act like dispersions that are corrected out anyway.
(If you are looking for "feel" rather than navigation grade accuracy,
etc.)

- Matt

My post to this seem to have been lost??? So I try again:

Hmm, thinking ... ... ... Say I drive a lap offline. This lap gets saved in a very
special way (for online ghost multiplayer racing purpose :o) ). The save file
contains a timestamp and car position for every frame in the lap, about 4000 posts
for a 2 minute lap. When I race someone online he gets my file and vice versa.
Then when my sim gets a packet from my opponent. It checks the packets time stamp
to figure out the lag, then looks up the car position in my opponents previously
saved lap, add the lag time to the timestamp of that post and then looks up the
saved laps car position in the new timestamp. Then draws the car.

Could work?

Of course, now when I think about it that's how it must work over internet, and it
explains the fluidness in F1RS.

I agree :o).

I believe encryption are much easier to crack than saving drivers input. I suppose
you agree that the driver cant cheat during the fast lap. Suppose he does a fast
lap when the cheat is on. The really fast guys are really consistent making
several of laps in a row within half a second. A better solution is probably to
demand saving all laps and then after each race randomly choose which laps to use
for verification.

He must have some luck here, so he turned it off on the lap he later gets
information to send in :o).

Me too, I'm always enjoying myself when I'm learning :o).

/Christer, and I'm sorry if you can see both my posts, I cant see my previous?

A car travelling at 300kph isn't going to vary its course much in the
space of 3 meters. :-)

Isn't GP2 with a variable frame rate more of a hack than a timer-based
physics model?

Some people apparently reverse engineered the packet format Papyrus
used and were able to have a program "drive" by just spoofing packets
to the server. While this is cool as a programming exercise, I'm not
sure where the fun in using this comes from...

So, then you engineer a cheat that works "between" laps, say adding
back half of the tire wear and 10% of the fuel you burned during that
last lap. So, each lap, taken as a unit is valid and verifiable, but
they don't add up to a valid race. So, then you simulate the whole
race, or sequence of laps or whatever. You quickly arrive at an
unworkable solution, as each race requires storing and sending many
megabytes of data across the wire to verify. Much easier to require
the users to download an executable with a cryptographic key embedded
in it just before the race.

Strong cryptography is very hard to break, particularly in limited
time. The whole computing and financial world depends on this being
true, and if it's proven to be not true, we all have bigger worries
than whether someone is cheating in a racing simulator. :-)

Relying on outsmarting the determined hacker and thinking of every
possible hole in advance is a futile effort. Your time is much better
spent locking things up with strong crypto; far easier to implement,
extensive security research has already been done for you, and the
more encyrpted bits flying around on the net, the more futile it is
for would-be hackers to lock onto the "interesting" ones.

---Jim

For once a noise free thread here in a long while (as long as
that "I'm lurking" cascade that's brewing up has been stopped in
its tracks :-) .

Not to digress from the topic of future sims, but ...

There is a simple hack idea for automatic frame-rate diddling
that can be back-hacked into GP2. This has been rattling around
in some empty corner of my brain for a while, but I dont think
I'll have the time to try it out. If any of you x86 hackers here
want to roll together code on a free evening to do this, I'll be
happy to chat.

The basic idea is to monitor GP2's frame rate, and when it
exceeds 100% by some threshold, you reduce the detail level on
the trackside objects till it the frame rate comes back up
again.

This is simple enough that it can be done in a small TSR to be
loaded before you run GP2.

The detail level can be diddled by stuffing a couple of ALT-D's
into the keyboard buffer.

Monitoring the frame rate may seem hard, but there's a real easy
way to do it. To test my theory, I connected an audio amp to the
joystick port, and got a steady 22 Hz buzz -- except when there
was a frame rate overload. The buzz then dropped in frequency.
This confirmed my suspicion that the idea should work. Here's
what you do -- poll the joystick port from the TSR. When GP2
begins another poll of the joystick, the bit changes. You count
the cycles, and that's the frame rate.

Now, implementation detail. Set a low-water mark, a time
accumulated under the low-water mark (which triggers a couple of
ALT-D's), a high water mark, and a time accumulated over the
high-water mark (which again triggers a couple of ALT-D's).

With this running, one should be able to get GP2 to
automatically drop some buildings on the start stretch and the
entrance to the tunnel in Monaco, for instance.

Anybody want's to play with the idea ?

(Of course, the sudden disappearance of buildings can be a bit
unsettling, but to me that's less unsettling than an unstable
car in a high speed turn -- YMMV :-)

-- //Shrikumar