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)
@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
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
key and include an array of states that enable the use of this document.
This could also work to simplify the “actions” key too
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.