feat(balance): Use weighted averages for armor values

[RobbieNeko]

Purpose of change (The Why)

The docs previously were lying and claiming a weighted average was in use, when in reality it was a straight average. In the Discord, we agreed that some sort of weighted average was a good idea due to armor values likely being balanced around this idea for multi-material armors.

Describe the solution (The How)

• Weights the armor values of multi-material armors:
• "Primary Material" is multiplied by 60%
• All other materials are multiplied by 40% / number of secondary materials.
• "Primary Material" is either specified in the underutilized JSON field or it's inferred to be the first in the list of materials
• Change how we process the materials on items so that it doesn't initially place them into a set
  • Without this change, the primary material implicitness from ordering doesn't work correctly whatsoever thanks to sorting
  • With this change, it is possible to put multiples of the same material in an entry, but it won't actually do anything for armor values and will just look weird
• Add a test to make sure we don't regress (makes sure that the material ordering is respected, compare a testing copy of the O-yoroi to a testing plated leather armor)

Describe alternatives you've considered

• Weight the primary material at 1, so that multi-material is straight upgrade over same thickness monomaterial

Kheir and Chaos both suggested that it'd be more preferable to have it between straight average and monomaterial.

Testing

• Compiled
• Loaded into a world
• Protection values on multi-material armor went up, mono-material armors remained the same
  ANBC suit for multi-material example:
  
  
  Kevlar vest for mono-material example:
  
  

Additional context

Not as grand of a swing as I expected generally, but still a nice little boost to the multi-material armors.

This does not contain any manually setting the primary material field for items, that can be done in a separate PR.

Checklist

Mandatory

• I wrote the PR title in conventional commit format.
• I ran the code formatter.
• I linked any relevant issues using github keyword syntax like closes #1234 in Summary of the PR so it can be closed automatically.
• I've committed my changes to new branch that isn't main so it won't cause conflict when updating main branch later.
• I understand that, unless specified otherwise, my contributions will fall under the AGPL v3.0 and/or CC-BY-SA 4.0 licenses

Optional

• This is a C++ PR that modifies JSON loading or behavior.
  • I have documented the changes in the appropriate location in the doc/ folder.
  • I have added a test to the tests run in order to prevent regression in the future

[autofix-ci]

Autofix has formatted code style violation in this PR.

I edit commits locally (e.g: git, github desktop) and want to keep autofix

1. Run git pull. this will merge the automated commit into your local copy of the PR branch.
2. Continue working.

I do not want the automated commit

1. Format your code locally, then commit it.
2. Run git push --force to force push your branch. This will overwrite the automated commit on remote with your local one.
3. Continue working.

If you don't do this, your following commits will be based on the old commit, and cause MERGE CONFLICT.

[RobbieNeko]

Thank you mighty tree of formatting, I hope you enjoyed your c++ meal

[chaosvolt]

Woooo boy, this is gonna affect a shitton of items that'll now have to be checked for differing values isn't it...like, if this automatically grabs the first material on the list and prioritizes it, it's gonna rapidly turn into a full overhaul...

[RobbieNeko]

Bash is usually only a 1-4 point bump, cut and ballistic depend on whether kevlar is involved or not

[chaosvolt]

So there is a big flaw in this PR: it assumes that what order the material is defined in the JSON actually determines what is the primary material.

Easy example to test: plated leather armor uses "material": [ "leather", "iron" ], while samurai armor uses "material": [ "iron", "leather" ]. They both have material thickness of 4. Logically you'd expect them to pick different primary materials and thus be slightly different, right?

Instead, they're both considered to be iron/leather (90% chance it's alphabetical order by material ID), so their armor values end up being identical. Warning players and contributors about this is going to a LOT harder, it's not "first on the list" but which is first in the hardcoded way it determines which of its materials will be picked first (again, fairly certain it's alphabetical order by material ID), and we're gonna have to make MUCH HEAVIER use of primary material if we want this to actually vary for multi-material items.

[RobbieNeko]

Fixed

[chaosvolt]

Okay I'm looking at this, and as expected this is going to be a headache.

So, here's plated leather armor as of build 2025-02-24:

And here's plated leather armor in this PR, after it's been fixed to show correctly as being leather/iron instead of iron/leather:

The primary material getting increased weight in the material calcs than it would under a pure average means the armor values are expected to go DOWN, not up.

[RobbieNeko]

Per suggestion by Oren in the Discord, switched to a 60% primary (40%/number of secondary materials) secondary approach

[chaosvolt]

Tested, wyrmskin armor no longer gets a jump in armor values and plated leather armor now actually gets shaved down in protection slightly. Again, apologies for not realizing sooner that "75% plus 50% means multi-material armor gets a freebie bonus in protection over the same thickness of mono-material armor" was intentional and not a bug, I would've spoken up sooner if I'd been paying attention and did the math on that.

As noted, I still lean against this since armor's gonna need a big audit, but I'll leave it to @Coolthulhu whether we should close it outright. If so, main thing to do is fix the documentation to not refer to an obsoleted mechanic. Given how complicated doing the math for material strength calcs is over just picking a thickness and seeing what it says it is in-game, I'm hoping not too many people balanced their armor by doing math from inaccurate documentation (and if they did then hopefully they actually tested their armor in-game and corrected their mistake afterwards).