Stunts Forum

Stunts - the Game => Car creation with Stressed => Topic started by: Duplode on December 09, 2008, 01:05:09 AM

Title: Physics investigations on Stunts
Post by: Duplode on December 09, 2008, 01:05:09 AM
I'm opening this thread as a spin-off from the "Dissecting" one, so we can post file dissections and gameplay experiments on Stunts physical model in a neat way. It could also be useful as a place for experimental CarBlaster questions. The first results I would like to announce are on a pretty basic but very relevant question that can finally be solved with good accuracy now that we have better insight on CarBlaster workings and the graphic files coordinates:

How long a track tile actually is?

The obvious experiment is to race a car through some distance at constant speed, measure how long does it take and calculate the length accordingly, the "constant speed" bit being the troublesome part: Due to truncation of digital speedometer readings to an integer value and to the nature of the rpm curve (defined in steps of 128rpm) it is very hard to be confident about keeping a constant and known speed value, even with tricks such as holding the gas steadily at redline or lowering aero drag to zero (so that the car rolls on forever at constant speed). Moreover, ideally one would prefer to run this test at very low speeds, so that times and positions can be measured with better precision; however, the speed truncation means the relative error of the speedometer is very high at low speeds (if you assume that a reading of 10mph could be anywhere between 10 and 11, that makes for 10% relative error...). Thus, I ended up doing the most obvious procedure, picking the Lada Niva and shooting it to 245mph in a 27-tile long straight, delimited by water terrain so I could check exactly where the tile boundaries were. The actual speed might be slightly higher than 245mph due to truncation, but at such high speeds the effect on the overall result of a 1mph difference would be rather small.

The results attained were as follows: the Lada took 15.4s to cross the 27 tiles at ~245mph (I was very lucky in that the measurement was unusually accurate, for the nose of the car had almost the same relative position to the start and finish lines when crossing them). Some math reveals that the straight was (assuming exact 245mph speed) 1.048 mile long, and thus each tile would have 0.03882 mile.

And now for the interesting stuff, during which I'll use imperial units so the numbers get prettier. Since one mile is exactly 5280 feet, that means one tile measures 204.95 feet, very close to an integer number... since we should expect a slightly higher speed than 245mph due to truncation, it is perfectly reasonable to admit the developers made it so that each tile has exactly 205 feet, or 62.484 meters. That, in turn, triggers a cascade of interesting implications:


Some nice little things I, and possibly others, were curious about were clarified with those tests. Hopefully the informations can also be useful when people start to design track/scenery elements to scale... ;)
Title: Re: Physics investigations on Stunts
Post by: CTG on December 09, 2008, 01:27:28 AM
You have too much time for thinking... :D

Few years ago I calculated the length of tiles to be able to tell the length of the lap (middle line). But those facts about gravity and sizes sounds really mad. :D
Title: Re: Physics investigations on Stunts
Post by: Duplode on December 09, 2008, 01:33:41 AM
In fact I had already tried to do those experiments several years ago (long before joining), but they were left incomplete due to lack of knowledge on the game internals. Now that the info was available, I felt compelled to finish them  :)

Few years ago I calculated the length of tiles to be able to tell the length of the lap (middle line).

You mean for the USC stats? I though you just used the time and the average speed data to calculate it...
Title: Re: Physics investigations on Stunts
Post by: Chulk on December 09, 2008, 01:41:35 AM
Few years ago I calculated the length of tiles to be able to tell the length of the lap (middle line).
Did you get the same results?

Really some interesting info, Dup. Nice findings!
Title: Re: Physics investigations on Stunts
Post by: CTG on December 09, 2008, 08:43:01 AM
Few years ago I calculated the length of tiles to be able to tell the length of the lap (middle line).

You mean for the USC stats? I though you just used the time and the average speed data to calculate it...

Not for USC stats because everybody uses a different line. I guess it was calculated for a YouTube video as an introduction part with the car&track data and pics (maybe Szeged track with Countach, since that not available).

Did you get the same results?

As far as I remember it was something like that, just testing with Knight Rider. ;)
Title: Re: Physics investigations on Stunts
Post by: Krys TOFF on December 09, 2008, 08:59:50 AM
Interesting, once again it's a part of stunts mystery that is shown public.

Quote from: Duplode
It is widely known that Stunts cars cannot go faster than 245mph due to game engine restrictions
Nope : max speed is 255mph, but you need lucky bugs to reach it.
Title: Re: Physics investigations on Stunts
Post by: zaqrack on December 09, 2008, 09:16:59 AM
really interesting, thank you!
Title: Re: Physics investigations on Stunts
Post by: dstien on December 09, 2008, 09:29:04 AM
  • And finally: have you ever had the impression that Stunts cars are a bit too large for the tracks they race on? Well, that's not just an impression anymore: Lancia, one of the shortest original cars, is 79 points long, which amounts to 15.8ft or 4.82m, surely much larger than the real car. Larger cars like the Corvette would be well over 6 meters... ::) The reason for those distortions is pretty clear: just like the very tall hills with strong gravity, the game designers have done so because it looks better at low resolutions. And nobody was supposed to notice anyway  :)
Aha. When I estimated the tile length to be 50 meters I assumed all the cars had real-life proportions.

  • The height of a ramp/hill/etc. is 450 points; using the 205/1024 conversion factor that would amount to 90.09ft, or 27.46m. One might wonder about what Stunts gravity would actually be like expressed into numbers then. Using the fact that a car, when not affected by any weird bugs, takes ~1.45s to drop from a hilltop to the ground, Stunts' gravity acceleration would be 26.1m/s^2, some 2.66 times the real-life value... counter-intuitive, isn't it? :)
Remember that shapes are modelled taller than they actually should be. In stressed's 3d view I multiply every Y value by 0.8. The reason for this--although it makes no sense--is probably that the game runs in 320x200 mode but would stretch to 640x480 on a IBM PC. (640 / 480) / (320 / 200) ~= 0.83. I don't think DOSBox stretches the image...
Title: Re: Physics investigations on Stunts
Post by: BonzaiJoe on December 09, 2008, 12:53:56 PM
Interesting, once again it's a part of stunts mystery that is shown public.

Quote from: Duplode
It is widely known that Stunts cars cannot go faster than 245mph due to game engine restrictions
Nope : max speed is 255mph, but you need lucky bugs to reach it.

I'm not sure the car actually goes that fast, it just says so in the evaluation...

I've had it say something like 340mph once, and believe me I wasn't going that fast :)

Really nice facts, Duplode!
Title: Re: Physics investigations on Stunts
Post by: Chulk on December 10, 2008, 01:02:17 AM
Interesting, once again it's a part of stunts mystery that is shown public.

Quote from: Duplode
It is widely known that Stunts cars cannot go faster than 245mph due to game engine restrictions
Nope : max speed is 255mph, but you need lucky bugs to reach it.

I'm not sure the car actually goes that fast, it just says so in the evaluation...

I've had it say something like 340mph once, and believe me I wasn't going that fast :)
I had a replay around 400 once too, after a crash in PG. I think the car doesn't go that fast, just the evaluation page gets confused.
Title: Re: Physics investigations on Stunts
Post by: Duplode on December 10, 2008, 04:35:24 AM
Nope : max speed is 255mph, but you need lucky bugs to reach it.

I'm not sure the car actually goes that fast, it just says so in the evaluation...

I've had it say something like 340mph once, and believe me I wasn't going that fast :)
I had a replay around 400 once too, after a crash in PG. I think the car doesn't go that fast, just the evaluation page gets confused.

I think so as well - 245mph is the limit for sustainable speed - but still it is something to wonder about how the game can possibly get confused with speed readings. Maybe on some  extreme crashes the forces acting on the car are intense enough that the 245mph cap actually gets broken, if only just for a frame...

BTW, just an useful observation on tile lengths. As mentioned, a tile is 205ft long. While giving the value in feet makes sense from a stressed user perspective, track designers may find another approximation more relevant: 205ft = 62.484m. Considering 62.5 = 1000/16, we can say that for all practical purposes 16 tiles = 1 kilometer...
Title: Re: Physics investigations on Stunts
Post by: Krys TOFF on December 10, 2008, 09:47:01 AM
Quote from: Duplode
BTW, just an useful observation on tile lengths. As mentioned, a tile is 205ft long. While giving the value in feet makes sense from a stressed user perspective, track designers may find another approximation more relevant: 205ft = 62.484m. Considering 62.5 = 1000/16, we can say that for all practical purposes 16 tiles = 1 kilometer...
Much more practical indeed, km means much more to me than feet. ;)
Title: Re: Physics investigations on Stunts
Post by: CTG on December 10, 2008, 10:59:58 AM
Quote from: Duplode
BTW, just an useful observation on tile lengths. As mentioned, a tile is 205ft long. While giving the value in feet makes sense from a stressed user perspective, track designers may find another approximation more relevant: 205ft = 62.484m. Considering 62.5 = 1000/16, we can say that for all practical purposes 16 tiles = 1 kilometer...
Much more practical indeed, km means much more to me than feet. ;)

The only thing I liked better in FM Towers version of Stunts (watching at YouTube): speedometer with kmh units. So the top speed of Indy is 394 kmh - a lot more than F1 cars in 1990-91.
Title: Re: Physics investigations on Stunts
Post by: Krys TOFF on December 10, 2008, 03:05:42 PM
FM Towns, not FM Towers. :D ;D
But there's no PG in FM Towns version...
Title: Re: Physics investigations on Stunts
Post by: CTG on December 10, 2008, 03:10:54 PM
FM Towns, not FM Towers. :D ;D

Sorry, I was still sleepy. :D (yes, at 10:59 ;D)
Title: Re: Physics investigations on Stunts
Post by: Chulk on December 10, 2008, 04:30:06 PM
Quote from: Duplode
BTW, just an useful observation on tile lengths. As mentioned, a tile is 205ft long. While giving the value in feet makes sense from a stressed user perspective, track designers may find another approximation more relevant: 205ft = 62.484m. Considering 62.5 = 1000/16, we can say that for all practical purposes 16 tiles = 1 kilometer...
Much more practical indeed, km means much more to me than feet. ;)
To most of us (just to avoid saying "to all of us")
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on February 17, 2009, 10:56:53 PM
Quote from: Duplode
BTW, just an useful observation on tile lengths. As mentioned, a tile is 205ft long. While giving the value in feet makes sense from a stressed user perspective, track designers may find another approximation more relevant: 205ft = 62.484m. Considering 62.5 = 1000/16, we can say that for all practical purposes 16 tiles = 1 kilometer...
Much more practical indeed, km means much more to me than feet. ;)
To most of us (just to avoid saying "to all of us")
On the other hand, stunts expresses speeds in miles/h...

P.S. When you were dropping from a hill, how fast where you going? I expect downforce is quite strong in stunts. :)
Title: Re: Physics investigations on Stunts
Post by: Duplode on February 18, 2009, 12:19:25 AM
On the other hand, stunts expresses speeds in miles/h...

Pertinent remark, and also graphic coordinates are in units of 0.2 feet - thus Stunts hackers are recommended to adapt to Imperial units...

P.S. When you were dropping from a hill, how fast where you going? I expect downforce is quite strong in stunts. :)

It was Countach on Default, so it must have been ~120mph. As far as I remember, though, the results were (barring the usual random bugs) independent of speed. I don't believe there is real downforce in Stunts, just some unreliable aerodynamic drag that sometimes disappears and gives way to Power Gear  :)
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on February 18, 2009, 12:44:42 AM
On the other hand, stunts expresses speeds in miles/h...

Pertinent remark, and also graphic coordinates are in units of 0.2 feet - thus Stunts hackers are recommended to adapt to Imperial units...

P.S. When you were dropping from a hill, how fast where you going? I expect downforce is quite strong in stunts. :)

It was Countach on Default, so it must have been ~120mph. As far as I remember, though, the results were (barring the usual random bugs) independent of speed. I don't believe there is real downforce in Stunts, just some unreliable aerodynamic drag that sometimes disappears and gives way to Power Gear  :)

In that case there is either a strong centrifugal force or reverse gravity in loops and tubes... :)
Title: Re: Physics investigations on Stunts
Post by: Duplode on February 18, 2009, 03:15:03 AM
That's an interesting point: there must be a model for centripetal force for such situations. Worth investigating...
Title: Re: Physics investigations on Stunts
Post by: Friker on February 18, 2009, 10:38:56 AM
i think there is a normal vector of a road while youre stick to the road and a normal vector of 'the Earth' while youre flying (high :) ).
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on February 18, 2009, 11:05:42 AM
i think there is a normal vector of a road while youre stick to the road and a normal vector of 'the Earth' while youre flying (high :) ).
Something like that, it would explain why you can drive slow and straight upside down in a tube...
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 11, 2009, 08:01:51 PM
After several months of very slow progress, it seems I finally managed to understand partly (about 40%) how the physical model of track elements is stored. Details to follow later...
Title: Re: Physics investigations on Stunts
Post by: dstien on April 12, 2009, 02:07:21 PM
Details to follow later...
Whoa, what a cliffhanger! I'm waiting in suspense. :o
Title: Re: Physics investigations on Stunts
Post by: Friker on April 12, 2009, 02:45:23 PM
Details to follow later...
Whoa, what a cliffhanger! I'm waiting in suspense. :o

im glad to see results from his investigation too :)

Duplode: give us the knowledge :)
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 13, 2009, 07:18:25 PM
Okay, here we go. First of all I must say "40% of understanding" was an over-estimation by far (as you'll see by the loads of mysterious stuff I can't explain), but hopefully what little was found will be worth the suspense already ( :)/ :D).

The new findings are about stuff contained in GAME.PRE (unpacked to GAME.RES, of course). Alongside with some other random pieces of data (crack patterns for the windshield in F1 view and many familiar in-game messages) there is a very large heap of bytes split between two resources with the rather suggestive names of plan and wall. Now, jumping to the first of the final conclusions (I won't follow chronological order in the explanation or else this will get twice as long as it'll get), we can say Stunts employs two different kinds of surfaces for building track elements:


The game then uses the definitions of surfaces and walls in GAME.RES to assemble the track elements, joining them in specific positions according to rules defined *somewhere else*.  Now, on to the nature of the resources themselves, starting with plan...

---

plan is composed of 536 structures of 34 bytes each. Each of these defines a plane in space (thus the name of the resource) which corresponds to one or more drivable surfaces in game. The structures can be described as (in this context WORD = 2-byte signed integer, as usual):

Code: [Select]
struct PLANE {
    WORD angleYZ;
    WORD angleXY;
    VECTOR origin;
    VECTOR normal;
    VECTOR[3] rotationMatrix;
};

struct VECTOR {
    WORD x;
    WORD y;
    WORD z;
};

The 'origin' vector is just a regular point coordinate that sets a point belonging to the plane. Usually the origins match vertexes employed on the actual track elements which employ the planes, thus allowing for relatively easy matching between planes and polygons in GAME1.3SH and GAME2.3SH (which contain the track elements 3D shapes). The 'normal' vector is a normal vector to the plane (good guess, Friker and Overdrijf!  ;)), whose length is 8192 (0x2000). A point and a normal through it are enough to define a plane unambiguously, thus 'origin' and 'normal' give full control over the plane attributes - by displacing the origin you can set the height and (to some extent) the position of the plane in the tile, while the normal sets the plane inclination in xy (banked road inclinations, etc.) and yz (ramp slopes, etc.) planes.

After the normal there is a set of three vectors whose length is 16384 (0x4000). Looked as a whole, they look very much like a 3D rotation matrix (http://en.wikipedia.org/wiki/Rotation_matrix) arranged by columns, though I'm not fully sure if they act strictly like one. Their role is to set the orientation of the car after it makes contact with the surface. The correct values should of course get the car lying on the plane of the surface. The values aren't hard to figure out once you know what the normal is. An interesting observation is to note this way of modelling the landing on a surface is very simple and quite unphysical (no forces, no torques, just a forced change of orientation) and may well be the source of several bugs we're so familiar with (think of this scenario: you are about to land from a jump, and the game is supposed to reorientate the car so it is parallel to the ground. Just as you land, however, the accumulation of rounding errors over the past few seconds makes engine think it still has to reorientate the car, even if it is horizontal already. Then the game over-corrects rotating the car further upwards, and *bam* - magic carpet! :) In fact, it is probably possible to make a bouncing track by messing up with the matrix in a consistent way).

Finally, there are the angles in xy and yz planes, which convey much of the same information given by the normal in a different format. These angles are given in fractions of 1/1024 of a circle, thus ranging from 0 to 1023. The thing is, modifying the angles has no visible effect over the surfaces, so I have no clue on what they're doing there (unless these angles interact with stuff contained in the other resource, 'wall', but that's another story).

---

Now, let's return to the macro-organization of 'plan'. After understanding the structure of the planes it becomes obvious that the 536 planes are arranged in blocks of four, planes within each block differing only in xz orientation (like ramps facing different directions). This reduces the actual number of surfaces to identify to 536/4 = 134. For instance, here is the set of ramp/slope surfaces...

Code: [Select]
0000516: 0000 4300 7800 0000 00fe 0000 4b1d 21f3 0040 0000 0000 0000 ab3a 6de6 0000 9319 ab3a
0000538: 4300 0000 0002 0000 7800 df0c 4b1d 0000 ab3a 6de6 0000 9319 ab3a 0000 0000 0000 0040 
000055a: 0000 bd03 88ff 0000 0002 0000 4b1d df0c 0040 0000 0000 0000 ab3a 9319 0000 6de6 ab3a
000057c: bd03 0000 00fe 0000 88ff 21f3 4b1d 0000 ab3a 9319 0000 6de6 ab3a 0000 0000 0000 0040 

and the values "translated" to decimal.

Code: [Select]
0 67 120 0 -512 0 7499 -3295 16384 0 0 0 15019 -6547 0 6547 15019
67 0 512 0 120 3295 7499 0 15019 -6547 0 6547 15019 0 0 0 16384
0 957 -120 0 512 0 7499 3295 16384 0 0 0 15019 6547 0 -6547 15019
957 0 -512 0 -120 -3295 7499 0 15019 6547 0 -6547 15019 0 0 0 16384

As you can see, axes permutations and sign inversions are the only changes involved. The order on each quartet is predictable: the first one is in S->N orientation (pointing to +z) and the others correspond to counter-clockwise rotations (for pieces of bridge corners and banked roads, the first plane of the quartet is from the corner going S->W, the second one E->S and so on).

By crossing data from GAME.RES and GAME1/2.3SH plus some in-game tests I could identify almost all of the quartets (only for 12 of them I have no clue). It was not a massive amount of work to do, as complex surfaces like corks u/d take a very large number of quartets and are easily recognizable. The identifications (as well as human-readable transcripts of both 'plan' and 'wall') are included in the .xls file attached.

One important point to stress before moving on: nowhere in plan there is any indication of how the surfaces are to be assembled. In fact, many of the surfaces are reused in several elements. For instance all ramps AND hill slopes share the same properties, so do all sorts of flat terrain both on and off hills. More remarkably, the surface of pipes and cork l/r use the exact same planes - the only difference is the walls of corks are shorter in the z direction and aligned properly so the final result looks looks like a spiral, and not like a tube. The differences between hill slopes and ramps, or corks l/r and pipes - namely, where each part of the surface starts and ends - are not in GAME.RES, so we're only looking at half the story here. Hopefully this data is not packed somewhere too hard to reach (the executables...), as we will need to find it in order to make more radical mods to the track elements.

---

Enough speaking of 'plan' already, let us move to 'wall'. 'wall' left me bewildered for the longest time, as I tried to find some correlation between the values there and 'plan', or GAME1/2. Anyway, here is how the vertical walls in game appear to be described:

Code: [Select]
struct WALL {
    WORD angleXZ;
    WORD x;
    WORD z;
};

'wall' has 3-integer structures which when combined describe of the xz projection of the wall path (that is, the wall path viewed from above). Each pair of 'x' and 'z' forms an endpoint for the wall segments, and angleXZ is the angle of said segment. Plotting 'x' and 'z' values reveal clearly most of the obstacle structures we know - block houses, bridge corner walls, slalom blocks... (I included some graphs in the .xls file which illustrate this point neatly). This looks clear enough, but there are a few unresolved issues with the description. First of all, trying to make simple changes to wall positions (like displacing slalom blocks from their positions) didn't work, at least for me - all changes to 'x' and 'z' ended up making the wall penetrable or otherwise buggy seemingly without changing the position as intended. Maybe the angles need to be adjusted properly prior to the adjustment to some specific value, or there is some additional info we're not aware of (the obvious possibility of having the physical walls linked to the graphical data in GAME1/2 is ruled out by a few simple tests, however). Furthermore, there is no obvious connection between 'wall' and 'plan' in terms of indices or list positions, so the resources must be called independently by a third entity in order to compose the objects. And the final issue, which I find the most annoying, is that there is no information at all about wall height, and yet we know a block house is much taller than a slalom block (and no, neither of them has a 'plan' surface associated to them). Thus, the 'wall' definitions are less complete than 'plan' ones, to the point of being confusing...

---

In conclusion, with these findings we elucidated quite a bit more of Stunts' data, but there is obviously a big piece of information still missing to complete the puzzle. As of now, we can make minor-to-moderate scale changes to elements, such as modifying bankings, slopes and heights of surfaces, but we cannot reassemble the planes which make an element at will, nor create new elements instead of overwriting them and not even decoupling the elements which share 'plan' surfaces (for instance, all changes made to one kind of ramp will be reflected on all ramps and on hill slopes too). I'm particularly interested in trying to reflect corks l/r and loops through the yz plane (thus changing their handedness), but I'm not very confident that will be possible.

Anyway, it's a beginning  :)
Title: Re: Physics investigations on Stunts
Post by: Friker on April 13, 2009, 07:47:26 PM
this... ... is ... ...great...
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 13, 2009, 10:53:53 PM
Wow.
Title: Re: Physics investigations on Stunts
Post by: zaqrack on April 14, 2009, 07:52:35 PM
 :o awesome work again...
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 23, 2009, 06:40:21 PM
Since further extensive testing of track surfaces will mean a hell lot of work, I have for the moment opted to resume testing of the unknown CAR*.RES / CarBlaster parameters instead. More specifically, I have been following a good hint left by Overdrijf (http://forum.stunts.hu/index.php?topic=2235.msg41175#msg41175) about possible size-related parameters on the not-understood region of the file (between the torque curve and the steering wheel dot coordinates). I will present some of the results without the technical details on how to do it (that will go straight to the Wiki as soon as I get to write it down). First of all, it turned out that there are not one, but *two* sets of car size data there! The first one is a trio of values that loosely match the 3D shape dimensions (as half-length, half-width and height). For some reason (code efficiency, I guess), however, this set is only used for car-car collision detection, and not with regular trackside objects, and thus it is not so useful - but it can be used for something very cool...

(http://i49.photobucket.com/albums/f283/Duplode/load_016-1.png)

...Trackmania-stlye racing vs. ghost cars. Too bad Skid is not smart enough to realize this and will keep swerving to avoid your car even if he can drive straight through it... this also explains why you can't crash at the scenario cars you can put with TrackBlaster - they have neither collision parameters nor a 'wall' definition in GAME.RES .

As mentioned, though, there is another dimension-related set of bytes, namely the 24 bytes just before the steering wheel coordinates. Each 6-byte sequence in it (two integers separated by 0000h) is a xz (width-length) coordinate set for one of the corners of the car, starting from front/left and then going clockwise. Although in principle you can position the corners to form any sort of four-sided polygon, in practice the polygon must be centred at zero x and zero z - failure to do so will introduce exotic bugs such as making the car move forward, backward, sideways, etc. on its own... By the way, the effect Overdrijf noticed after changing one of the parameters (the car rotates mid-air and lands on two wheels) is not a bug of this sort, but rather a reflection of the fact that one side of the car became longer than the other, so it tends to rotate as it leaves the ground.  In any case, if you plan to make reasonable cars you'll be most likely bound to make rectangles symmetric about the origin (or trapezes at the very most if you want the front to be narrower than the rear or something).

The question that arises by now is whether collision tests confirm such explanations. Such tests are rather elusive because (as you probably know by now) Stunts' collision model is not the most reliable or precise piece of code around, and sometimes it just doesn't do what it should. Anyway, by making symmetrical changes to the corners' positions, it was possible to make cars which were wider...

(http://i49.photobucket.com/albums/f283/Duplode/load_014.png)

longer...

(http://i49.photobucket.com/albums/f283/Duplode/load_015.png)

and shorter than the defaults.

(http://i49.photobucket.com/albums/f283/Duplode/load_018-1.png)

(narrowing the car a lot is difficult to achieve, it seems that there is a hard-coded lower limit to the width of the car)

A more dramatic demonstration of the coordinates in action is below:

(http://i49.photobucket.com/albums/f283/Duplode/load_013-1.png)

The car appears to be floating above the water, but in fact it is not - as it was made a couple times wider than the 3D shape, its right side wheels are still safely on the grass.

That is not the most interesting part of the story, however! During the tests it became obvious that the car length, as defined by the corner positions, influences the behaviour of the car. Shorter cars are more responsive to direction changes than longer cars, which has a number of important consequences:
Now, please have a look at the list of the positive z coordinates (that correspond to half-lengths) for a number of common cars (CDOR is Melange, the other abbreviations are more clear):

Code: [Select]
ANSX 1856
AUDI 1472
CDOR 1856
COUN 1984
FGTO 1984
GATE 1920
JAGU 1920
LANC 1472
LM02 1856
NSKY 1984
P962 1920
PC04 1792
PMIN 1984
RANG 1856
VETT 1984
ZGT3 1984

Notice how Audi and Lancia are indeed dramatically shorter than other cars. That finally provides a convincing explanation for their delightful handling, as well as their notorious bug-proneness. Maybe even more striking is to see that Melange, through inheriting the parameters from the LM-002, became shorter than the rest of the IMSA cars - and that may justify its magic carpet potential... :)
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 23, 2009, 08:21:03 PM
Cool, you really found it!

So the halflength-value for a car should be about 2x the halflength in the car0 3D model, and therefor arround 40x as large as the halflength in car1.

Lol. I tried playing around with those 24 bites a bit, trying to keep the original symmetry and just making the values lower. The car started flying, completely out of itself. It crashed on the roof of the world, I didn't even know something like that existed. Now this was with my already screwed up car, but I haven't seen it do this before...
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 23, 2009, 10:00:13 PM
So the halflength-value for a car should be about 2x the halflength in the car0 3D model, and therefor arround 40x as large as the halflength in car1.

Now that you mentioned it, I compared shapes for different cars with the half-lengths and half-widths, and the results are not very conclusive. If you look at the length/width proportions for Lancia, for instance, it appears the length is actually the front-wheel-to-wheel distance instead of the full length (and indeed - if you throw it against a slalom block it will only crash when the front wheels reach the block). For other cars, however, that does not hold - often the half-length is intermediate between the full length and the wheel-to-wheel distance. So the best practice is probably to set an intermediate value between the two and then fine tune according to your aesthetic preferences as well as handling effects. Anyway, if you assume Lancia's half-length is half of its wheel-to-wheel distance, the conversion factor would be exactly 64. Since this is a ridiculously convenient number, I guess it is exact... the conversion factor is actually 184/7 32, I messed up the divisions  :)

Lol. I tried playing around with those 24 bites a bit, trying to keep the original symmetry and just making the values lower. The car started flying, completely out of itself. It crashed on the roof of the world, I didn't even know something like that existed. Now this was with my already screwed up car, but I haven't seen it do this before...

1. Roof of the world!!  :o Please attach the test *.RES you were using so we can load the replay, it's a must see!  :o

2. Oops, I glossed over a proper explanation of what "symmetric" means in this context, I will add it to this post in a short while... no, better, I'll just reply again.
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 23, 2009, 10:09:03 PM
So the halflength-value for a car should be about 2x the halflength in the car0 3D model, and therefor arround 40x as large as the halflength in car1.

Now that you mentioned it, I compared shapes for different cars with the half-lengths and half-widths, and the results are not very conclusive. If you look at the length/width proportions for Lancia, for instance, it appears the length is actually the front-wheel-to-wheel distance instead of the full length (and indeed - if you throw it against a slalom block it will only crash when the front wheels reach the block). For other cars, however, that does not hold - often the half-length is intermediate between the full length and the wheel-to-wheel distance. So the best practice is probably to set an intermediate value between the two and then fine tune according to your aesthetic preferences as well as handling effects. Anyway, if you assume Lancia's half-length is half of its wheel-to-wheel distance, the conversion factor would be exactly 64. Since this is a ridiculously convenient number, I guess it is exact...

Lol. I tried playing around with those 24 bites a bit, trying to keep the original symmetry and just making the values lower. The car started flying, completely out of itself. It crashed on the roof of the world, I didn't even know something like that existed. Now this was with my already screwed up car, but I haven't seen it do this before...

1. Roof of the world!!  :o Please attach the test *.RES you were using so we can load the replay, it's a must see!  :o

2. Oops, I glossed over a proper explanation of what "symmetric" means in this context, I will add it to this post in a short while...

Here it is. And it's more symmetric, even in this context, then my only slightly corkscrewing car.
I might have met the fence, but that usually doesn't crash a car, so I think it was the roof...
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 23, 2009, 10:49:23 PM
Here is the proper explanation about "symmetry". The first thing you should do is to make CarBlaster display byte values in hexadecimal (press Shift+H), it makes everything much more convenient. Now, if you go to the 24-byte section of (random example) Acura, you'll see the relevant values are arranged as pairs of bytes. The first of these, the x coordinate for the front/left corner, has values 40 and FC (in hex, which I'll indicate by appending them with 'h'). The pair, however, is supposed to be read as a single number; and to do so you invert the order of the bytes. Thus, 40 and FC become FC40h =  64576 after converting to decimal. This is the first subtlety. Of course, 64576 is a ridiculously high value - and then comes the second subtlety: very large values (above 8000h) are in fact negative numbers stored in a convenient way. To recover the original number, subtract the value you got from CarBlaster from 10000h and invert the sign. In our case, 10000h - FC40h = 3C0h --> -3C0h = -960, which is the value we expected to find. Now, if you jump six bytes forward, you'll see the values for the x coordinate of the second (front/right) corner are C0h and 03h, thus the coordinate value is +3C0h = +960 - symmetrical to the front/left coordinate, as it should. Applying the same principle everywhere, once you settle for values of half-length and half-width for a sane rectangular car, the pairs of bytes should be set like this...

Code: [Select]
1st (front/left) 2nd (front/right) 3rd (rear/right) 4th (front/right)
x-coordinate -halfwidth +halfwidth +halfwidth -halfwidth
z-coordinate +halflength +halflength -halflenght -halflength

...with the negative values being stored as (10000h - (your absolute value in hex)). If you are just messing around with values/doing quick tests, the easiest way to keep track of the changes is to, every time you add to a x-coordinate byte, add the same amount to all other corresponding x bytes (that is, the ones 6, 12 and/or 18 bytes before or after) with the same sign and subtract the same amount from the ones with opposite sign, and vice-versa for subtraction, and the same goes for the z coordinates.

---

And about your replay: zOMG  :o :o It seems your car did reach the outer space, and when it happened the world flipped over and you hit the ground - from below  :o And what's more, I had seen crazy stuff while testing the parameters but levitation from a standstill is a new one for me too - it's a must check...
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 23, 2009, 10:54:59 PM
Well, it did already have a minimum speed. But why it went upwards...
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 23, 2009, 11:18:32 PM
For one of the most spectacular screenshots you'll ever see: get the CARSUKA.RES above into Stunts (for the non-Overdrijf folks reading this, just fit it with graphics from some other car), pick it, press Enter in the main menu to go racing and, immediately afterwards (while it's still showing "Please Wait")  start holding the up and left arrows. You won't regret spending two minutes with this...
Title: Re: Physics investigations on Stunts
Post by: zaqrack on April 24, 2009, 08:37:40 AM
wow  ;D ;D ;D a Stunts rocket. like the window braking graphics too :)
Title: Re: Physics investigations on Stunts
Post by: CTG on April 24, 2009, 09:48:19 AM
wow  ;D ;D ;D a Stunts rocket. like the window braking graphics too :)

Weird things happen when people try to mess up the .RES files. I have a car for some years which accelerates only in the first 4 gears - if you switch up to fifth, it slows down and can't switch back (maybe invalid value for the position of 5th gear)... ;D
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 24, 2009, 09:52:14 AM
Car modding: it's about fast cars and breaking things.
Title: Re: Physics investigations on Stunts
Post by: BonzaiJoe on April 24, 2009, 10:34:07 AM
FĂșcking incredible car. In 2009, 18,5 years after the game was released, the roof of the world has been found! Looking a bit like a wooden board and sometimes a bit like a fence.
Another funny thing: if you let the car "roll" out of the truck, it also begins to fly backwards, but then if you press a key, you teleport back to the start/finish line (you won't stay there for long though ;))
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 24, 2009, 11:17:09 AM
We're just really lucky that stunts does not keep track of what date it is, that roof is basically the same thing as the milennium bug, starting from zero because you've run out of numbers.
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 26, 2009, 01:55:28 AM
1. The replay suggests the "roof" is at 7fffh =  32767 stressed coordinates (the largest positive position value that can be stored in two bytes), which is 72,8 times the height of a bridge or approximately 2km  :)

2. Overdrijf, here is a possible explanation for what happened to your car: You set all z-coordinates of the car bounding box to the same, negative value. Thus, your car has zero length, and that's why the physics went nuts. The zero length makes it spin on its own so it gets pointing down - but since all corners are set to a negative z value, the car is off-centre and tends to go backwards as well (like before). But if the nose is pointing down, backwards becomes upwards, and so... :)

3. The conversion factor between stressed coordinates and the CAR*.RES internal coordinates appears to be 32 (I managed to write it wrong twice on my post early on this page...)

4. With some additional findings, now there are only 29 bytes in CarBlaster whose function is still unknown, and most of these seem to be effectless for most useful purposes. Expect to see a lot of corrections and additions at the Car Parameters page on the Wiki soon...  ;)
Title: The Magic Formula (TM)
Post by: Duplode on April 28, 2009, 11:25:36 PM
If you have access to CarBlaster I strongly suggest you to perform the following demonstration.

1. Open the Ferrari GTO (other cars which can reach 245mph would work just as fine).

2. Change the mass of the GTO to some other value, it can be anything you want.

3. Calculate the quotient 65536/<your chosen mass> and look at the part of the number after the decimal point. If it is:

5. Load the modified car in Stunts and test your chosen value.

6. Rejoice.

7.  8) 8) 8) 8) 8)
Title: Re: Physics investigations on Stunts
Post by: BonzaiJoe on April 28, 2009, 11:44:43 PM
Wow!!  :o The secret of power gear! That's a landslide, congratulations Duplode  8)

Only one distinction missing: speed difference between ACURA power gear and Indy power gear.
Title: Re: Physics investigations on Stunts
Post by: zaqrack on April 28, 2009, 11:48:36 PM
I can not imagine you did not find this out in a dream. :)
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 29, 2009, 12:09:28 AM
Wow ones again. You really are good at this. So the drag really has nothing to do with it, and my kart has a very special unreachable powergear... :)
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 29, 2009, 12:52:06 AM
By the way, I'm probably sounding spoiled now, but it appears you where so exited about the second set of dimensions that you didn't mention were the car-to-car set is located. :)
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 29, 2009, 07:07:45 AM
I can not imagine you did not find this out in a dream. :)

Not quite, it was rather like one of those situations when lots of apparently unrelated informations suddenly start to make sense together when you stumble at the missing piece  :)

Only one distinction missing: speed difference between ACURA power gear and Indy power gear.


This distinction was, in a way, already pointed out - by you  :) Many years ago you wrote, and a few years later I read, a "Tips for Newbies" article in which the powergears of Indy and Acura were called "flexible", in opposition to the GTO and Vette ones. That is the fundamental distinction: "rigid" (or boring :)) powergear, the most common kind, works exactly the same for all cars that have it - to reach it you have to be at/above 225mph and the car must not have enough engine power to keep accelerating on its own by then. Flexible powergear, on the other hand, can be reached below the flat track top speed, and the minimum launch speed depends on the balance of forces acting on the car (including engine power, gear ratios, aero drag, steepness of slope, etc.). The launch speed for flexible powergear can potentially be much lower than 225mph, a fact that is evident on any Acura/Indy lap... The speed of the car when in PG is the speed of the car at maximum rpm in the (final) gear, so that's why Acura and Indy are different. If Acura had a value for mass that would give it rigid PG, however, it would never reach it, as the top speed is below 225mph (that is exactly the case for Audi, by the way). I like "rigid" and "flexible" terminology, guess I'll stick with it  :)

So the drag really has nothing to do with it, and my kart has a very special unreachable powergear... :)

Drag does not affect the kind of powergear indeed, but it if the powergear is flexible it changes the minimum speed (higher drag leads to easier-to-reach powergear). You mentioned to be using mass=15 and drag=19. 15 is a flex-PG value (same as Indy), and 19 is quite low, so the minimum speed might be well above 156mph (have you tested going through a loop, though?  :))

By the way, I'm probably sounding spoiled now, but it appears you where so exited about the second set of dimensions that you didn't mention were the car-to-car set is located. :)

Oh my bad, maybe I shouldn't have gone so far in skimming detail on that post  :D The range of interest is 0EEh - 0F3h, and values are in the usual x-y-z pattern. I will (try to) start writing some of this stuff (and more) to the Wiki now, so stay tuned  ;)
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 29, 2009, 09:14:56 AM
So the drag really has nothing to do with it, and my kart has a very special unreachable powergear... :)

Drag does not affect the kind of powergear indeed, but it if the powergear is flexible it changes the minimum speed (higher drag leads to easier-to-reach powergear). You mentioned to be using mass=15 and drag=19. 15 is a flex-PG value (same as Indy), and 19 is quite low, so the minimum speed might be well above 156mph (have you tested going through a loop, though?  :))

Not 15, 5. That's actually just a bit on the heavy side for a "realistic" superkart. :) So that would make it rigid. But no, I haven't tested a loop yet, I should probably still do that. (But I'm too lazy to do that before getting the new dashboard to work, and that's gonna take a few days.)
Title: Re: Physics investigations on Stunts
Post by: CTG on April 30, 2009, 06:18:21 PM
Duplode, may I have a question? How do you have so much energy for this Stunts research plus high level racing in the same time? This work is amazing!
Title: Re: Physics investigations on Stunts
Post by: Duplode on April 30, 2009, 06:25:11 PM
Duplode, may I have a question? How do you have so much energy for this Stunts research plus high level racing in the same time? This work is amazing!

Thanks - in my case, I think one thing feeds the interest for the other, and vice-versa  :)
Title: Re: Physics investigations on Stunts
Post by: Overdrijf on April 30, 2009, 06:37:16 PM
O, I forgot to mention, I tried the loop. As predicted by your formula, it does not powergear (for having a rigid/boring powergear and limited top spead).
Title: Re: Physics investigations on Stunts
Post by: Duplode on May 11, 2009, 05:08:08 PM
You can already read full report on how to control PG when tuning a car at http://wiki.stunts.hu/index.php/Power_gear_bug (http://wiki.stunts.hu/index.php/Power_gear_bug) ...
Title: Re: Physics investigations on Stunts
Post by: CTG on August 03, 2013, 05:59:10 PM
Daaaaaamn, I just realized that I use a bad theory for air drag limited top speed calculations. It worked for all my custom cars, except Veyron: it should reach 245 mph without powergear, but somehow it accelerated only up to 237. Problem solved. Sometimes I should read the instructions carefully... :D
Title: Re: Physics investigations on Stunts
Post by: gagarin on April 02, 2015, 03:25:13 PM
OFF: just found this spare account, forgot about it completely... (guests cannot see the memberlist)

ON:
Have you ever noticed that car size ratios are far from real life values? Duplode described the height anomaly and that some cars are just way too big. But their relative size is weird, too. Audi Quattro and Countach have almost the same length in real life - while in Stunts, difference is 22 units (>1.3 m).

Stunts Wiki says 1 pt = 0.2 ft = 6.1 cm (confirmed).

Lamborghini Countach
Real life size: 420/200/107
Stunts size: 104/38/18; which means: 634/232/110
Difference in %: +51.0 (!!!) / +16.0 / +2.8

Way too long and flat.

Lancia Delta Integrale
Real life size: 390/177/136.5
Stunts size: 79/34/25; which means: 482/207/153
Difference in %: +23.6 / +16.9 /  +12.1

Ratios are more or less fine.

Lamborghini LM002
Real life size: 490/200/185
Stunts size: 88 (without spare wheel)/34/31; which means: 537/207/189
Difference in %: +9.6 / +3.5 /  +2.2

The largest car from the pack in real life - very undersized in the game, compared to other cars.