Loadout Addition Guidelines

[Mnemotechnician]

Wizden/delta-v use a different loadout system. This issue outlines the key things you need to know and have to do when adding new items to the loadouts.

Firstly, loadouts follow a hierarchy of the following three prototypes (from bottom to top):

• Loadout prototypes - these define loadout items. They are pure boilerplate and serve no functional purpose besides going from an EntityPrototype to a more formal LoadoutPrototype. When creating one, just follow the template of the existing loadout prototypes. The loadout name should (but doesn't necessarily have to) match the name of the item it provides.
• Loadout groups - these are categories of items. The player has a fixed amount of points in each category that they can spend taking items from the said category. Most categories only give the player 0-1 points, allowing them to take at most 1 item. There are hundreds of such groups, their IDs follow the format [Job][Loadout slot], e.g. MedicalDoctorNeck. Can be inherited.
• Role loadouts - these specify which groups of loadouts each job can take, e.g. a bartender can pick from BartenderHead, CommonBackpack, Trinkets, etc.

When adding a new loadout, do the following:

1. Create a loadout prototype for each item you add. See above.
2. If you want to add readouts to an existing group, do NOT directly add them to the upstream groups. Instead, create a NEW, ABSTRACT loadout group in the _Floof namespace, and make the upstream group inherit from it.
   • For example, take a look at the CommonCollars loadout group. Upstream loadout groups like BartenderNeck were changed to inherit from it.
3. If there is no loadout group your item could be added to, then you should create a new loadout group in the _Floof namespace and adjust the respective role loadouts accordingly.
   • Unless otherwise necessary, make sure to make the new loadout group inherit from the group it replaces. For example, if your goal is to give the bartender a unique backpack, you should create a new group BartenderBackpack that inherits from CommonBackpack (since that is what the bartender role loadouts prototype uses right now).
   • Example syntax:

# The loadout prototype
- type: loadout
  id: ClothingBackpackBartender
  equipment:
    back: ClothingBackpackBartender

# The loadout group
- type: loadoutGroup
  id: BartenderBackpack
  parent: CommonBackpack # This group will include all items from CommonBackpack, aka passenger backpacks
  abstract: true # This group cannot be used directly, instead it has to be the parent of another group
  name: loadout-group-medical-collars
  loadouts:
  - ClothingBackpackBartender

In the upstream files...

  - type: roleLoadout
    id: JobBartender
    groups:
    - GroupTankHarness
    - BartenderHead
    - BartenderNeck # DeltaV
    - BartenderJumpsuit
-   - CommonBackpack
+   - BartenderBackpack # Floofstation - bartender used to use the passenger backpack group.
    - BartenderOuterClothing

Why

The goal of this is to minimize the amount of times we have to touch upstream loadout groups. While using this technique, only 1 PR (one contributor) has to touch the upstream loadout groups/role loadouts to introduce a new parent, and all future changes (additions and removals to/from this group) will be confined to the Floofstation namespace. This will make dealing with merge conflicts significantly easier.