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.
Ahh! Sorry for the extremely late reply. At the same time - thank you for your detailed reply. Defect#17 seems like something I have seen and mean. Very interesting to see inside the A.I. soul like this.
I just checked again with the multiselect and made 2 small videos showing it. The key to make it actually work is to hold the shift key and select the enemy unit first, then yours, click again on yours and leave the shift button unpressed.
Its a weird scheme, and you will see, in the first video I had to find out how to do it again. The second video shows it more clearly.
I downloaded the latest GOG version I had, setup_m.a.x._1.04_(21516).exe, and its on MAX 1.04, just to be sure its still there. You can't move an unit that is on an active construction job or similar. Also the unit you want to move needs to have speed left, otherwise it won't work.
Here are the Youtube links showing it.
https://youtu.be/Bd9c5pk_wrQ?t=23 https://youtu.be/Bd9c5pk_wrQ How is the progress coming along? I am usually checking the roadmap and love every piece of new progress.
Thanks for the hard work!
Best,
sal4
Edit:
Ahahah, of course it had to crash in the first video :D
