One of my all time favorite games of my youth was Alien Legacy. For its time (1994) the graphics, visuals, and sound were top notch for what a 13 year old had access too, and it had a solid story line as well. Aliens, planetary exploration, research, technology, lasers, mind control, it had all you could hope for. Over the years I have come back to the game a couple times, but never really got over the hump of a couple of the bugs. To be honest, I only ever remember successfully completing the game once in my youth, and I basically bombed everything into submission.

TLDR: Long standing bug fixed with simple executable in game directory available on GitHub. Game available on MyAbandonware.

The Bug

So out the gate, this game had an issue, it was disguised as a game mechanic, you cannot use the Mass Driver on high gravity worlds. The Mass Driver technology is an electromagnetic catapult capable of hurling large packets of ore from low-gravity moons or asteroids to other planets. To maintain a space station the mass driver is an essential since ore is required for most everything. At a certain point in the game, without spoiling too much, you need to maintain a rather robust space station over a specific world. Without the mass driver this task is nearly impossible. If you build your mass driver in the wrong place and saved your game, the save file would be corrupted and the game would regularly crash. This made a positive victory outcome incredibly difficult.

Well with a bit of searching and effort and a bit of AI (Claude) help, it ends up the actual issue is that the game mechanics end up dividing by zero, which causes a crash.

DOS/4GW Professional error (2001): exception 00h (divide by zero) at 180:001F75F5
Crash address (unrelocated) = 1:0002E5F5

It ends up that the code was reading a value from beyond the table it was intended to use. In some cases it would land on a usable number and others it would land on zero. If it landed on a number, it did mess up some of the multiplication on the turns needed to transmit the ore, but the game was still functional, and this odd variance was explained away by the gravity in the game docs. In the case it landed on a zero the game was basically toast.

The Fix

The fix is five in-place edits, same length as the original code, so nothing else moves.

obj1 offset	original	patched	effect
0x2E5B7	83FA04 7C3F 8D42FC 6BD00E	83EA04 83FA0F 733C 6BD20E	cmp edx,4 / jl / lea eax,[edx-4] / imul edx,eax,14 becomes sub edx,4 / cmp edx,15 / jae skip / imul edx,edx,14: an unsigned compare rejects codes below 4 and above 18, so the table can no longer be over-read. This is the actual fix.
0x2E594	89442434 8B6C2434	89C5 85ED 740D 9090	Replaces a redundant register spill with mov ebp,eax / test ebp,ebp / jz skip: a zero divisor on the first idiv contributes nothing instead of trapping.
0x2E5E8	89442434 8B6C2434	89C5 85ED 740D 9090	Same guard on the second idiv (the crash site).
0x2A89C	31FF 668BB83E950000 89D0 C1FA1F F7FF 89C2	0FB7B83E950000 92 99 85FF 7501 47 F7FF 89C2	A second function (installation cost display) has the same unchecked lookup. Rewritten with movzx/xchg/cdq to make room for test edi,edi / jnz / inc edi, so a zero divisor is treated as 1.

Don’t worry, about coding though, to make this easier for everyone to use, there is just a simple executable, ALFIX.COM, that you add to the game folder and run one time. It will make the necessary edits to the al.exe game file, and then you are all set. You can find a full writeup and code over on GitHub with options for making the fix from your modern system or from within dos. If you just want the dos executable you can also grab it here, but the GitHub is the more reliable location.

Added Bonus

So one other pain point I always had with this game was the lack of an autosave feature. Since there was going to be an automated editing tool to modify the file anyways, I figured exploring a little add-on wouldn’t be bad.

With this add-on every 200 turns the game silently writes AUTO1.SAV, AUTO2.SAV, etc (rotating, so the five most recent are kept) using the game’s existing save routine. The save files appear in the normal Load Game list and nothing changes in the UI or your own save files.

The game’s turn method ends in an epilogue. For autosave, the epilogue is replaced by a jump into a routine placed in the unused padding at the end of the code. This reads the turn counter and if it is a multiple of 200, it calls the game’s own save routine to make the autosave, and then runs the displaced epilogue. I have played a few thousand turns since adding this with no issues, so it is a welcome benefit for anyone who has played a couple hours and has a crash and realizes they had not saved recently.

Victory

So far both the fix and the added autosave appear to be working great, and I made my first victory without just killing everyone.