TonyE

Calling it good enough for now in 2021.014. There are a number of unrealistic edge-cases you can make happen, especially speed illegal for a specified altitude but I'm no longer seeing corrupted speed displays and such.

lol, I bet it was a friendly angle! Younger son is at 1.5% height for his age (last week was his first time over the first percentile, yay!), older son is at about the 15th percentile. In short they are not expected to be tall!

Still no crash here. Did you disable those ExportDLLs? Perhaps we will get lucky and 2021.013 fixes it by accident. Here are some choice MessageLog entries. To Go 5:21:49:08 9xStorm Shadow II (BZM) Missiles Hit Enemy SS-27 Sickle Bty 011 (VZm) To Go 5:21:49:03 The SS-27 Sickle Bty 011 unit ZE000, a SS-27 Sickle Bty class, is destroyed! To Go 5:21:49:02 11xStorm Shadow II (BZM) Missiles Hit Enemy SA-12 Bty 019 (VZm) To Go 5:21:48:59 The B-1B Lancer is firing 11 x AIM-ABM1 AAMs at aircraft. To Go 5:21:48:59 The B-1B Lancer is firing 2 x AIM-ABM1 AAMs at aircraft. To Go 5:21:48:59 The B-1B Lancer is firing 11 x AIM-ABM1 AAMs at aircraft. To Go 5:21:48:59 The B-1B Lancer is firing 2 x AIM-ABM1 AAMs at aircraft. To Go 5:21:48:58 25xStorm Shadow II (BTM) Missiles Hit Enemy SS-20A Saber TEL 003 (VZm) To Go 5:21:48:57 1 enemy Tu-160M Blackjack of group (TPA), has been shot down. To Go 5:21:48:57 10 enemy Tu-160 Blackjack of group (TPA), have been shot down. To Go 5:21:48:57 The SA-12 Bty 019 unit YQ000, a SAM SA-12 Bty class, is destroyed! To Go 5:21:48:53 The SS-20A Saber TEL 003 unit YB000, a SS-20A Saber TEL class, is destroyed! To Go 5:21:48:50 33xStorm Shadow II (BZM) Missiles Hit Enemy SA-12 Bty 019 (YQm) To Go 5:21:48:48 0 of 2xStorm Shadow II Missiles Shot down by 2xSA-16 Gimlet (Igla-1) (FPh=25 Ph=25, DPh=50) To Go 5:21:48:26 1 enemy Y-8J AEW of group (ZMa), has been shot down. To Go 5:21:47:21 5 enemy Tu-142MZ Bear F of group (ZVa), have been shot down.

I made matching changes to the shared pascal code in uHCDateTime.pas as well. Side note, I wrote the original code while on honeymoon in 2015. What a wife :).

I've widened that particular buf variable to 360=_MAX_PATH+100 characters (Windows has a quasi-limit on paths of 260 characters) and expect it will result in no more overflow for you.

HCE - 2021.013 - 2021-12-## =========================== - Chg:31941 GE The Day, Month, Year display of GameTime was not incrementing the month at the end of a month so it looked like Groundhog Day at the end of every month. Fixed. Also fixed a month bug. (thanks donaldseadog) https://harpgamer.com/harpforum/topic/31941-game-time-date-doesnt-progress-at-midnight/

So far cannot reproduce this one in a pre-release build of 2021.013. I gave the 0025 and 0023 saves a try. I see you have three ExportDLLs enabled. EduMetrics should not be a problem but you might try disabling lazTurncoat and ToolBox to see if the crashing stops, otherwise I'm going to need more instruction on how to reproduce.

Hmm, there are 3,090 instances of 'buf' in the source code. One that stands out is the scenario filename including path. What the is the full path and filename of your save? Example: C:\Matrix Games\HUCE\SomeFolder\SomeScenario.scq There will be a buffer overflow if that full path + filename is slightly more than 150 characters.

Eric, so far I cannot reproduce with the scenario and database you provided. Do I have to do anything special? I tried both saving the scenario File\Save and File\Save As (using your pristine copy before each try).

Hehe, hadn't noticed that, I'm hoping to check it out later today.

It was another non-traditional celebration but a very Merry Christmas. My brother and now his younger son caught Covid so we were only able to get together with my sister's family on Christmas Day instead of my mom and her three kids' families as originally planned.

I had hoped to get one more build out before being swept away by the holidays but didn't quite make it. We had a day of maintenance (hair cuts, snow shovelling, bank deposits, laundry, cookie making, Christmas show watching, paper snowflake making, dentist & doctor visits) before the main attractions start tomorrow! Be well and joyous, see ya next week or a little sooner if I sneak away

You may have attached the wrong zip file, all I see in it is your commondb.res.

Lots of logic involved here. Some rules that I have implemented: 1. Don't allow changing speed/alt/depth from the Unit window for single unit groups. You should be using the Group window. 2. Don't allow changing speed/alt/depth from the Unit window for the first unit in the group. You should be using the Group window to set the stage then use the Unit window to affect 'child' units. This isn't a perfect solution because the first unit in the group may not be the center of the universe. 3. Don't allow changing speed of slaved units. These units are meant to maintain a specific distance from the group center. This is a common status for Main Body (center ring) units. You can still change altitude/depth. I'm still working through a problem with air group speeds when changing the altitude of a unit in the air group, speeds get messed up.

GE fixed so that your test case of an aircraft unit in a fixed base group no longer crashes the GE. Test scenario uses HCDB2. Additional Test cases to try: -1. Aircraft unit in air group -2. Aircraft in a carrier group -3. Aircraft in a ship group -4. Ship in ship group -5. Ship in fixed base group -6. Submarine in submarine group -7. Submarine in a ship group -8. Submarine in a fixed base group HCE - 2021.013 - 2021-12-## =========================== - Chg:31914 GE Aircraft unit speeds can now be changed in the Unit window without crashing the GE. (thanks donaldseadog) https://harpgamer.com/harpforum/topic/31914-ge-2021009-crash-editing-speed-in-unit-window-for-aircraft-units/ UnitSpeedAltTest_v1.zip

Fixed coded! Yay team . I hadn't done serious trigonometry in a while but had to pull it out after 10pm. Shortly after I gave up for the night it came to me so of course I popped back up and that bit worked. In short, instead of storing unit offsets from group center as pixel x, y values, we now store them as distance units. Distance units are a strange unit of measurement, 6211 DUs per nautical mile that the original developer conceived or copied. HCE - 2021.012 - 2021-12-22 =========================== - Chg:31898 GE The formation editor will draw units in the correct location now for most situations. This includes changing the group map zoom level while the formation editor is open. Limited testing also suggests units will properly adapt to changing of formation zone sizes. When you select a unit in the unit list, the unit should have a dotted box drawn around the current position of the unit and the formation zone(s) it is assigned to should be highlighted. This means the units will not always show in their assigned zones (aircraft transiting to their formation position, ships catching up after a formation or course change, etc.). The Unit window will show the actual positions of friendly units, even for the group that is currently having its formation edited. That can give you some manner of before/after comparison. (thanks eeustice) https://harpgamer.com/harpforum/topic/31898-ge-formation-editor-units-dont-draw-at-correct-location-on-group-map/

Making good learning progress on this which means I have the units drawing in the expected spot at each zoom level but not in a way that can be released for public consumption. Call it proof of concept that now needs to be operationalized.

Fixed in 2021.012 2021.012 using the test scenario attached to the issue: a) As Blue: Sink ship first, shoot down plane second. Blue minimum victory achieved dialog is shown. Blue total victory achieved dialog is shown. b) As Blue: Shoot down plane first. Blue minimum victory achieved dialog is shown. Next sink the ship. Blue total victory achieved dialog is shown. 2021.012 using my total victory condition only test scenario: a) As Red: Run helo out of fuel. Blue minimum victory achieved dialog is shown. Next get Red ships on station. Red total victory achieved dialog is shown. This is correct since Red has no minimum victory conditions defined. Next run helo out of fuel. Blue total victory achieved dialog is shown. There are no Blue units remaining so the game ends, Red is declared the winner in the no Blue units remaining dialog since Red reached total victory first.

Updated to version 24 to get rid of the "Oh Crap" dialog 😇

This is what I'm talking about people, awesome! donaldseadog took it upon himself to test simple combinations of victory conditions and found at least this one that isn't working as expected. For the rest of you, do more of this please to get a better simulation!

Fix coded for 2021.011. Turns out I wrote this issue/bug in 2010. Oops.

Fixed in 2021.011. Instant Action will not trigger if a BattleSet, Scenario, or Saved game is specified on the command line. Also, Instant Action now has EC2000 in its purview, assuming almost all users have HUCE and in turn the EC2000 BattleSets.

Fixed in 2021.011, thanks donaldseadog! Since there is no way to select sectors (pie slices) in the main body (center ring of formation), the game assumed it was the first sector, 0-44 degrees. I added code to look 0-359 degrees if the unit is assigned to the main body. if (ring > 0) bearing = random(45); else bearing = random(360);

Confirmed in 2021.010. The P3s in the Main Body only appear to be patrolling in the 0-45 degree or so slice.

Marking as "Not an issue" since I think ohstop straightened things out by getting the game installed correctly. If not, please provide the requested information.