View Issue Details

IDProjectCategoryLast Update
0023837AI War 2Gameplay IssueSep 30, 2020 11:38 am
ReporterBadgerBadger Assigned ToChris_McElligottPark  
Status resolvedResolutionfixed 
Product Version2.604 A Thousand Screaming Idiots 
Fixed in Version2.604 A Thousand Screaming Idiots 
Summary0023837: Problem with fireteam deserialization
DescriptionHey Chris, there's a problem with fireteam deserialization. I used the "scrub grove" save from 0023826

I added some logging to Fireteam.cs, DeserializeFireteamsAndDiscardAnyExtraLeftovers():

            int numTeams = Buffer.ReadInt32( ReadStyle.NonNeg, "countOfLivingFireteams" );
            ArcenDebugging.ArcenDebugLogSingleLine("We are deserializing fireteams for " + ForDebugging_FactionName + " and there are " + numTeams, Verbosity.DoNotShow );
            for ( int i = 0; i < numTeams; i++ )
            {
                int id = Buffer.ReadInt32( ReadStyle.PosExceptNeg1, "id" );
                ArcenDebugging.ArcenDebugLogSingleLine("\tHandling team " + i + " id " + id, Verbosity.DoNotShow );

9/29/2020 6:07:02 PM We are deserializing fireteams for hunter fleet and there are 35
9/29/2020 6:07:02 PM Handling team 0 id -1
9/29/2020 6:07:02 PM Handling team 1 id -1
9/29/2020 6:07:02 PM Handling team 2 id -1
...
9/29/2020 6:07:02 PM Handling team 34 id -1

Since all the fireteams have id -1 they all get discarded, which means that the Hunter needs to rebuild all its fireteams every time the game reloads. Since sometimes fireteams were in the middle of actually attacking, this causes them to behave stupidly (and buys the player several LRP steps for the hunter to reorganize itself and attack).

I only tested this on the hunter, but I expect it applies to all the factions that use fireteams.
TagsNo tags attached.

Activities

BadgerBadger

Sep 29, 2020 8:14 pm

manager  

scrub grove.save (1,126,925 bytes)

Chris_McElligottPark

Sep 30, 2020 10:57 am

administrator   ~0058805

Thanks, this is really useful and I should be able to take care of it.

Chris_McElligottPark

Sep 30, 2020 11:11 am

administrator   ~0058806

Unfortunately, this is actually not a serialization problem -- that would be far simpler. I have turned on serialization logging, and am able to verify that whatever the id is at the time of save is what gets loaded back in again on the other end.

There are times where the ID is -1, such as in the save that you originally have above, and the question is what we do with fireteams in that case. I'm not sure that just discarding them all is the best idea. But is there some way for them to reconnect with their members and generate a new ID if they are ID-less? I am guessing not, since the squads/ships refer to them by ID, rather than them having a list of squads inside them.

What I then did was let the game run for something like 3-4 minutes, and then saved it again after it had generated new fireteams. The fireteam data that is saved has proper numbers, rather than being -1. This is the data that was written via the serialization log, and it was read correctly again (and fireteams remained) after deserialization.

So my conclusion is that either there was a bug in a prior version that led to fireteams not serializing properly (this seems very unlikely, though), or that more likely there is some sort of bug that is causing the fireteam ids to be set to -1 during gameplay under some specific unknown circumstances.

I'm going to look at a few things with the id field itself, and see if I can't narrow that down. I have one suspicion that might bear fruit. The attached save is the one from after letting it run for 3-4 minutes, and it has fireteam ids in there properly.
scrub grove 3.save (1,097,053 bytes)

Chris_McElligottPark

Sep 30, 2020 11:18 am

administrator   ~0058807

Wait, hold on, this is a several-level thing. It is a deserialization problem, but the savegame you gave was two deep rather than one deep in the chain. I think I found it.

Chris_McElligottPark

Sep 30, 2020 11:33 am

administrator   ~0058808

Bit 1, which fixes nothing:

* Renamed the "id" field on Fireteams to be FireteamID, and made it a get-only property rather than a naked variable.
** This way we can make sure that it is not accidentally being set when we don't expect (it was not).
** There is now a SetFireTeamID() method that is used for actually changing the ID, and it can have extra instrumentation in there as needed, if needed. At the moment it's good.

* Also made the constructor for Fireteam private, so that it can't be called directly from other classes.
** There is instead now a public static CreateNewWithIDFromList() factory method on Fireteam which should be used, and which ensures that it's not possible to forget to assign the FireTeamID when initializing a new Fireteam.
** As with the other change, we found no errors in the code, but we are keeping the changes partly to make fireteams that little bit more accident-proof both in terms of our own future code, and modder code.

Chris_McElligottPark

Sep 30, 2020 11:38 am

administrator   ~0058809

Got it!

* Fixed a line that was missing where during fireteam deserialization we were not actually assigning the fireteam id to the fireteam. This has been present since September 3rd, when we were overhauling a lot of the externaldata and how it is read in.
** This was particularly tricky to find, because the data was being read in properly, and so the serialization logs all showed things properly as did the deserialization logs. However, since nothing was done with the read-in ID, it then would have the game behave improperly and the NEXT time that serialization happened it would write -1 for all the fireteam IDs that it had previously deserialized, which was the first sign in data of something being wrong.
** Anyhow, this was causing the hunter and other factions to be notably stupid for a few minutes after loading any savegame, but is now fixed.

Thanks. :)

Issue History

Date Modified Username Field Change
Sep 29, 2020 8:13 pm BadgerBadger New Issue
Sep 29, 2020 8:13 pm BadgerBadger Status new => assigned
Sep 29, 2020 8:13 pm BadgerBadger Assigned To => Chris_McElligottPark
Sep 29, 2020 8:14 pm BadgerBadger File Added: scrub grove.save
Sep 29, 2020 8:30 pm BadgerBadger Description Updated
Sep 30, 2020 10:57 am Chris_McElligottPark Note Added: 0058805
Sep 30, 2020 11:11 am Chris_McElligottPark File Added: scrub grove 3.savemet
Sep 30, 2020 11:11 am Chris_McElligottPark File Added: scrub grove 3.save
Sep 30, 2020 11:11 am Chris_McElligottPark Note Added: 0058806
Sep 30, 2020 11:18 am Chris_McElligottPark Note Added: 0058807
Sep 30, 2020 11:33 am Chris_McElligottPark Note Added: 0058808
Sep 30, 2020 11:38 am Chris_McElligottPark Status assigned => resolved
Sep 30, 2020 11:38 am Chris_McElligottPark Resolution open => fixed
Sep 30, 2020 11:38 am Chris_McElligottPark Fixed in Version => 2.604 A Thousand Screaming Idiots
Sep 30, 2020 11:38 am Chris_McElligottPark Note Added: 0058809