TonyE

Hehe, true enough. Hobby time is too rushed!

Well done, I was wondering if someone would pick up on some of the fallacies. ChatGPT wrote reasonable code for a non-sensical equation, at least non-sensical in how ChatGPT explained the equation. The Radar Equation - Radartutorial is a much better start to the basics of radar in the real world.

My first conversation with ChatGPT, not bad at all. It chose the radar "range" equation which does not take into account emitter power, detector sensitivity, etc. but still, amazing (and scary?).

I'm not sure exactly what you are asking. The H3 South Atlantic War supplement is GDW 0718. eBay is where many people go, such as https://www.ebay.com/p/118157409?iid=134309423228 You can also e-mail the Admiralty Trilogy group (Bond, Carlson et. al.) and ask if they might want to shoot you a PDF of the H3 supplement since it sounds like you've purchased the newer supplement. I haven't heard if this has worked for anyone. adtrgroup@aol.com

2022.027 - 2022-12-03 Added ability to change base filename of iterative gametime saves and ability to change MessageLog file.

Demo version 2022.028 has been uploaded

This is testing using the autotest batch files. While there are some errors above, this is the fewest errors we've ever had in the Harpoon [Classic] world.

AutoTest Batch Results for 2022.024: USNI re-make: no issues Original GIUK no issues NACV no issues MEDC Cannot reproduce: Exit code: -1073741819 command: Winharp32.exe -f 03-04b.txt -a -b 03 -c 04 -g 011111118 -p 4 -u -1 IOPG no issues HDS I GIUK no issues NACV no issues MEDC Cannot reproduce: Exit code: -1073741819 command: Winharp32.exe -f 08-11r.txt -a -b 08 -c 11 -g 111111118 -p 4 -u -1 IOPG no issues HDS II GIUK Cannot reproduce: Exit code: -1073741819 command: Winharp32.exe -f 10-09r.txt -a -b 10 -c 09 -g 111111118 -p 4 -u -1 NACV no issues MEDC no issues IOPG no issues HDS III GIUK Cannot reproduce: Exit code: -1073741819 command: Winharp32.exe -f 14-09b.txt -a -b 14 -c 09 -g 011111118 -p 4 -u -1 NACV no issues MEDC Cannot reproduce: Exit code: -1073741819 command: Winharp32.exe -f 16-04b.txt -a -b 16 -c 04 -g 011111118 -p 4 -u -1 IOPG no issues EC2000 GIUK Cannot reproduce: Exit code: -1073740940 command: Winharp32.exe -f 18-11r.txt -a -b 18 -c 11 -g 111111118 -p 4 -u -1 NACV no issues MEDC Fixed: Exit code: -1073741676 command: Winharp32.exe -f 20-05b.txt -a -b 20 -c 05 -g 011111118 -p 4 -u -1 Fixed: Exit code: -1073741819 command: Winharp32.exe -f 20-11b.txt -a -b 20 -c 11 -g 011111118 -p 4 -u -1 Fixed: Exit code: -1073741819 command: Winharp32.exe -f 20-11r.txt -a -b 20 -c 11 -g 111111118 -p 4 -u -1 IOPG no issues EC2003 GIUK no issues NACV no issues MEDC no issues IOPG no issues WestPac Cannot reproduce: Exit code: -1073740771 command: Winharp32.exe -f 26-06b.txt -a -b 26 -c 06-g 011111118 -p 4 -u -1 Cannot reproduce: Exit code: -1073741819 command: Winharp32.exe -f 26-06r.txt -a -b 26 -c 06-g 111111118 -p 4 -u -1

And...fixed another memory bug, EC2003 autotest batch was 100% successful after these changes. 2022.023 fix coded

Found and fixed a double-freeing of memory in eff102 (area defense) for a pretty specific situation of aircraft in a non-aircraft formation being shot down by surface to air gunfire. The test case was indeed EC2003 MEDC 3.0 as Blue where Red ships get within a Blue carrier formation and start shooting down formation air patrols. Re-running EC2003 autotest batch files now to see how much of an improvement is seen (this is without padding the memory allocations, so the most desirable situation).

Note to self: Combat3.c line 605ish around staff_warned with modification dates in 2021 is suspicious, examine it better.

At present I don't have a way for you to help. I logged every memory allocation in EC2003 MEDC 3.0 and didn't have any of my favorite memory bug of allocating the size of a pointer (4 bytes) instead of the size of the structure. That's rather unfortunate since they are relatively easy to detect when logging all of the allocations. So on to tougher things to fix.

A debug build of 2022.022 running under the autotest batch files for EC2003 MEDC had zero errors. Next up is turning off Optimization to see if that sneaks around whatever underlying problem is happening.

I removed the XML saving ability in the GE, that didn't help. Then I ran this with the debugger and the VS2022 debugger crashed so didn't get any useful information. Will try a debug build next.

EC2003 MEDC 3.0 seems to pretty consistently have a non-zero exitcode.

When using the autotest batch files against 2022.021 and 2022.022 Release builds, I'm getting assertions thrown in Stubs.c line 351, GetPtrSize. Even if I ignore the assertion, the GE exits soon afterward without warning. Instead of an exitcode of 0 (clean termination of the GE), I see an exitcode of -1073741819. I thought this might only be when using the AutoTest batch files where multiple copies of the GE are running simultaneously so I ran just EC2003 MEDC in single-file (one scenario at a time, one copy of GE running at a time) and still see the exitcode of -1073741819 for 50% of the scenarios (8 clean exits, 8 errors) so far. Error scenarios: EC2003 MEDC 3.0 Blue EC2003 MEDC 5.0 Blue EC2003 MEDC 7.0 Blue EC2003 MEDC 8.0 Blue EC2003 MEDC 9.0 Blue EC2003 MEDC 12.0 Blue EC2003 MEDC 2.0 Red EC2003 MEDC 4.0 Red EC2003 MEDC 5.0 Red EC2003 MEDC 6.0 Red EC2003 MEDC 7.0 Red

The system isn't set up that way, whomever created those BattleSets put the Player side orders into the scenario background (on purpose). There is no magic logic in the game itself that re-arranges how the orders are parsed. I agree on the Not an Issue though.

I haven't investigated yet but is this intentional in the EC2000 and EC2003 BattleSets? Since they are Red or Blue only, perhaps someone was 'smart' and pasted the playable side's orders into the Scenario Background. Does it happen in the others like Original GIUK?

That would qualify as a wishlist item by my measure. Issues have one part and I think that one part of overallocation is solved.

AllocateRounds does not take into account PH so considering layering that on top since after the fix, the # of rounds is underestimated...

lol, turned out to be even more simple, AllocateRounds already had a parameter of whether to take missile defenses into account or not. Flipping that from TRUE to FALSE for gunfire should fix the issue.

Note to TonyE: Combat5.c AllocateRounds is the generic function, see also AllocateARMs for a specialization. Consider another specialization for gunfire, AllocateGunfire perhaps.

Welcome back Randy, what is the name of the installer you ran (and perhaps its size)? From your file listing it looks like you installed a patch but not the full game before a patch. Or you installed the full game and patches into two different directories. I have 33 .rsr files for instance in my HC directory.

Neglected to post this earlier, should be fixed. HCE - 2022.016 - 2022-09-21 =========================== - Chg:32566 SE Valid target types shown in weapon listings (Platform Display) should match between GE and SE. In this case the GE was correct. The SE now uses identical code to accomplish this. Afterward, moved Repweap.c to Common\SRC\ and deleted GE\SRC\Repweap.c and SE\SRC\REPWEAP.C (thanks donaldseadog) https://harpgamer.com/harpforum/topic/32566-scenario-editor-not-separating-surface-attack-missiles-for-land-and-sea-specific-missiles/

I'm working on a much more comprehensive revamp of the HarpoonEvent structure for 2022.021. No promises that I won't just scrap it for what works in 2022.020 but if it does emerge, here is what is going into it so far: 1. Leverages the uuids I've been adding to key game structures. a) Adds a uuid to each HarpoonEvent so it can be uniquely referenced instead of depending upon a Group Id and Unit Id combination or order of saving in the saved game file to indicate a correct reference. This fixes I32501 again and better. b) References the associated unit, if there is one, by that unit's uuid instead of its Unit Id. c) References the associated group by its uuid instead of its Group Id in Scenario files. 2. Separates event type from the time trigger type to allow for more and easier additions of new event types