View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0023837 | AI War 2 | Gameplay Issue | Sep 29, 2020 8:13 pm | Sep 30, 2020 11:38 am | |
| Reporter | BadgerBadger | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.604 A Thousand Screaming Idiots | ||||
| Fixed in Version | 2.604 A Thousand Screaming Idiots | ||||
| Summary | 0023837: Problem with fireteam deserialization | ||||
| Description | Hey 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. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Thanks, this is really useful and I should be able to take care of it. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. :) |
| 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 |
