MTM2.com

I have to find that conversation that I had with Cale...

Anyway. I have started trying to get this to work (to have different back tires and front tires) and so far I have hit a snag. It seems that the game decides to crash if the standard trucks don't have the new wheels (even if the trucks aren't supposed to be used in the race, I am starting on my own with a tweaked truck).

I have some ideas how to fix this... I'm first trying to implement the "easier" ones and not the ghetto roundabout one (aka the noob programmer way, lol).

Well I got it to work... the noob way. lol

What was the other one Cale? A different set of axle bars? Can you show me some pics of what you mean exactly?

My main issue right now is to find a way to keep the new trucks compatible with the unpatched version of the game (right now they would work only with comm patch).

Edit: I probably have a solution for this.

If you can briefly summarize how the tire loading code works, I might be able to offer some suggestions on how to make it more seamless. Without that information, I can at least mention that tracks have a string and two integers that are entirely ignored by the game (Locale and Latitude/Longitude) that could be interpreted any way we want, and perhaps the truck files may have some unused data fields as well that you could use? That way the patch would be able to pick up on the new tires and the old version would just ignore them.

This picture of Grave Digger should illustrate it well. The truck has both an upper and a lower set of silver axle bars that go from the axle to the chassis (4-link suspension = 4 links per axle). You can see the driveshaft just behind the lower set of silver bars.



It's not a be-all, end-all thing for trucks, but it would make certain trucks look at little more complete.

Also I should add - different tires is a HUGE improvement! There's a lot I can do with that!

I figured that's what you were asking but I wanted to make sure.

How it reads:

1. A simple IF statement that looks at the .TRK file. If it detects a number 2 (in MTM2 Truckname) it switches to the MTM2 truck reading algorithm. If it doesn't, it switches to MTM1 reading algorithm.
2. It reads the values from the trk file, among them the base name of the wheel .bin name. Then inside the code it takes that base name and applies it to 16L.bin, 16R.bin etc and it just copies L and R for front axle and rear axle.
3. It further reads the location of the tires and sends them using pointers to the rendering engine (and it is clearly defined as left front, right front, rear left and rear right).

What I did:

I basically copy pasted the code from above into my own big IF statement where if it reads MTM2.1 Truckname it switches to my copy/pasted code that enables 4 different tires. If it doesn't detect 2.1 it switches to the default MTM2 code. So new trucks will have to be made using default 16L.bin and 16R.bin (and add 16RL.bin and 16RR.bin or whatever name I chose for the enhanced trucks) to keep it working with vanilla.

What I don't like about this is that the block of code that deals with reading the .bin files and then sends them to the rendering engine has like 40 lines of code and I basically added another 40 lines of code on top of that saying the same thing. It just looks ugly from a nerdy OCD programmer point of view.

Man this axle bar is incredibly frustrating. I am unable to figure out how to raise the bar at the connection with the axles. I can raise it at the connection with the undercarriage (and it looks just great) but for the life of me I can't do it at the axles and I've no clue why. It's obviously hardcoded into the axles somehow but i seem to find it impossible to find the freaking variables.

Only took me like... forever. 5 hours of finding where the code was hidden and then 30min to get it to work

Freakin' AWESOME. Might have to go back to edit the trucks now lol. Looks fantastic.

Looking pretty sweet. I guess I can't offer much about the code as I probably would've done it a similar way, at least for the initial work. Although if it hurts the OCD senses, perhaps the routine can be rewritten in the future. If it's mostly duplicated code, you might be able to use the same 40-line block but with a few if statements added to cover your new cases. If the object rendering data is stored in a struct or class (likely, I would think), you could add a new flag like bPatchVersion so that the rendering routine knows which branches to take.

Makes sense. I'll keep it as is for now and will look into it in the future.