RIP to your modding attempt.

It is possible to do a jump-to-the-end-and-back kind of thing (I do this with my patching work on RoN) but initially setting it up is a bit more involved because you need to basically allocate more space to the program. If you / someone were doing a bigger patch it’d be worth doing (it gives you virtually infinite space), but for a once-off like this probably not. There are also alternative ways to implement larger changes which you could look into at that point (which may be more sensible, tbh), but since this is what I’ve used in RoN it’s the method I know best. If you have the space you can add something more-or-less completely new, but you would have to do it in a way that understands the state of the system (registers, stack, memory) at the moment your new code starts, how to change that state to do what you want (including how to have the state set up the way that individual functions need so that you can call them), and then how to restore it to the original state once you’re done so that the program can continue executing its original code (restoration is straightforward though). If you jump in to tweak something then you don’t really have to understand as much of the state or how to change it, since you don’t necessarily need to know how to e.g., pull pilot info or weapon info into registers / memory so that you can actually use/read/manipulate it; the scope of what needs to be understood is very limited so long as the change you’re making is small.

For the way the function is set up, it’s possible that this is the result of compiler and the original function was more readable in its original C++ or whatever. Since I don’t really know how the weapon data is handled so it’s hard for me to say, and I don’t have grounded experience in how compilers specifically modify code structure when doing C++ -> assembly / machine code.

Yep, large-in-torso and small-in-arms seems to be how it’s set up. Not really sure why ¯\_(ツ)_/¯

If MC2 is fussy about something it seems like there’s a good chance MC1 would be as well given how surprisingly similar they’ve looked under the hood so far. You might also be able to look at some of the existing MC1 modding – maybe somebody has some anecdotal experience with how it works given that a few people have already added weapons and stuff.

Weapons – a 6-pack a day keeps the Elementals away, but if you load up on racks, watch your back?

It looks like magic-wise, it’s a lot more doable to tweak a variable or slightly rearrange existing functions than to add something truly new? Unless you can jump all the way to the end of the file instead of looking for a cave, do whatever you like, then jump back up. Probably inefficient but this function seems like it’d only be used once a mission. Idk anything about assembly beyond a vague impression of it being horrible though.

The long chain of if() && if() seems like a really bad way to do it when they could have just set a flag or something on the weapon def.

If I’m reading it right, small guns go to arms first, big ones go to torsos first? Backwards from how most of the game’s mechs are canonically laid out but it does mean losing an arm costs less firepower and the PC games almost never have different firing arcs for arms.

Last LBX… wonder if weapons need their ammo to be in the same location, or if they can only feed from their own ammo bin. The Mechcommander 2 mech defs seem emphatic about part order. But again, out of scope.

Def very neat that you were able to sort it out.