Malasquor: https://klei1984.github.io/max/

And the list of vanilla bugs that it has already fixed:

https://klei1984.github.io/max/defects/

klei.604: Hello Sal, if by any chance you know about any M.A.X. v1.04 defects that are not on the list yet, I would be more than happy to add them.

klei.604: I could not reproduce the multi select tool exploit to move non team member units. Maybe this was a thing in pre v1.04 M.A.X. versions. I tried in hot seat, single player turns and simultaneous turns modes.

Most weird defects are caused by running out of extended memory. In those cases heap or free store memory allocations silently fail. The compiler does not call constructors and simply assigns null to applicable variables. Usually null pointer dereferences do not crash the game as under DOS this usually points to something found in DOS 1k memory which is not being used by the game and the DOS extender itself extensively or at all.

In the Watcom C/C++ compiler the heap allocator and the stack are actually using the same XMS memory space without much protection. For non library functions the compiler emits a stack overflow test into each function prologue. If that test fails you get the stack overflow runtime error on your screenshot and the game exits.

There are a couple of cases where the game uses recursion and in those cases the call depth could go as deep as many units are in the game. In many cases huge local buffers are created on the stack too that makes things even worse.

The game also uses two hash maps that potentially use hashing algorithms that do not work properly when there are huge amounts of units present. I always wanted to prove this but I did not find the time yet. This would explain misplaced units like cones, slabs or tapes remaining after construction sites are left.

Even though save files them selves are robust, due to the above memory allocation and management short comings it could easily happen that anomalies are generated that are then saved and loaded into games.

I also observed once that two computer units entered close proximity and then one of them started to build a building that overlapped with the other unit. I could not capture this on a video unfortunately. This is defect #17 in the list and is very similar to what you described. In this case the paths manager uses an optimized path finding algorithm and when the path is walked the builders switch tasks and maybe this special use case does not check whether there is something in the way. In case of human players it is nearly impossible to instruct a unit to start building something at a location and parallel instruct another to move there as well. But the simulation in which the computer players live there are just three main steps to plan actions. Beginning of the turn, middle of the turn and end of the turn. Due to this the planning phase could easily instruct several units to move to somewhere and start to build there synchronously in which case four tile units could cause issues.

I loaded your save file and with my current setup, DOS/32A extender, 64 MB RAM for dosbox and enhanced graphics disabled the stack overflow issue does not happen and end turns progress fast.

Sarxis: I watched the graphics expansion you worked on.

Sarxis: I forgot how great the game music is!

klei1984: I made a new blog post showcasing the current status and how to configure the latest public builds to use the new graphics settings.klei1984: I also like the ambient music a lot. Brian Luzietti made an excellent job. The music in M.A.X. 2 is also very similar even though it was made by another composer. In M.A.X. 2 the music was adaptive which means that the mood or feel of the music changed depending on what happened in game.

klei1984: The game is already playable though.

klei1984: All latest GitHub Actions builds are publicly available here: https://github.com/klei1984/max/actions . After some time older builds are removed by GitHub automatically though.
The game is already playable though.