TonyE

Thank you for the writeup. That performance is disappointing. I'll have a look, eventually...

Forgot to post that I confirmed this behavior based on the files provided. There is very suspect code in Effect1.c ProcessSplitGroupEvent that starts with a comment /* group does not exist anymore *or* only has one platform left */ and another chunk later in the same procedure that deals with the new group sinking. It would be super helpful to have a save just before the weapons hit that sink the ship so I can step through the code to see how the event is mis-assigned.

HCE - 2024.004 - 2024-08-08 =========================== - Chg:33561 GE Make sure to notify ExportDLLs of ActGroupPtr changes. Five places were added that were previously missed. (thanks donaldseadog) https://harpgamer.com/harpforum/topic/33561-actgroupptr-not-firing-when-airgroup-is-split-to-form-a-new-group-which-takes-active-status-in-game/ - Chg:00000 GE A group is now considered 'showing' as long as any unit in the group is showing. Previously the group 'showing' determination only used the first unit in the group. (thanks donaldseadog) - Chg:33554 GE When splitting less than all of the planes in a plane unit from a formation patrol, the remaining plane(s) in the formation patrol were having their formation event deleted which left the aircraft orphaned to eventually run out of fuel and crash. At least one case (donaldseadog's Patrol-good.hpq) should be fixed. (thanks donaldseadog) https://harpgamer.com/harpforum/topic/33554-base-air-patrols-loosing-their-base/ - Chg:00000 GE Fixed a few more spots where moving > 127 aircraft in a unit resulted in an integer overflow (limit is really 255)

Quite the challenge on this one, even with the reproduceable case. 2ish hours into debugging and finally see that when processing the SplitGroup event Effect1.c MovePlanesToNewGroup is called. One of the early lines of that procedure deletes all of the air patrol events for the donating aircraft unit. That's a wrong action to take in this case since we are only moving half of the planes in the unit to a new group. Since I'm sure it will bite us later, the procedure also removes all formation events for the unit. My first suspicion is that we can leave the air patrol and formation events in place unless we are moving all planes in the unit to the new group.

Thanks guys, I would not at all be surprised if the corruption is either in the save game or load save process. I would be surprised if it is autosave specific.

Thank you for all of this effort, it is truly the hard part of improving the game. Changing the often < 5 lines of misbehaving code is the easy part!

Wasn't just air groups, any group split. Nice find! HCE - 2024.004 - 2024-07-## =========================== - Chg:33561 GE Make sure to notify ExportDLLs of ActGroupPtr changes. Five places were added that were previously missed. (thanks donaldseadog) https://harpgamer.com/harpforum/topic/33561-actgroupptr-not-firing-when-airgroup-is-split-to-form-a-new-group-which-takes-active-status-in-game/

HCE - 2024.003 - 2024-07-10 =========================== - Chg:00000 GE Very beginnings of adding unit type SATELLITE which equates to unit and group type of 'P'. Probably should have used 'O' for orbital. 's' and 'S' were already taken. (thanks WalterE) - Chg:32081 GE Added more code to prevent selecting an invalid formation patrol area. (thanks donaldseadog and others) https://harpgamer.com/harpforum/topic/32081-game-freezes-if-bad-patrol-sector-made-in-group-formation-editor/ - Chg:00000 GE Finally, after decades, removed two race conditions in the FindRandomPatrol function where once in a while the game would get stuck in an infinite loop hoping that a random number would match a set of formation zones and sectors.

Fix coded for 2024.003

I have a fix that I'm so far testing successfully. Have I mentioned how much I hate the ancient user interface code?!? I'm finally fixing a forever old piece of formation-keeping code that has logic that would occasionally infinitely loop. It is the code that when a formation patrol is assigned to multiple rings and/or sectors must decide which individual formation spot to go to at that time so not a common use-case but happened to hit when I was testing the crash fix and I finally am conquering.

formedit.c FramePatrolRegion tries to figure out what ring is selected and in this crash case it identifies a ring one beyond what the UI shows which leads to the experienced nastiness. No fix yet.

Confirmed here in 2024.002. Thanks for the older issue reference, that helped me skip right to the function in play, MoveAndSetPosition in formedit.c. It is not a regression from the previous fix, rather a new case with the same end result. I don't have a fix yet but have a strategy to further debug via a bunch of logging statements. Debugging isn't super straightforward since if I set breakpoints that is going to result in more windows messages which will prevent the code from acting naturally so it is a case here of log, recreate issue, review logs, tweak code, repeat...

For the SE you are looking for an executable called Wscenedt32.exe.

Agh, sorry for the delay, I have posted up the collection at

Harpoon 3 Platform Workbooks View File Excel spreadsheets used to help in platform editing tasks in combination with H4 Paper Rules Annex data. Sonar Calculator Platform Workbook Fuel Calculator Sensor Performance These workbooks use macros. They were last maintained by VCDH/Dale Hillier. Submitter TonyE Submitted 05/29/2024 Category Tools/Docs  

That would be novel. You could start with your fancy tools to look at THCReloadEvent/RELOAD_EVENT type of Harpoon Events.

I just e-mailed the author to see if he is willing to send over the most recent versions. If not, I have somewhat older versions that I'll post if he's okay with them being posted. He may be at sea so it could take a while for a response... Do you have the Reimer Editor (platform editor) up and running?

HCE - 2024.002 - 2024-04-02 =========================== - Chg:00000 GE When splitting a group by splitting aircraft from a single unit into two units (one in donating group, one in destination group) the destination unit would have the unique id (uuid) of the donating unit making it no longer unique. This messed up further processing of Harpoon Events for those units, such as landing. Fixed to not overwrite the uuid generated for the new unit. (thanks donaldseadog and others)

HCE - 2024.002 - 2024-04-02 =========================== - Chg:00000 GE When splitting a group by splitting aircraft from a single unit into two units (one in donating group, one in destination group) the destination unit would have the unique id (uuid) of the donating unit making it no longer unique. This messed up further processing of Harpoon Events for those units, such as landing. Fixed to not overwrite the uuid generated for the new unit. (thanks donaldseadog and others)

Eric is looking at the magazines on bases, are base magazines exporting and importing correctly for the rest of you in 2024.001? Again, any existing corruption would remain.

Yes please if you have a neat way to do that. I'm not 100% sure but I think the key will be land air events (the launch/land event gets created by the processing of the landair event).

Confirmed using TonyD's test.hpm using 2024.001 with group AIA as the troublesome group. The group has two units that won't land, each of those units having a single F/A-18. There is no LandAir event nor LaunchLand event for those units so they are stuck.

Thanks E, that is a good sign!

The whales now have an option in 2024.001 once somebody adds the non-magnetic hull flag to the whales and the fishies in the DBs.