Hierarchy Module Document

[Curtis Lemay]

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.

[Curtis Lemay]

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.

[Curtis Lemay]

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):

[Curtis Lemay]

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:

[Curtis Lemay]

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.

[Telumar]

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

[Curtis Lemay]

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.

[Telumar]

Thanks - much better

[Curtis Lemay]

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!