Is there a way to assess what causes a crash? I like to play huge maps (256x256) and have long games where I max out research before eliminating factions. Typically this results in a lot of late game crashing. Since Yitzi, for example, is able to take saves that crash and figure out what exactly is causing it, I was wondering if there was a known way to figure out what's causing it. I haven't noticed any crash dumps or logs in the Alpha Centauri folder, so I was curious as to how one does this. Is it a simply matter of turning on the scenario editor and checking (enemy) units' actions? If it's related to the unit limit, how can I determine if I'm at the cap?

Most of my crashes for my current game have been happening after attempting to move my own units, often the same units, but sometimes entirely different ones, so I'm not sure how to determine what specifically triggers the crashes. Being as I'm already on Yitzi's latest patch, I'm doubting that patching is a solution.

Speaking of, does anyone else get an odd bug on larger/longer games where your units and enemy units will "swap bases" so to speak? It's pretty frequent in my large games; I'll either have enemy units suddenly in my base and activated during my turn as if they were my own (usually this causes a crash immediately upon them activating) but I've also had units outright swap bases. They'll suddenly be on the opposite side of the map, coming out of an enemy base (this doesn't crash, usually).

Yitzi's latest patch seems to fix this, mostly. It does still show enemy units in my bases from time to time, but while the active unit icon on the map might be an enemy scout or whatever, the HUD still shows the correct unit active (and this doesn't produce crashes). Unfortunately, should I move that active unit outside my base, it will appear on the opposite side of the map (presumably where those "swapped" units came from). The glitch itself still prevents me from accessing my units when clicking on that base, assuming they're holding position.

Currently I'm probably the only one actively modding the binaries since Yitzi does not seem to be active any more. SMAC/X doesn't provide any crash dump logs that I know of but it could be possible to step through the crash process with a debugger and figure what's going on.

There is a hard cap on the number of units after which any new units will probably cause a crash. The unit table starts at 0x952828 and the next unrelated variable starts at 0x96c85c so that leaves space for exactly 2049 units before it starts overwriting other stuff. The cap might be even lower because of other limitations - not sure.

About that base swapping bug it might be helpful if you figure out the simplest instance where it occurs and post an autosave just before AND after it happened. I don't guarantee any fixes for it though.

The game doesn't display the unit count directly, but you can estimate it by infiltrating every faction and then counting the units in each faction's command nexus. Also remember to account for any native life, you won't see any count for those either. That game lasted for so long it's possible some other variable can also be overflowing, so not sure.

Yitzi patch may have fixed some bugs, but I have no information about how it was done. There's no source code for binary fixes which makes comparing them a little bit annoying.

alien crossfire map editor: works fine until i have included the new faction in the game. then it refuses to list it when i start a new game.
i do not disturb the fixed texts, change only the variables.

Custom faction names should also be included in alphax.txt. Try to find this section:

;
; These are factions you want included in the startup list.
; These may also be chosen when a random faction is selected.
; First item is file name, second item is search key.
; These should always be the same except for debugging purposes.
;
#CUSTOMFACTIONS

Compare the syntax to the listed standard factions if it's not clear what to do.

[1] I would bet this is memory bleed.
To explain, lower level computer languages, like C++, require more care to execute because there is less inbuilt safety, e.g., if you load too many items into a linked-list stack, it will overwrite whatever was in memory above the insufficiently large stack, clobbering it. When whatever was using that bit of memory tries to retrieve its registered data, it instead retrieves the dirty data and tries to fit it into whatever it's doing with it, and fails (in unpredictable ways).

[2] Yes. The best way to fix this bug is to change your strategy. Also, if it is caused by something other than a memory bleed, then it will appear in a smaller game, thus identifying the problem.
Your hardware is too powerful for the software. If you played the game on a contemporaneous PC, it would lock-up due to the load on the processor before you reach this problem. :)