WarmaHordes model representation in YAML

aurum_adeptus_syvestro.yaml

###
# This is a first draft on a final goal to have warmahordes models described
# in YAML files. The plan is that we can start with just a couple of fields
# and be able, with time, to represent the entire model in a file.

---

# name of the card at cards.privateerpress.com
name: Aurum Adeptus Syvestro

# id of the card
ppid: 4142

# main faction of the card and partisan
factions:
  - crucible-guard
# works for (mercenary and minions)
works_for: []
# other keyworks under the card name
keywords:
  - ordic

# number of card faces available
scans: 4

# model cost, represented as a list of a single
# elements for most of the cases, two elements
# for units with min and max allowance, and three
# elements for unit attachments with cost increment
point_cost:
 - 0

# model type as described in rules
type: warcaster

# ppid list of possible command and unit attachments
attachments: []

# battlegroup points for warcasters and warlocks
battlegroup_points: 28

# field allowance: C, 2, 3, ..., U
field_allowance: C

models:
  - name: SYVESTRO 1
    base: small

    damage_capacity: 16

    # (optional)
    # list of columns from left to right with capital
    # letters to refer to systems and white spaces for
    # empty boxes, imagine it as if the grid is rotated
    # 90 degrees to the right. Example for Toro:
    # damage_grid:
    #   - "L   "
    #   - "MLL  "
    #   - "MM    "
    #   - "CC    "
    #   - "RR   "
    #   - "R   "
    damage_grid:
      - ""
      - ""
      - ""
      - ""
      - ""
      - ""
    damage_spiral: # optional
      mind: 0
      body: 0
      spirit: 0

    stats:
      spd: 6
      str: 6
      mat: 6
      rat: 6
      def: 15
      arm: 15
      cmd: 8
      #(optional?)
      focus: 7
      fury: 0
      thrs: 0

    advantages: []

    immunities:
      - corrosion
      - fire

    weapons:
      - name: fulminator grenade
        type: ranged
        rng: 6
        rof: 1
        aoe: 3
        pow: 0
        qualities:
          - damage type magical
        special_rules:
          decrepitation: This weapon...
      - name: purified blade
        type: melee
        rng: .5
        pow: 4
        p_s: 10
        qualities:
          - blessed
          - damate type magical

    special_rules:
      - alchemical_mask:
          common_special_rules: true
      - field_alchemy:
          description: This model
          bullet_points:
            ephemeral_vitae: bla bla
            impenetrable_haze: ble ble
            super_fuel: bli bli

    # spells are best to be described in other
    # documents to be reused
    spells:
      - admonition
      - explosivo
      - purification
      - revive
      - stygian abyss
      - transmutation

    # optional
    feat:
      name: meta principle
      flavor: necessary?
      description: yes, necessary

  # this would be the point to define more models
  # in a card like when you have leader different
  # from grunts stats or like two characters like
  # lynus and edrea
# - name: ...
#   base: ...

We need an animi block with probably the same structure as the spells block

# ppid list of possible command and unit attachments
attachments: []

Is this a list of ppid's that this card can attach to, or a list of attachments that can attach to this card? If the later, how should we handle the attachment[*] rule on the command and weapon attachment bits?

Can we use _ instead of for empty boxes? it's a little easier to count out in an IDE visually. I do not feel strongly about this so please don't hesitate to say no.

    # (optional)
    # list of columns from left to right with capital
    # letters to refer to systems and white spaces for
    # empty boxes, imagine it as if the grid is rotated
    # 90 degrees to the right. Example for Toro:
    # damage_grid:
    #   - "L___"
    #   - "MLL__"
    #   - "MM____"
    #   - "CC____"
    #   - "RR___"
    #   - "R___"

maybe dashes, even more visible and like _ won't require "", but might be confusing for the leading list item dash.

#   - L---
#   - MLL--
#   - MM----
#   - CC----
#   - RR---
#   - R---

another option with "" required, but the X doesn't help with visibility

- "[X][X][ ][ ][X][X]"
- "[ ][ ][ ][ ][ ][ ]"
- "[ ][ ][ ][ ][ ][ ]"
- "[ ][L][ ][ ][R][ ]"
- "[L][L][M][C][R][R]"
- "[X][M][M][C][C][X]"

trying . instead

- "[.][.][ ][ ][.][.]"
- "[ ][ ][ ][ ][ ][ ]"
- "[ ][ ][ ][ ][ ][ ]"
- "[ ][L][ ][ ][R][ ]"
- "[L][L][M][C][R][R]"
- "[.][M][M][C][C][.]"

and without []

- "..  .."
- "      "
- "      "
- " L  R "
- "LLMCRR"
- ".MMCC."

```yaml
# ppid list of possible command and unit attachments
attachments: []

Is this a list of ppid's that this card can attach to, or a list of attachments that can attach to this card? If the later, how should we handle the attachment[*] rule on the command and weapon attachment bits?

the ppid of the models that can be attached to this one, like

name: Crucible Guard Rocketmen
...
atatchments:

• 1111 # officer
• 1112 # gunner

we might not need to specify availability depending on the themed force here like Mosby for mercs for example.

For damage grids, i think that . for empty boxes looks the best. We should also take into account the format for colossals. We could either structure them as an array of grids from left to right, or we could do a single grid with 12 elements starting left to right.