News:

Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu

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

Started by Cyberman, July 23, 2004, 08:15:12 PM

Previous topic - Next topic

Krys TOFF

Marvelous ! Thanks again dstien for your hard work.
Zak : you're pure evil, the kind of evil I like. ;D
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. :D

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

Quote from: dstien on March 25, 2008, 07:41:30 PM
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 :)

Quote from: dstien on March 25, 2008, 07:41:30 PM
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.
But we can't be quite sure.


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! 8) 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:


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...
But we can't be quite sure.


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 ! ;D 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...
Yes, it is me. No, I'm not back at racing (for now...)

dstien

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


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.

Quote from: Duplode on March 26, 2008, 04:15:30 AMWhile 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

Quote from: zaqrack on March 26, 2008, 11:31:32 AM
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...

Quote from: Krys TOFF on March 26, 2008, 01:08:36 PM
Wow, wow, wow ! I want a yellow version of EVERY car ! ;D Not gold, yellow.

Just replace yellow with purple for me! ;D

Quote from: Krys TOFF on March 26, 2008, 01:08:36 PM
Best would be a black and yellow car, like good-old-Senna-days in Lotus F1 team.

Quote from: Chulk on March 26, 2008, 08:15:57 PM
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]
Quote from: dstien on March 26, 2008, 10:46:42 PM
Nice find, Duplode! According to my current understanding of the mesh structure, the number of color variations is a part of the header:


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...