Dissecting the Stunts files, trying to. Anyone know more?

[Krys TOFF]

Marvelous ! Thanks again dstien for your hard work.
Zak : you're pure evil, the kind of evil I like.
Duplode : I'm not sure I'd like to create track this way, except somebody modify trackblaster to allow it. I'm not a specialist of hex-editing.

[CTG]

Pure Stunts fits me better. And I also think solving these codes can lead to serious game manipulations - having a fatal effect on the competitions.

Nice work but really dangerous.

[zaqrack]

Look, there are almost no new pipsqueaks. Those who I play with since years can almost all be trusted, and those who are new are probably new to the game as well, and don't know how to make these modifications.

[CTG]

Partly right... what about Dstein? He's a newbie and he broke the code.

Paranoid mode OFF.

[dstien]

I don't see how reversing visual game assets - bitmaps and 3d shapes - is a threat to racing competitions. The information about car tunings, replays, high scores and tracks have been available for quite a while. From my experience with other game communities I've noticed that there's a distinct correlation between the urge to claim deceitful achievements beyond one's capabilities and sub-average intelligence.

My motivation for doing this is that I want to make new cars from scratch. Reversing is fun as well.

[CTG]

Sub-average intelligence, lol... How do you explain my... okay, I'm not unmodest.

[zaqrack]

I've noticed that there's a distinct correlation between the urge to claim deceitful achievements beyond one's capabilities and sub-average intelligence.

LOL, good point. Intelligence can be substituted with supressed depression/agression as well

My motivation for doing this is that I want to make new cars from scratch. Reversing is fun as well.

Just keep on the good work. You're something like a messiah for the community

[BonzaiJoe]

Please don't mind CTG... I don't think he was being serious, and you'll find that in a strange way, even when he is serious, he isn't that serious

I'm very excited about these new finds, and I don't believe they are threatening to the competition at all.

[Duplode]

Breaking news:



Today I managed to find some bits of useful info about ST*.3SH (car shapes) file structure in the search of an ultimate goal, which as you can see was achieved: Car palette edition is now perfectly viable! I'll try to condense the results in a readable way.

Each car has seven resources accessed via the offset list: car0...2 and exp0...3 . car0 draws the (more detailed) car shape seen in the selection menu; car1 holds the normal on-track shape and car2 is the low-res distant shape (similar to the tunn/ztun situation I mentioned a few posts above). The three shapes are fully independent. As for the exp's they're much smaller in size (a fact that originally led me to believe colour data was stored there, which is not true) and they purposes aren't so clear - one thing, though, one of them controls for sure are the bits of debris that fly after a crash...

Considering now the structure of the car_ resources, body panels are drawn independently from each other (that probably means it's all rectangles!). That conclusion was quickly reached when I located the first actual colour-changing byte, which turned the (front) trunk of the blue Countach golden... thankfully, it seems the vector data for each panel is stored just beside the colour bytes, and so it was also possible to selectively skew that boot coordinates (no clue about coordinates yet, though).

Going into the specifics of the colours, each panel has all seven available colours stored on a seven-byte string, indexed to the game's internal palette. While this makes fine-tuning possibilities endless (bi-colour cars!!), it also might make colour changes a headache if one lacks a good hex editor (I'm comfortable with KHexEdt, under Linux obviously) - even more because the number of panels and resource lengths vary from car to car. Fortunately, at least if one is interested in whole-car changes, patterns for the default colour sets are easy to recognize. I employed in my tests Countach and P962, which share the colour set, plus NSX, which shares the first three colours. Since default colour byte values are in ASCII range, a very easy way to spot them was provided by my editor "Extract strings" function, which selectively locates printable character strings. All that was needed was to look for 7-character/byte strings which appeared a lot of times through the file. Results are surprisingly unambiguous - for the Countach there are four closely related 7-char strings that appear a grand total of 176 times through the file:

Code Select Expand


33 37 3f 43 47 4b 4f
32 36 3e 42 46 4a 4e
31 35 3d 41 45 49 4d
30 34 3c 40 44 48 4c


Looking at those strings byte chart above, columns correspond to each colour available, while each line/string is associated to a particular shade of the main colour (33 37... are the lightest tones and 30 34... the darker ones). Thus, swapping colours between existing cars requires merely identifying the correct strings and replacing them adequately. The golden Countach had the body colour strings swapped with the NSX ones. Although I haven't tested yet, minor colours such as windows, headlights and stuff seem to be handled the same way (the non-body panel 7-char strings are all repetitions of a same value, indicating they do not change with the car colour). The logical next question is whether we can insert new colours... the answer is a shiny yes, with only two caveats: first, we're restricted to Stunts' colour palette (values seem to range from 01 to 81 in hex, including a rather large number of duplicates); and second, we need to identify properly all available colours in Stunts palette , so we can choose light and dark tones properly.

Now we have a nice customization feature to toy with our cars and, perhaps more importantly, colour strings may be of great help in identifying body panels in the vast arrays of bytes in those .3SH files once we tabulate the colour palette. Customizing car colours was something I would really love to be able to do, and now it is possible... thanks to dstien's insight: Zak chose a good metaphor describing your role here as messianic  . I leave you with my custom STCOUN.3SH attached and a screenshot to show how the golden Countach looks damn cool in-game - considering an order, Zak? 

[BonzaiJoe]

Well done!

This is the greatest game-alteration since Mark Nailwood. Keep it up!

The moment there is a black car, I will stop racing red cars...

[zaqrack]

I'm in for a golden countach of course!
Let's take it a step further: The winner of the season gets a special golden Countach Or more than that, on each track, the winner earns the right to receive a special coloured car's P3S, and use it in races. Too bad it'd only appear in that colour on his computer, but it could be a fun idea anyway. And it's not that hard to write a tool similar to Car Blaster which allows us to change a car's color entirely (colouring only some parts could be more complicated because of the different shape of the cars).

As far as I know, Stunts uses a 64 colour palette. But I may be wrong.

[Krys TOFF]

Wow, wow, wow ! I want a yellow version of EVERY car ! Not gold, yellow. And black too if possible. Best would be a black and yellow car, like good-old-Senna-days in Lotus F1 team.

[Chulk]

Great job Duplode! And of course a huge Thanks to Dstein for making all this possible! By the way, I'd love to have a Silver version of every car, but specially Indy as it would look as McLaren...

[dstien]

Nice find, Duplode! According to my current understanding of the mesh structure, the number of color variations is a part of the header:

Code Select Expand


struct SHAPE {
    BYTE numVertices;
    BYTE numPolygons;
    BYTE numPalettes;

    [...] // Vertices and other unknown data?

    POLYGON polygons[numPolygons]
};

struct POLYGON {
    WORD numIndices;
    BYTE colors[numPalettes];
    BYTE indices[numIndices];
};


This means that the number of palettes isn't fixed. We can use the simple exp_ shapes to verify these assumptions:



There are four explosion shapes, they all have one polygon, so the number of vertices per polygon appears to be variable. For STCOUN.3SH, exp0 and exp3 are quads with the default color and a darker shade. exp1 is a triangle with the default color and exp2 is a single black line.

While this makes fine-tuning possibilities endless (bi-colour cars!!), it also might make colour changes a headache if one lacks a good hex editor (I'm comfortable with KHexEdt, under Linux obviously) - even more because the number of panels and resource lengths vary from car to car.

Yes, the field of free hex editors is a sad state of affairs. It looks like Okteta will replace the unmaintained KHexEdit in KDE4. I tend to use shareware Windows hex editors under Wine to get advanced features such as scripting and data structure templates.

CTG - My comment was aimed at cheaters, I'm sorry if I offended anyone here.

Edit: Added polygon struct pseudo code.

[Duplode]

Or more than that, on each track, the winner earns the right to receive a special coloured car's P3S, and use it in races. Too bad it'd only appear in that colour on his computer, but it could be a fun idea anyway.

That would be a nice distinction, particularly if we get to construct spectacular-looking colour combos...

Wow, wow, wow ! I want a yellow version of EVERY car ! Not gold, yellow.

Just replace yellow with purple for me!

Best would be a black and yellow car, like good-old-Senna-days in Lotus F1 team.

By the way, I'd love to have a Silver version of every car, but specially Indy as it would look as McLaren...

Well, after we can identify polygons properly I do think we can make awesome black/golden JPS Special Lotuses and Silver/Red Vodafone Mclarens...

[/quote]

Nice find, Duplode! According to my current understanding of the mesh structure, the number of color variations is a part of the header:

Code Select Expand


struct SHAPE {
    BYTE numVertices;
    BYTE numPolygons;
    BYTE numPalettes;

    [...] // Vertices and other unknown data?

    POLYGON polygons[numPolygons]
};

struct POLYGON {
    WORD numIndices;
    BYTE colors[numPalettes];
    BYTE indices[numIndices];
};


This means that the number of palettes isn't fixed. We can use the simple exp_ shapes to verify these assumptions:

There are four explosion shapes, they all have one polygon, so the number of vertices per polygon appears to be variable. For STCOUN.3SH, exp0 and exp3 are quads with the default color and a darker shade. exp1 is a triangle with the default color and exp2 is a single black line.

After wondering for a while and reading Wikipedia in order to visualize polygons and vertexes properly (never worked with 3D graphics before), I understood your pseudocode and saw it working on the Countach front trunk panel (colour codes at 0x09aa). It's quite cool, really  . But there is non standard stuff as well... I had most of my experiments today with wheel "polygons" (On the Countach, the range is from 0x096c to 0x09a7). There are four so-called-polygons, one for each wheel, with appropriate colour strings and vertex indices. However, behaviour is very different: first of all, setting a byte colour, say, at 0x26 automatically sets all three tyre/wheel colours - tyre  front as 0x26, tyre lateral as 0x27 and the wheel itself as 0x28. Moreover, the word "numIndices" is 0x0c, but there are only six indices to edit... and if you try to deform a tyre by extending it in one direction the wheel will be suitably adjusted and a second distortion, symmetrical in relation to the origin vertex, will take place as well. Thus, there is *something* else involved in wheel drawing. Anyway, understanding the graphics does not seem so distant a goal now  .

BTW, FYI, counting printable-byte colour strings reveals we have (a few more than) 223 polygons in STCOUN.3SH. Of those 223, 148 are in car0 and 66 in car1...

And before I go to bed: the fact the wheels load three colours simultaneously actually proved helpful: it made obtaining the full colour palette much easier! There really are 130 "colours" (0x01 to 0x80). The quotation marks are due not only to the high number of repetitions or very similar shades but also for some of those colours actually are the semi-transparent ground textures from loops and bridges! Anyway, I attached a very sloppy (and sleepy!) spreadsheet chart which may serve as a rough guide for the time being...