Matrix Games Forums

Telumar wrote: Mon Jul 27, 2026 6:50 am

Curtis Lemay wrote: Sun Jul 26, 2026 8:16 pm

Telumar wrote: Sun Jul 26, 2026 7:51 am

That's a good idea! The info panel might also be the realm that could harbour the two digits behind the comma

Unfortunately, it turns out that the info panel is only used by graphical objects like buttons, checkboxes, etc. Straight text doesn't use it. TOAW still has things to teach me.

Fortunately you have the power to change that

If my name was Ralph, and I had a few spare months.

I've now fixed Hierarchy bug #38. Units with very low equipment counts but with subordinate attachments couldn't resist overruns. The problem was difficult to find => impossible without the debugger. I had expected that some routine had omitted the strength from the subordinates, but that wasn't the issue => the defenders had full strength accounted for. Rather, the overrun check also totals active and passive equipment for the defender and if more than 90% is passive it gets auto overrun. And the routine that checks for active/passive ratio had omitted the contributions from the subordinates. Since the superior only contained a commander (passive) regardless of the unit's total strength, it was rated as 100% passive and ran away.

I fixed it so that the subordinates were included in the active/passive check and it mostly worked. (I had to fix another issue I introduced with the fix: I was using the built-in "current player" value, and the units that were being checked were for the non-current player instead. I finally got it all corrected and it is now fixed.

This makes me think there may be lots of other routines that impact stuff other than strength that still need subordinates included. I'll have to make a closer checkout of that issue soon.

Here is Page 1 of the Unit Report for the defender in one of the overrun attacks. Note that its only equipment is a commander (passive equipment):

But, here you see on Page 2 of the Unit Report that the unit also had a bunch of subordinate units attached (all huge active equipment counts). It should have been almost 100% active equipment. But due to the omission of the subordinates to the passive check, it was rated 100% passive:

Here are a suite of overrun attacks about to be attempted. Note the huge sizes of the defenders and tiny sizes of the attackers. Yet, before the fix, all four were consistently overrun. After the fix, none could be overrun => correct.

Curtis Lemay wrote: Tue Jul 28, 2026 6:26 pm

If you would add a space between Manpower and (% of Auth) as well as one between the (manpower) number and the opening bracket indicating % it would be much better to read. Like this:

Manpower (% of Auth.): 1190 (99,17%)

....

Of course "Manpower Estimate: 1190 (99%)" would even be better

Telumar wrote: Tue Jul 28, 2026 7:27 pm

Curtis Lemay wrote: Tue Jul 28, 2026 6:26 pm

If you would add a space between Manpower and (% of Auth) as well as one between the (manpower) number and the opening bracket indicating % it would be much better to read. Like this:

Manpower (% of Auth.): 1190 (99,17%)

....

Of course "Manpower Estimate: 1190 (99%)" would even be better

Alright, done.

Thanks - much better

Curtis Lemay wrote: Mon Jul 20, 2026 9:13 pm I've fixed Hierarchy bug #42. Attachment checkboxes weren't having any effect for subordinated units.

Turns out, I was checking a subordinate for attachment rules and not the superior unit's rules. Corrected that and it works fine now.

Well, I spoke too soon about this issue. There was a deeper issue that didn't show up until I made a more thorough checkout. Turns out I wasn't comparing the unit to be attached with the parameters of the unit that had orginally occuppied the slot. I finally got that corrected and (I think) it's now fixed.

Now I'll get a new version up ASAP. Edit: Done!

Since I posted 4.2.0.27, I got a flood of new hierarchy bugs from the testers. I've just fixed Hierarchy bugs #44 & #45. In the Editor, I wasn't clearing the unit detachment flag to OFF when a subordinate unit was added to a superior. I hadn't noticed since, if fresh units are used for everything, those flags were automatically clear to start with. But, Telumar managed to make a unit where they were set to ON instead, and thus the problem. Now the flag is properly set to OFF upon adding.

I also found that it was possible to do subordination with OFF-MAP units, IF the Superior was also OFF-MAP. Now, a check is made to ensure the superior is ON-MAP and this is no longer an issue. Maybe designers would have liked that ability, but I prefer to be safe.

Here's the OOB-Units report for Telumar's test scenario. Note that all units were undeployed at start (thus allowing the issue of doing the subordination with undeployed units). Since I changed that so units have to be placed on map to do subordination, I deployed the units that had the issue.

Here's the problem: Before the fix, attaching the subordinates produced this issue => subordinates are attached but detached at the same time.

This shot shows that the units (superior and subordinates) must be on the map to do subordination:

Here's the unit before subordiates are attached:

And here is after successfully subordinating the units (after the fix):

I've fixed hierarchy bug #47. With the expansion of unit and formation names from 16 to 32 characters, the name slot on the Combat Chart no longer had enough space for those larger names.

I fixed it by doubling the space (from 250 to 500) and the names should now easily fit:

Here's an example showing an extra large name fitting on the chart:

Note: This name had an additional issue: The end of its name - "Support" - triggered the "Port Attack" attack-type (because of the ending "port"). It's name ended in "Su", and it's attack-type was listed as "P". I added a initial space to the search for that attack-type and you can see that the name now ends correctly in "Support" and the attack-type is corrected to "A".

I fixed Hierarchy bug #46. The error was in how the code read Designer Preferences. Older versions had to omit a portion of the current list of preferences to stay in sync and I bungled that. Now its fixed. Two weeks to fix one bug.

I've fixed Hierarchy bug #48. Turns out, the issue was that Under Orders Movement didn't work if the path was longer than the unit's remaining movement points. I removed that impediment and it now works fine.

Here is an example from my Killer Angels 1863 scenario: Hill's HQ (at Chancelorsville) is attempting to move "Under Orders" towards Lee's HQ (north of Ashby's Gap). Hill's HQ only has 4 MPs left so Lee's HQ is far out of range to reach in only one turn. Before the fix, Under Orders Movement wouldn't generate any path to the target.