V2 Enums solution of some sort?
Here's a few examples of enums that should be quickly and easily presented to the UI: MONSTER_TYPES ATTACK_TYPES DIE_TYPES DAMAGE_TYPES USES_TYPES SIZE_CHOICES
These shoudl be accessible and enumeratable with a simple api call somewhere.
Additional thoughts:
ideally this should honor the same document (and ruleset) filters as the related data endpoints, and return an appropriate subset of values for the content in those docs.
The goal of this set of endpoints is to let the user populate frontend filters for a given type of item appropriately, without downloading the entire corpus of values first.
Can these literally just be their own models, queryable each? api.open5e.com/v2/creaturetypes api.open5e.com/v2/sizes
etc?
That would help with i18n
Solution for size:
Each "object" which includes creatures has a Size mapping, and Size is displayed as follows:
"size":{ "key":"medium", "name":"Medium", "space":5.0, }
There is an issue with Small and Medium both being 5.0, so they can't be sorted appropriately, but I'm thinking maybe I just set small to 4.99? It's a bit of a hack. The intent is for space to never really be displayed, only Medium, but it can be used for token generation and such downstream.
What is "space" representing?
If we are thinking token generation, from a DM POV when playing on a grid:
- tiny 0.25
- small 0.5
- medium 1
- large 2x2 (or 2x1 for a horse for example) And so forth.
Those would help when generating a token that is correct for a 1 inch grid VTT.
I've got an approach for this. Basically: v2.models.enums.py contains a set of lists of tuples. They are ordered. I intend to expose these named lists in the api at some endpoint, along with their explicit order. It's not perfect, but it should at least push all necessary information for sorting, enums, etc down to the client side.
Solution in #425
This has been merged.