Allow multiple items on layer and body part

[bombasticSlacks]

Summary

Features "Adds infrastructure and json so that multiple items can be worn on a body part"

Purpose of change

With the desire to move towards more layering of armor the current system has the major flaw of not allowing multiple disparate pieces on the same layer even if they wouldn't effect one another. Such as wearing knee pads and shin guards or a breast plate that has shoulder armor and hip armor with armor that covers the rest of those limbs.

This can be seen with some of the un-intuitive current workarounds like certain things that hang off the front of your torso being waist items like the survivor harness and almost all strapped torso armor being set as outerwear so it doesn't conflict with backpacks.

Describe the solution

I've implemented a number of limb sub locations for the legs, torso and arms. These locations are exclusively used for testing for stacking encumbrance penalties on the limb and layer. The locations are as follows:

Torso

id	name
torso_upper	upper torso
torso_neck	neck
torso_lower	lower torso
torso_hanging_front	item hangs off your front
torso_hanging_back	item hangs off your back

arms (left and right)

id	name
arm_shoulder_r	right shoulder
arm_upper_r	right upper arm
arm_elbow_r	right elbow
arm_lower_r	right forearm

legs (left and right)

id	name
leg_hip_r	right hip
leg_upper_r	right thigh
leg_knee_r	right knee
leg_lower_r	right calve

If an item doesn't have sub location information defined it is assumed it covers all sub-location areas of the body parts it covers so this doesn't break any current items. However on the strapped, and outer layer it provides a lot of power for pouches and armor.

As long as all of your armor on a limb and layer has separate sub-locations you get no stacking encumbrance penalties.

This data is shown on the UI as follows:

It can be added to an item by adding "specifically_covers": [ "sub_loc_1", "sub_loc_2"] to the armor definition.

So for elbow_pads it would be:

  {
    "id": "knee_pads",
    "type": "ARMOR",
    "category": "armor",
    "name": { "str": "pair of knee pads", "str_pl": "pairs of knee pads" },
    "description": "A pair of knee pads made of stout plastic and cloth.",
    "weight": "210 g",
    "volume": "1500 ml",
    "price": 2500,
    "price_postapoc": 50,
    "to_hit": 1,
    "material": [ "plastic", "cotton" ],
    "symbol": "[",
    "looks_like": "legguard_hard",
    "color": "dark_gray",
    "material_thickness": 5,
    "flags": [ "WATER_FRIENDLY", "BELTED", "ALLOWS_TAIL" ],
    "armor": [
      {
        "covers": [ "leg_l", "leg_r" ],
        "encumbrance": 0,
        "cover_melee": 5,
        "cover_ranged": 5,
        "cover_vitals": 90,
        "specifically_covers": [ "leg_knee_r", "leg_knee_l" ]
      }
    ]
  },

I have also in this PR modified:

84 storage items to use this system. No numerical changes other than adding the correct tags:

21 Torso armors. These were modified if they extended out onto limbs but not fully covered them. Coverage on those limbs was modified based on what pieces they cover multiplied by the items original coverage.

The split for % of the limb is as follows:
shoulder 20%
upper limb 40%
elbow 5%
lower limb 35%

So if something extended onto the shoulder and upper limb the max coverage it could have is 60%.
If the armor has 90% coverage on the torso that gives it a value of 54% coverage on that limb.
Encumbrance was likewise scaled based on the current encumbrance. If something with 100% torso coverage had 10 encumbrance, if it now additionally covers 50% of the arms, the arms would have 5 encumbrance.

the items modified were:

40 limb armor pieces. These pieces were modified so that they can now be combined with torso items that extend onto the shoulders and hips as well as mix and matched with each other. With that said they actually did need to have their coverage reduced to compensate.
I do a similar system to above where I base if off the max coverage the item could have based on the pieces it covers.
However instead of multiplying by the torso value (since there isn't one) I have personally defined a few categories of items:

• Junk: 80% Melee Coverage, 80% Ranged Coverage, 0% Vitals Coverage
• Hand Made: 90% Melee Coverage, 90% Ranged Coverage, 50% Vitals Coverage
• Military Fabricated: 90% Melee Coverage, 95% Ranged Coverage, 90% Vitals Coverage
• Ancient Fabricated: 95% Melee Coverage, 90% Ranged Coverage, 70% Vitals Coverage
• Enclosing Fabricated 95% Melee Coverage, 95% Ranged Coverage, 90% Vitals Coverage

these aren't in the JSON anywhere I am just using them to systematically scale coverage with each item fit into a category as best as possible. Encumbrance is scaled based on the old encumbrance same as above. This isn't close to a perfect system but it lets me reasonably scale the values for now without anyone being able to cry favoritism. Someone could later overhaul pieces as they see fit.

the limb items are:

Describe alternatives you've considered

This problem could be partially fixed with wear with style tags but that would lead to long lists for things like backpacks with strapped chest armor.

Not meddling with the current system.

Testing

These are not the final values (those are above) these are just early examples.

Added tags to hard arm guards saying it covers just forearms and elbowpads that just cover elbows. wearing both:

Wearing two pairs of hard arm guards

Wearing elbow pads, hard arm guards, and steel arms

Additional context

Next up will be moving some belted items to where they actually belong however I was instructed not to change any layers in this PR.

[lgtm-com]

This pull request introduces 1 alert when merging 6809fd3 into 7dce252 - view on LGTM.com

new alerts:

• 1 for Missing return statement

[Venera3]

Two things I think would make this easier to handle for content contributors:

• As discussed on Discord, allowing for optional sublocation arrays to futureproof them for mutant limbs (ETA Soon), with the armor in question choosing any available "free" sublocation on the relevant bodypart - two pairs of elbow pads on your weird spider arms, for example. Depending on the implementation it might need an extra keybind to the + menu to walk the item down the available limbs, like it's possible to change item sides already. This might also provide a (slightly work-intensive) way to define mutation clothing incompatibilities.
• The ability to separately define sublocation "sets", that get invoked by id or defined/modified inline in the item definition - this would cut down on the lines necessary to add a new item, or the necessary adjustments if one adds a new type of limb, for example.

Also, how does this deal with items that can be worn on one arm/leg on either side?

[bombasticSlacks]

It works with the sided code the same way items do currently.

[Terrorforge]

How does this handle totaling up coverage? Because if you didn't alter the coverage logic, it seems to me we now have a situation where wearing a cuirass and steel arm guards, instead of giving you 76 + 19 = 95% chance to impede an attack to the arm, you have a 0.24 x 0.81 = 19.44% chance of bypassing both pieces of armor (i.e. only about 80% coverage), and a 0.76 x 0.19 = 14.44% chance of somehow getting stopped by both.

[bombasticSlacks]

@Terrorforge I didn't change it. I've mentioned this issue elsewhere. My preferred solution is to do a single roll to hit per limb per layer and iterate through all pieces until one you select one or run out (so that they will be additive). However this would nerf stacking armor on a layer which I'm not sure how people would feel about.

[l29ah]

This PR introduced #52800.