rec.autos.simulators

1) The computer controlled cars twitch and erratically swerve on track.

2) The caller's car will periodically and instantaneously jump ahead or
behind 10-20 car lengths and then instantaneously jump back into normal
position.  This makes for hellacious wrecks if your jump lands you in or
on another car.

3) Problems 1 and 2 are much worse at certain tracks (ie: Bristol) and
rare at other tracks (Talledega).

PLEASE HELP (Rick, are you there?)!  We're using this modem
initialization string:  AT&F1-SSE=1&K0.  The -SSE=1 allows us to do
simultaneous voice and data, the &K0 turns off data compression.  Error
checking and correction are still on, if we disable error control (&M0)
we lose the ability for simultaneous voice and data but we still get the
problems listed above.  We've tried baud rates of 9600, 19200, 28800,
and 38400 with no change in the problems.

Desperate for a wreck free modem race...

Scott (and many thanks in advance!)
--
Scott M. Petty

Rick Genter
Technical Lead, IndyCar Racing II
Papyrus Design Group, Inc.

If either of you has TSR's which do power management or anything else which
might cause a timing glitch, you could see this sort of problem.  The only
time I've seen this is running under WIN-95 (rebooted to DOS exclusive
mode). (If you're running WIN-95, you'll need to be rebooted to DOS mode to
be able to run modem play at all).

I've seen NASCAR working fine with Intel DSVD modems, but don't have any
personal experience with the USR DSVD; it is possible that they have some
timing issues when doing simultaneous voice, though USR modems in general
have done exceptionally well with NASCAR.

You should get considerably better performance if both of you are running
with V1.21; we improved the physics extrapolation modeling in the 1.21
release.  I'd encourage you to give that another try; you might try it with
DSVD and error correction disabled, as you've mentioned you've tried in the
past.  Another possibility is to limit the connect rate of the modems to
19.2K baud or less; it is possible that you're seeing a modem retrain due
to a connection at an unsustainable rate, and if this is the case, you can
probably achieve a more stable connection at a slightly slower connect
rate.  I believe the USR commands to do this in the init string would be
"AT &N8" for a 14.4K baud connection, "AT &N6" for 9600.

Your observation that modem play at Tally is cleaner than at Bristol is
correct, but it sounds like what you're experiencing is a lot worse than
what you should be able to expect ...

Charlie Heath