5e-database: Monster Data is missing Armor Type

The SRD includes armor types for monsters, such as:

Aboleth: 17 (natural armor)

Thug: 11 (leather armor)

The armor type is not provided along with the monster data. I propose we add it as an armor_type field.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 3
  • Comments: 32 (5 by maintainers)

Most upvoted comments

@Redmega @fergcb #518 Is all done and has all of the data added in. This will be a breaking change. I’ll need to do the API changes as well but that can be another day.

Heya, Sorry for poping in since I’m fairly new here. In reading this I would suggest we consider how the API might be used in a program, so with that being said I am with txtsd in thinking that notes should be limited to “human readable” text that is not used to provide important data.

I like the idea of the armor key holding an array of document values that describte the armor attributes. I also recognize the need to indicate that some have an associated condition or state, especially with shape changes or fighting stances that are common to many creature types.

So I would propose that we add a new key to the main creature api document that might look something like

"states" : ["humanoid","bear form","hybrid form"]

I also considered implying a default state, but I think we can just leave it at state index 0 since the DM would choose this.

This state key would represent an enumeration type declaration. I would propose that ANY subdocument may use the

"required_state"

key and include an array of states that enable the use of this document.

"armor": [
    {
      "armor_class": 10,
      "armor_type" : "natural",
      "required_state" : [ "humaniod" ]
    },
    {
      "armor_class": 11,
      "armor_type": "natural",
      "required_state" : [ "bear form","hybrid form" ]
    }
  ]

This could also work to simplify the “actions” key too

"actions": [
		{
			"name": "Multiattack",
			"desc": "In bear form, the werebear makes two claw attacks. In humanoid form, it makes two greataxe attacks. In hybrid form, it can attack like a bear or a humanoid.",
			"options": {
				"choose": 1,
				"from": [
					[
						{
							"name": "Claw",
							"required_state" : [ "bear form","hybrid form" ],
							"count": 2,
							"type": "melee"
						}
					],
					[
						{
							"name": "Greataxe",
							"required_state" : [ "bear form","hybrid form" ],
							"count": 2,
							"type": "melee"
						}
					],
					[
						{
							"name": "Greataxe",
							"required_state" : [ "hybrid form" ],
							"count": 1,
							"type": "melee"
						},
						{
							"name": "Claw",
							"required_state" : [ "hybrid form" ],
							"count": 1,
							"type": "melee"
						}
					]
				]
			},
			"damage": []
		}

This design choice would also be useful for things like fighting styles, and can help a programmer handle monsters with various states by detecting if the state array length. It can be implicit that if the states key has no value, then we don’t need to check for conditions.

Just a thought, and thanks for hearing me out!

JK. I wrote the API change too!

Fair enough! #304 is a great solution for this particular problem. I do see your point that right now conditionals are not a big problem. I guess we can revisit it in the future if further expansions make them more abundant.

I see your solution also gets rid of using notes for data which may need to be used by a program which is also great.

Let me take care of this.