Stunts trials

[Cas]

As of now, with what we know, it's possible to create new track elements, but... you have to replace an existing element (cannot "add") and the physical model of it cannot change, so it's only the appearance that will.

We would like to find the trick to change physical models and maybe something we can tweak so we can add a few more slots for stunts. I think the second one is easier to find.

[mrdries]

Okay. Yeah, seems so hard to discover how to do these things without the source code. Have no idea how that's even possible.

But I love the fact that there is a Stunts community. Really cool. Always loved this game too.

[Cas]

It's not easy, but some things can be done. A lot of work came during the disassembly phase and then the ASM extraction analysis. I wasn't part of that. The idea was to begin translating all that to C, but very little of that was done. So what I've been doing with the folks more recently is working on the pure ASM code, guided by the remarks left by the guys that did the disassembly.

[mrdries]

That's quite something. Very intriguing stuff. It's like deciphering Rosetta's stone.

I guess, if it were somehow possible, I suppose not, to put two track elements on the same location, you could have a pipe with the roof of a tunnel. Or a banked road on top of a highway.

If you could somehow switch slots, especially slots from landscape elements and track elements, you could have a road in the shift-F1 menu and since it would be a landscape element, you could put something on top. Though I'm sure that's not how it works.

Just changing colors from a track element or a landscape element, is kind of cool though. Like a light grey road or a dark brown bridge or a muddy hill. It may not look ugly or out of place.

[Cas]

The issue here lies in how Stunts engine does rendering and physics during gameplay.

In my graphics engine, track grids are converted to a group of models that are placed at the right positions and with the right rotations to agree with the map, but in theory, the engine supports placing them at non-integer locations and with non-right angles and it's perfectly possible to put one on top of another. As you play, elements are rendered by distance at their designated positions.

But Stunts does not do it this way. It does still use the grid while rendering, so a tile remains a tile during the game and two elements cannot share a tile. This sets a limit to what we can do by tweaking, unless we found a way to separate these attributes.

Your suggestion of using terrain codes to render track elements does have a greater chance of working. I don't know where in the code terrain codes are resolved, but if I find that, I could have the engine look at codes beyond the currently available and load other graphic models. The physics models of these new elements, if the attributes (graphical and physical identity) are not split, would have to be, for example, all equivalent to plain grass at low level, but if we could split that, we could choose to assign any of the existing terrain models to the new graphical models. Then the only thing that would not work would be Stunts recognising them as part of the track, so we'd have to use a trick like your trials to actually use these elements, but it's still a pretty good thing!

[Daniel3D]

If I understood and remember correctly the game builds a track tile in phases. First the terrain, then the track/scenery a road surface area and finally the collision model.
A terrain/track combination is connected to one or several collision models. But there are a limited number of possibilities.

The road surface code and collision models are not yet fully understood. And can't be changed as it is.

[mrdries]

I see. I guess that if you could find the position of the physical properties of a normal straight road tile, within the code. And if you'd also find the physical properties of a muddy or an icy straight road within the code, then you could compare the code of these two tiles. And since the only physical difference of these two tiles, would be the traction of the road surface, then you might be able to figure out where this is determined within the code. And perhaps, how it works.

And perhaps then, you could change the traction of other track tiles too?

Though I'm sure, the real difficulty might be to locate the physical properties of a track element within the code.

Although, I suppose that the similarity of the F1, F2 and F3 tiles, normal, muddy and icy roads, would make the code of these tiles very similar. Almost like the tiles are repeated three times. So the code might also almost repeat itself three times? And thereby, it could expose its location? Just guessing.

[Cas]

In my understanding, surface type is handled by Stunts as an attribute already separate from collision, which is handled via physical models based on two structures called "plan" and "wall". At some point of the source, it is hard-coded which track code leads to which combination of surface type, collision model and graphical model. If this place in the source is found (which surely has already been found when it was disassembled and analysed, so it must have labels and comments there), we could tweak this, but for a track element won, there's a track element lost.

An issue here would be that, if we change the collision model of a track code, it's logic circuit part correspondence will not change. So your track piece will continue to fit only in the same combinations as it used to fit before (except in trials-like tracks, of course).

Going back to graphical models and using terrain codes, I forgot to say the last time that Stunts works out terrain codes by applying a "special product" operator. That is, you take one terrain code and one track code and you obtain a new track code as a result. This is only done for track elements on the sides of hills. When there is water, the models are indeed both rendered. When there's something on top of a hill, it's elevation is updated and also, the hill model is rendered. This means that higher track values are often reserved for models of roads on the sides of hills.

[mrdries]

Yeah, one track element won is one track element lost. That really sums it up.

Thanks for explaining. It's clearer now.

The only thing I can think of right now that might feasible and may have a significant impact, is to have a "concrete tile" in the terrain.
So that you could move over it, just like you would on a road.
It would have quite an impact on the game play, because it allows for a far greater diversity in the curves we take. Now, we take the curves that are determined by the different tiles, like a sharp corner or a big corner, etc. But it you would have a "concrete tile" or "asphalt tile", you would make different trajectories. If you have for example two tunnels and you'd have to drive through both of them, you could take a more diagonal path when driving from one tunnel to the next, which isn't always possible when you have to follow the existing tiles.
Of course, there would still need to be a road that would connect those two tunnels, unless for trials. But that would still be possible. You could connect them with roads and cut corners by driving on a concrete tile.
It may allow for other cool stuff, like driving close to a building when you're cutting a corner and such. So I really think it would make quite a difference in game play.
Though I guess that even including this one new terrain element, may result in the loss of another terrain element?

[mrdries]

I know this is all very off topic, but one other idea, would be to use a brown terrain tile and a white terrain tile to simulate the effects of a muddy road or an icy road.

Probably complicated to do but if you had a white terrain tile with two parallel surfaces, a bit like the tunnel where you can drive in it and on it. But the difference between these two surfaces would be minimal. The tile itself would be slippery. If you'd have a road on it and if the track element as well as the terrain element would be active, you would see white spots on the road. That's the second surface of the terrain tile, slightly above the road. It has white spots so it appears that the road is icy. And you would drive on these white spots and they would be actually slippery, so the road becomes slippery.

All this would be to eliminate all the icy roads from the F3 menu.

The same could be done with the muddy roads.

So you'd have lots of new slots by using two terrain tiles like some kind of multiplier. And if you'd have lost terrain elements by doing so, perhaps they could be reinstated as track elements.

It would be like a Stunts mod.

[Cas]

Well, as for a full-asphalt tile, the closest to that I know in Stunts, at least physically (not graphically) is the chicane, which works like a 2x2-tile full asphalt surface. Of course, it has one entry and one exit, but through the magic of "illusion", you can merge two of them and create a two-input/two-output such block.

The more I read about ideas like this, the more I wish I could crack the physical part of the engine or come up with a good idea of how to develop my own, because the graphical part is pretty much resolved.

[Daniel3D]

I believe that surface effects are isolated from collision models and graphic models. So that would make full tile surface effects to replace grass the most feasible of all ideas. Also because there is room in terrain. Although also limited because they all share the same group of element ID.

[mrdries]

Yeah, man... what can I say... I hope you do. Or I hope you guys do. I have this feeling it could be cracked.

Looks like a pretty cool achievement.
When there is room in terrain, you wouldn't even have a terrain element lost.

[Daniel3D]

It a long way ahead. Even if llm, Duplode, CAS and I would each spend many hours a week on the matter, it may still take a few years.

[mrdries]

Yeah, much harder than I thought.

Would it be any easier if you could 'copy' the chicane into the terrain code to make it into a 2x2 terrain element?