<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments for MHLoppy	</title>
	<atom:link href="https://mhloppy.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>https://mhloppy.com</link>
	<description>Data-driven decision making is the only way to go</description>
	<lastBuildDate>Thu, 16 Jul 2026 13:06:12 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.1</generator>
	<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by GypsyFromTheSatelliteOfLove		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45446</link>

		<dc:creator><![CDATA[GypsyFromTheSatelliteOfLove]]></dc:creator>
		<pubDate>Thu, 16 Jul 2026 13:06:12 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-45446</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45392&quot;&gt;MHLoppy&lt;/a&gt;.

No prob hehe the fact that you got as far as you did is already hero stuff :)]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45392">MHLoppy</a>.</p>
<p>No prob hehe the fact that you got as far as you did is already hero stuff 🙂</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by MHLoppy		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45392</link>

		<dc:creator><![CDATA[MHLoppy]]></dc:creator>
		<pubDate>Thu, 16 Jul 2026 02:00:16 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-45392</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45388&quot;&gt;GypsyFromTheSatelliteOfLove&lt;/a&gt;.

Sure, I&#039;ll let you know if I figure out the .gmm files, but just to be straightforward that I think it&#039;s extremely unlikely that I will. I think I&#039;d probably have to reverse engineer a huge chunk of the game to do it (and even then, maybe the game exe doesn&#039;t explain the format of all of its file types!), but the time and effort -- for someone of my limited skill level -- is hard to justify against an existing backlog of other projects.

One of the reasons I could do the change in the article is because I got pretty lucky and the thing I wanted to fix involved a relatively isolated system which was relatively easy to understand. One of the other gameplay bugs that I wanted to fix (LB-X damage) I&#039;ve spent nearly as much time and effort on but have made basically no progress on fixing because the systems involved are larger and interconnected, and they&#039;re individually much harder to understand (let alone when having to combine multiple bits together to get the full picture). I expect the code required to understand .gmm files -- if it&#039;s explained by the game code rather than some separate tool which we don&#039;t have -- is probably more like that than like the simpler weapon distribution code :&#039;(]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45388">GypsyFromTheSatelliteOfLove</a>.</p>
<p>Sure, I&#8217;ll let you know if I figure out the .gmm files, but just to be straightforward that I think it&#8217;s extremely unlikely that I will. I think I&#8217;d probably have to reverse engineer a huge chunk of the game to do it (and even then, maybe the game exe doesn&#8217;t explain the format of all of its file types!), but the time and effort &#8212; for someone of my limited skill level &#8212; is hard to justify against an existing backlog of other projects.</p>
<p>One of the reasons I could do the change in the article is because I got pretty lucky and the thing I wanted to fix involved a relatively isolated system which was relatively easy to understand. One of the other gameplay bugs that I wanted to fix (LB-X damage) I&#8217;ve spent nearly as much time and effort on but have made basically no progress on fixing because the systems involved are larger and interconnected, and they&#8217;re individually much harder to understand (let alone when having to combine multiple bits together to get the full picture). I expect the code required to understand .gmm files &#8212; if it&#8217;s explained by the game code rather than some separate tool which we don&#8217;t have &#8212; is probably more like that than like the simpler weapon distribution code :'(</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by GypsyFromTheSatelliteOfLove		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45389</link>

		<dc:creator><![CDATA[GypsyFromTheSatelliteOfLove]]></dc:creator>
		<pubDate>Thu, 16 Jul 2026 01:09:52 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-45389</guid>

					<description><![CDATA[Oh and i am defo not the sort to abuse the poor LLMs :)... i am very much in the handmade camp (just bad at it lol) but welcome coders who would take that route since i think that is the future for sure... but seeing efforts like yours is really inspiring :)]]></description>
			<content:encoded><![CDATA[<p>Oh and i am defo not the sort to abuse the poor LLMs :)&#8230; i am very much in the handmade camp (just bad at it lol) but welcome coders who would take that route since i think that is the future for sure&#8230; but seeing efforts like yours is really inspiring 🙂</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by GypsyFromTheSatelliteOfLove		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45388</link>

		<dc:creator><![CDATA[GypsyFromTheSatelliteOfLove]]></dc:creator>
		<pubDate>Thu, 16 Jul 2026 01:06:37 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-45388</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45384&quot;&gt;MHLoppy&lt;/a&gt;.

Much better than me for sure! 

True about writing game logic... but i think for a modern map and campaign editor, the gmm file is the last one needed? Maybe? But from what ive seen, its the last one IronArthur didnt fully decode? 

I think if the gmm files (which i think is the data for the hierarchical astar they used? Like the rooms and doors info?) I think an editor would be more realistic? 

But anyway, congrats on this work, its really good! If by any chance you get to peak into the gmm (or any other game logic from the data), please let us know?]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45384">MHLoppy</a>.</p>
<p>Much better than me for sure! </p>
<p>True about writing game logic&#8230; but i think for a modern map and campaign editor, the gmm file is the last one needed? Maybe? But from what ive seen, its the last one IronArthur didnt fully decode? </p>
<p>I think if the gmm files (which i think is the data for the hierarchical astar they used? Like the rooms and doors info?) I think an editor would be more realistic? </p>
<p>But anyway, congrats on this work, its really good! If by any chance you get to peak into the gmm (or any other game logic from the data), please let us know?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by MHLoppy		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45384</link>

		<dc:creator><![CDATA[MHLoppy]]></dc:creator>
		<pubDate>Wed, 15 Jul 2026 23:25:42 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-45384</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45362&quot;&gt;GypsyFromTheSatelliteOfLove&lt;/a&gt;.

I think I saw the original MCUnity project briefly a couple months ago but didn&#039;t look that hard at it.

As far as I understand, it (and your successor) are so far all focused on assets? So from a mess-around-with-it perspective it&#039;s cool, but you&#039;d still need to recreate the game code to have something resembling MC1 in more than just visuals. I guess you could theoretically not attempt to re-create the logic and just roll your own but then I&#039;m not really sure what the end goal would be for the project then.

I unfortunately don&#039;t have any advice to offer on your .gmm files issue. I&#039;m also probably not as good at this as you think I am :P (I&#039;ve never even solved a simple crackme ( https://en.wikipedia.org/wiki/Crackme ) lol), but good luck with your efforts! I imagine the few online MC/BT communities would be interested in hearing about it, and I know there&#039;s been recent interest in abusing LLMs to work on MC2.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45362">GypsyFromTheSatelliteOfLove</a>.</p>
<p>I think I saw the original MCUnity project briefly a couple months ago but didn&#8217;t look that hard at it.</p>
<p>As far as I understand, it (and your successor) are so far all focused on assets? So from a mess-around-with-it perspective it&#8217;s cool, but you&#8217;d still need to recreate the game code to have something resembling MC1 in more than just visuals. I guess you could theoretically not attempt to re-create the logic and just roll your own but then I&#8217;m not really sure what the end goal would be for the project then.</p>
<p>I unfortunately don&#8217;t have any advice to offer on your .gmm files issue. I&#8217;m also probably not as good at this as you think I am 😛 (I&#8217;ve never even solved a simple crackme ( <a href="https://en.wikipedia.org/wiki/Crackme" rel="nofollow ugc">https://en.wikipedia.org/wiki/Crackme</a> ) lol), but good luck with your efforts! I imagine the few online MC/BT communities would be interested in hearing about it, and I know there&#8217;s been recent interest in abusing LLMs to work on MC2.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by GypsyFromTheSatelliteOfLove		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-45362</link>

		<dc:creator><![CDATA[GypsyFromTheSatelliteOfLove]]></dc:creator>
		<pubDate>Wed, 15 Jul 2026 20:02:55 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-45362</guid>

					<description><![CDATA[Yo! This is awesome! Have you by chance checkes out ironarthur&#039;s work? He got pretty far decoding the source code and game files as well! 

Ive been digging around his work and some of the binaries in mcg too (but nowhere close to this level of skill!). Atm, i am trying to continue ironarthur&#039;s work, but have reached a wall with decoding the .gmm files used for creating maps in the game. But between me and iron, we have managed to get the assets out of the game pak files and into unity... here&#039;s the very janky hacked together stuff we figured out :)

https://github.com/GypsyFromTheSatelliteofLove/MCUnityContinued]]></description>
			<content:encoded><![CDATA[<p>Yo! This is awesome! Have you by chance checkes out ironarthur&#8217;s work? He got pretty far decoding the source code and game files as well! </p>
<p>Ive been digging around his work and some of the binaries in mcg too (but nowhere close to this level of skill!). Atm, i am trying to continue ironarthur&#8217;s work, but have reached a wall with decoding the .gmm files used for creating maps in the game. But between me and iron, we have managed to get the assets out of the game pak files and into unity&#8230; here&#8217;s the very janky hacked together stuff we figured out 🙂</p>
<p><a href="https://github.com/GypsyFromTheSatelliteofLove/MCUnityContinued" rel="nofollow ugc">https://github.com/GypsyFromTheSatelliteofLove/MCUnityContinued</a></p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by Sardonic		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-44903</link>

		<dc:creator><![CDATA[Sardonic]]></dc:creator>
		<pubDate>Thu, 09 Jul 2026 14:44:37 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-44903</guid>

					<description><![CDATA[Man, putting all the big weapons in the left arm?  That&#039;s just sinister]]></description>
			<content:encoded><![CDATA[<p>Man, putting all the big weapons in the left arm?  That&#8217;s just sinister</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Bonus: A Quick Look at Next-gen Image Formats (JPEG XL etc) by MHLoppy		</title>
		<link>https://mhloppy.com/2023/01/2022-pc-nas-upgrade-bonus-next-gen-image-formats-jpeg-xl-avif/#comment-41851</link>

		<dc:creator><![CDATA[MHLoppy]]></dc:creator>
		<pubDate>Sat, 16 May 2026 12:23:17 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=2534#comment-41851</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://mhloppy.com/2023/01/2022-pc-nas-upgrade-bonus-next-gen-image-formats-jpeg-xl-avif/#comment-41848&quot;&gt;lorenamer&lt;/a&gt;.

I imagine if there&#039;s a coordinated, sustained push by &quot;all&quot; of big tech, one of the next-gen formats might be able to make pretty good inroads if they&#039;re aggressive enough about it. I&#039;m not sure what it would take for them to do it though, particularly because even now some people oppose the use of WebP even though support for it has become pretty good; pushing a new format aggressively would annoy plenty of people who just want &quot;it&quot; to keep working as-is without having to worry if X program or service supports Y format.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://mhloppy.com/2023/01/2022-pc-nas-upgrade-bonus-next-gen-image-formats-jpeg-xl-avif/#comment-41848">lorenamer</a>.</p>
<p>I imagine if there&#8217;s a coordinated, sustained push by &#8220;all&#8221; of big tech, one of the next-gen formats might be able to make pretty good inroads if they&#8217;re aggressive enough about it. I&#8217;m not sure what it would take for them to do it though, particularly because even now some people oppose the use of WebP even though support for it has become pretty good; pushing a new format aggressively would annoy plenty of people who just want &#8220;it&#8221; to keep working as-is without having to worry if X program or service supports Y format.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Bonus: A Quick Look at Next-gen Image Formats (JPEG XL etc) by lorenamer		</title>
		<link>https://mhloppy.com/2023/01/2022-pc-nas-upgrade-bonus-next-gen-image-formats-jpeg-xl-avif/#comment-41848</link>

		<dc:creator><![CDATA[lorenamer]]></dc:creator>
		<pubDate>Sat, 16 May 2026 11:03:59 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=2534#comment-41848</guid>

					<description><![CDATA[30 years of JPEG is wild when you think about how much everything else has evolved in tech. I remember being surprised that JPEG 2000 never really took off despite being positioned as the successor—kind of confirms what you said about it not being a clear upgrade in practice. Makes me wonder what format will finally push JPEG into retirement.]]></description>
			<content:encoded><![CDATA[<p>30 years of JPEG is wild when you think about how much everything else has evolved in tech. I remember being surprised that JPEG 2000 never really took off despite being positioned as the successor—kind of confirms what you said about it not being a clear upgrade in practice. Makes me wonder what format will finally push JPEG into retirement.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Patching MechCommander&#8217;s &#8220;left arm bug&#8221; for fun and profit by MHLoppy		</title>
		<link>https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-41264</link>

		<dc:creator><![CDATA[MHLoppy]]></dc:creator>
		<pubDate>Wed, 06 May 2026 14:08:00 +0000</pubDate>
		<guid isPermaLink="false">https://mhloppy.com/?p=3954#comment-41264</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-41250&quot;&gt;Vana&lt;/a&gt;.

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&#039;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&#039;ve used in RoN it&#039;s the method I know best. If you have the space you &lt;em&gt;can&lt;/em&gt; 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&#039;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&#039;t really have to understand as much of the state or how to change it, since you don&#039;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&#039;re making is small.

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

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

If MC2 is fussy about something it seems like there&#039;s a good chance MC1 would be as well given how surprisingly similar they&#039;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.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://mhloppy.com/2026/05/mechcommander-weapons-left-arm-bug-fix/#comment-41250">Vana</a>.</p>
<p>RIP to your modding attempt.</p>
<p>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&#8217;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&#8217;ve used in RoN it&#8217;s the method I know best. If you have the space you <em>can</em> 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&#8217;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&#8217;t really have to understand as much of the state or how to change it, since you don&#8217;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&#8217;re making is small.</p>
<p>For the way the function is set up, it&#8217;s <em>possible</em> that this is the result of compiler and the original function was more readable in its original C++ or whatever. Since I don&#8217;t really know how the weapon data is handled so it&#8217;s hard for me to say, and I don&#8217;t have grounded experience in how compilers specifically modify code structure when doing C++ -> assembly / machine code.</p>
<p>Yep, large-in-torso and small-in-arms seems to be how it&#8217;s set up. Not really sure why ¯\_(ツ)_/¯</p>
<p>If MC2 is fussy about something it seems like there&#8217;s a good chance MC1 would be as well given how surprisingly similar they&#8217;ve looked under the hood so far. You might also be able to look at some of the existing MC1 modding &#8211; maybe somebody has some anecdotal experience with how it works given that a few people have already added weapons and stuff.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
