Topics

As the title says, I recently started to dissect the files of Stunts. Originally, I wanted to know if it?s possible to replace the graphics of the opponents.
Needless to say, I had no luck. So I started to dissect the files, trying to figure them out.
Not much did I find, perhaps someone knows more?

I took much information(almost all) from the Stunts FAQ, didn?t mark it, though, as I simply added what little I found.
(Note: I pasted everything from a text-file I keep, I hope the formatting survived it.)

BTW: I hope it?s the right forum, didn?t find a more fitting. If that has been posted already, please point me to the thread, I did search, but there?s always the chance I used the wrong words...

Anyway, here?s the info:

Version 1.0 had partially uncompressed files, while those of 1.1. are compressed. Not all of them  just some.
The files containing graphics are apparently compressed in ALL versions.
The RESource files, however, are uncompressed in V1.0 - that?s why programs like Opponent Blaster can change them easily.

The files of V1.1 are NOT encrypted, rather compressed. The initial "p" in their extensions probably means "Packed". So, "RESource" becomes "Packed REsource".
An indication for packed raher than encrypted is that the packed files contain the size of the old files(compareable with the Opp?.RES files), and, well, they?re simply smaller. Not just a few bytes.

The "PVS" thus would mean "Packed VS" - whatever a VS file is, though one can assume the "V" standing for "Vector", as we know that Stunts uses Vectorgraphics, instead of bitmaps.

The packing method is unknown, I don?t think it?s any of the common archivers, though. It doesn?t look like it?s been compressed by ARJ, ZIP, LHA or such, even if the header is stripped away.

Now the structure, as far as I can tell(not far) - I took most information from  available resources:

*) RES files
There are (perhaps) two of them - one for cars, one for opponents. They might be of the same basic structure,
but I have no  information about that. It seems likely, though.

Opponent structure(uncompressed):

Code Select Expand


OFFSET   SIZE      DESCRIPTION

0x0000   LongInt   Resource file size in bytes
 ...
0x0005   Byte      0x1B - probably an End of Header tag
0x0006   215Bytes  I wish I knew. It looks like some sort of Index table,
                            perhaps the positions to the texts below(for win, loss,
                            etc...). Surely it?s no binary data, it?s too structured
                             for that.
0x00DE   2 Chars   Opponent's initials    
 ...
0x00E0   7Byte     Nothing, Zero. Apparently unused
0x00E7   20Byte    Junk? Some bytes, ones and zeroes. Can be overwritten
0x0103   151Byte   Nothing, a few bytes in between, nothing serious(?)
 ...
0x019B   Byte      Paved road
0x019C   Byte      Dirty road
0x019D   Byte      Icy road
0x019E   Byte      Paved sharp corner
0x019F   Byte      Dirty sharp corner
0x01A0   Byte      Icy sharp corner
0x01A1   Byte      Paved corner
0x01A2   Byte      Dirty corner
0x01A3   Byte      Icy corner
0x01A4   Byte      Bridge
0x01A5   Byte      Paved slalom road
0x01A6   Byte      Corkscrew up/down
0x01A7   Byte      Chicane
0x01A8   Byte      Loop
0x01A9   Byte      Corkscrew left/right, Pipe
 ...
0x01AB   Text      Here begins a large chunk of text - Name, Expertise,
                          Problems, Info,  it?s all here, simply written up.
                          No coding, no structure, apparently.
0x034F   35Bytes   Some bytes, they seem to be important. Perhaps the
                           coordinates for the evaluation videos? Or the text
                           coordinates, though I doubt that.
0x0372   till EOF  The Win/Lose/Crash texts

Note: The texts have no special encoding, other than ENTER indicated by "]", text fragments
     are ended with 0x02E00 apparently.


Opponent structure(compressed):
I wish I could say I know as much about these as about the uncompressed - the sorry truth is, I know hardly anything.

Code Select Expand


OFFSET   SIZE      DESCRIPTION

0x0000   1Byte     0x02 - Header ID? Indication for Compressed file?
0x0001   2Byte     Size of UNCOMPRESSED file + 1
0x0003   1Byte     0x00 - always. Don?t know why
0x0004   1Byte     Either 0x0A or 0x0B - perhaps the second half of a word?
                          (previous byte)

That?s it. There are several characters at the beginning, but I have no idea what they mean. They might be part of a Huffman encoding, though.



*) Highscore files:

Code Select Expand


OFFSET   SIZE      DESCRIPTION

    0x0000   17 Chars  Driver's name
                         (zero-terminated string)
    0x0011   24 Chars  Driver's car name
                         (zero-terminated string)
    0x0029   1 Byte    OppWinFlag - zero when won, one when lost
    0x002A   2 char    Opponent?s initials
    0x002B   1 Char    Separator("/")
    0x002C   5 Char    Opponents car (short version)
    0x0032   Word      Time achieved by human driver

    The time value has to be divided by 20 to get a result in seconds, e.g.

         2131 / 20 = 106.55 seconds = 1 minute, 46 seconds, 55 hundredth

Note: Version 1.1 apparently doesn?t work "clean" - the strings are not, like in V1.0, folloed by ".", but mere memory copies - with whatever junk lay in there. Do not read beyond the final Zero!


*) Track files
  are well-known enough, I think - no need to describe them here again.

*) PVS files
As said above, they?re probably compressed. So the PVS might mean "Packed Vertex Structure", since the graphics are vector-based, instead of simple bitmat.
They?re used for the opponents animation as well as the background, apparently. The opponent pictures are NOT saved in them, they?re somewhere else, maybe hardcodec somewhere, along with the number of opponents.

Code Select Expand


OFFSET   SIZE      DESCRIPTION

0x0000   1Byte     0x02 - Header ID? Indication for Compressed file?
0x0001   2Byte     Size of UNCOMPRESSED file + 1