Crash logs and solutions

[Tethys]

And I think that it could be a save game thing too though, since the new attribute(s) in trek.exe is not being transferred to the save game.

There is only GShipList and starbaseInfo for shiplist.sst attributes in saved games. Weapon data is not stored, only current hull points (plus for some reason shields for ships/monster only - for an unfinished feature I guess).
And the production value/10 for TT ground combat (hence editing shiplist.sst doesn't work for TTs in the map).

So no need to waste the time of Flocke to investigate this.

There is a battle calculation I saw somewhere, and a mismatch of one of the (inner?) values causes the crash log. Torpedoes and possibly even whether or not it had phaser firing capability, are in the save file somewhere. Maybe something to do with empire/military strength? I don't have time to look more deeply into it, because of all the back projects I want to complete and GALM updates.

RF gave me a crash log from UDM latest version 3.0.1db, this crash happens during recloak of a ship.

Version Under Test: 72
File: tcmath\tcmath.c, Line: 34, REAL_GE_ZERO(value)
Initialize State: 31
Player Empire: 3
Starting Seed: 1335727061
Galaxy shape: 0
Galaxy Size: 1
Turn State: 20
Turn Number: 63

any ideas?

thunderchero

I have been running into this crash in MUM in large combats lately.

if I lower agility crash is less frequent

TC, by logic it seems that perhaps there is some total/fleet agility being calculated, and a threshold exceeded. If the mod is having alot of fast attack ships, or ships with higher agility values in a tactical combat, it could be presumed that the agility values of both fleets are being calculated for use by BotFs combat turn calculations.

I know high agility on fast attack ships makes for a pretty interesting show of events

[Spocks-cuddly-tribble]

None of the values used for tactical combat is loaded from saved games, just the current hull points (as told and obviously needed).


Yes, re-cloak uses fast evade movement code and max agility is one factor increasing the chance for e.g. hob texture/LOD switch mode bugs.

This crash also happens from time to time in ECM with vanilla hob fix (different solo mode commands within AI combat groups slightly increases the risk too).

But, unless too many fancy tactics push the flawed BotF combat calculations to the limit, it's about max one crash per 300 turns played.

[Tethys]

Here is a repeatable crashlog I encountered in GALM this morning.

The ship must be redeployed into and out of a taskforce prior to these steps below.

Train a ship. Select that ship and set it up to travel. Now without adjusting the ship's heading, select orders and Train Crew once more. Crash log:

-------------------------------------
ST:BOF Tue Oct 17 05:08:45 2023

Version Under Test: 72
File: ..\..\source\game\ship.c, Line: 968, taskForce != NULL
Initialize State: 31
Player Empire: 1 Starting Seed: 1697090203
Galaxy shape: 3 Galaxy Size: 2

This crash log exists in several places already, the only cause is relatable to taskforces.

[thunderchero]

Here is a repeatable crashlog I encountered in GALM this morning.

The ship must be redeployed into and out of a taskforce prior to these steps below.

Train a ship. Select that ship and set it up to travel. Now without adjusting the ship's heading, select orders and Train Crew once more. Crash log:

-------------------------------------
ST:BOF Tue Oct 17 05:08:45 2023

Version Under Test: 72
File: ..\..\source\game\ship.c, Line: 968, taskForce != NULL
Initialize State: 31
Player Empire: 1 Starting Seed: 1697090203
Galaxy shape: 3 Galaxy Size: 2

This crash log exists in several places already, the only cause is relatable to taskforces.

that crash log is only at 00449844
Line: 968 is only listed once.

The 18 fleet taskforce was so experimental and should not have been ever released due to saved games and coding issues.
I personally would not add it to any new mod or even suggest using it.

[Tethys]

The 18 fleet taskforce was so experimental and should not have been ever released due to saved games and coding issues.
I personally would not add it to any new mod or even suggest using it.

At least once a week I consider removing it. I can't be sure it's not causing sync errors when people redeploy their fleets in MP (if it is causing crashes in SP it most likely has deeper issues in MP).

I really wish QD and everyone would come back around.. wonder if maybe Infinite is gonna draw them back? We could only hope..

[thunderchero]

At least once a week I consider removing it. I can't be sure it's not causing sync errors when people redeploy their fleets in MP (if it is causing crashes in SP it most likely has deeper issues in MP).

I really wish QD and everyone would come back around.. wonder if maybe Infinite is gonna draw them back? We could only hope..

UDM still has 18 task force and was top game played in MP, so I doubt if it alone is issue. Other patch combos may have different effect.
I am not adding most of the newest patches to UDM only patches that need updating.

[Tethys]

Once all the proverbial ducks are in a row I plan to export all files from current GALM and start with a fresh vanilla, then add heavy mods via Patch Tool with adjusted values so all patches are green, crush any conflicts, and stabilize the mod as much as humanely possible using the latest iterations of modding tools. As it is right now, GALM is having a pretty hard time with UE 0.8.0 (I think I broke it, always asking to update the EXE but when I allow that, game crashes without logs). Any adjustment to GALM now must be light and non-exe modifying due to it's delicate nature and my personal expectations. :p

Literally adding a period to a description wants me to update the exe so it can break itself. I am looking for my 'compare trek' tool now to see what's the issue that UE wants to keep "updating" in the exe. Perhaps its some phantom I can ignore for now (I have been and its been working so far *knock on wood*)

Update: Problem seems to be UE thinks the main structures are somewhere else? But they aren't...

UEchanges.png (94.74 KiB) Viewed 1757 times

Update: Well, I fixed it. No more UE prompt to save the exe. I let it save the exe and the res, then deleted the exe and restored the backup exe, leaving the res in place. Saved a change just now, no prompt to save exe, no crashes in game anymore *knock on wood*

[Spocks-cuddly-tribble]

The ship must be redeployed into and out of a taskforce prior to these steps below.

Train a ship. Select that ship and set it up to travel. Now without adjusting the ship's heading, select orders and Train Crew once more. Crash log:

File: ..\..\source\game\ship.c, Line: 968, taskForce != NULL

That's a very old and well known issue. It happens most after re-loading a saved game and re-redeploying, aborted move orders and different orders/movements for ships before in the same task force. It's not that bad since mostly an issue due to save scumming.

Instead of a crash, it can even cause your TTs to liberate enemy systems (i.e. no system takeover, instant retransfer to old owner with liberation morale message). Aborted move order and/or partial redeploy issue: viewtopic.php?p=59286#p59286

18 fleet taskforce (...) if it is causing crashes in SP

Thunderchero made two special updates for this patch (crash issue with terraform and scrap): viewtopic.php?p=59256#p59256

I'll look at your other post later. They are a bit overwhelming/time consuming and I still need to get the ECM update done.

[thunderchero]

mostly an issue due to save scumming.

this is one thing I don't understand

does "save scumming" = saving over the same saved game causing corruption?
or
is just the act of changing order without executing previous order cause corruption?

after my latest project on saved games, every saved game is deleted/moved before new save is written. So it is impossible to get corruption by overwriting saved game because it can't over-write any save. If save is present and not deleted it would leave archive.tmp.

[Spocks-cuddly-tribble]

does "save scumming" = saving over the same saved game causing corruption?
or
is just the act of changing order without executing previous order cause corruption?

Usually it just means reloading a save (e.g. before a battle) and repeat the same turn until you like the outcome.

Here I mean loading a saved game and redeploying task forces (and/or changing other orders, even system build orders can cause issues in this case) before ending the loaded turn. Saving the same turn again (perhaps repeated with changed orders) makes it even worse.

after my latest project on saved games, every saved game is deleted/moved before new save is written. So it is impossible to get corruption by overwriting saved game because it can't over-write any save. If save is present and not deleted it would leave archive.tmp.

This part was unclear until lately. So it's good the know we don't need to worry there.
Above issue is about corruptions of ingame data stored in the saved game (e.g. stuff like temp TF IDs vs. orders).

[thunderchero]

Usually it just means reloading a save (e.g. before a battle) and repeat the same turn until you like the outcome.

Here I mean loading a saved game and redeploying task forces (and/or changing other orders, even system build orders can cause issues in this case) before ending the loaded turn. Saving the same turn again (perhaps repeated with changed orders) makes it even worse.


This part was unclear until lately. So it's good the know we don't need to worry there.
Above issue is about corruptions of ingame data stored in the saved game (e.g. stuff like temp TF IDs vs. orders).

so would this logic be correct

users should always use auto save/last save when possible? (this is only saves without new orders)
or
If user saves game to saved slot, it should always be at beginning of turn before any orders have been made.

this would be best to prevent TF/system order corruption?

so this is purely data stack error and has nothing to do with saved game file.

once save is loaded it would be in a data stack and no longer read from file until deleted then saved again
(code is just saving what is in that stack without checking for duplicate orders/TF)

[Tethys]

The ship must be redeployed into and out of a taskforce prior to these steps below.

Train a ship. Select that ship and set it up to travel. Now without adjusting the ship's heading, select orders and Train Crew once more. Crash log:

File: ..\..\source\game\ship.c, Line: 968, taskForce != NULL

That's a very old and well known issue. It happens most after re-loading a saved game and re-redeploying, aborted move orders and different orders/movements for ships before in the same task force. It's not that bad since mostly an issue due to save scumming.

Instead of a crash, it can even cause your TTs to liberate enemy systems (i.e. no system takeover, instant retransfer to old owner with liberation morale message). Aborted move order and/or partial redeploy issue: viewtopic.php?p=59286#p59286

18 fleet taskforce (...) if it is causing crashes in SP

Thunderchero made two special updates for this patch (crash issue with terraform and scrap): viewtopic.php?p=59256#p59256

I'll look at your other post later. They are a bit overwhelming/time consuming and I still need to get the ECM update done.

I'll have a look at those links soon. I am a bit worn out by the spiral galaxy generation subroutine. Don't worry yourself on most of those posts, I agree I've been going extra a lot lately. Been testing many values in the exe lately and wanted to document the results (for future references). There might be one pressing matter but I am too tired to think of it right now. Sorry if I am being overwhelming it is not intentional.

[Spocks-cuddly-tribble]

users should always use auto save/last save when possible? (this is only saves without new orders)
or
If user saves game to saved slot, it should always be at beginning of turn before any orders have been made.

this would be best to prevent TF/system order corruption?

In theory yes, but it depends on what you want.
I wouldn't do it, micro management for fleets, system build queues, research and intel is just too much work lost each time when loading a saved game.

In most cases problem is ordInfo out of sync with altered and/or temp files (new fleet separated form a task force).
So latest UE might be able to auto-fix most of the issues (at least for ships/fleets).

Just note 'repeated' changes done in loaded games before ending the current turn sometimes might cause issues (most work fine).
Say you moved many fleets for an important battle and the UI somehow skipped a TF sorely missed in that battle.
Unless you redeploy ships, reloading and correcting this should be fine.

One time I had to remove all items from a 'frozen' build queue and take the loss of the invested industry to fix it (and/or you see wrong construction times in the systems list). I think I repeatedly altered the following queue items and saved the same turn again to trigger this hidden issue?

so this is purely data stack error and has nothing to do with saved game file.

once save is loaded it would be in a data stack and no longer read from file until deleted then saved again
(code is just saving what is in that stack without checking for duplicate orders/TF)

I can neither confirm nor deny this right now.
IIRC DeleteFileA is used only for the old last.sav, so I was under the impression the regular save slots just get updated (not re-created from scratch)?

Bottom line is: To be one the safe side prevent any alterations in re-loaded saved games before ending turn whenever possible (aka "save scumming").

[thunderchero]

I can neither confirm nor deny this right now.
IIRC DeleteFileA is used only for the old last.sav, so I was under the impression the regular save slots just get updated (not re-created from scratch)?

Bottom line is: To be one the safe side prevent any alterations in re-loaded saved games before ending turn whenever possible (aka "save scumming").

at 0051CADB will delete old game%d.sav before archive.tmp is renamed to save slot selected

[Spocks-cuddly-tribble]

0051CADB will delete old game%d.sav before archive.tmp is renamed to save slot selected

I see, and so I can clearly confirm your above statement wrt to the external 'container' X.sav file.

But, as Flocke found out years ago, there is still older turns data garbage in the sav files.
So this is carried over from the loaded arc files (i.e. some sub-files sometimes are improper updated and not cleaned up)?