Add Monster Armor Types

[txtsd]

What does this do?

This adds monster armor types.

How was it tested?

No tests. It was manually entered.

Is there a Github issue this is resolving?

Yes #280

Did you update the docs in the API? Please link an associated PR if applicable.

No

More

So right now it's a straight rip from the PDF. Let me know how you want the data actually formatted. Here are the unique entries:

{'10 in humanoid form, 11 (natural armor) in bear and hybrid form',
 '10 in humanoid form, 11 (natural armor) in boar or hybrid form',
 '11 in humanoid form, 12 (natural armor) in wolf or hybrid form',
 '14 (natural armor), 11 while prone',
 '15 with _mage armor_',
 '16 with _barkskin_',
 'armor scraps',
 'barding scraps',
 'breastplate',
 'chain mail',
 'chain mail, shield',
 'chain shirt',
 'chain shirt, shield',
 'hide armor',
 'hide armor, shield',
 'leather armor',
 'leather armor, shield',
 'natural armor',
 'natural armor, shield',
 'patchwork armor',
 'plate',
 'scale mail',
 'scale mail, shield',
 'splint',
 'studded leather',
 'studded leather, shield'}

Words surrounded by underscores are in italics.

[bagelbits]

I think all of these:

'10 in humanoid form, 11 (natural armor) in bear and hybrid form',
 '10 in humanoid form, 11 (natural armor) in boar or hybrid form',
 '11 in humanoid form, 12 (natural armor) in wolf or hybrid form',
 '14 (natural armor), 11 while prone',
 '15 with _mage armor_',
 '16 with _barkskin_',

mean that how we do AC is flawed for monsters.

[txtsd]

Those are all how it is in the SRD, so suggestions as to how we should handle them are welcome!

For example: The Archmage entry says Armor Class 12 (15 with mage armor)

So should we drop these and add them later as a special case, or take care of them in this PR itself?

[txtsd]

Maybe we can do something like this:

{
  "armor_class": 12,
  "armor_special": [
    {
      "type": "spell",
      "spell": "mage armor",
      "armor_class": 15
    }
  ]
}

{
  "armor_class": 14,
  "armor_type": "natural armor",
  "armor_special": [
    {
      "type": "condition",
      "condition": "prone",
      "armor_class": 11
    }
  ]
}

{
  "armor_class": 10,
  "armor_special": [
    {
      "type": "form",
      "form": "humanoid",
      "armor_class": 10
    },
    {
      "type": "form",
      "form": "bear",
      "armor_class": 11,
      "armor_type": "natural armor"
    },
    {
      "type": "form",
      "form": "hybrid",
      "armor_class": 11,
      "armor_type": "natural armor"
    },
  ]
}

[Redmega]

armor_type here seems to just imply "Whatever's in the parentheses after the armor class."

I think there's two paths this can take: Assume the above, and submit as is (so things like "armor_type": "12 with mage armor" will exist), or figure out an object structure.

My vote would be for something like this:

{
"armor_type": null,
"armor_special": "15 with mage armor"
},
{
"armor_class": 14,
"armor_type": "natural armor",
"armor_special": "11 while prone"
}

fwiw I don't think we should have markdown italics in this field as none of the other fields have markdown (language, senses, etc)

[ogregoire]

We've already handled this kind of stuff in the past. The example with form is close to an acceptable solution.

I think that the armour class should be a structure instead of a flat number.

[bagelbits]

I was thinking probably something like this:

{
  // Stuff
  "armor": {
    "armor_class": 12,
    "armor_special": [
      {
        "type": "spell",
        "spell": "mage armor",
        "armor_class": 15
      }
    ]
  }
  // Other stuff
}

{
  // Stuff
  "armor": {
    "armor_class": 14,
    "armor_type": "natural armor",
    "armor_special": [
      {
        "type": "condition",
        "condition": "prone",
        "armor_class": 11
      }
    ]
  }
  // Other stuff
}

{
  // Stuff
  "armor": {
    "armor_class": 10,
    "armor_special": [
      {
        "type": "form",
        "form": "humanoid",
        "armor_class": 10
      },
      {
        "type": "form",
        "form": "bear",
        "armor_class": 11,
        "armor_type": "natural armor"
      },
      {
        "type": "form",
        "form": "hybrid",
        "armor_class": 11,
        "armor_type": "natural armor"
      },
    ]
  }
  // Other stuff
}

[txtsd]

Okay looks like I'll be changing armor for every monster entry :sweat_smile:

[bagelbits]

Sorry about that. >___<

[bagelbits]

I'm trying to remember how we've handled stuff like this in the past.

[ogregoire]

The array of armors is the way to go. @bagelbits provided a correct draft example here. I agree that notes may not be the best choice at the moment.

But we must find hints in how the armor class is defined. The AC is calculated based on different formulas. There is the "natural armor", but there are a lot of different AC formulas. Such as the formula for "light armor", the one for "medium armor", and so on. There are even two different AC formulas for "unarmored defense" for monk and barbarian.

So let's just be pragmatic and write that: formulas.

{
  "armor_class": [
    {
      "value": 12,
      "formula": "natural armor"
    },
    {
      "value": 15,
      "formulas": "mage_hand"
    }
  ]
}

{
  "armor_class": [
    {
      "value": 14,
      "formula": "natural armor"
    },
    {
      "armor_class": 11,
      "formula": "prone"
    }
  ]
}

[bagelbits]

For something like:

"formulas": "mage_armor"

Does it make sense for us to link the spell in some way?

[bagelbits]

An alternative approach building off of that could be:

"formula": "spell"
"spell": {
  "name": "Mage Armor",
  "index": "mage-armor",
  "url": "/api/spells/mage-armor"
}

[txtsd]

I don't think I'm going to have the time for this in the near future. Someone else can pick it up.

[Redmega]

Idk if I like formula for this, it implies we are including some type of math... I liked armor_type before, I feel like that's more in line with the way some other entries are labeled.

[ogregoire]

formula is not the name I chose, but the one WotC choose: https://dnd.wizards.com/articles/features/rules-answers-january-2016

You might prefer the word method which is also referenced, but there are definitely some maths involved...

[Redmega]

Yeah there's absolutely maths involved, but none that are evident from the data. We simply give the final number, and any contributing factors (i.e. spell, or worn armor, etc.) Hence my vote for just a type of some sort

[fergcb]

I'm also not a fan of formula. @Redmega is right that it implies that the data is supplying the instructions to calculate the AC, rather than the calculated AC or the condition that grants it. I would propose something like this, incorporating some of the previous suggestions:

{
  "armor_class": [
    {
      "value": 12,
      "type": "natural"
    },
    {
      "value": 15,
      "type": "spell",
      "spell": {
        "name": "Mage Armor",
        "index": "mage-armor",
        "url": "/api/spells/mage-armor"
      },
      "desc": "15 with mage armor"
    }
  ]
}

{
  "armor_class": [
    {
      "value": 14,
      "type": "natural"
    },
    {
      "value": 11,
      "type": "condition",
      "condition": "prone",
      "desc": "11 while prone"
    }
  ]

[bagelbits]

Now that lycanthropes are split apart, this should resolve a couple of the outliers.

[bagelbits]

I think I like @fergcb's approach. Though for conditions, I would use an APIRefernce shape to link to the Condition table. Also, for monsters with only one AC, we would essentially have to do this for consistency:

{
  "armor_class": [
    {
      "value": 12,
      "type": "natural"
    }
  ]
}

As long as that's acceptable, I'm fine with it.

[fergcb]

@bagelbits More than acceptable! I'd forgotten about the Conditions collection, if I'm quite honest, but you know me and my fondness for my APIReferences :)

[bagelbits]

Closing in favor of #518