bugfix(armorstore): Create overrides for ArmorTemplate data from custom maps to avoid CRC mismatch in the next multiplayer game session

[Caball009]

• Closes Mismatch in ArmorTemplate data after playing a map with map.ini with changes to the armor templates #1976

Implemented an override system for the ArmorStore like the ThingFactory to avoid potential mismatches because the original ArmorTemplate data is overwritten and not restored.

TODO:

• Make implementation / code resemble that of the ThingFactory as much as possible.
• Replicate in Generals.

[Mauller]

I guess we can do something similar for weapon templates as well?

[xezon]

Not directly related:

Can we perhaps make a change to streamline the override code between classes and then provide some code to avoid this boiler plate code in each of these classes that do overrides? Perhaps some template functions that help set it up.

[Caball009]

I was also thinking along those lines. I figured I'd start with the simplest of the classes that need overrides to see what it's required and what the review comments would be.

@Mauller I'll see if I can find a way to reuse the same code for all these INI parsers that require overrides.

[xezon]

Ok how do you wish to proceed with this matter?

Possible strategy:

1. Clean up all existing INI override code and streamline their implementions
2. Provide helper code for all INI override boiler plate code and place them in EA code
3. Add INI overrides with helper code to all remaining classes that need INI overrides (very complex)

[Caball009]

I've started with this. I need to check out all INI overrides, though, because some classes do stuff that others don't.

I think I can show the code I'm working on in a couple of days.

[Caball009]

@xezon #2083 I'm thinking of streamlining it like this.

[bobtista]

The override chain is created, but I don’t see where existing armor references begin using its final node.

INI::parseArmorTemplate() stores this lookup result unchanged (INI.cpp:1266–1269), while ArmorTemplateSet stores a raw const ArmorTemplate* (ArmorSet.h:65) and returns it unchanged (:81). Because the base data is normally parsed before a later map.ini appends its override, those stored references continue pointing at the base template.

This appears to be the missing consumption step described in Override.h:40–44: a container holding an overridable pointer should use OVERRIDE, or otherwise resolve getFinalOverride() at a centralized access boundary. Could ArmorTemplateSet use OVERRIDE, or provide equivalent resolution before the armor is used? ArmorStore::makeArmor() is another possible boundary, since ActiveBody.cpp:270 passes the stored template there.

Centralizing this is important—the consumer-side omission fixed separately in #2160 shows how easily callers can forget it.

Could the PR also verify that:

• a map.ini armor override affects damage during that match; and
• the original armor values return after leaving the match?