Hierarchy Module Document

[Curtis Lemay]

I agree that the AAA units need to be added to the Combat Report and will try to add that. I'm not sure that supply should be deducted due to the very short duration of AAA combat.

Deduct supply. The AAA combat should reflect actions over time, not a tactical duel of guns versus aircraft. In scenarios with turns involving weeks or months, this is certainly valid.

Combat supply deductions are independent of time scale. So they equate to different amounts for different time scales.

[sPzAbt653]

The Veteran part of the Untried/Veteran equation is a bit misleading. In TOAW terms, 'Untried' means that you don't know the exact combat value [Unit Proficiency] of a unit so labeled. Once an Untried unit is exposed to combat, its' status changes to Veteran, the only effect being that its' Proficiency is reset to a value + or - of its' starting Proficiency. Would there be a reason for any units to be left out of this equation?

If a scenario designer wanted proficiency to be static, then they could tick the 'Veteran' box for such units.

It would probably be more accurate for the labels to be 'Untried/Tried' instead of 'Untried/Veteran'.

[rhinobones]

. . . I want to change them from "D" to "AAA R#":

Are you going to make a distinction between anti-aircraft artillery (AAA) and surface to air missiles (SAM)? Patriot batteries might object to being called artillery.

Regards

[Lobster]

Time over target is very short for aircraft. I don't think the deduction should be different than the one for AS (Escort or CAP). Whatever that is should be about right. I'll have to check that, though.

One aircraft over a Combat Air Support target isn't a practical example. It would be several aircraft over an extended period of time resulting in multiple targets and an extended period of time. It would rarely if ever be a one and done.

[Curtis Lemay]

OK, I've added logging of AAA units to the Combat Report and Combat Chart.

[Curtis Lemay]

Here are the AAA units showing up in the Combat Report. The codes in the brackets will enable this to be added to the Combat Chart as well.

[Curtis Lemay]

And here is how they show up in the Combat Chart:

[Curtis Lemay]

Here is the revised Combat Chart Legend, showing how to interpret the AAA unit entries:

[Curtis Lemay]

Here's a look at the code for this (see where I added logging to the Combat Report). Note the part commented out on line 3096. So...Ole Norm originally had a supply deduction equivalent to the one for an AS Furball (I'm guessing that's about 1 per combat), but then changed his mind about it. Easy to add that back in and see how it works out. Stay tuned.

Edit: I also wonder about the logic on line 3087. Looks like an issue to me.

[Curtis Lemay]

Ok, I've fixed Additional item #9 (adding supply deduction and proficiency increase check to AAA units). And I fixed the logic bust in that line I noted in the AAA use routine (I listed that as Legacy Bug #31).

[Curtis Lemay]

Here I show how AAA units that are used get a 1 point supply deduction. They are also checked for a Proficiency increase (though no increase occured in this case). They remain untried.

[Curtis Lemay]

Here we see which AAA units participated in this combat. Now, closer units have better chances (before, all units in-range had 50% chances. ). (Compare to previous results: https://forums.matrixgames.com/viewtopi ... 5#p5247825).

[Curtis Lemay]

Here's the way the code has been changed (3096 & 3097 added, and 3087 modified). In line 3087, note that the electronic support check has a test for default levels for both sides => passing cancels any electronic support check failure. Also, now, the electronic and communication check passing are required. Then the range check is required too. Before, the electronic and communication checks could pass and the unit would be added even if it failed the range check. Or, the unit could fail either of the electronic or communication checks but still be added if it passed the range check. That is now changed. Passing the electronic and communication checks is now required (with the allowance for the factor on the electronic check above) and passing the range check is also required. Finally, note the change in the range check: Before the randomization occured AFTER the check against the range. So, all ranges within range had a 50% chance of passing. Now chance of passing is inversely proportionate to distance from the target (which was surely what Ole Norm meant to do).

Compare to the previous way here: https://forums.matrixgames.com/viewtopi ... 8#p5247828

Edit: The existing electronics check just compared a random test of each sides levels relative to each other (a feather-weight difference = superiority). I thought that was too severe (50% failure when levels were equal), so I made a new test that made a ratio of the two levels and made a random test against that ratio (2:1 ratio required for 50% failure, etc.).

[Curtis Lemay]

I'm setting Legacy bugs 12 & 13 to fixed. Also, I'm setting Legacy bug 19 to postponed.

I never could reproduce issue 13 until just recently. Of course, I can't be sure that what I'm seeing is exactly what that issue was about, but, for now, I'm assuming it is. Then, issue 19 is going to require examples from the Beta Test, or something similar to enable me to find the problems. So...it's being postponed till that test.

[Curtis Lemay]

Here, I attempt to save a unit to a specific folder using the "Save Unit As..." option:

[Curtis Lemay]

The unit file should be in the Hierarchy folder, but it isn't. Where is it?

[Curtis Lemay]

Well, I looked around for it and found it in one folder higher than the target folder. Note that the target folder name has been appended to the file name. In other words, the \\ is missing between the folder name and the file name:

My assumption is that this was the issue for those who did the save thing, then never could find the unit file. Also, note that .MAL files (map) and .OOL files (OOB) have the same issue.

[Curtis Lemay]

OK, I added code to insert the \\ in the right place (first checking that it's missing, just in case this issue reverses itself down the road) and now those files are written in the right folder. I've also confirmed that those files read correctly so the read path is correct.

[Ratbag55]

I am experiencing something that I do not know if it's "working as designed" or not:

When I am in Force Editor and I Copy Current Formation, a copy of the Formation is created with Formation Name "unassigned". This is what I would expect.

But when I choose Cut Current Formation, move to a new place in the Force Editor list and choose Paste Formation, strange things happens. The first time I choose Paste Formation, the name of the copied Formation is pasted into the Formation from which I have selected a unit. When I choose Paste Formation again, the units of the Formation I copied are now pasted in, but with a completely new Formation Name.

The behaviour I would be expecting when selecting Cut Current Formation and then Paste Formation is for the entire Formation including all units of that Formation to be cut from the list, and then have that Formation with all its units and Formation Name preserved be pasted into the list at the "place" in the list that I have selected.

I know this might not be entirely clear the way I descibe it, and I apologies if this have already been covered. Also not sure if this will change with the new nested hierarchy?

[Curtis Lemay]

I am experiencing something that I do not know if it's "working as designed" or not:

When I am in Force Editor and I Copy Current Formation, a copy of the Formation is created with Formation Name "unassigned". This is what I would expect.

But when I choose Cut Current Formation, move to a new place in the Force Editor list and choose Paste Formation, strange things happens. The first time I choose Paste Formation, the name of the copied Formation is pasted into the Formation from which I have selected a unit. When I choose Paste Formation again, the units of the Formation I copied are now pasted in, but with a completely new Formation Name.

The behaviour I would be expecting when selecting Cut Current Formation and then Paste Formation is for the entire Formation including all units of that Formation to be cut from the list, and then have that Formation with all its units and Formation Name preserved be pasted into the list at the "place" in the list that I have selected.

I know this might not be entirely clear the way I descibe it, and I apologies if this have already been covered. Also not sure if this will change with the new nested hierarchy?

I think you're describing Legacy Bug #6.