Stunts trials

[Daniel3D]

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?

I think that it is easier to use the hilltop.
Because that is a terrain tile with ground properties. If we know how ground properties are set we could maybe redirect that.
Off course it's also possible that it works the other way around. If no surface is set, then it must be ground/grass...

[mrdries]

Hmm... I imagine that when there's some willingness to create some new track or terrain element, you'd want to start with something easier than this.

So just supposing for a moment that you'd want to create a Stunts mod, with your own track and terrain elements, as a side project. You don't have to care about deleting or modifying existing elements. You could do whatever you like. But you'd want to do more than just visual effects.

Would anything be somewhat straightforward?

Making a road wider?
Changing the grip of the road to whatever it might be?
Combining an icy road with the collision properties of road blocks?
Adding a sharp corner to an existing tile?
Deleting collision effects on a tile so that your car wouldn't crash?
Deleting the surface properties of a road but without deleting the road visually?

Just wondering.

[Duplode]

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.

This is a very interesting idea! It would likely still be too hard to put in practice right now (changing the surface of a road depending on the terrain code would require adding a bit of code to the road element branch, and adding code is the bane of the assembly-poking techniques we've been using lately), but I think it's the approach with the highest chance of working under the current state of the art that I've heard of in a long while.

Would anything be somewhat straightforward?

[1] Making a road wider?
[2] Changing the grip of the road to whatever it might be?
[3] Combining an icy road with the collision properties of road blocks?
[4] Adding a sharp corner to an existing tile?
[5] Deleting collision effects on a tile so that your car wouldn't crash?
[6] Deleting the surface properties of a road but without deleting the road visually?

Assuming we're limited to our current assembly-poking methods (because if we were to begin porting to C again, in principle everything is possible): #1, #3 and #6 should be straightforward. #2 doesn't seem feasible because the grip modifiers for the surfaces are on the car files, and not on the track element code. #4 wouldn't be difficult (just imitate what the game already does for splits), but the need to add code to the element branch would most likely be a blocker. #5 should be possible, but not straightforward, in particular because there are multiple types of crash (for instance, crashes against walls are handled differently from crashes against trees and other 3D objects).

(By the way, on Restunts exploring: much of the physical model construction is laid out in seg004, and in particular build_track_object. While that's a big function, the code paths are relatively straightforward, and it is moderately well documented. Once upon a time I had made good progress in documenting its caller, update_player_state, which is crucial for understanding things like collisions, but then I lost my data.)   

[Cas]

I've been working with Daniel3D on the needle-colour mod, which, I think, is the first assembly-poking mod in Stunts. What I can tell you from having tried... and succeeded is this:

My first idea, something I predicted by taking a look at the code before touching anything, was that replacing a single word, a pointer, could allow for turning what previously was a constant (the needle colour) into a variable that could be pointed at a field in the car parameter structure. This change, we later made and worked perfectly, it was super simple and I can assure you, completely stable, but most modifications we will be interesting in making cannot be solved by changing a single word. We were lucky that this was the case.

Then, as an improvement, by injecting additional code, we set sail to try something active, that would allow for independently changing the colours of the two needles. This is something we made chiefly to demonstrate that it is possible to make effective mods by assembly code injection (or to fail miserably and prove myself wrong otherwise). It worked, but we had to add some nops to fix code alignment problems and while the code hasn't failed ever so far, we will never be 100% sure that it's stable. The same thing will happen with any code injection we make this way. We do it this way because we don't have the original source code. If we had it, it'd be a million times better to work on that source instead.

The best thing we can do with what we have, that is, before one day the whole code is ported to C or before I or somebody else can come up with a whole new engine, is, instead of making tons of code-injecting mods, make a single code-injecting "hub" that accepts external plug-ins. This way, there would be a single source of potential instability. This is akin to what Forge does on Minecraft, I guess. It's no easy work, but I think it should be done before mods begin to proliferate wildly

[Daniel3D]

Or maybe rewrite the whole segment..

[mrdries]

Thanks!

Yeah, I think I understand. Poking is possible but rather challenging. So you guys are looking for a better long term approach.

It's surprising how fun it would be to be able to play around with track elements.
I mean... road blocks in a tunnel with an icy road surface. :-)

[mrdries]

Anyway, losing your code sucks. Used to program a little myself, had a backup... till it fell on the ground. Lost it all.

Best of luck to you all. It's pretty cool stuff. I'm going to download the alternative Indy colors.