Warmahordes theme representation in YAML

example_theme.yaml

### 
# This is a first draft at theme force representation in YAML files
# This should be compatible with the proposed model representations
# from https://gist.github.com/moisesguimaraes/dc80cb5ab87e8e6333cd28b543d0bd34
---

# name of the theme force
# Note: I think that unthemed should just be a very vanilla theme with the filters for
# that faction's models and merc/minions models that work for it
name: Vengence of Dhunia

# we use this unique name to refer to the theme internally. This may also be suffixed
# with the respective faction in cases like Flame in the Darkness or Heart of Darkness
unique_name: vengence_of_dhunia

# Factions the theme list applies to. Note that it is possible we make multiple versions
# of the same theme because they are materially different depending on the faction they
# are played in, such as Flame in the Darkness. Also Heart of Darkness should probably be
# 6 themes instead of 1
factions: 
  - minions
  - trollbloods
  
# A list of filters for which models should be naturally included. A model must match ALL
# criteria in one or more filters to be included in the theme
included_models:
  - description: Trollblood Warlocks # Exact text from warroom for this line item
    types: [warlock]                 # match the type field from the model entry
    factions: [trollbloods]          # match the factions field from the model entry. Only one faction on the model
                                     # needs to match one entry in this list
  
  # Models must be of type warlock and include the character Carver.
  # Note: this entry could potentially include the `factions` filter as well but is not necessary at this time as
  # there are no non-minions carver warlocks
  - description: Carver Warlocks
    types: [warlock]
    characters: [carver]             # match included characters on the model entry. Note: I think we need to add a `characters`
                                     # list to the top level, or add a `character` field to the models object.
  
  # helga warlocks, same as carver
  
  - description: Lord Azazello, The Castellan
    ppids: [1234]                       # match a list of exact PPIDs. Not compatible with any other filter options
  
  - description: No-character Trollblood warbeasts
    types: [warbeast]
    facions: [trollbloods]
    non_character: true                # filters for everything else in the description then removes characters from the results
  
  # non character minion warbeasts, same as above
  
  - description: "Trollblood Scattergunner models/units"
    types: [solo, unit]
    factions: [trollbloods]
    tags: [scattergunner]             # A list of tags that each model must contain. They must contain ALL days listed here
    
  # trollblood barrage, slugger, champion same as above
  
  - description: "Dhunian models/units"
    types: [solo, unit]
    factions: [trollbloods, minions] # example of a multi-faction filter. Technically this isn't just restricted
                                     # to trolls and minions but for now that's all there are
    tags: [dhunian]
    
  # stone scribe, pyg, weapon crews
  
  - description: "Farrow units/solos with ranged weapons"
    types: [unit, solo]
    tags: [farrow, has_ranged_weapons]     # Since we probably don't want to transcribe all the model stats in
                                           # the first wave, we can apply meta-tags like `has_ranged_weapons` to models
                                           
  - description: "Minion Trollkin Solos"
    types: [solo]
    factions: [minions]
    tags: [trollkin]                       # note that trollkin is a tag and trollbloods is a faction

  # battle engine example. This should probably just be `ppid` filter but hypothetically there could be
  # a filter for multiple types of battle engines
  - description: "War Wagon Battle engines"
    types: [battle_engine]
    tags: [war_wagon]


# This section is for models that have some kind of restriction to how they can be added
# The apps logic should recognize that the included_models list takes precidence over restricted
# if a model matches both categories
restricted_includes:
  # Standard Merc and Minions example. We have to split this into two filters so it is clear
  # that you get one of each type
  - description: "This army can also include one Minion Solo that will work for Legion"
    pick_limit: 1                # the number of options from this list that can be included in the list. This has no
                                 # bearing on FA. If a model is selected, you can add it as many times as the FA allows
    modified_fa: 1               # Modified the FA on the models included in this filter to this value. Note that if
                                 # they are also matched by the `included_models` filter that this filter has less precidence.
    factions: [minions]
    works_for: [legion]
    types: [solo]
    
  - description: "This army can also include one Minion Unit that will work for Legion"
    pick_limit: 1
    modified_fa: 1
    factions: [minions]
    works_for: [legion]
    types: [unit]
    
    
  # Heart of Darkness Menoth variant example 
  - description: "Up to two non-partisan units of the same Faction as the warcaster in this army"
    list_limit: 2                 # this is like pick_limit and modified_fa except that the list should resitrict
                                  # the total number of models that match this filter regardless of their FA
                                  # this means you could have 2 of the same unit, or two different ones. 
                                  # `list_limit` is incompatible with `pick_limit` but may be compatible with `modified_fa`
    types: [unit]
    factions: [menoth]
    filter_tags: [partisan]      # after filtering for models that match this filter, remove any with any of the listed tags


requisition_options:
  - description: "One command attachment"
    type: [attachment]          # Are we doing attachments as a card type and command/weapon is a type,
                                # or is command/weapon attatchment each their own card type?
    tags: [command]
    factions: [infernals, menoth]
    
  - description: "One small or medium based solo with marked soul"
    type: [solo]
    bases: [small, medium]     # models must match only one field in this list
    factions: [infernal, menoth]
    tags: [marked_soul]
  
  
  - description: "Three feralgheist solos"
    ppids: [12345]
    req_multi: 3              # this filter option is exclusive to requisitions. It specified the number of instances
                              # of a choice that count towards one req pick. I think we need to require this be used with only
                              # a single `ppid`

Should ppids be just ppid singular instead of an array? Is there any situation where we want to list out multiple PPIDs that we wouldnt just otherwise split into two filters?