TonyE

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.

HCE - 2022.015 - 2022-09-20 =========================== - Chg:32501 GE Changes to help troubleshoot the referenced issue, it isn't expected to be fixed yet. In DumpScenarioHarpoonEventList and RestoreGame changed loop variables that deal with Event counts from short int to ushort int to match the data saved in the saved game. This doubles the allowable HarpoonEvents from 32,768 to 65,536. https://harpgamer.com/harpforum/topic/32501-air-patrols-crashing-unable-to-deleteait-patrols/ 18 files changed, 144 insertions(+), 17 deletions(-)

Good job finding that utility. Welcome back!

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

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.

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.

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

Got there in the debugger by setting a breakpoint on change in memory contents of the AIR_PATROL_EVENT for ACb unit 21. It took a long time to run those 14 game seconds. I was expecting it to be one game second from 1-40.0071. So slowly getting closer to the moment things go awry.

They are temporary structures created when needed, primarily when the formation editor is opened. The structures are freed when the formation editor is closed.

Hint to TonyE and donaldseadog: 1. formedit.c FormationDlg() says that air units with CombatFlag <= 0 will show up in the formation editor. 2. formedit.c AddFormRec() looks for an AirPatrolEvent associated with the unit via FindAirPatrolEvent() to determine if the unit is a formation air patrol or just part of the formation. If it is a formation air patrol, form->state is set to AIR_FORM. 3. formedit.c FindAirPatrolEvent() finds the first AirPatrolEvent based on the group matching (not the group id, the group structure in memory) and the unit's id matching. 4. formedit.c MakeFormationList() builds the list box of items in the formation. It looks at the FormRecs already created and shows them as formation air patrols if form-> STATE == AIR_FORM || form->state == PATROL_FORM. In short, I expect that somewhere along the line, the affected formation air patrols are losing their associated AirPatrolEvent or the association (via somehow changed UnitIds) is broken.

True there is no underlying MCM type for the game to differentiate behavior. I agree that MISSION_ASW is the closest. Now what should the auto-created formation patrols be doing? My opening position is that the code should look at loadout type just like the player created formation patrol creation does.

My initial position is that the 'fix' is to update HCDB2's MCM loadout type to point to one of the MISSION_ASW slots. That will not fix the auto-created formation patrols (first would still be ASW, the rest would still be AEW). I validated that if you had enough MH-53E MCM to trigger two auto-created patrols, the second will be AEW as I suspected. Thoughts?

The auto-created formation patrol. Looks at the aircraft type, not the loadout of the aircraft. It sees the MH-53E as NAVL which defaults to an ASW type for the first auto-created MH-53E formation patrol. If the GE had enough MH-53Es to create another automatic formation patrol, I suspect based on reading the code (but I haven't tried adding more MH-53E) that the second and subsequent MH-53E MCM auto-created formation patrols would be AEW.

The player created formation patrol is 'correct'. The MCM loadout type of the MH-53E in HCDB2 is categorized as MISSION_PATROL (type 114 specifically). See https://harpgamer.com/harpforum/topic/31399-operation-gauntlet/#comment-59996 for the MISSION_MAP of how the game interprets loadout types. To see a list of the loadout types in the particular DB, look at qLst_LoadoutType (a query in pfBuild2005.mdb aka the PE). So going to Medium and turning on radars is the appropriate reaction, even if it isn't what you want as the player. I haven't looked at the auto-created formation patrol. I am moderately disturbed that the GE creates its own patrols and doesn't leverage what the scenario author did in the SE but that's for a different thread/discussion.

Call me even more clueless, what page or section are you in? I'm not easily able to find where you are in the book. I'm looking at pages 2-3 in the rules book (Example of play).

Fix coded and deployed as part of 2022.014

HCE - 2022.014 - 2022-09-01 =========================== - Chg:32506 GE If AirAttacker is executed when the attacking group can no longer see the target group, abandon the attack. (thanks donaldseadog) https://harpgamer.com/harpforum/topic/32506-runtime-error-in-ge/ 7 files changed, 30 insertions(+), 6 deletions(-)

Excellent example with which to recreate the situation, it triggers every time for me :). Digging in... The target group is ZWH as indicated in your ge.log. That target group still exists and has an AS.565 Panther helicopter in the air. However, you/the player no longer detects any units of group ZWH so it is and should be difficult for your group ATA to execute an attack. The lack of detected units of ZWH causes the get_group_type() call from GetTargetType to return the default value of 'R' which means Reference Point/REF. GetTargetType returns that value of REF to AirAttacker. I've added code to abandon the attack in this case.

HCE - 2022.013 - 2022-08-25 =========================== - Chg:00000 GE Throw an assertion error when type_aa has the value INVALID_ATTACK_CODE. This is to troubleshoot AirAttacker. HCE - 2022.012 - 2022-08-25 =========================== - Chg:00000 GE Write Windows version to ge.log - Chg:00000 GE Enhanced ac_ai logging "-l ac_ai" on the command line to include the value of type_aa in AirAttacker to troubleshoot https://harpgamer.com/harpforum/topic/32506-runtime-error-in-ge/ 9 files changed, 40 insertions(+), 15 deletions(-)

To help troubleshoot, please run 2022.013 with ac_ai logging turned on. If the troublesome code is triggered, you will get an assertion error. At that point, grab your ge.log, zip and upload it for analysis (a saved game from that game second or the one before would help too). Example command line (activates ac_ai supplemental logging to ge.log and autosaves every game second rolling over after 255 saves): Winharp32.exe -l ac_ai -S000010255 The log entries of interest will look something like: 100232 Combat5.c:1580 - G TCR:AirAttacker: BOm.. AirTargetType = 100232 Combat5.c:1602 - G BOm:target_type = 109, range=1325, bearing=208 100232 Combat5.c:1658 - WR.attack_type=6, auto_flag=1 100232 Combat5.c:1696 - after case, gflag=0, wrange=0, WR.weapon_range=0, attack type (type_aa)=4

Correct, we haven't narrowed it down much so given what we currently know, it applies to both sides.

This is happening in AirAttacker meaning aircraft attacking anything else. AirAttacker isn't able to figure out what kind of unit it is attacking (which is very strange) so the type does not get set, hence the uninitialized variable. More to come, probably in the form of additional logging to narrow down the root problem.

Hint to TonyE: Unit IDs fun was from HCE - 2020.005 - 2020-07-10

Are you able to reproduce either behavior in smaller scenarios?

HCE - 2022.011 - 2022-08-19 =========================== - Chg:00000 GE Code cleanup, mainly renaming variables with the name "type" such as unit type, group type to help isolate an uninitialized variable with that name. (thanks donaldseadog) - Chg:00000 GE Code cleanup, hundreds of additional variable initializations, many of the warnings were false positives suggesting a variable could be uninitialized upon use where really it wasn't possible in the flow of the code, but still, working over decades toward zero compiler warnings for the core game code. - Chg:00000 GE Call ntdll.dll directly for Windows version since Microsoft deprecated the formerly easy ways with Windows 8.1. - Chg:00000 SE Ditto on all for SE because why not. 57 source files changed, 747 lines inserted, 2558 lines deleted!