Patching MechCommander’s “left arm bug” for fun and profit – MHLoppy

MechCommander 1 has an annoying quirk where it shoves all1 of a mech’s biggest weapons into its left arm. If your mech is kitted out with mostly/only big weapons, then losing that arm means you basically lose the mech. Normally this issue doesn’t have much impact on the outcome of a mission. Specifically targeting individual locations on a mech has pretty low accuracy (even with high-gunnery pilots) so it tends to not matter much for enemy mechs, and the chance that one of your own mechs loses specifically that arm by pure chance is pretty low — though it can happen. It’s still a weird issue though, and the times where it does happen to you can be a little rough. Well no more! After being infected by Vana with a brain worm about why the code for distributing components didn’t seem to work for big weapons, I spent a day figuring it out and now have a working fix. (Note that I’m going to be referring to the location in question as the “left arm” even though it’s not clear whether it’s actually the “left arm” or the “right arm” and the visuals of the mech are inconsistent after losing an arm. This is the location that gets blown off when you use the “fire at left arm” command as labeled in the manual, so I’m going with that.) About a month ago I noted that MechCommander 1 (or at least the MechCommander Gold copy that I have) seems to come with embedded debugging symbols of some kind, giving some useful limited insight into what the game’s code is actually doing.2 This means that we can take a gander to find out:

Which weapons count as “big” (is it just the >=9 tons rule I’ve seen tossed around?) How weapons and equipment are distributed on a mech Why the hell “big” weapons specifically all get lumped into the left arm

Sir, this Long Tom looks real big from down here — I think we can call it “big” The game exe itself is in machine code (or if first disassembled, assembly). But thanks to tools like Ghidra (yes, by the wonderful folks at the NSA) we can also translate individual functions into C-like code.

This translation won’t necessarily be accurate to the structure of the original source code, but it generally has much better at-a-glance readability than the assembly does. To start off with, here’s the function that seems to determine whether a weapon is “big” “large”, which is the classification that’s relevant to the left arm bug.

When combined with the weapon IDs in the compbas.csv file (which is packed inside the MISC.FST file)3 and other sources (including some testing of my own), we can translate this into a list of “large” and “small” weapons, where “small” is just everything that isn’t explicitly defined as “large”. IDWeaponAvailabilityTonnageSize98Rail GunExpansion only30.0Small99Light Gauss RifleExpansion only13.5Small100Light AutocannonBase game9.5Large101AutocannonBase game15.5Large102Heavy AutocannonBase game19.5Large103Light Ultra AutocannonBase game11.0Large104Gauss RifleBase game16.5Large107Light LB-X AutocannonExpansion only9.5Small108LB-X AutocannonExpansion only14.5Small109Heavy LB-X AutocannonExpansion only19.5Small110C. Light Ultra AutocannonBase game8.5Large111C. Ultra AutocannonBase game13.5Large112C. Heavy Ultra AutocannonBase game17.5Large113C. Gauss RifleBase game13.5Large116C. Light LB-X AutocannonExpansion only8.5Small117C. LB-X AutocannonExpansion only13.5Small118C. Heavy LB-X AutocannonExpansion only17.5Small120LRM RackBase game4.0Small123SRM PackBase game3.0Small125Streak SRM PackBase game5.0Small126Heavy ThunderboltExpansion only21.0Small130C. LRM

RackBase game3.0Small133C. SRM PackBase game3.0Small135C. Streak SRM PackBase game4.75Small139Large X-Pulse LaserExpansion only13Small140Laser LaserBase game9.5Small141Large ER LaserBase game11.0Large142Large Pulse LaserBase game12.0Large143LaserBase game4.0Small144Pulse LaserBase game6.0Small145PPCBase game12.0Large146ER PPCBase game15.5Large147Heavy FlamerBase game8.0Small150C. Large ER LaserBase game10.0Large151C. Large Pulse LaserBase game11.0Large152C. ER LaserBase game3.5Small153C. Pulse LaserBase game4.0Small154C. ER PPCBase game13.5Large155C. Heavy FlamerBase game7.0Small160Long Tom CannonExpansion only34.0Small (I’ve excluded several invalid weapons from the list, including a few weapons explicitly checked in the getWeaponLarge() function like the LRM 15 that I assume are just cut content and that — as far as I know — you never actually encounter in-game. The Sniper Cannon which you only get from cheating is also treated as inaccessible content for the purpose of this article) So the first and most obvious takeaway is that LRMs come in racks but SRMs come in packs, which is vital information for defeating the Clan invaders. Can you imagine if somebody called them LRM packs or SRM racks? You can’t expect the Inner Sphere to fight a war with incorrectly named equipment. The second most obvious takeaway is that every single weapon added in Desperate Measures has been accidentally classified as a “small” weapon because the getWeaponLarge() function evidently wasn’t updated to consider them, and the default output of the classification function for weapons without explicit exceptions is “small”. There’s a few classifications that are subjectively a bit borderline. The Light Autocannon is 9.5 tons and “large”, while the Large Laser is the same weight and isn’t considered “large”.

I would personally say that if the Large Laser doesn’t count as “large” then the light ACs shouldn’t either, or alternatively the Large Laser should count as Large if the light ACs do, but I don’t think it’s worth losing sleep over and there are some reasonable arguments to keep it the way it is.4 This also shows that although the “being >=9 tons makes it large” rule is close, it’s not quite accurate — even if you give a blanket exclusion of the rule for all of the incorrectly classified Desperate Measures weapons. The aforementioned Large Laser (9.5 tons) and Clan Light Ultra Autocannon (8.5 tons) break the rule. To spot-check that our baseline understanding is correct, we can subject our pilots to several friendly-fire accidents.

These results support that:

“Large” weapons do just go into the left arm (and that the paperdoll is mirrored.. or they’re all in the right arm and it’s not mirrored and the manual uses the term “left arm” wrongly). “Small” weapons don’t just go into the left arm and are more distributed across the mech. Desperate Measures weapons are being incorrectly classified as “small” weapons even though they should logically be “large”. Mech pilots should unionize.

If you look too closely you may notice that sometimes the mech being tested on appears to have its right arm destroyed, not its left arm. That seems to just be either a visual bug or an art-resources constraint (where maybe they didn’t make a separate version for each missing arm?) – the arm that’s visually missing on the mech sprite seems to vary depending on either the angle the mech is facing or whether mercury is in retrograde. And fuck, man, I don’t want to go and fix up every single bug this game must have, so we’re just going to ignore it.

One other oddity is that in the Heavy LB-X test, Beast’s health (power?) bar is acting like most of his weapons are gone even though none of them are. I thought there might be a risk that the actual in-game functionality and the weapon listings in the UI aren’t synchronized, but all four weapons seemed to fire just fine – I’m assuming the issue is just pilot health + some damage on presumably where all four weapons are located.

Maybe the side torsos have taken some structure damage from the destroyed arms, and it’s not showing on the large paperdoll (because they still have armor), only on the simplified one at the bottom of the screen?

Interesting as a detour it would be, figuring out exactly what’s going on with the paperdoll discrepancy is out of scope, so let’s move on. The distribution of weapons is not determined by nature, it is determined by code Alrighty, so how — in general — is equipment distributed to a mech’s various locations? Well, first thing is to find out where in the game code this is handled. One way to know if you’ve found the right code is to change the suspected function and see what happens in game. In this case, I changed the suspected function to distribute unknown-thing into places where unknown-thing wasn’t supposed to go. After making this change, blowing off a mech’s left arm had the effect of immediately killing the pilot.. and not destroying any of the mech’s weapons. With the left arms popped and the pilots dead, I shot the mechs on the ground to blow off their right arms as well and they still didn’t lose any weapons – a fun side effect of the change I guess. I’m still kind of curious what locations the weapons actually did go to, but couldn’t reasonably explore every single question I had along this journey so I skipped answering this (focus-firing specific locations is very slow — even against stationary targets — so it would not be entirely trivial to answer empirically).

Tracing through the assignment of equipment onto the mech in a debugger suggests that I may have shifted at least the life support and engine into the left arm with my change, which would certainly explain the loss of both meat and metal once those were out of the picture. This itself is quite interesting, because it suggests that MechCommander actually does — at least in some capacity — make use of “internal equipment” like this instead of purely relying on checking the structural condition of a given location (head / CT, etc) – which is honestly what I thought it was doing in this situation.

As trivia, these are the components that seemed to be assigned to locations on the mech during my test (I didn’t specifically track which locations received which equipment):

life support 2x hip 2x shoulder gyro sensors (presumably the specific sensor will match whatever the mech is equipped with) cockpit 2x leg actuator 2x arm actuator fusion engine

I can’t guarantee that all of this equipment actually does anything, but some non-zero amount of it does seem to have some non-zero effect on the game given the death-by-arm observed above. Anyway, diving into that more is another out of scope concern. If you want to actually solve the problem you’re trying to figure out, sometimes you have to aggressively fend off these offers of dubious quests along winding paths amidst the forest of knowledge. Here’s the top of the function that seems to be handling equipment distribution. I’m not going to run through the whole thing because it’s a couple hundred lines long, I don’t understand everything that it does, and doing so would be yet another out-of-scope detour.

Relevant to us is the check at the top where param_1 is compared against 100. In the base game, weapons start at ID 100,5 which gives some insight to speculate that the top of the function handles the placement of non-weapon equipment (like the stuff listed above). That theory is supported by the available evidence, so it’s probably at least mostly correct, but it’s out of scope to exhaustively confirm it. The part we really care about is how this function handles placement of weapons: equipment with an ID of >=100.

Thanks to the debugging symbols giving us some function names, most of the high-level details are pretty self-evident if you make some assumptions about what the called functions do:

Check if a weapon is large or small. If small, assign to locations 2-5 based on an algorithm that checks for small weapons at those locations. If large, assign to locations 2-5 based on an algorithm that checks for large weapons at those locations.