AAML Crashes after combat, turn 1117

[baz08]

If it helps, i'm playing as Federation and the combat i end up in is against the Cardassians

[Flocke]

Helping would when you can name the exact installed AIO version as well as provide some working saves of preceding turns in case you have some.

Edit: Opening the file with latest UE dev version, I get an error that easily explains why the game crashes on load:

Code: Select all

Error: game11.sav: Index exceeds max number of shipname groups of 62.

corrupted_aaml_game11.jpg (70.67 KiB) Viewed 1050 times

I will see how to fix this. At least I should get UE fixed to load the map but disregard the error, so one can remove some ships.

Further there are two system with the bugged worker update flag set, that we already have found to cause issues:

Code: Select all

Warning: in SystemEntry: Federation Aucdet system at 44.19 has the bugged worker update flag set. (unset)
Warning: in SystemEntry: Federation Allanor system at 37.23 has the bugged worker update flag set. (unset)

Edit2: Fixed this and a ton of other issues in my current UE build, that were not related to the save. Will keep analysing...

[thunderchero]

Helping would when you can name the exact installed AIO version as well as provide some working saves of preceding turns in case you have some.

AIO version 2.0.0 or very early 2.0.1 beta before 4:3 maps

[baz08]

I'll happily give any information i can.

All in one version was the beta 2.0.1 from this link viewtopic.php?p=56455#p56455

I don't have other saves from recent turns preceding the crashes, most other saves are from over 1 week prior, which i can share if needed.

bugged worker update flag set, is there a patch fix for this?

[Spocks-cuddly-tribble]

Both crashes are related to GTForceList. Original after battle/AI codes, fixed save from thunderchero during AI process turn.

GTForceList and/or 'working' file should be corrupted (maybe even GShiplist).

EDIT: IIRC TFs for battles are read from one of the two pointer lists in sector.lst+38/+3C viewtopic.php?p=58134#p58134

Fixed save from thunderchero was reported to show phantom duplicates of ships (hence error earlier -> bug/deviation of 'working' TFs?).

Shipname index error (shipname.dat?) indicates either saved game corruption or bug in shipname patches and/or shipname.bin -> we'd need to check trek.exe and shipname.bin.

UE fixed save from thunderchero should have corrected the worker marker in systInfo.

[thunderchero]

You can try to reset all AI files by switching player empire and back (in the fixed save game).

But it is a bit work since we don't know the affected AI empire(s): viewtopic.php?p=57851#p57851

after switching all races I get a crash when selecting these 2 systems (going to build screen)

select.jpg (27.9 KiB) Viewed 1005 times

with this crash log
File: ..\..\source\game\solarapi.c, Line: 5279, query != NULL
on original saved game I am able to enter build screen of those system

[Spocks-cuddly-tribble]

after switching all races I get a crash when selecting these 2 systems (going to build screen) with this crash log
File: ..\..\source\game\solarapi.c, Line: 5279, query != NULL

That's why you recently updated most mods with this patch (in my suggestions for Dafedz):

Auto-fix_Line_5279_when_loading_single_player_saves.patch viewtopic.php?p=57851#p57851 (see edit notes)

So you don't need UE to fix saved game after switching player empire with my patch or after other issues leading to this bug.

[thunderchero]

after switching all races I get a crash when selecting these 2 systems (going to build screen) with this crash log
File: ..\..\source\game\solarapi.c, Line: 5279, query != NULL

That's why you recently updated most mods with this patch (in my suggestions for Dafedz):

Auto-fix_Line_5279_when_loading_single_player_saves.patch viewtopic.php?p=57851#p57851

So you don't need UE to fix saved game after switching player empire with my patch or after other issues leading to this bug.

changing 75 -> EB fixed issue with system, but still crashes after combat during turn processing

but something is UE integrity check I just noticed
Found taskForceId -32767

why is ID negative? Did we hit a file limit?

[Spocks-cuddly-tribble]

Found taskForceId -32767

why is ID negative? Did we hit a file limit?

I told you guys the GTForceList (& working) needs to be checked and repaired.

This number doesn't look like a temp ID, but rather like a bug: viewtopic.php?p=55981#p55981

You need to find problematic TFs in all files and remove (or fix) them via new UE saved game editor.

[Flocke]

Found taskForceId -32767

why is ID negative? Did we hit a file limit?

I noticed that one as well, after I fixed some other issues in current development build. Looks like an unsigned short vlaue issue. I'm at it, just need to make sure my UE build is working fine again and am checking issues one by one.

The stbof.res shipname groups btw now load fine again, above issue I posted was related to some broken code mess I had to fix.

One other bug I found with the save so far, is that in Caldonia the strcInfo entry of the isolinear scanners is doubled.

[Spocks-cuddly-tribble]

Looks like an unsigned short vlaue issue.

Question If one removes all ships from a task force (redeploy, destroyed, owner change) i.e. dissolves a fleet:
Will BotF reuse the unused IDs for the next newly generated task force
If not (cf AI Tasks) then you need less than 6 new TFs per turn/empire (AI redeploy!) to hit the signet/short limit in this saved game.

EDIT: 5B2350 TForceCntr -> inc for next TF ID -> no reuse of idle IDs

UE would need to change all TF IDs (+ all references to them) to reuse unused IDs and adjust TForceCntr to fix this saved game.

One other bug I found with the save so far, is that in Caldonia the strcInfo entry of the isolinear scanners is doubled.

Might be a vanilla AI bug with scanners (not upgraded but upgrade added as extra structure).
After system takeover a player can upgrade second scanner so you have two times the same (I'd scrap one in this case, but one might do for the lols?).

[Flocke]

Question If one removes all ships from a task force (redeploy, destroyed, owner change) i.e. dissolves a fleet:
Will BotF reuse the unused IDs for the next newly generated task force

Ofc not. If they cared for it, they had used integers for the id. But obviously noone by the time expected the game to ever be played for so long.

Instead there happens a value overflow and they become negative like it was TEMPORARY task force ids:
viewtopic.php?p=55981#p55981

This case the max used unsigned taskforce id written to GTForceList is 0x8120 = 33056 = -32480.
Negative numbers start from 0x8000 = -32768 and are counted upwards.

I am not sure how BotF deals with the taskforces when they become negative.It might even be the game then proceeds to automatically assign new taskforce ids each turn, given they are considered temporary. But it might also be they work fine unless you reload the game.

From experience however, as soon as you face that barrier, pretty soon the game becomes broken.

UE would need to change all TF IDs (+ all references to them) to reuse unused IDs and adjust TForceCntr to fix this saved game.

Yep, that is what I'll likely do. And it actually should not be much of a problem, since I already pretty well analysed and implemented to remove all existing taskforces and add new ones. So most of the code is already there. Issues arise when the taskforce id references are messed up too, or even shared by multiple taskforces:
viewtopic.php?p=56155#p56155

To fix the issue for trek.exe we best hook and patch the id generator to search a free id slot. That shouldn't be hard to implement and likely will fix many of the late turn crashes.

This time the given game save has 484 taskforces in service. So with 32767 regular slots there is plenty free ones available.

Might be a vanilla AI bug with scanners (not upgraded but upgrade added as extra structure).
After system takeover a player can upgrade second scanner so you have two times the same (I'd scrap one in this case, but one might do for the lols?).

I remember that one. I considered to scrap one, but since for mods I can't rely on the id and neither the scanner building group, and given it doesn't cause much of an issue, I think I'll just keep it.

[Spocks-cuddly-tribble]

If they cared for it, they had used integers for the id.

Increasing index range was no option at the time - given the RAM issues they tried to address with hotfix patches.
They could have implemented reuse to reduce RAM (core files bloated with 95% unused entries), many of the files QD analysed use dynamic sorting/allocation. In this game: 108 * (32767-484) * 2 (base + working file) = about 7 MB wasted for empty TFs (in 1999!).
But they didn't even care to fix up to 1GB RAM wastage in tactical combat with BotF patches 1.0.1 and 1.0.2.

To fix the issue for trek.exe we best hook and patch the id generator to search a free id slot. That shouldn't be hard to implement

Yes could be done in a realistic/small project (if this was an important/common issue). Asm or hooking makes no big difference in this case.
But, as you say, adapting given UE features to fix saved games is faster and good enough.

and likely will fix many of the late turn crashes.

Not that many, only repeatable without crash log (but with clear windows event logs) from long time pet-universe games against weak AI mods (turn lag would kill interesting/good games).

[Flocke]

Increasing index range was no option at the time - given the RAM issues they tried to address with hotfix patches.

Don't tell me that they allocate a data array to map all the taskforces by array index!

Yes could be done in a realistic/small project (if this was an important/common issue). Asm or hooking makes no big difference in this case.

Without question it is a common issue. I have seen broken saves like that a few times and it is sure to break the game rather soon than later. The player and AI just need to redeploy ships often enough and the counter raises amazingly fast.

Further, once the errer occures, it might have bad side effects like messing with temporary taskforces and breaking the order references.

Nonetheless it is something that is much easier to address when I progress with the framework project, because interfacing the taskforces that I have analysed so much already, will without question be one of the first data structures I'm going to interface. And once that is done, it will be no more than 5 lines of code easy to write in about two minutes, while in asm you will need many more lines and invest lots of thinking I guess.

But I don't have a library ready yet, so feel free to go ahead and fix it in asm code.
But, as you say, adapting given UE features to fix saved games is faster and good enough.

Well, I completed to implement the taskforce id recomputement, fixing GTForceist, GTForceHd, GWTForce, GWTForceHd, TForceCntr, GShipList, the alienTFInfo files, monster.lst, ordInfo and result.lst. I however still can't load the game. But other than whats reported, already for the unpatched game save it crashes at a different offset, which is why I asked for the AIO-version. Myself I currently have BOTF_Top_10_mods_2.0.2_Beta2 installed and that might be incompatible:

Code: Select all

Name der fehlerhaften Anwendung: trek.exe, Version: 0.0.0.0, Zeitstempel: 0x37965563
Name des fehlerhaften Moduls: trek.exe, Version: 0.0.0.0, Zeitstempel: 0x37965563
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000193f6
ID des fehlerhaften Prozesses: 0x0x3184
Startzeit der fehlerhaften Anwendung: 0x0x1D9279FA876784D
Pfad der fehlerhaften Anwendung: C:\Spiele\BotF\AAML\trek.exe
Pfad des fehlerhaften Moduls: C:\Spiele\BotF\AAML\trek.exe

In case any of you like to give it a try and are too lazy to get the latest UE source from vscode branch, here the patched save with recomputed taskforce ids:

game11.sav

(382.23 KiB) Downloaded 35 times

I don't have the named AIO version and will be away for a few days, so either I need a working save to confirm it is not an install issue, hex patches, or the appropriate AIO installer. Then I would try with removing ships, orders and stuff. If that doesn't help, I'd have to try reset AI or check the asm code. But any hints are welcome!

Here the log of the many fixed integrity check issues:

aaml_integrity.txt

(72.9 KiB) Downloaded 35 times

UE TF patches.jpg (109.69 KiB) Viewed 867 times

[thunderchero]

In case any of you like to give it a try and are too lazy to get the latest UE source from vscode branch, here the patched save with recomputed taskforce ids:
game11.sav

I made it to next turn on saved game above.