It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
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.
avatar
DDDespair: 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.
[...]
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?
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.
Post edited July 16, 2018 by induktio
avatar
induktio: 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.
Thanks for the reply. Is there any way to determine how many units are in play, like would that be reflected in the table if I used a debugger? I'm really just trying to discern why moving some units, or even skipping them, will cause a crash yet if I load an auto save from 2 turns ago, I won't get a crash from those units despite doing the same actions. I've heard of weird examples of the game trying to make a rover attack a needlejet and so on, other weird errors, but being as I'm moving units to empty spaces when this happens I don't see how that can be the case.

Just trying to figure out the cause so I can avoid/prevent it in the future. Obviously I need to stop playing large maps and long games.

As for the base swapping bug, currently I have a base in the midst of it. Check the attached image. My current move is for the "ship" at Alpha Basin, but that ship is actually a former, as shown on the left menu. The bottom bar shows my "ship" as well as a bunch of enemy units. If I move the former out of the base, it'll appear at some base halfway across the map. I suppose I can try using one of the 30-40-50 turn auto saves to try and catch it before it happens. I'll see what I can do, but as I stated before, the crash variant where those enemy units actually do show up as enemy units across all 3 of those red boxes, and the resulting crash from attempting to move them, doesn't seem to happen in Yitzi's patch.
Attachments:
untitled.jpg (440 Kb)
avatar
DDDespair: Thanks for the reply. Is there any way to determine how many units are in play, like would that be reflected in the table if I used a debugger? I'm really just trying to discern why moving some units, or even skipping them, will cause a crash yet if I load an auto save from 2 turns ago, I won't get a crash from those units despite doing the same actions. I've heard of weird examples of the game trying to make a rover attack a needlejet and so on, other weird errors, but being as I'm moving units to empty spaces when this happens I don't see how that can be the case.
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.
avatar
DDDespair: [1]… to discern why moving some units, or even skipping them, will cause a crash yet if I load an auto save from 2 turns ago, I won't get a crash from those units despite doing the same actions. …

[2] Just trying to figure out the cause so I can avoid/prevent it in the future. Obviously I need to stop playing large maps and long games.

[1] As for the base swapping bug, currently I have a base in the midst of it. Check the attached image. My current move is for the "ship" at Alpha Basin, but that ship is actually a former, as shown on the left menu. The bottom bar shows my "ship" as well as a bunch of enemy units. If I move the former out of the base, it'll appear at some base halfway across the map. I suppose I can try using one of the 30-40-50 turn auto saves to try and catch it before it happens. …
[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. :)