Wrong hex usage for defensive reserve activation?

[Stamb]

According to the living manual.

2.png (52.95 KiB) Viewed 758 times

Which also makes logical sense, however in the game units that join a battle via reserve activation use CV of a hex, maybe with fortifications, where they actually are.
I saw it before, but did not make a screenshot.
Today i got another example. You will never see 40 CV on map panzers in heavy snow in fortification 0. This panzer div joined the battle from an urban or heavy urban.

1.png (312.97 KiB) Viewed 758 times

For saves check server game vs Leumas

[K62_]

Fortunately, this is just a display issue. It's possible to generate some funny combat reports in '41 if you place an HQ in an urban location, like Smolensk. Any SUs, such as brigades, contributed by this HQ will be displayed in combat with a huge CV. The fight happens normally despite the display bug.

[Wiedrock]

Limiting the complexity and only looking at "SUs rolled", German defender and Fort Levels with Clear Terrain I found the following:
Note that all weapons have been set to range 0 and the TOEs are only containing several slots filled Rifle Squads and one with Support. Leaders are "9s".

1. The basic case, no modifiers involved at all.
   Final CV are looking completely normal seemingly using the initial CVs as base for their calculation.
   Initial CV is 279, this means the max finalCV is 279x1.25x1.25=436.

   

   visbugCV_normal.jpg (117.34 KiB) Viewed 552 times

2. The following is the most common/"normal" case with defender's Hex having a Fort level while the HQ's Hex is just Clear Terrain, nothing else.
   Defender gets buffed by the Fort Level while the rolled SU does not in any way get a benefit regarding its initial CV.
   Final CV are also looking completely normal seemingly using the initial CVs as base for their calculation.
   Initial CV is 985, this means the max finalCV is 985x1.25x1.25=1539.

   

   visbugCV_def Fort 5.png (789.61 KiB) Viewed 552 times

3. Now let's see how the final CV changes when we directly assign the SU to the CU.
   We get a max final CV of 1676x1.25x1.25=2619 due to the Fort 5 of the defender's Hex being properly applied to both units.

   

   visbugCV_both Hex Fort 5_direct assigned.jpg (114.97 KiB) Viewed 552 times

4. The "visual bug CV" can easily be reproduced as in the following examples.
   1. You can see the difference between initial and final CV clearly indicating it being a bug in example "A" in the following. Seemingly that one it is using the same initial CVs as for the first example I have posted above, without any Fort for their calculation.
      Initial CV is 970, which should give a max finalCV of 970x1.25x1.25=1516, but it doesn't.
      The final CV is the same/similar as using the base CV of the non-Fort example of ~280 which makes us end with ~430 (280x1.25x1.25) again.
   2. The next example should give the same final CV as the "directly attached" example above of ~2600, but it doesn't, instead it is ending with the same final CV as with the example 2 I have posted above, of about ~1530.

   

   visbugCV_HQ Fort 5.jpg (228.92 KiB) Viewed 552 times

[Joel Billings]

I couldn't follow the last combats and exactly what you thought was going wrong. Can you state what you think the last battle shows, and what about it is wrong. Thanks.

[Wiedrock]

I couldn't follow the last combats and exactly what you thought was going wrong. Can you state what you think the last battle shows, and what about it is wrong. Thanks.

The last two battles show the initial CV being affected by the 5 Fort Levels of the HQ Hex (very high initial CV of the rolled SU).
But the final CV calculation does not seem to use these initial CV values shown for the rolled SU, but uses those of the examples without Fort levels in the HQ Hex (which are ~140 instead of ~830).
So the final CV will be the same as if the HQ would not be standing in a lvl 5 Fort Hex, while the initial CV are boosted without affecting the final CV (that's the visual bug K62 said it is).

Attached the Scenario (see northwest of Odessa Region), you have to change the Fort levels depending on what to test.

[Joel Billings]

Ok, so you're confirming and providing a save that the initial CV is off, but the final CV is correct. Did I understand that right? If it's just the initial CV that is wrong, then the bug seems very minor.

[Wiedrock]

Yep that's it.

Stamb's post shows it applies to RESERVE Units (likely Density or Terrein defense Modifier or Fort).
My post shows that it applies to SUs "rolled" (with Fort). So it may be affected by Fort/Terrain/Density/Weather-Road (in whatever hex).


The following is a brainstorm/ToDo I have noted down on some variants/what one could look at to see what factors are causing issues to what types of units (to see if it's all "fake CV" or in some cases "real CV":

Defense:
Factors are:

• Terrain
• Density
• Fortifictations
• (+special Winter 41 Heavy Snow stuff)

Units are:

• CUs (Defender Hex)
• RESERVES behind
• SUs attached in Defender Hex
• SUs attached to RESERVE
• SUs in HQs

....now look up every factor for each type of unit

[confirmed] Fortification HQ Hex → rolled SUs

Attacker:
Factors are:

• Density
• Weather/Road(also see overall country road network (at least for the SUs))
• river Disruption
• (+special Winter 41 Heavy Snow stuff)

Units are:

• CUs (current/attacker Hex(es))
• RESERVES behind
• SUs attached in attacker Hex(es)
• SUs attached to RESERVE
• SUs in HQs

....now look up every factor for each type of unit

Bonus:
Check if shown CV is actual CV or just "visual bug" for each case/combination. [preliminarily confirmed for tested cases]

Related questions that come up:
- which CV is used for SCOUT calculations
- which CV is used to determin RESERVE committments
- which CV is used to cause "Halted" attacks at longer ranges

[Wiedrock]

Note: All Editor testing.

TLDR: "New Bug" which may be cause/related to all the other issues. The RESERVE Unit's final CV uses CV modified by CPP (so maybe the attackingCV) while the initial CV uses defensiveCV (or non-CPP affected attacking CV).

---

Working on the combinations. Marking the bugs red the working stuff green.
[the Hexes the units are standing in are being looked at]

visbug_chart_WIPv1.jpg (119.37 KiB) Viewed 461 times

While working ont his I encountered some generous rounding in the Rough terrain (still being investigated - very likely some oddity/generous rounding with the Density). This lead to some idea to have some CPP added. So in the following example you can see the RESERVE one time with 0CPP and one time with 100CPP being committed.
The 0CPP has no bug in it. It uses the defensive CV as the initial CV, which in this case should be fine (it's the same number as the attacking CV), but for the final CV in case of the 100CPP unit it seems as if it uses the attacking CV, making the 100CPP variant to have a massive final CV increase.

0CPP calculation works out:
275x1.25x1.25=430CV max finalCV.

100CPP variant uses:
(141+133x2)x1.25x1.25=636CV max finalCV.

---

So the whole issue/visual bug MAY be related to initialCV using the DefensiveCV/Modifiers while the finalCV uses the AttackingCV/Modifiers (or something like this).

[Wiedrock]

The FoW is lifting.

CPP affecting finalCV also goes for the rolled SUs with 100CPP on the defense, so in the following we can combine RESERVE and rolled SUs.

Attached first example has both, RESERVE and SU inside HQ at 100CPP. The math works out again.

visbug_CPP_RESERVEandSUrolled_example1.jpg (446.75 KiB) Viewed 428 times

Furthermore (here we may see the mentioned rounding (but may also simply be related to the lerger numbers)), above you can see the same defense in a Rough Hex.
The 100CPP from the test before we can combine with a +90.3% (Edited Mot. Division's TOE bonus CV in dense terrain) for the RESERVE and the rolled SU and the math works out. This is essentially the same calculation as for an attack into that hex would be done (for the SU and the RESERVE).

The indicators are all pointig towards:
initialCV = defensive CV - using a unit's own Hex to a larger degree
finalCV = likely attacking CV - using attacking CV as if the unit would attack into the Defender's (friendly) Hex. It is impacted by CPP and defender's Hex Density (need to look up which Hex's weather+road modifier is being used).

Note: Only tested German side, as shown. All Editor tests. Still far away from having all combinations tested.

[Wiedrock]

Playing a bit more with Density there is something off by itself, I can't rly make sense of what is going on tbh.

The current results of testing, weather seems to not impact the "Defense" in this context in any way it appears, after spotting some oddities with it in attacks I decided to leave out Weather completely for now.

In General when it comes to this "visualCV bug", Attacks seem to work and the only issues arise during defense (red marked pairs).
Weird is (as an example), that initialCV of RESERVE CU is impacted by the Fort and Density of the Hex it is standing in but not the Terrain modifier itself (the finalCV is likely completely differently calculated as it seems so this is just pointing out weird things besides this).
For the rest see the Chart below (no guarantee for correctness, definitely confusing).

visbug_chart_WIPv2.jpg (250.27 KiB) Viewed 393 times

As pointed out in the recent post there are weird things in dense terrain and the CPP changes final CV.
Somethign I will try to expand upon (simply by showing it) without being able to make sense of it.

So below you see the 0CPP example ending with way higher finalCV than it should be able to. Ending with 3923 while the theoretical max should be ~3637 finalCV. If we factor in the Density (which for this TOE increases CV by +90.3%), the math works out.

The second example with 100CPP we need to apply the CPP bonus, the Density Bonus and would still not get the rigth math, we would expect a max CV of 4584, but got 4861.
So no idea what happened there, possibility is that it for some reason used the actual starting CV (which for this TOE is always ~141CV), then the math works out but this is honestly just trying to make sense without it making sense at this point.

Somethign is off.
In Defense.
Related to CPP.
Related to Density.
...ignoring Weather.

visbug_Density issues.jpg (732.13 KiB) Viewed 393 times