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

[Duplode]

Wow, that 3D editor looks sweet!  I have a number of feature suggestions boiling in my head but I will leave them for later, after we actually get to play with the thing.

My problem with this editing thing is similar to church vs making clones. It's nice there are people able to change things in this game but I think the original one with all the silly bugs and mistakes is a perfect one for having fun.

CTG, that comment simply does not reflect what's going on. Bug "fixing" would require reverse engineering the sources, something that's not being attempted at all right now. The real point is, as BJ mentioned, adding diversity in cars, graphics and so on within the framework of Stunts gameplay. Besides, even if someone actually thought fixing the bugs was a good thing (something I disagree with as strongly as you), the reasonable approach would be to make a new game (à la Ultimate Stunts).So, stop being so pessimistic! 

editing obstacles is very promising! We can substitute blovk houses with giant ramps and such

The only problem is that it seems the physical model for the track elements is not stored toegether with the graphical model/3D shapes (so if you replace the highway 3D shape for the tunnel one you'll get a tunnel-looking highway, and not a proper tunnel). The physical model and material definition locations are the most important stuff we haven't located yet...

[dstien]

stressed can now open and display shape resources. Only materials are editable, and saving is still highly experimental. The 3d view doesn't draw wheels and spheres yet. If you're editing GAME1.3SH the truck animation won't work because stressed rebuilds the vertex list, animation transformations are performed on fixed vertex indices. Also, the game may crash because Stunts' shape parser is very picky about the 1-3 last bytes of each shape resource. We'll have to solve this riddle first...

To upgrade your local copy:

Code Select Expand


# Delete old config
rm -f ~/.config/stuntstools/stressed.*

make clean
svn update
make
src/app/stressed &


When you select a primitive in the first table, its vertices and materials will appear in the other two. The primitive in question will be highlighted in the 3d view. Use mouse buttons + move to control the 3d view. I have no idea how Duplode managed to make all those skins in a hex editor, but this approach will hopefully make it easier...

My problem with this editing thing is similar to church vs making clones.

Don't worry, installing game mods is voluntary. Unlike unborn clones, you actually have a choice.

Wow, that 3D editor looks sweet!  I have a number of feature suggestions boiling in my head but I will leave them for later, after we actually get to play with the thing.

I have some ideas as well, but most tasks should be left to a real modelling tool. First priority right now is to fully understand the shape structure.

[BonzaiJoe]

I love the dark clouds!

[dstien]

I love the dark clouds!

Good catch! The clouds are in fact 3d shapes as well.

[Chulk]

Is there any way I can get that editor? I couldn't find it in this topic...

[Duplode]

I have no idea how Duplode managed to make all those skins in a hex editor, but this approach will hopefully make it easier...

You may be sure indeed it will!! For the umpteenth time, thanks... BTW, the most painful part is not actually making the changes, but reverting or tracing them back after a few days...

I updated my SVN copy and played around on the editor a bit, but haven't tried to save and run shapes with modified materials created from stressed yet. Aside for the little quirks unimportant at this stage, the significant point I noticed was the "Unknown" data being stored as an 8-byte sequence - we had found there are (at least) two separate blocks of data in the Unknown region, with 4-byte sequences associated to each polygon. I'm trying to investigate those sections but the observations still make little sense to me.

I have some ideas as well, but most tasks should be left to a real modelling tool. First priority right now is to fully understand the shape structure.

Well, of course you're absolutely right... Anyway, my suggestions settled down to three in the end: one of them was rather obvious and is already implemented and another depends on how you're planning to implement vertex list edition and import/exporting, so it is best left for later. The third one, however, is about materials: it would be nice if we could export an individual material list for each paint job on a shape to an external file and then import it later on, so that we can select and distribute paint jobs for custom colour sets easily. From another point of view, I would say the current functionality of stressed clears the two main complications of paint scheme design - namely, relying on my wonderfully confusing 2D maps for locating polygons and on the limited and often frustrating "Find/Replace/HexCalc" tool set to do anything at all. Having the ability to store individual paint jobs would solve the next complicating factor by providing easy means of backup and reloading, thus allowing for faster (and more fun) care-free testing.

I love the dark clouds!

That reminds me of something I always forget to look by myself: is the light blue sky rendered as a "3D" shape as well?

Is there any way I can get that editor? I couldn't find it in this topic...

You can get it, but not through the topic because it is in development and only available via dstien's project SVN "feed". Assuming you're under Windows, getting it will require some extra steps I'm not familiar with, so it's better to leave dstien to guide you...

[Krys TOFF]

Such news in this thread while I was away for 1 week. Oh gosh, I love this thread !

We may also be able to change sky cube and background. what about a black sky and a moon-like background, with yellow sand instead of grass, and also a lunar gravity (huuuuuuuge jumps expected ! )

[BonzaiJoe]

I think Stunts already has lunar gravity... 

[dstien]

Aside for the little quirks unimportant at this stage, the significant point I noticed was the "Unknown" data being stored as an 8-byte sequence - we had found there are (at least) two separate blocks of data in the Unknown region, with 4-byte sequences associated to each polygon. I'm trying to investigate those sections but the observations still make little sense to me.

I just needed a place to stash the values while testing. I've been away for a few days, but I have now checked in some updates. Unknowns are correctly parsed according to our current knowledge. Unknowns, depths and vertex co-ordinates are now editable for easy testing.

At a second look it seems like Unknown1 holds a range of angles from where the primitive is visible, used for advanced culling. This is what makes a bridge polygon visible from all sides, while, for example, the tunnel ceiling is only visible from beneath.

it would be nice if we could export an individual material list for each paint job on a shape to an external file and then import it later on, so that we can select and distribute paint jobs for custom colour sets easily.

Hm, wouldn't it be easier to just swap 3SH files? Of course, patches are welcome.

That reminds me of something I always forget to look by myself: is the light blue sky rendered as a "3D" shape as well?

Not that I know of.

Is there any way I can get that editor? I couldn't find it in this topic...

I'll try to whip up some Windows builds soon*.

*) Definition of "soon" is subject to change.

[Duplode]

but I have now checked in some updates. Unknowns are correctly parsed according to our current knowledge. Unknowns, depths and vertex co-ordinates are now editable for easy testing.

Great, great, great... my SVN directory will update itself as soon as I finish this post...

At a second look it seems like Unknown1 holds a range of angles from where the primitive is visible, used for advanced culling. This is what makes a bridge polygon visible from all sides, while, for example, the tunnel ceiling is only visible from beneath.

Yes, Unk1 definitively does some sort of "angular culling" (if my terminology is coherent, that is...). When you look at several values of both unknowns for faces of the same object, it's clear there must be a pattern depending on orientation of the faces, only that the actual pattern is not very obvious...
I performed a couple experiments by replacing Indy shapes with tennis courts (so as to take advantage of the net, a very easy polygon to watch  ). Naming Cartesian axes as x = length, y = width and z = height, the first two bytes of Unk1 appear to control visibility depending on xz angle (so that objects may disappear when viewed from above - actually from over a certain vertical angle - with "wrong" values), and the last two bytes are related to xy angles (typical example is rotation at car selection screen). What is utter confusing is what sort of limits do those bytes impose... the only certain thing is FF FF grants full visibility and 00 00 gives no visibility (effectively making the polygon invisible, something shape editors could explore later on...). For the xy bytes at least, it seems also that each byte controls half of the possible viewing angles (a 180º range). I simply can't understand, however, why many values of the xy bytes result in far more than two visibility angle ranges (thus making polygons flicker a lot in the car selection screen, for instance), why widely separated values often give nearly the same effects, or why no matter what is done you get always the same viewing range with the xz bytes if their values are neither FF FF or 00 00 (at least from above, that is)...

it would be nice if we could export an individual material list for each paint job on a shape to an external file and then import it later on, so that we can select and distribute paint jobs for custom colour sets easily.

Hm, wouldn't it be easier to just swap 3SH files? Of course, patches are welcome.

Well, I thought of three main reasons for inserting individual material lists into .3SH files:

• Allowing non-editing users (and editing ones too ) to pick their 7 favourite colours easily in a custom file
• Making editors able to restore changes in an individual paint job easily from backups (if one is dealing with the 11 standard colour definitions or simple derivatives such as the ones I presented on the early posts it would "just" require auto-replacing colour strings in an hex editor, but when you start to make more detailed edition it gets a lot harder)
• Allowing for easy recovery of a nice editing work from a .3SH full of failed experiments (this is sort of my current situation with the custom STPMIN.3SH  )

Of course, such commodities are likely not (and need not be) top priority issues for your stressed at the moment, and by the time such sort of stuff actually gets tackled my Java (Fortran? Err...no ) skills might be decent enough for building a reasonable tiny add-on. But the important is the idea gets registered 

To switch exploration areas for a brief while, I attempted to dissect a somewhat different file, TEDIT.RES . It basically consists on a list of icon pointers for the track editor interfaces mixed with some other related stuff. Maybe dstien has already looked into it, but anyway here go the main findings. The relevant resources are:

• A huge number of e??? text resources, each containing a set of dialog box messages, error warnings, track piece descriptions, etc.
• A pbox resource with 36*11 = 396 bytes that controls which track pieces will be available on each coordinate of each panel of track editor interface (SHIFT+F1, then F1, F2... F10). Pieces are arranged in the "natural" panel order with coordinates of each panel arranged by rows. Byte values point to track elements using the usual definitions of Track File Format (specified here)
• Three sets of 186 text IDs associated with individual track pieces. snam has 4-byte IDs pointing to resources in SDTEDIT.ESH that define the "shape" of an icon (a very easy way of messing up with use of the regular editor... ). mnam is similar and points to some complementary (maybe colour related? .ESH structure is very different from regualr bitmaps) data on SDTEDIT.3SH. Finally, tnam uses 3-byte IDs pointing at the e??? resources within TEDIT.PRE used as track element descriptions (for instance, "svc" calls "esvc" which prints "corkscrew left/right").
• And last, but not least, ter0...4 are 900-byte resources that define what the default terrains actually are, employing the familiar track file format.

And finally I'd like to close with some new pics - versions of some of my sample paint jobs overhauled with relative ease thanks to stressed... starting with Chulk's suggestion:



Now it almost looks like the real thing, or at least what it would look like on Geoff Crammond's 1992 F1GP... 




My American Racing Blue Corvette also benefited a lot from easier detail picking. With a couple small changes, it's a lot more refined now:




(In case you're wondering, I do intend to release my custom .3SHs, it's just they aren't quite up to releasing standards yet  )

[Chulk]

And finally I'd like to close with some new pics - versions of some of my sample paint jobs overhauled with relative ease thanks to stressed... starting with Chulk's suggestion:



Now it almost looks like the real thing, or at least what it would look like on Geoff Crammond's 1992 F1GP... 

WOW!! That looks great man! THANKS!!!

PS:

I'll try to whip up some Windows builds soon*.

*) Definition of "soon" is subject to change.

[cody]

hmm, what format dose stressed inport/export out of?

[dstien]

Duplode - Nice work! Speaking of materials, I just tried altering the number of paint-jobs. It turns out vehicles can have anywhere from 1 to 127 paint-jobs. In other words, the counter is a signed integer, but 127 should be sufficient. I've added a widget to stressed for setting the number of paint-jobs. Since altering this number can be destructive, you'll have to explicitly hit enter or move focus to another widget before the change takes effect.

hmm, what format dose stressed inport/export out of?

None yet, but it'll have to be a simple, text-based format with widespread adoption and support for n-gons. The biggest obstacle is how we should handle the limited amount of materials.

[cody]

so no importing .3ds .obj .z3d or .max? dang, i was looking forward to building cars    ive started on a few of them.

[Duplode]

so no importing .3ds .obj .z3d or .max? dang, i was looking forward to building cars    ive started on a few of them.

Well, thanks to dstien stressed is in active (and pretty fast, I'd say) development... so c'mon, don't be so let down and keep looking forward!

I've added a widget to stressed for setting the number of paint-jobs. Since altering this number can be destructive, you'll have to explicitly hit enter or move focus to another widget before the change takes effect.

So the changes are staring to get bigger...

None yet, but it'll have to be a simple, text-based format with widespread adoption and support for n-gons. The biggest obstacle is how we should handle the limited amount of materials.

Back in the very early stages of hacking I grabbed the *.OBJ format definiton from Wikipedia and used my stuxplic parser to make *.OBJs from vertex lists. The main issue was all 3D editors I could find either started screaming about the n-gons (Blender...) or automatically converted the mesh to all-triangles (obviously an horrible solution for our case). As for the colours, maybe the easiest way out, at least for the initial versions, could be exporting only the vertex list and letting stressed handle the materials on its own.

And thank you all for the appreciations...