rec.autos.simulators

    rotfl

    ***en 'ell, he's serious too. LOL.

    Now that I've stopped laughing (and thanks for the laugh btw), anyone
who asks a question, clearly without any research whatsoever (like popping
on over to - http://www.racesimcentral.net/), deserves no more than such a
link anyway. He got off lucky in fact.

    yeah.

Same response a lot of people come back with.  Swearing and then the stupid
LOL.  It's a wonder you didn't plop in,

<rolling eyes>

All in all, you're worth a killfile.

Alanb

asap too thanks!

-Larry

Well, I dabble in FPS tournaments occasionally and I've watched replays  
(or demos as they're known in the FPS world) of 30 players in an online  
server and you can follow any player pretty much perfectly.

Honestly, if GTL or rFactor don't have class leading (or at least 1999  
standard) multiplayer, I'll be quitting sim-racing for at least 5 years.  
These are the only games that have cars that I'm interested in.  LFS's  
cars & tracks bore me to death and N2003's (GTP etc) physics, FF etc just  
feels primitive after playing the ISI stuff (and RBR.)  At the moment, I'm  
enjoying the stunning RH2004 mod for F1C even more than the likes of GTR  
etc but the lack of decent multi is eating away slowly at my enthusiasm.

Sadly, I don't think ISI/Simbin etc realise that there's a lot more to  
decent multiplayer than just good netcode.  I strongly doubt that Ian Bell  
has ever even participated in an online league.

The physics seem good to me, but the cars & tracks are about as exciting  
as sliced bread and the graphics & sounds are woeful.

This is the basic way things work...

You have a whole bunch of clients who are trying to play the same
game-that is, everyone needs to know where everyone else is, what
they're doing, etc.  This is called the game state.  You designate a
server to be the one 'true' game, and each client sends info on what
they are doing to the server, and the server collates it and sends it
all back out to the clients.  As a client, you tell the server what
you're doing, the server tells you what everybody else is doing.

Except... the game state is *huge*, much bigger than even broadband
could possibly cope with as player numbers go up, so the server only
sends 'deltas', it only sends what changed since the last frame.  But
each packet might get lost en route, a series of packets might arrive
out of order, so the client has to somehow patch this all together to
get some kind of representation of what's going on.

Also, when you steer left, you don't send your new position/velocity to
the server, you send your control input, and the server does the
physics and stuff, then tells you where you end up.  This is because
you might have just steered into another car.  Lets say you're driving
alongside somebody else, there's a bit of a gap between you, and you
move towards them just as they move towards you.  You (your computer)
thinks there is no crash (because you steer immediately but you don't
see them move for a while due to lag), their computer thinks there is
no crash, but the server sees you *both* steer, decides you crashed and
then has to tell you both (and everybody else) that you just crashed.

Even stranger, because of lag, lets say everyone in the game has a ping
of 100ms to the server.  If you steer, the server only finds out about
it 100ms later.  If someone else steers, you only find out about it
200ms later.  1/5 of a second.  If you're on dialup and your ping is
500ms, you steer and it happens on your screen *half a second* later.
That's unplayable, so your computer doesn't wait for the server, it
does it immediately, assuming that the server will tell you the same
thing anyway.  Your computer also predicts what everybody else is up
to.  When you finally get an answer from the server, your computer
shifts everybody in the world into their proper place, which makes them
jump, or 'warp'.  Of course, they warp to the places they were at when
the server sent the packet, so 100ms ago...

Basically, no client ever sees what's really going on.  They are always
incorrect by some margin.  If you have a steady broadband connection to
a decent server in a game with good netcode and prediction, you might
not even notice anything except the occasional warp, but you're still
seeing into the past to a certain extent.

As for client replays, the positions of the cars comes from the server,
the client does no physics on them, it just puts them where it's told,
or predicts if it has no data.  Client replays are *always* incorrect.
Plus, good netcode will drop distant state info.  If the server is
sending out state for 40 cars, that's a lot of data (=bandwidth), so it
will drop cars which are further away, updating them less often, so the
client does more prediction.  It's less accurate, but you don't care.
Sometimes they might disappear completely.  The only replay which shows
what really happened to everybody is (by design) the server replay.

Why are flight sims better for replays?  Because if you're 10 miles
from someone and the server isn't giving you much info, or you have a
lot of lag, then you start to predict, your predictions start to go
wrong, but hey!  If they are 10 miles away and their position is 5
metres out of true, can you tell?  No.  If you're driving alongside
someone at 200mph and their position is 5 metres out, can you tell?
You betcha.

I know this is a bit epic, but I've had my head in this stuff for ages
and I'm only just figuring it out.  I'm making my netcode generic, but
I'm starting with a flight sim because it hides the errors ;-)  The
biggest problem I've had (thankfully 'solved' now) is, if you're
sending the difference on each frame, what happens if the last packet
didn't arrive?  How do you work out the new values if you never had the
old ones?!  You could just resend the lot, but that takes *ages*.  What
happens if you get packet 6 before packet 5?  Arrgh, it's a nightmare!
Thanks for letting me vent! :-)

By the way if anybody wants to know more (details, code), I'm happy to
help out.  The internet is great for WinSock tutorials, great to tell
you the problems for games, but thin on solutions...  all of my info
comes mainly from Quake, Quake 2 and Freespace 2 source code.

    An educated guess tells me that any netcode that starts out using
control input is stuffed. I would think it should start by having 6 pieces
of info, X times per secong. The 6 pieces of info are a 3D point + the
accompanying 3 angles of rotation about the 3 planes. I'd guess that's how
Papy code works. The only problem with Papy code is the crude use of linear
prediction which creates collisions that never actually happened such as
when an inside car warps up into an outsie car. Anyway, anything after these
6 bits of info is just nice - engine rpm and throttle opening/engine volume,
tyre squeal/smoke probably being next in the pecking order. Then maybe you
throw in front wheel turn, etc, etc. The server should be able to have the
option to enable/disable as much of the nice stuff as possible and also
control the freq that data is sent/recieved at. That way available bandwidth
can be used to either maximize field numbers and/or the quality of the multi

    I basically disagree with the gist of your post too ie that it's a
nightmare. Papy have had it pretty well sorted since GPL and even b4 that
with Hawai. Any company setting out to do things properly, with the right,
dedicated people, should have this sorted in no time. And it should be the
first thing to be sorted with emphasis on not only the racing, but the
results reporting after races.

Well, that's about all the net games ever made, then.  If you let
clients just send their positions, they can hack the game to speed up,
for example.  If you don't send the control inputs to the server for it
to verify movement, you've got one almighty cheat-filled game going on.
 Ideally, you would want to do as much as possible on the client, but
clients are easy to hack.  Look at Counter-Strike-the most common hacks
are aimbots, because the speed you can turn is not restricted, so they
just lock on to the nearest player, calculate the control inputs they
would need to do so and send them back to the server, so the server
can't tell anything bad is going on.  You never see teleport hacks or
jump hacks or speed hacks, because the server would notice and disallow
it.

There are a few good articles around, such as "The Internet Sucks: Or,
What I Learned Coding X-Wing vs. TIE Fighter" by Peter Lincroft on
Gamasutra.  Another good one is "Instant Replay : Building a Game
Engine with Reproducible Behavior" by Patrick***inson.  They dovetail
quite nicely.  You could also check out the Unreal Networking
Architecture at http://www.racesimcentral.net/(look at the
client prediction bit).  Or, just check out the source code to, say,
Quake, which is pretty much identical in operation to Quake 2, Quake 3,
Half-Life, Counter-Strike, and all the other games descended from
Quake.

Well, you need a velocity vector to even start predicting any kind of
movement, and if you wanted to add any kind of accuracy you'd need an
acceleration vector too.  Same for angular velocity and angular
acceleration.  So minimum 18 floats, which is 72 bytes per packet.
That, as you say, is without the 'nice' stuff.  Add on the IP header
(20 bytes) and UDP header (8 bytes), and it starts getting big.  Figure
100 bytes for this 'bare minimum' stuff.  If the server is running at
20fps (like Quake 2), and you have 40 cars, each client has to download
100 * 20 * 39 = 78,000 bytes every second from the server.  If you're
on 512kbps broadband, that's 512 kiloBITS per second, 64 kiloBYTES per
second.  So you physically CANNOT play the game, even on half-a-meg
broadband.  God help you if you're on dialup.  Remember, this wouldn't
result in lag, that's the delay between sending and receiving data,
this is beyond the physical limit of the amount of data you can receive
over a given timeslice.

LOL!  Papy have some of the best netcode around, and as you say, it's
been in development since, well, when was Hawaii?  We're talking 8
years minimum.  My netcode isn't even 8 weeks old!  It is a nightmare
trying to coordinate dozens of people across the world, each with
different pings, packets getting lost, arriving out of order, needing
to severely restrict what you send due to the reasons I've outlined
above, stopping cheating, etc.  It isn't a case of ISI netcode being
especially bad, it's Papy netcode being especially good.  Remember, ISI
weren't even allowed to do dedicated servers until recently, so they
don't exactly have 8+ years of experience here...

Andrew McP

As soon as a car goes around a corner, the velocity keeps changing, but
the acceleration remains pretty constant (towards the centre of the
corner), so if you only use velocities, then as soon as you lose data
in a corner, all the cars start going straight (imagine swirling a rock
on a piece of string around your head-losing a packet is like cutting
the string, the rock moves in a straight line with its last known
velocity, now that it has no acceleration acting on it to drag it round
the circle).

Cheers!

Remco

Andrew McP

Have no problem with the tracks and graphics but the sound is perhaps
the weakest part of the game but it doesn't detract hugely from what is
a very well done racing simulator with solid netcode.

The guys behind this deserve a lot of credit.

I haven't messed much with the multi demo, have they at least
implemented a better tire model if not better net, menu (argh, the demo
menus are worse than the old SCGT/F1x menus), and replay code?