This is getting quite exciting, 😄

As I re-run through each game second, I'm planning to capture the state of the AIR_PATROL_EVENT that should be associated with AC021 aka Group ACb Unit 021.

100289 RestoreGame: E->ourGroup->id == "ACb", E->UnitID == 21 from Eric's save 'Unit ID Test 1-41.001.hpq'

100290 Command: E->ourGroup->id == "ACb", E->UnitID == 21 from Eric's save 'Unit ID Test 1-41.001.hpq'

100303 ProcessAirPatrolEvent: E->ourGroup->id == "ACb", E->UnitID == 153 from my save Unit ID Test 1-41.001.0013.hpq

 

At GameTime 100290 there is a ProcessLaunchAirEvent call that has a parameter LaunchAirEventPtr E2.  There is a field in that structure E2->patrolling which happens to point to our AIR_PATROL_EVENT that gets corrupted.  So that is when it gets corrupted, now we have to dig back to the creation of this seemingly wrong LaunchAirEvent.  The LaunchAirEvent is for group ZGC, no unit specific and should be launching qty 1 of plane 10539 (its AnnexID in the DB) with loadout 56483 in case anyone wants to look up what plane and loadout that maps to.  I imagine that information could be handy to see if the launch air event is also corrupt.

 

Note to TonyE: Loadgame.c function RestoreGame around line 370 does some wacky matching of AIR_PATROL_EVENTS to LaunchAirEvents.  Being wacky, it is suspect.

 

3 hours ago, TonyE said:

Note to TonyE: Loadgame.c function RestoreGame around line 370 does some wacky matching of AIR_PATROL_EVENTS to LaunchAirEvents.  Being wacky, it is suspect.

 

I re-loaded the save  'Unit ID Test 1-41.001.hpq' and at this wacky point in RestoreGame the GE associates that group ZGC LaunchAirEvent with the group ACb unit 21 AirPatrolEvent.  If I cancel that association, AC021 does not lose its purpose in life as a formation air patrol.  Progress!

 

I need to look next at the save game process to see how it saves LaunchAirEvents and compare that to the RestoreGame restoring of LaunchAirEvents.  

The save and restore functions at first glance look to be in sync.  TonyD could possibly be onto something by suggesting a limit may have been breached.  That limit could be number of HarpoonEvents the code can cycle through when saving and loading saved games.  While the list of HarpoonEvents can be as long as memory permits (hundreds of millions very conservatively), the saving and loading of saved games had a limitation of 32,768 (a signed short integer).  I was able to double that without breaking anything.  That will be a part of 2022.015.  Anyway, from 'Unit ID Test 1-41.001.hpq', here are the LaunchAirEvents with patrols that have a non-matching group (both the base HarpoonEvent and the patrolling associated HarpoonEvent have an associated group).  I don't know what significance there is that they are four in a row from 5617 to 5620.  There are over 22,000 HarpoonEvents in the saved game and it just happens that four in a row are affected, hmm.  

100289 Loadgame.c:383 - attaching AirPatrolEvent for Group=ZWC UnitId=143 patrolling_idx=5620 to Group ZVC
100289 Loadgame.c:383 - attaching AirPatrolEvent for Group=ZWC UnitId=142 patrolling_idx=5619 to Group ZGC
100289 Loadgame.c:379 - attaching AirPatrolEvent for Group=ACb UnitId=21 patrolling_idx=5618 to Group ZGC
100289 Loadgame.c:383 - attaching AirPatrolEvent for Group=ZVC UnitId=179 patrolling_idx=5617 to Group ZGC

TonyE, Loadout 56483 is an ASW loadout used on Z-9EC and Zhi-9C Helo's

Thanks all for the hard work on this issue.  Build 2022.015 has been uploaded as has a 2022.015 version of the Launcher.  Please grab them and get them up and running.

The ge.log is going to have additional entries when you enable the issue specific logging for this issue, I32501.  It will look something like...

100289 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZWC UnitId=143 patrolling_idx=5620 to Group ZVC LaunchAirEvent
100289 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZWC UnitId=142 patrolling_idx=5619 to Group ZGC LaunchAirEvent
100289 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ACb UnitId=21 patrolling_idx=5618 to Group ZGC LaunchAirEvent
100289 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZVC UnitId=179 patrolling_idx=5617 to Group ZGC LaunchAirEvent
100289 Setup.c:1336 - OpenBattlsetResFile
100290 Command.c:285 - I32501 found our group ACb unit 21, E->UnitID=21
100290 Command.c:290 - I32501 HarpoonEvent count is 22796 at start of GamteTime=100290
100290 Scenedit.c:255 - I32501 22796 HarpoonEvents in saved game
100291 Command.c:285 - I32501 found our group ACb unit 21, E->UnitID=153
100291 Command.c:290 - I32501 HarpoonEvent count is 25847 at start of GamteTime=100291
100291 Scenedit.c:255 - I32501 25821 HarpoonEvents in saved game
100292 Command.c:285 - I32501 found our group ACb unit 21, E->UnitID=153
100292 Command.c:290 - I32501 HarpoonEvent count is 24050 at start of GamteTime=100292
100292 Scenedit.c:255 - I32501 24019 HarpoonEvents in saved game

My first ask of you is to work backwards from 'Unit ID Test 1-41.001.hpq' until you don't see any errant AirPatrolEvents to LaunchAirEvent associations like "100289 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZWC UnitId=143 patrolling_idx=5620 to Group ZVC LaunchAirEvent".  You don't have to run any game time for these log messages to show up in ge.log, just loading the saved game at 0 time compression will do the trick.

Once you find that save, zip and post it up of course then run some game seconds to see what we get, there is a small chance that 2022.015 will fix the issue by doubling the number of HarpoonEvents the save game and load saved game duo can handle.

Should you happen to hit 32,768 HarpoonEvents active in the game (the old limit), you should see an assertion error, capture your ge.log and the current and prior game second save should that happen.

Attached is the last good saved game before air patrols became corrupt.

Unit ID Test 1-39.0008.zip

Attached are my 2 GE saved logs. It appears in the 2nd log file is when the patrols messages appear.

ge.zip

I started a scenario run new, Spratly Island #4-1032.scq then loaded the save from after 1 game second and the save after two game seconds (ge.logs attached).  

These are different in that they are assigned to a group UnitId == 255 aka NO_UNIT so I need to review the code to see what that means.  They may be legitimate but I have my suspicions that they aren't.  

My hunch is that the problem is with the saved game loading logic that if one played the scenario without ever loading from a save, this particular cause of errant formation patrols wouldn't happen.  Anyway, more to come eventually.

I32501_100001_ge.zip I32501_100002_ge.zip

Just now, TonyE said:

I started a scenario run new, Spratly Island #4-1032.scq then loaded the save from after 1 game second and the save after two game seconds (ge.logs attached).  

The first one is interesting upon further review, looks like a potential off by one error.

00001 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=YQR UnitId=255 patrolling_idx=4414 to Group ZQR LaunchAirEvent
100001 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZQR UnitId=255 patrolling_idx=4413 to Group ZYa LaunchAirEvent
100001 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZYa UnitId=255 patrolling_idx=4412 to Group YUa LaunchAirEvent
100001 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=YUa UnitId=255 patrolling_idx=4411 to Group ZER LaunchAirEvent
100001 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZER UnitId=255 patrolling_idx=4410 to Group ZGR LaunchAirEvent
100001 Loadgame.c:381 - I32501 attaching AirPatrolEvent for Group=ZGR UnitId=255 patrolling_idx=4409 to Group ZXa LaunchAirEvent

Is it feasible to save the AirPatrolEvent info from the end of one play and then at the beginning of the next so as to compare before game save with after game load?

On 9/23/2022 at 8:34 PM, donaldseadog said:

Is it feasible to save the AirPatrolEvent info from the end of one play and then at the beginning of the next so as to compare before game save with after game load?

Absolutely, that is exactly what the save game function is doing.  What exactly are you looking to have implemented?

On 9/26/2022 at 7:20 AM, TonyE said:

Absolutely, that is exactly what the save game function is doing.  What exactly are you looking to have implemented?

Oh, I wasn't after anything, I didn't realise this was already happening in trying to track down this illusive fiend

5 hours ago, donaldseadog said:

Oh, I wasn't after anything, I didn't realise this was already happening in trying to track down this illusive fiend

Oh, but you are on to something.  You rightly want to do a comparison of the state of the HarpoonEvents when they are dumped into a saved game file with the HarpoonEvents as loaded.  Thanks to the XML scenario file format work (that I haven't finished), I have code that can save the HarpoonEvents in XML format.  One could then in theory take that XML file of HarpoonEvents at save and compare it to the XML file of HarpoonEvents after load.  One online comparison tool is https://extendsclass.com/xml-diff.html .  Does this approach seem like a place to start, essentially duct taping together existing functionality with a limited amount of code to aid in the troubleshooting?