Attack Charge now only affects Base-Attack-Classes (4, 3, 31)

:arrow_forward: GAME INFORMATION

  • GAME BUILD #: 101.101.61591.0 8647032 (new DLC update is cause of bug)
  • GAME PLATFORM: Steam (not related to bug)
  • OPERATING SYSTEM: Windows 10 (not related to bug)

:arrow_forward: ISSUE EXPERIENCED

Before the update, you were able to control which attack class was going to be affected by the attack charge by putting it on top of the attack class list.
This allowed you, for example, to make the charge only affect cavalry. Since the charge is activated no matter what armor classes the attacked unit has, this meant that it was possible for the charge to be “wasted”, which wasn’t necessarily a bad thing though, and I don’t want that to be fixed tbh.

Since the new update, even if you put an attack class on top of the base melee class for instance, the charge will still be applied to the unit’s base melee attack class.

Now what’s weird is that Coustilliers already have some other attack classes above their melee attack. My guess is that the attack class had to have an attack value that’s greater than 0 for it to be applied over one of the base attack classes (3, 4 and 31), and since Coustilliers never get any bonuses for their other attack classes (Archers [15], All Buildings [11], Standard Buildings [21]), there was never any problem with their Charge only affecting archers (attack class 15 is on top of the list).

:arrow_forward: FREQUENCY OF ISSUE

  • 100% of the time / matches I play (ALWAYS)

:arrow_forward: REPRODUCTION STEPS

To see the “correct” behavior before the update, a developer has to do the following:

  1. Download this mod, which was made with the dat file of the previous version:
    Gofile - Free file sharing and storage platform
    https://files.catbox.moe/f33rmm.zip (alternative download in case GoFile’s servers are overloaded)
  2. Run a game instance with the version right before the DLC
  3. Run the Scenario Editor with the mod
  4. Set up some combat tests with the following units:
  • Pikeman - Light Cavalry
  • Pikeman - Long Swordsman
  • War Elephant - any unit

To see the behavior since the update, change the Pikeman’s attributes to the following (the same as in the old mod I provided) and place it in the same 2 combat test scenarios:

  1. Add a charge attack (Charge Type 1 or 3) (not adding a Special Graphic might cause a crash)
  2. Remove all attack classes
  3. Add a Cavalry attack class (8) and a Base Melee attack class (4), and put the Cavalry attack class on top

:arrow_forward: EXPECTED RESULT

  • The Pikeman’s charge attack only affects its cavalry attack class (8) since it’s on top of its attack class list, thus dealing more damage to the Light Cavalry with its charge, but not dealing more damage to the Long Swordsman.
  • The War Elephant’s charge attack affects its base melee attack class (4) since it’s on top of its attack class list, thus dealing more damage to all units with its charge.

This however, works not as intended in the new update, and instead, the Charge seems to be applied to the unit’s Base Attack class at all times.

UPDATE!
I played around with it a bit more, and the charge has no effect at all when the unit doesn’t have one of the base attack classes. So if you give a unit and an attack charge and only the cavalry attack class for instance, the charge will have no effect at all.

:arrow_forward: IMAGE


^ Relevant Pikeman stats in my updated mod version. Specific stats have changed, but the principle is the same.


^ Relevant Pikeman Stats in my old mod version, where things still worked.

:arrow_forward: CATEGORY

Modding

:arrow_forward: Priority

Probably low, since not many people seem to use it like this anyway

This change is intended. Thank you for the report.

Since it’s intended, would it be possible to add a new flag which dictates which attack class the charge is applied to?

Actually, why intentionally remove interesting ways to use some mechanics? In no way could this have been required for some of the new changes to Charges in the update, and therefore, this should get fixed.