Hierarchy Module Document

[Curtis Lemay]

Actually, the values do accumulate to something that approximates reality:

Add scenario complexity to that spreadsheet and you'll have all the funny numbers in one place. What does a number like 43,853 actually mean?

Maybe you should ask your scenario beta testers and see if they find your numbers more, or less, informative than what I proposed. After all, the prime function of the beta testers is to give you input, recommendations and changes to incorporate.

It's a manpower estimate for a scenario side. For example, take the numbers for my Shiloh 1862 scenario and compare them to historical numbers. For Shiloh they are found here:

https://en.wikipedia.org/wiki/Battle_of_Shiloh

Note the spreadsheet comparision.

[Telumar]

Actually, the values do accumulate to something that approximates reality:

Add scenario complexity to that spreadsheet and you'll have all the funny numbers in one place. What does a number like 43,853 actually mean?

Maybe you should ask your scenario beta testers and see if they find your numbers more, or less, informative than what I proposed. After all, the prime function of the beta testers is to give you input, recommendations and changes to incorporate.

Bob wrote earlier - way earlier - that he introduced manpower estimate to calculate chances for leaders killed in combat (Bob correct me if I am wrong). As for now it only serves this purpose but why not have it displayed to players? It adds a nice bit of chrome. However I think there is more planned down the road than just this.

[Curtis Lemay]

Actually, the values do accumulate to something that approximates reality:

Add scenario complexity to that spreadsheet and you'll have all the funny numbers in one place. What does a number like 43,853 actually mean?

Maybe you should ask your scenario beta testers and see if they find your numbers more, or less, informative than what I proposed. After all, the prime function of the beta testers is to give you input, recommendations and changes to incorporate.

Bob wrote earlier - way earlier - that he introduced manpower estimate to calculate chances for leaders killed in combat (Bob correct me if I am wrong). As for now it only serves this purpose but why not have it displayed to players? It adds a nice bit of chrome. However I think there is more planned down the road than just this.

See 5 b here:

https://forums.matrixgames.com/viewtopi ... 2#p5201782

[Mkha2023]

Just wanted to thank you and the betas for the effort put in to try these improvements for the update.

[Curtis Lemay]

OK, first, I've determined that Hierarchy bug # 18 (flag unit destroyed while unsupplied didn't always kill the commander) is a real bug (which I didn't have evidence of till now). My problem was that my test scenario was only a single combat, that eliminated only one commander. But the new tests show that the issue only occcurs about 5% of the time, so that test couldn't catch it. But my new test used 10 combats that I ran 10 times => for a total of 100 combats. That was enough to reveal the issue. Kudos to Josant for originally posting the issue => he was right!

I've now fixed this issue. I couldn't find the exact cause, so I decided to repair any ommisions after the end of each combat. This was a pretty complicated process but tests show that it worked.

[Curtis Lemay]

Here was the test scenario with 10 combats with the defenders unsupplied. Each defending stack had one formation with one commander assigned. Combat eliminated each stack and should have eliminated all 10 commanders.

[Curtis Lemay]

I ran the scenario 10 times for a total of 100 combats. Here are two complete trials. Note that 5% of combats both times failed to eliminate the commander even though the flag unit was destroyed while unsupplied.

[Curtis Lemay]

Some of the failures showed the flag unit had been subdivided. To check this, I replace the Infantry Icon with the HQ Icon (which doesn't subdivide) for the flag units and ran another trial. The results are attached. Note that there are less failures but there are still two left.

[Curtis Lemay]

Rather than look forever for the remaining cause, I decided to attack it from a different direction: I would check the result at the end of the combat and if the defending hex was unsupplied and the defending flag unit in the hex was destroyed, I would check if the commander remained assigned to its formation I would change that commander to "Captured".

I also decided that commanders that had become "Wounded" would also be changed to "Captured". Wounded commanders could return to action if they recovered from their wounds so this was an additional benefit of this method. (Some may say that wounded commanders could be evacuated by air before the defending hex fell. Even if that has some basis, it is too compex for now.)

In the attached test, commanders that were originally captured or killed are unchanged but if wounded or left assigned, they were changed to captured.

[Curtis Lemay]

Next, I created a similar test scenario where side 1 is the one being destroyed unsupplied => to check out the procedure for that side.

[Curtis Lemay]

It was fortunate that I did that since there was an issue with the other side. But I fixed it and the results are shown. Again, wounded and assigned commanders were changed to captured.