[WIP] SRD Monster snippets

[G-Ambatte]

While perusing the oldest open issues, I came across #300 - SRD Monsters. A little Googling returned this GitHub gist by tkfu, which is the SRD monsters in one large JSON object.

I have wrapped this in a random selection function and built it into a standard monster block. The formatting of the Traits and Actions fields required a little tweaking of the p+p format, so I added the srd class to the monster block and added the required styling to the 5ePhb.style.less, adjacent to the existing monster styling blocks.

Given the size of this PR - the data file is nearly 600kb alone - I thought it best to let everyone see the state of it as it currently stands. With some additional work, I believe that this PR will resolve #300.

---

Snippet Menu:

Result:

[ericscheid]

Looks great.

Highly confident that the very next request would be for a way to pick a specific SRD monster (instead of random).

Perhaps a very simple popup dialog with a) text input, b) list of matches, c) an I'm feeling lucky button.

[G-Ambatte]

Yes - I was looking at how to do that but that level of interaction isn't something the snippet gen functions have done previously, so it's treading new ground. So I thought I should let some other eyes scan over it as it stands, before I dig into the snippet generator any deeper.

[G-Ambatte]

So I WAS just going to leave it at that... But instead:

• Shifted functions to separate SRD module
• Fix random SRD monster function to select different monsters each time
• Add function to select by monster name
  • Currently operates by user typing in desired monster's name
  • Monster names are exposed via the monsterNames function, so it should be possible to implement some sort of user selection function
    • 327 monsters currently in the list

[G-Ambatte]

Whoooops... Somehow completely left Legendary Actions off the list, so they weren't getting processed at all. Added now.

[G-Ambatte]

Select SRD Monster:

Menu:

Input box:

Error message:

Multiple results found alert:

Result in brew:

[Gazook89]

I wonder if this type of thing should be in a new snippet menu, like "Generators"? Or perhaps this could just replace the current stat block generator (once it more closely matches the existing output in the Traits/Actions areas).

[calculuschild]

@Gazook89 I agree, this seems like the start of a separate tool almost, and might best fit as a new snippet group. #300 also mentions spells, and I could see magic items, etc. as well. I don't know if "generators" is quite the right word there since we would just be grabbing existing items from a collection. But something similar.

On the other hand, #300 also mentions an "NPC Generator". And at some point we would have to ask ourselves what the difference is between our randomly-generated silly snippets, and a full "generator". ("SRD", "Pre-Generated", "Library", etc.)

My initial thought is to go ahead with this as a snippet (in a new group, where we eventually add Magic Items and Spells, maybe something else). But later, it might be nice to change this from a snippet into a more fully-fledged "tool" button. With an SRD catalog, but also NPC generators, etc. How far do we go beyond being just a "text editor" and becoming a "database/generator?" When do we move something like this to a separate "app" like https://tetra-cube.com/dnd/dnd-statblock.html?

Also, I agree with @ericscheid , the JSON object is too big to bundle into our source. Any "database"-y things like this probably need to be loaded on demand as a separate file.

[Gazook89]

How far do we go beyond being just a "text editor" and becoming a "database/generator?" When do we move something like this to a separate "app"

two more thoughts on this:

1. Is this something where we just reach out to existing generators (like tetra-cube) and give them the updated syntax for v3 and let them handle it? Stay out of the 'content' business entirely
2. Or as you suggest as a possibility, a separate tool in the "naturalcrit family of products"....https://generators.naturalcrit.com/. Of course, that means a whole new site and interface....

[G-Ambatte]

2. Or as you suggest as a possibility, a separate tool in the "naturalcrit family of products"....`https://generators.naturalcrit.com/`.   Of course, that means a whole new site and interface....

I like the idea of this: if we were to create a /data/new endpoint (POST an object to /data/new containing {title: 'something', text: 'something else', metadata: '{ renderer: legacy }' } and get redirected to https://homebrewery.naturalcrit.com/new, preloaded with the data from the object), then the SRD Monster Generator program (and/or similar projects) could serve as an standalone example of how to create a new brew via the data API. There are logistical questions about hosting and subdomains and the like which can probably only be answered by @calculuschild, but a lot of this needs to stop being hypothetical and become actual code before answers are actually useful.

[G-Ambatte]

a separate tool in the "naturalcrit family of products"....https://generators.naturalcrit.com/

I believe that in the interest of making sure that Homebrewery remains focused on being an editor, it would be best to shift this development out of Homebrewery and into either it's own separate project, or as an aspect of the NaturalCrit project. However this new project would ideally link to Homebrewery; ideally by opening a Homebrewery new page which has been pre-populated with the appropriate SRD monster data for the users to alter and save to their accounts as they see fit.

I'll mark the PR as blocked and leave it open for now, just in case there's any further useful discussion to be had.

[G-Ambatte]

Another option would be to use the DND5eAPI.com API to retrieve the SRD data. Whether this would reduce it to the point of being snippet suitable again is another question entirely... I suspect that the underlying point, that we keep the focus of HB on the editor, is still entirely valid.

[ericscheid]

See also #1400 Particularly comments about importing data from third party APIs