GWTForce vs GTForceList

editing Savegames files; support/discussion/questions

Moderator: thunderchero

Post Reply
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3237
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

GWTForce vs GTForceList

Post by Flocke »

Flocke wrote: Thu Sep 18, 2008 2:56 am
Spocks-cuddly-tribble wrote:What means "only in behavior" ?
I meant this:
Flocke wrote:Offset 0x0038 to 0x003B = sector row (GTForceList => next turn, GWTForce => actual turn)
Offset 0x003C to 0x003F = sector column (GTForceList => next turn, GWTForce => actual turn)
The structure of both files is the same it only seemed to differ in the behavior of sector row and column. That means if you set another position in GTForceList the Fleet will occure there (even if on the other side of the map and without of reach) after ending turn.
Cause there are still some unknown values I can't assure that this is the only difference but cause of same structure only the interpretation/behavior should be different. :)

Analysing an UE fleet movement issue, I found that I messed GTForceList and GWTForce. On turn start it usually doesn't matter, but when you re-group your task forces, and save thereafter, BotF saves the new task forces only to GWTForce and leaves GTForceList unchanged.

When with UE a re-grouped task force is moved and no task force is left in the previous sector, it raises the following crash next turn:

Code: Select all

File: gdllist.c, Line: 534, gdlList != NULL
This happens cause UE yet only updates the sector in both files for matching task force ids. By re-grouping task forces, the ids in GTForceList however become oudated and don't match GWTForce any longer. On turn progress then BotF looks up the GTForceList sectors and expects to iterate GWTForce task forces of each sector, which does fail when there are none. What task forces there are however doesn't seem to matter, and I can't tell why it's iterating them.


Further, for any new task forces, the game assigns some temporary task force ids, that are replaced the next turn. These temporary ids have special negative id ranges, that UE doesn't recognize yet. UE instead reads them as unsigned values and uses the highest one to update the TForceCntr, which then crashes the game a few turns later when ai re-groups it's task forces I guess.

These temporary ids are offset by the different empires like this:

Cardassians: FF FE (-2)
Federation: EC 78 (-5000)
Ferengi: D8 F0 (-10000)
Klingons: C5 68 (-15000)
Romulans: B1 E0 (-20000)
Minors I guess start with: 9E 58 (-25000)

They are counted down by -1 each new temporary task force id. And I think the counter is reset each turn.
So essentially all negative short values are reserved for temporary task force ids and -1 is special for 'none' ofc.


These both are the main UE sav game corruption issues I found, beside that I recently already fixed a major issue with OrdInfo that corrupted the save when there were small yet unknown entries. So yeah, currently UE has a few major file corruption issues, that should be fixed soon. :mad:

edit (Apr 09): above issues are fixed in latest yet unreleased UE version
Post Reply

Return to “editing Savegames files”