Envious developers of racing sims :o)

I really hope I got your attention with that subject, cause to me you're truly envious. I would love to take part in the development of a racing sim, as a developer, that is :o). Well this aint a job application, but rather an attempt to influence the development of future racing sims. The subject is "How to make it almost impossible to cheat in a racing sim". GP2 was very close, but didn't reach all the way. What they did, was to resimulate saved laps. In order to do this they had to save all the driver's input, the car setup and all helps used in the replay file. This is the way to do it :o), but it's not enough to avoid cheating. Sooner of later there will be editors popping up on the internet, which can change for example tyre type, and it wont be noticable when resimulating the replay. My solution to this is to add a function to the racing sim where you can view all the data in a replay file; Car setup, BHP, grip, weight, tyre type, helps used, etc, etc. This would make it impossible to cheat with an editor, right :o)? For multiplayer races, allow at least the drivers fastest lap to be saved as a replay. Where GP2 also failed or didn't have the budget :o), is their choice of not saving timestamps for the driver inputs, instead they choosed to go with a constant frame rate. I believe much of the calculations in a racing sim is done with differential equations. I'm also guessing that when you choose a certain frame rate in GP2 the differential equations used is optimized for that frame rate. What I'm trying to explain is why GP2 allowed slow motion driving. Constant frame rate is perhaps a better solution for realism, as long as you stay below 100% processor occupancy, but why not do this instead? Add a byte to every driver input. Let that byte tell the simulator which frame rate is to be used for the next frame. Measure the time it took for that frame to be produced (GP2 already does this with it's processor occupancy function). If it took longer time than expected - lower the frame rate. If it took a shorter time than expected, say between 80% and 100% - keep the frame rate, but if it was lower than 80% of expected frame rate - increase the frame rate. With these two solution it would be impossible to cheat with an editor and very, very hard to cheat by driving in slow motion, right :o)? Ohh, and a "multiplayer with ghost cars" option, would also be nice :o), or am I pushing it now :o)? /Christer Andersson http://www.geocities.com/MotorCity/2922/ competition http://home4.swipnet.se/~w-41236/ - Home page with GP2 hotlaps and F1RS ghostlaps, setups included

Quoted text (45 lines)

> I really hope I got your attention with that subject, cause to me you're truly > envious. I would love to take part in the development of a racing sim, as a > developer, that is :o). Well this aint a job application, but rather an attempt > to influence the development of future racing sims. > The subject is "How to make it almost impossible to cheat in a racing sim". GP2 > was very close, but didn't reach all the way. What they did, was to resimulate > saved laps. In order to do this they had to save all the driver's input, the car > setup and all helps used in the replay file. This is the way to do it :o), but > it's not enough to avoid cheating. Sooner of later there will be editors popping > up on the internet, which can change for example tyre type, and it wont be > noticable when resimulating the replay. My solution to this is to add a function > to the racing sim where you can view all the data in a replay file; Car setup, > BHP, grip, weight, tyre type, helps used, etc, etc. This would make it > impossible to cheat with an editor, right :o)? > For multiplayer races, allow at least the drivers fastest lap to be saved as a > replay. > Where GP2 also failed or didn't have the budget :o), is their choice of not > saving timestamps for the driver inputs, instead they choosed to go with a > constant frame rate. I believe much of the calculations in a racing sim is done > with differential equations. I'm also guessing that when you choose a certain > frame rate in GP2 the differential equations used is optimized for that frame > rate. What I'm trying to explain is why GP2 allowed slow motion driving. > Constant frame rate is perhaps a better solution for realism, as long as you > stay below 100% processor occupancy, but why not do this instead? Add a byte to > every driver input. Let that byte tell the simulator which frame rate is to be > used for the next frame. Measure the time it took for that frame to be produced > (GP2 already does this with it's processor occupancy function). If it took > longer time than expected - lower the frame rate. If it took a shorter time than > expected, say between 80% and 100% - keep the frame rate, but if it was lower > than 80% of expected frame rate - increase the frame rate. > With these two solution it would be impossible to cheat with an editor and very, > very hard to cheat by driving in slow motion, right :o)? > Ohh, and a "multiplayer with ghost cars" option, would also be nice :o), or am I > pushing it now :o)? > /Christer Andersson > http://www.geocities.com/MotorCity/2922/ - Over a year old GP2 no help hotlap > competition > http://home4.swipnet.se/~w-41236/ - Home page with GP2 hotlaps and F1RS > ghostlaps, setups included

Well, all this sounds ok but I would prefer online racing with the game itself run from a dedicated server machine that only allows drivers to adjust their setups and, of course, drive :) -- We are the Hosh! You will be assimilated! Lower your defences and surrender! Your technological and biological distinctiveness will be added to our own. Your culture will be adapted to service us. Resistance is futile. Have a nice &*($ing day!

> Well, all this sounds ok but I would prefer online racing with the > game itself run from a dedicated server machine that only allows drivers > to adjust their setups and, of course, drive :) Assimilate this :o) The game itself, is that the simulation part? In that case the clients, our machines, gets the car positions from the dedicated server, and draws them in the 3D world, then sends back our driver input to the server. For 30 frames per second we would need pings below 33 ms??? Say the dedicated server would simulate 22 human cars. Say in a normal simulation, to produce one frame 1/3 of the time is used to simulate your car, 1/3 is used to do the AI and the last 1/3 is used to calculate and draw the graphics. Then you would need about a 22 * 1/3 * P200 as a server to get a P200 physics engine per human player, that is a Pentium 1400 MHz??? So if you mean that the simulation part should run on a dedicated server we need a Pentium 1400 and pings below 33 ms??? /Christer Andersson

Quoted text (11 lines)

> > Well, all this sounds ok but I would prefer online racing with the > > game itself run from a dedicated server machine that only allows drivers > > to adjust their setups and, of course, drive :) > Assimilate this :o) > The game itself, is that the simulation part? In that case the > clients, our machines, gets the car positions from the dedicated > server, and draws them in the 3D world, then sends back our driver > input to the server. For 30 frames per second we would need pings > below 33 ms???

It's actually not even that forgiving, since the physics and collision detection needs to be run at higher than 30Hz for good results with correctly modelled springs and dampers. You won't even see that level of performance (with respect to latency ("ping times")) on a lightly loaded Ethernet LAN. Also note that "ping times" reflect only the overhead of replying to an ICMP packet, which is done at a fairly low level in the IP stack, whereas car position updates from control inputs would almost certainly be a higher latency computational path. :-) ---Jim

> The game itself, is that the simulation part? In that case the clients, our machines, > gets the car positions from the dedicated server, and draws them in the 3D world, Online WWII air games (Air Warrior, WarBirds) have the advantage of years of experience at doing this. WarBirds (with which I am most familiar) keeps the local player apprised of the positions etc. of up to 32 other close planes quite well, while passing voice messages (assuming you have a microphone on your win95 of Mac system) all in less than 19200 kb. My WarBird connections tonight gave around 300ms ping time. Racing would seem to be a bit different, but any game will have to live within these limits. I'm sure someone will figure out how best to deal with this limitation ;) - Matt WarBirds: =para= WarBirds Training Staff

Quoted text (9 lines)

> > The game itself, is that the simulation part? In that case the clients, our machines, > > gets the car positions from the dedicated server, and draws them in the 3D world, > Online WWII air games (Air Warrior, WarBirds) have the advantage > of years of experience at doing this. WarBirds (with which I am > most familiar) keeps the local player apprised of the positions > etc. of up to 32 other close planes quite well, while passing > voice messages (assuming you have a microphone on your win95 > of Mac system) all in less than 19200 kb.

The obvious solution is to let each players computer simulate their own car, and only exchange car positions with the other players, instead of letting one server do it. This is how I do believe Air Warrior does it, and F1RS. Then pings around 400 ms will be playable. In racing the other drivers cars could be ghost cars, in the sense that you could drive through them without any damage at all. Then you could have pings well over 1000 ms and still have some fierce racing :o). /Christer Andersson

> It's actually not even that forgiving, since the physics and collision > detection needs to be run at higher than 30Hz for good results with > correctly modelled springs and dampers. You won't even see that level > of performance (with respect to latency ("ping times")) on a lightly > loaded Ethernet LAN. Here's one who seems to know what he's talking about :o). I'm guessing differential equations are used to model the car and therefore you would want as many iterations as possible per time unit. I've been doing some calculations on the saving of driver inputs in replay files and it seems as if GP2 saves the driver input once per frame. I guess the frequency for collecting the driver inputs should only be done once per frame, if I'm correcting in my assumption that the simulation of a frame is done in this order. 1. Collect driver input. 2. Calculate the new car position (here we need as many iterations in the differential equations as possible). 3. Calculate (only needed for AI cars) the other cars position. 4. Calculate and draw the frame. 5. Tell the 3Dfx card to show the frame :o). In step 3 and 4 we cant collect driver inputs, so there's really no meaning in collecting the driver input more than once per frame. I actually looked up ICMP :o). I guess with pings you can get a feel for which bandwidth you have between you and the other driver, since it's always 32 bytes sent back and forth in a ping. Say you have a ping of 300 ms, then it took 150 ms for 32 bytes, which gives us a bandwidth of about 7 * 250 bits per second, about 2kbit/s. I guess a 28.8 modem will do, with the current speed of internet :o). /Christer Andersson

Quoted text (9 lines)

> > It's actually not even that forgiving, since the physics and collision > > detection needs to be run at higher than 30Hz for good results with > > correctly modelled springs and dampers. You won't even see that level > > of performance (with respect to latency ("ping times")) on a lightly > > loaded Ethernet LAN. > Here's one who seems to know what he's talking about :o). I'm guessing > differential equations are used to model the car and therefore you would want as > many iterations as possible per time unit.

You need to integrate fast enough for the integration to be stable, and to provide the resolution in "feel" you want. (If you want to model running over a manhole cover for instance, the vehicle can't integrate all the way over the feature in one frame or you wouldn't even feel it.) You need to be fast enough to be much quicker than the frequencies of the dynamics (suspension, for instance) you are interested in modeling. A factor of 10 is a general rule of thumb. For landing gear in my day job, we integrate at 1000 Hz for real time sims, and would prefer 5000 ;) One problem that seems to hit both PC flying and racing sims is that the pilots/drivers can input in the 10 Hz range and cause problems by moving the controllers faster than the vehicles themselves can respond ;) (causing an oscillation) - Matt

> You need to be fast enough to be much quicker than > the frequencies of the dynamics (suspension, for instance) > you are interested in modeling. > A factor of 10 is a general rule of thumb. > For landing gear in my day job, we integrate at 1000 Hz > for real time sims, and would prefer 5000 ;) I'm guessing that you simulate landing gear to improve the construction of it. This is a much tougher goal than the PC simulators have, cause they only have to fool the human brain, and I guess we all know how easy it is to fool the human brain :o). I'm guessing a frequency of 300 Hz would be quite enough to fool a brain. I'm also guessing precalculated tables are used in PC simulators and values landing in between are interpolated. I dont either believe we have true 3D, but some kind of approximation, easy to calculate, but good enough to fool the brain :o). /Christer Andersson, dont know much, just guessing :o)

On Sat, 21 Feb 1998 14:13:02 +0100, Christer Andersson

Quoted text (7 lines)

>The obvious solution is to let each players computer simulate their own >car, and only exchange car positions with the other players, instead of >letting one server do it. This is how I do believe Air Warrior does it, >and F1RS. Then pings around 400 ms will be playable. In racing the other >drivers cars could be ghost cars, in the sense that you could drive >through them without any damage at all. Then you could have pings well >over 1000 ms and still have some fierce racing :o).

What kind of fierce racing could you have if you could just drive through the other cars? Everyone can use the best line and no need to worry about anyone else. That's a hotlap competition. Cheers! John

> Here's one who seems to know what he's talking about :o). Thanks. I *ought* to; otherwise someone wasted a lot of salary money on me... :-) You're stuck the the MicroProse mindset here. There's no reason that physics calculations and frame updates should be tied together. It's perfectly reasonable for the physics to be calculated on a constant timebase and the graphics engine just draws the results of the latest physics calculations to be completed at the time one begins to draw a new frame. This permits the physics rate to be done at a constant rate in wall-clock time, but a varying rate in frame-count time. A different (and I'd argue better) method is (very roughly): Physics thread: (timer driven) P1. Get control inputs P2. Calculate new player and AI car positions and collisions with each other and static objects. P3. Copy this snapshot and timestamp into a shared memory area. P4. Goto P1 Graphics thread: (running anytime the physics thread isn't) G1. Lock and copy the latest world snapshot (from step P3) to a scratch area in your thread space. G2. Draw the frame and display it. G3. Goto G1. Of course, I have an historical bias in preferring the multiple thread model. Unless it's not. The ping protocol supports varying size ping packets. (This is a source of numerous entries on the "50 ways to crash Win95 without knowing jack about computers" list.) Computing bandwidth in the absence of considering latency is not especially relevant for ***. Latency is the real limiting factor today. (After all, I could ship you a huge box of CD-Rs, at >660MB each every day. The bandwidth of this "connection" might be enormous, but it doesn't have low enough latency to support a racing game. :-) ) Additionally, even a single average latency number isn't everything. % packet loss and variability of latency on individual packets is meaningful. For the purposes of the originating (or, at least an earlier) post, it's not technically possible to get a good experience for the user by running the simulation engine on the server. (This would go a long way to preventing cheating, but it's technically infeasible.) ---Jim

This is (roughly) how it was done in the old Atari arcade games, Hard Drivin' and Race Drivin'. Since this was ~10 years ago, there was no cheap way to do it all with one processor, it was a multi-processor machine and there were separate processors calculating the car model (now called physics model), graphics, force feedback, sound, game play, etc... The various processors communicated through shared memory -- and all ran as fast as they could be clocked (reliably). Road & Track actually did an article that showed a crude block diagram of the system... From where (or when)? So true for something like driving simulation, where there is a (slow) human in the loop -- any significant lags not part of the real system may cause the whole thing to be unstable. -- Doug Milliken Research Associates Inc.

I agree in that a threaded version would be more beautiful :o), but I dont think it's the way to go as long as the client machines (Pentium, K6, M2) only have one processor. There is to much overhead switching between the threads instead of using that power to have a little better physics model, IMO. I guess your history is not in x86 processors, since you have a bias to multiple threads :o)? But you get the latency with pings, dont you :o)? If you get a ping of 300 ms, you know the latency is lower than 300 ms. If we take your example and you where pinging me with the help of CD-R's, then you would get them back a couple of days later. We're not talking milli seconds any longer, are we :o). Not if you send every packet with a time stamp, which really is needed if you want to allow 3000 ms pings. The timestamp could just be 2 bytes, which resets every time it reaches 65536 milli seconds. If the simulation are done on the clients and the multiplayer game saved the time of all the drivers fastest lap and you where forced to save your fastest lap, and the saving of the lap was in the format of driver inputs and simulation settings, and there was a function in the simulator where you could view the simulator settings for a saved lap. Then the lap can be resimulated on every client, producing the same lap time on every client and the data used for the simulation could be viewed on every client. Then the only way to cheat is to have another better driver to drive for you, am I right or am I right :o)? /Christer

Jim, Then why is Papy using this model for GPL? According to articles I've read. Jeff

> >For the purposes of the originating (or, at least an earlier) post, > >it's not technically possible to get a good experience for the user by > >running the simulation engine on the server. (This would go a long way > >to preventing cheating, but it's technically infeasible.) > Then why is Papy using this model for GPL? According to articles I've > read. They aren't. Each client machine will run its own physics model. --Jim

> I agree in that a threaded version would be more beautiful :o), but I > dont think it's the way to go as long as the client machines (Pentium, > K6, M2) only have one processor. There is to much overhead switching > between the threads instead of using that power to have a little better > physics model, IMO. You probably spend more time doing the variable number of incremental evaluations of the physics equations (assuming you are not willing to go into "slow-motion" mode) than you spend doing a thread switch. (Remember, it's not much more than slamming a stack pointer and saving a handful of registers on an x86. It was nice under DOS, when that was exactly what it was.) 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

>>(What do you want to bet that the number closely reading this thread >>is now well under 10, perhaps as low as 2? :-) ) >I'm lurking, but I am reading. So make that at least 3 ;-) 4. [Battle stations! We have a cascade alert! :) ] -- 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.

>>(What do you want to bet that the number closely reading this thread >>is now well under 10, perhaps as low as 2? :-) ) >I'm lurking, but I am reading. So make that at least 3 ;-) 4 now Regards from 'spinning Neil'. -- Neil Charlton http://www.charlt.demon.co.uk/ --

Quoted text (27 lines)

> > I agree in that a threaded version would be more beautiful :o), but I > > dont think it's the way to go as long as the client machines (Pentium, > > K6, M2) only have one processor. There is to much overhead switching > > between the threads instead of using that power to have a little better > > physics model, IMO. > You probably spend more time doing the variable number of incremental > evaluations of the physics equations (assuming you are not willing to > go into "slow-motion" mode) than you spend doing a thread > switch. (Remember, it's not much more than slamming a stack pointer > and saving a handful of registers on an x86. It was nice under DOS, > when that was exactly what it was.) > > I guess your history is not in x86 processors, since you have a bias > > to multiple threads :o)? > 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... :-)

I might have a solution to this. As you know in GP2 you can get the processor occupancy, so they measure the time it took for the latest frame to be made. My proposal to a solution is to switch fps during simulation according to following algoritm: 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). If you cant resimulate with the same input and get the same result, then it's not a simulation :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

> 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? Well, if you're getting 30fps, and have a 72Hz refresh rate, you can presume that your drawn frame will be off by 1/30th of a second plus 1/144th of second to wait for VBlank to page flip. Even without extrapolation, that's probably OK, but linear extrapolation would work for the 35ms or so that you'd have to extrapolate. If your framerate is horrendous, extrapolating from the calculated time to the "displayed" time is not your biggest worry. :-) 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

> I might have a solution to this. As you know in GP2 you can get the > processor occupancy, so they measure the time it took for the latest > frame to be made. My proposal to a solution is to switch fps during > simulation according to following algoritm: It's my impression (from not being able to find one easily after desultory looking, and headache from deriving one in the past ;) that higher than first order non-constant step integration schemes are somewhat hard to come up with. 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:

Quoted text (13 lines)

> > 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? > Well, if you're getting 30fps, and have a 72Hz refresh rate, you can > presume that your drawn frame will be off by 1/30th of a second plus > 1/144th of second to wait for VBlank to page flip. Even without > extrapolation, that's probably OK, but linear extrapolation would work > for the 35ms or so that you'd have to extrapolate. If your framerate > is horrendous, extrapolating from the calculated time to the > "displayed" time is not your biggest worry. :-)

I'm a bit sceptical to this 35 ms extrapolation. 35 ms is about three meters at 300 kph. Sorry for my english, but is horrendous very good or very bad. I'm guessing very bad, though :o). So far I prefer the GP2 method and I think it can be improved with variable fps, so the slow motion wont accur. 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). Geoff Crammond seems to have done it in GP2. A couple of drivers has tried submitting lap times made with a little to high BHP, and those could not be resimulated on any other machine. The saved lap file is cracked too, in the sense that it's common knowledge what it is saved. Tell me more about the robot driver, environment, racing mode, etc? 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?

Quoted text (9 lines)

> > Well, if you're getting 30fps, and have a 72Hz refresh rate, you can > > presume that your drawn frame will be off by 1/30th of a second plus > > 1/144th of second to wait for VBlank to page flip. Even without > > extrapolation, that's probably OK, but linear extrapolation would work > > for the 35ms or so that you'd have to extrapolate. If your framerate > > is horrendous, extrapolating from the calculated time to the > > "displayed" time is not your biggest worry. :-) > I'm a bit sceptical to this 35 ms extrapolation. 35 ms is about > three meters at 300 kph.

OK, so you use linear extrapolation to draw where the car *will be* (approximately) when the frame is displayed. There's not much error in this extrapolation, and GP2's method doesn't have any inherent advantage that I can see here... 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

> > 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... > As I suspected, but this is impossible if the driver inputs were to > be saved to verify a lap. To verify hot-lapping contests, this is still defeatable. I can drive a "near" hotlap, save it, and have a computer program attempt to optimize this lap. Right, but could you tell the difference between someone who's tires were 80% worn out versus 81% worn out at a pit stop? Remember, even subtle cheating is a problem, and subtle cheating is harder to detect than blatant cheating... At one level, you can encrypt a signature of the application, or the results file, or replay or whatever, and ensure that hasn't been modified since the application wrote it. (Unless you can discover the key used to encrypt it.) If you allow a hacker unlimited time, and unlimited software modifications to his own machine, he can probably beat you. If you limit his time (say, force a download of a new application or "enabler" within 2 hours of a race) and use cryptography, he has a harder time hacking the code in time to affect the race. ---Jim

> > Right, but could you tell the difference between someone who's tires > > were 80% worn out versus 81% worn out at a pit stop? Remember, even > > subtle cheating is a problem, and subtle cheating is harder to detect > > than blatant cheating... > Agreed, but subtle cheating is not at all as big of a problem as > blatant. That's your opinion. IMO, all cheating is evil, and in some ways subtle cheating is much worse. (If someone cheats and beat me by ten seconds a lap at Taladega, I can immediately know he's cheating. If he beats me by 2 tenths of a second, I don't know if he's cheating or just better than I am. That's far more insidious.) Same deal in real racing. No one builds a 500 cubic inch Winston Cup motor or a 45 gallon fuel tank because they'd be caught almost instantly, but someone might try to get away with a 360 cubic inch motor, or an extra fraction of a gallon in the fuel system. Having 2 extra cubes or 0.2 extra gallons is still an advantage that I want to *know* another team doesn't have before I pour my time into making my car competitive... And, you could have the best of both world with two people working together. One puts in the track time, the other build the cheating program. Together, they are faster than either one alone and it's still a problem. It's just another way to raise the bar. Just like all your on-line hotlapping idea does is to restrict the time the cheater has to cheat. Same with crypto; it just makes it less likely that the cheater will be able to effectively cheat within the time alloted. ---Jim

Quoted text (13 lines)

> > > Right, but could you tell the difference between someone who's tires > > > were 80% worn out versus 81% worn out at a pit stop? Remember, even > > > subtle cheating is a problem, and subtle cheating is harder to detect > > > than blatant cheating... > > Agreed, but subtle cheating is not at all as big of a problem as > > blatant. > That's your opinion. IMO, all cheating is evil, and in some ways > subtle cheating is much worse. (If someone cheats and beat me by ten > seconds a lap at Taladega, I can immediately know he's cheating. If he > beats me by 2 tenths of a second, I don't know if he's cheating or > just better than I am. That's far more insidious.)

Well, my opinion can easily change after having more experience of online racing :o). I came to think of this after I sent my post :o). Online hotlapping makes it also impossible to drive in slowmotion. I believe all racing simulators should be able to crack, so you offline can drive in slow motion, but this is impossible online :o). I really enjoy this thread, Jim, and I would like to thank you for being patient with me :o). I dont think I have much more to say on the subject for now, though, since we seem to have gone through the most of it :o), so then again - Thank you for a lovely little discussion :o)! /Christer Andersson, just another no helps sim racer :o)

One of the more famous NASCAR cheats was to route the fuel line all over the place, so the tank , which they measured, held exactly the right amount, but the fuel line held an extra gallon or so.... MM

Quoted text (59 lines)

> > > > Right, but could you tell the difference between someone who's tires > > > > were 80% worn out versus 81% worn out at a pit stop? Remember, even > > > > subtle cheating is a problem, and subtle cheating is harder to detect > > > > than blatant cheating... > > > Agreed, but subtle cheating is not at all as big of a problem as > > > blatant. > > That's your opinion. IMO, all cheating is evil, and in some ways > > subtle cheating is much worse. (If someone cheats and beat me by ten > > seconds a lap at Taladega, I can immediately know he's cheating. If he > > beats me by 2 tenths of a second, I don't know if he's cheating or > > just better than I am. That's far more insidious.) > Well, my opinion can easily change after having more experience of online racing > :o). > > Same deal in real racing. No one builds a 500 cubic inch Winston Cup > > motor or a 45 gallon fuel tank because they'd be caught almost > > instantly, but someone might try to get away with a 360 cubic inch > > motor, or an extra fraction of a gallon in the fuel system. Having 2 > > extra cubes or 0.2 extra gallons is still an advantage that I want to > > *know* another team doesn't have before I pour my time into making my > > car competitive... > > > I believe there is a level of cheating where if you spent the time > > > on the track instead of trying to find a cheat, you would have been > > > much faster than with the cheat :o). > > And, you could have the best of both world with two people working > > together. One puts in the track time, the other build the cheating > > program. Together, they are faster than either one alone and it's > > still a problem. > I came to think of this after I sent my post :o). > > > > If you > > > > limit his time (say, force a download of a new application or > > > > "enabler" within 2 hours of a race) and use cryptography, he has a > > > > harder time hacking the code in time to affect the race. > > > I dont think encryption is necessary with the saving of "simulator state and > > > driver input" method. > > It's just another way to raise the bar. Just like all your on-line > > hotlapping idea does is to restrict the time the cheater has to > > cheat. Same with crypto; it just makes it less likely that the cheater > > will be able to effectively cheat within the time alloted. > Online hotlapping makes it also impossible to drive in slowmotion. I believe all > racing simulators should be able to crack, so you offline can drive in slow > motion, but this is impossible online :o). > I really enjoy this thread, Jim, and I would like to thank you for being patient > with me :o). I dont think I have much more to say on the subject for now, though, > since we seem to have gone through the most of it :o), so then again - Thank you > for a lovely little discussion :o)! > /Christer Andersson, just another no helps sim racer :o)