Btw, I recently did my first patches with ghidra. Is there any way to avoid jumping into a code cave by shifting all the instructions up then updating any statements referring to those memory locations? Seems like it should be simple enoigh in theory, but I didn't find an implementation on a cursory search. Could probably code up a plugin pretty easily.
It's basically re-linking the executable. Way too easy to shoot foot - miss one reference and things break in a spectacular, or, worse, subtle fashion. Which means: you definitely need to know where all the references are and what they point to.
References are under no obligation to be presented in a sensible, decompiler-friendly way.
Which is why "jump out into the patch, jump back in" is such a staple of patching. The other way is the hard way, full of pitfalls and potential issues.
Great writeup! Vividly remember this being a thing especially in multiplayer. What was that janky match matching service, MSN something?
Also a really underrated game, the mechanics (line of sight over the horizon stuff) and isometric graphics were pretty cool for the time and it had a well developed story/campaign mode.
As far as I know even DH is still only modifying the game at the data files level, not the "actual code" level (with the exclusion of the resolution edits).
So probably the fix for the left arm bug will work fine for DH or any of RizZen's other campaigns, but because of the new weapons I wouldn't bother using the weapon classification fix unless you revise the fix to match the modded weapons (which is unlikely to be worth the effort tbh).
I never played this game! I didn't realize there was a RTS after Crescent Hawk's revenge. I'm looking at the MC2 source code now... it looks like there is a Linux port, meaning could probably get it working for Apple using Fable 5, AI haters, I will challenge you to a batchall.
I've gotten older games running just fine with Whisky/game porting toolkit. Sometimes you also need something to fix old DirectX issues like dgvoodoo2.
If you want to make it even easier you could try loading it via Heroic Launcher which supports game porting toolkit.
(Do note: whisky.app is out of development now that the Dev quit to do being pestered by the community so much)
I wonder if the board game materials have rules or guidance about where equipment goes? I dunno how close the computer games stick to the board game materials though.
The board game has extensive rules on mech design, but for weapons, it's just wherever they'll fit. Some of the built-in hardware has fixed locations: cockpit, life support, sensors go in the head; engines go in the center torso (with light and xtralight fusion engines spilling out into the side torsos as well), arm and hand actuators go in the arms, and hip, leg, and foot actuators go in the legs. You can see this in the critical slot section in a record sheet: https://i.redd.it/jt3p2f1v14gf1.jpeg
This one definitely deviates from tabletop: pretty much everything except the smallest weapons have an integral tonnage, and the weapons themselves don't line up directly with their tabletop versions.
The newer games tend to be absolutely consistent with the mech design rules in terms of what weapons are available, and their weights and sizes, such that board game designs are legal in the game (and usually the state you get the mechs in before you customize them), and customized mechs are legal board game designs. They tend to limit the customization by doing things like having mechs have predefined hardpoints that limit what types/sizes of guns can go where, because otherwise you just end up with every mech being identical, with maximum armor and the rest of the tonnage being spent on whatever happens to be the most optimal weapon.
That damned Vulture in the base in the second demo mission was rough. I hit a serious wall in the campaign in Op1M5 when you had to defend the farm. It’s almost a shame that MC2 is so easy in comparison
I have forever been confused by 'left' and 'right'. It takes me a few seconds of deliberate thinking to get it right.
So in one of my first piece of software that I wrote for real money I had two functions. One called create_scene_left(), the other called create_scene_rght().
I was very pleased with myself for sneaking in creating_a_scene, but the left and right versions did the opposite of what their names indicated. Users of the software had no problems, but I am sure it would confuse any maintainer.
It even took me an year to even realize that the names were wrong.
In my experience it was not that hard (as far as 25 year old games go) to get running on a Windows 10 system, which is what I played MC1 on and made Mantis on. I wrote down the steps I used[1] but there are alternative approaches using e.g., dgVoodoo which are not hard to find if you search for them. As far as I'm aware there's no need to use a retro system to reliably run MC1.
If you are for some reason intent on playing MC1 on a retro rather than modern system, Mantis is just a glorified automated hex editor and you can byte-for-byte replicate what it does to the game exe by copy-pasting the hex edits which are already outlined in the OP (for the bug fixes) and elsewhere (for the rest of what Mantis does).
I was just noticing that there was a whole lot of work fixing these minor bugs, and then went all lazy writing the patch... Or maybe I was spoiled by decades of scene patches, cracks and tiny demos with chiptune music and funny graphics.
There is a certain irony I guess, but in my eyes the "patch" is the hex edits, not Mantis. If I had published these fixes but never gone back and made Mantis, I would still have considered the work "complete".
Mantis was made nearly one month after the actual patching was done partly as an excuse to test out a few things like the build settings available in newer .NET releases (e.g., framework-dependent vs self-contained build with trimming, JIT vs AoT vs ReadyToRun compilation). It wasn't really laziness to target .NET 8 because exploring those build options made it take longer than just building using e.g., .NET Framework since Mantis is so basic. As I said, glorified automated hex editor.
34 comments
[ 208 ms ] story [ 1848 ms ] threadJust non-disassembled function or unidentified struct would ruin your plans…
References are under no obligation to be presented in a sensible, decompiler-friendly way.
Which is why "jump out into the patch, jump back in" is such a staple of patching. The other way is the hard way, full of pitfalls and potential issues.
Also a really underrated game, the mechanics (line of sight over the horizon stuff) and isometric graphics were pretty cool for the time and it had a well developed story/campaign mode.
(Assuming they didn't fix it themselves, it is a pretty big overhaul to MC1)
Lovely stuff. Always a joy to see anything MechWarrior related end up here on HN.
So probably the fix for the left arm bug will work fine for DH or any of RizZen's other campaigns, but because of the new weapons I wouldn't bother using the weapon classification fix unless you revise the fix to match the modded weapons (which is unlikely to be worth the effort tbh).
I've gotten older games running just fine with Whisky/game porting toolkit. Sometimes you also need something to fix old DirectX issues like dgvoodoo2.
If you want to make it even easier you could try loading it via Heroic Launcher which supports game porting toolkit.
(Do note: whisky.app is out of development now that the Dev quit to do being pestered by the community so much)
This one definitely deviates from tabletop: pretty much everything except the smallest weapons have an integral tonnage, and the weapons themselves don't line up directly with their tabletop versions.
The newer games tend to be absolutely consistent with the mech design rules in terms of what weapons are available, and their weights and sizes, such that board game designs are legal in the game (and usually the state you get the mechs in before you customize them), and customized mechs are legal board game designs. They tend to limit the customization by doing things like having mechs have predefined hardpoints that limit what types/sizes of guns can go where, because otherwise you just end up with every mech being identical, with maximum armor and the rest of the tonnage being spent on whatever happens to be the most optimal weapon.
Came here excited that MeshCommander is maintained again.
[1] https://github.com/Ylianst/MeshCommander
https://www.youtube.com/watch?v=8CVvOWlfl1U
(original Mechcommander is still the best of the series, even if mission 5 broke my soul for awhile).
So in one of my first piece of software that I wrote for real money I had two functions. One called create_scene_left(), the other called create_scene_rght().
I was very pleased with myself for sneaking in creating_a_scene, but the left and right versions did the opposite of what their names indicated. Users of the software had no problems, but I am sure it would confuse any maintainer.
It even took me an year to even realize that the names were wrong.
So, it won't work on the same retro PC as the game.
If you are for some reason intent on playing MC1 on a retro rather than modern system, Mantis is just a glorified automated hex editor and you can byte-for-byte replicate what it does to the game exe by copy-pasting the hex edits which are already outlined in the OP (for the bug fixes) and elsewhere (for the rest of what Mantis does).
---
[1] https://mhloppy.com/2026/04/mechcommander-windows-10-without...
Mantis was made nearly one month after the actual patching was done partly as an excuse to test out a few things like the build settings available in newer .NET releases (e.g., framework-dependent vs self-contained build with trimming, JIT vs AoT vs ReadyToRun compilation). It wasn't really laziness to target .NET 8 because exploring those build options made it take longer than just building using e.g., .NET Framework since Mantis is so basic. As I said, glorified automated hex editor.