TonyE

SE fixed as well for 2023.007

HCE - 2023.007 - 2023-04-20 =========================== - Chg:00000 GE Removed the extra parameter on free_Unit and free_Group since I intend to make them available to ExportDLLs and the parameter was only there for historical debugging purposes, not needed anymore. - Chg:00000 GE Incremented DLL interface version to 35 for the newly added dllFuncRefs below for the ExportDLLs. - Chg:00000 GE ExportDLL interface now makes the unit_Free function available to ExportDLLs void unit_Free(UnitPtr pUnit) This does not add the unit to the unit kill counts. This will free the group if you are freeing the final unit in the group. - Chg:00000 GE ExportDLL interface now makes the group_Free function available to ExportDLLs void group_Free(GroupPtr pGroup) - Chg:00000 GE Updated RESRSRStructureVersion to 6 from 5 then back to 5 - Chg:00000 SE Updates to handle RESRSRStructureVersion == 6 - Chg:00000 GE BSStrings BroadVicType array added - Chg:32936 GE Game crashed in ProcessSinkingShipEvent when the unit to sink could not be found. This is a more likely occurrence since uuids were added to HarpoonEvents. The code has been modified to first look for the unit in the specified group, then fall back to finding the unit irrespective of the group, then if the unit is still not found, fail gracefully by not trying to sink the already gone unit. (thanks eeustice) - Chg:00000 GE Changed NM_DU() to have a long int parameter instead of short int. Changed DU_NM() to have a long int result instead of short int. - Chg:00000 GE Tons of other code changes to slowly work toward speeds > 32768 kts working in the game. - Chg:33042 GE There was a bug in the safe string copy routine. Fixed that ;). Anyway, those older scenarios with MessageEvents open correctly again. (thanks TonyD, donaldseadog) - Chg:00000 SE MessageEvents are now converted from old to new format upon loading scenarios.n back to 5

Fix coded for 2023.007, but more importantly points out that I seem to have forgotten to add the MessageEvent conversion code to the SE so awful things probably happened to those re-saved scenarios' MessageEvents. Did they even work? Subtext: The SE should have crashed too since the bug is in code used in the code that converts the older MessageEvent format to the newer one, except the SE never calls that code...

And we finally left IRC in favor of Discord

We had an incident this morning of accounts being successfully created, validated, then used to post 50ish garbage posts about airlines. Those accounts have been marked as spammers and IP addressed blocked. The captcha mechanism for the forum has been changed and hopefully won't make your lives more miserable. What will be miserable is that we have re-enabled moderation of all posts. As a result, your posts will not be immediately available for others to read. Those of us caring for the site are hobbyists will real jobs so there could be a delay in approving posts of a day or more but we expect it will be much less. Hopefully we'll be able to go back to the free and wild days shortly.

Fix coded for 2023.007 - Chg:32936 GE Game crashed in ProcessSinkingShipEvent when the unit to sink could not be found. This is a more likely occurrence since uuids were added to HarpoonEvents. The code has been modified to first look for the unit in the specified group, then fall back to finding the unit irrespective of the group, then if the unit is still not found, fail gracefully by not trying to sink the already gone unit. https://harpgamer.com/harpforum/topic/32936-ge-crash-2003006/ (thanks eeustice)

There is no unit in the scenario at the time of the error with the expected uuid so just added additional code to stop trying to sink it and put a line in ge.log instead. "Unit with uuid==ebf57315-6d82-4ea0-a898-d4a36083be58 is already gone, can't sink it"

Confirmed as an issue. The error is happening in ProcessSinkingShipEvent where the unit with uuid ebf57315-6d82-4ea0-a898-d4a36083be58 should be sunk but there is only one unit in the group VOS associated with the event and that unit doesn't have that uuid. Interestingly, the single unit in VOS is also sinking or already sank. My first alternative approach will be to see if there is still a unit with that uuid in a different group and if there is, sink that one. This all is a result of adding uuids to events and from a programming perspective is a possitive sign since before the uuid work, this event most likely would have sunk the wrong unit.

Linkage:

ReleaseNotes.txt updated for the next release. As for far more rounds than needed, that is a pervasive issue with missiles in general. If someone is willing, post up an issue with a saved game from a few seconds before the AI launches its first Silex/ASROC-style weapon.

HCE - 2023.006 - 2023-04-12 =========================== - Chg:00000 GE ASROC-style weapons should be wicked dangerous again and eject their torpedoes directly over the estimated position of the target. Previously (since 2018 or earlier), they were ejecting the torpedo 30ish seconds from the target, potentially a long way for a small torpedo to hit. (thanks donaldseadog)

HCE - 2023.005 - 2023-04-07 =========================== - Chg:32897 SE Fixed crash when trying to look at plane loadouts. Some of the country index variables hadn't previously been expanded from char to ulong like they should have been. https://harpgamer.com/harpforum/topic/32927-se-crash/ (thanks eeustice)

Fix coded HCE - 2023.005 - 2023-04-07 =========================== - Chg:32897 SE Fixed crash when trying to look at plane loadouts. Some of the country index variables hadn't previously been expanded from char to ulong like they should have been. https://harpgamer.com/harpforum/topic/32927-se-crash/ (thanks eeustice)

Confirmed. Start the SE, choose WestPac BS, go to the Platform Display, select Aircraft, and try to look at the loadouts of any aircraft. Error in UnitDisplayDlg, UnitDisplayParam is null so UnitDisplayParam->disk_id cannot be passed to HandleLoadoutReport.

Should be the same as invalid type-aa assertion failure - Defect Tracking - HarpGamer

Can you zip and send me your DB please? tonye@harpgamer.com I'm having trouble loading the save with the stock HCDB2.

Eric reports no more issue in 2023.004

HCE - 2023.004 - 2023-04-04 =========================== - Chg:32897 GE Rather than loosing attacks against submarines from close to a weapon's max range, now prompt to fire them from at most 2nm away. This could negatively affect weapons like CAPTOR mines that might ideally loose their torpedoes from farther away. It would be a good thing to test. https://harpgamer.com/harpforum/topic/32897-stand-off-asw-weapons-failure/ (thanks Enrique)

HCE - 2023.004 - 2023-04-04 =========================== - Chg:32897 GE Rather than loosing attacks against submarines from a close to a weapon's max range, now prompt to fire them from at most 2nm away. This could negatively affect weapons like CAPTOR mines that might ideally loose their torpedoes from farther away. It would be a good thing to test. https://harpgamer.com/harpforum/topic/32897-stand-off-asw-weapons-failure/ (thanks Enrique)

HCE - 2023.003 - 2023-04-04 =========================== - Chg:32923 GE Attempt again to fix type_aa != INVALID_ATTACK_CODE in Combat5.c assertion. The theory this time is that the AirTargetType global is causing everything to go astray. It should only be used by the player and I believe only when launching attacks so its value is reset to zero after any of those situations. https://harpgamer.com/harpforum/topic/32923-invalid-type-aa-assertion-failure/ (thanks donaldseadog) HCE - 2023.002 - 2023-04-03 =========================== - Chg:00000 GE HandleLanding wasn't assigning a uuid to HarpoonEvents - Chg:00000 GE ProcessLaunchAirEvent wasn't assigning a uuid to HarpoonEvents Remedied that both for the initial alt/speed and the destination alt/spd for AEW and such patrols where there is a second event. - Chg:00000 GE For the above two items, saved game version incremented to 0x3480321B so that the user will be warned that they are best banished. - Chg:00000 GE Scenario file version incremented to version 10 for fixes to Intermittent sensor events and use of (Staff) Message events. This build and newer builds of the game will not open version 9 scenarios, they are forever banished. - Chg:00000 SE Same for SE.

Fix coded (again). Thanks to your provided ge.log and saved game, I can force the unexpected value into AirTargetType which then leads to the assertion. That lends credence to my theory about AirTargetType being the culprit but does not conclusively prove that theory nor conclusively prove that the fix is correct. HCE - 2023.003 - 2023-04-## =========================== - Chg:32923 GE Attempt again to fix type_aa != INVALID_ATTACK_CODE in Combat5.c assertion. The theory this time is that the AirTargetType global is causing everything to go astray. It should only be used by the player and I believe only when launching attacks so its value is reset to zero after any of those situations.

Do you happen to know how/why AZA was launched? I'm looking at a scary global variable called AirTargetType that could have been set when you launched airplanes from a base for an attack (as opposed to say pulling them out of a formation patrol, ferry mission, or long range patrol). That global variable is throwing things off. That is also why the problem isn't readily reproducible from a saved game since the state of the AirTargetType global variable is not saved to and loaded from saved games so it resets to the more friendly value of 0 rather than the unfriendly value of 1 that is leading to the assertion.

Man, the impossible bug that keeps happening...

Don, if you are still having your issue with 2023.002, please post that up as a new issue. I could not and still cannot reproduce Eric's issue when I used just the two listed ExportDLLs.

HC 2023.002 fixed in SE