Proposed New SRD Guidelines

[sigrunixia]

This is a Work in Progress. The results will go in the Admin Repo.

Feel free to provide input, @Obsidian-TTRPG-Community/inquisitors.

---

If there is an Obsidian Linter fix associated with the rule, it will be listed.

Structure

In general, the files and folder structure is ideally going to look similar to the source.

Example:

• Chapter is a top-level folder.
• Section is a second level folder.
• Individual subsections are separate notes.

However, in the case of Obsidian formatting, preview files, linking of content, and more, this may not always be logical. Relative freedom is given on overall structure within the vault.

What is unacceptable is as follows:

• All files in /.
• All files in one folder.
• No folders at all.
• No tags.

Real Dates

ISO8601 formats. Sorry, its the only realistic way.

Files

• Files should be kebab-cased and sluggified. Meaning Ancient Black Dragon.md becomes Ancient-Black-Dragon.md. This can be taken care of right before release with the plugin Obsidian Bulk Replace or another form of Regex Replace.

Folders

• SRD projects should start under ./compendium/shortname/. For example: ./compendium/13A This is for parity with TTRPG-CLI which will further augment content in the future as it gains the ability to process custom .json.
• If there is enough content, and the formatting allows for it, in the SRD, you can also use ./rules per the guidelines of the TTRPG-CLI which are re-iterated below.

By default:
items, spells, monsters, backgrounds, races, and classes are in /compendium/
files defining conditions and weapon properties are in /rules/

Frontmatter

• The minimum required keys is aliases and tags. Linter Rule: Insert-YAML-Attributes.
  • Templater combined with aliases: [<%- tp.file.title.replace("-", " ") %>] is <3. It will remove the first - from the file name and use the result as the value, when the note is created, or if pasted and then templater re-ran.
• If the content you are working on can be legally shared, add the publish key as well.
• Frontmatter is going to be dependent upon file types.
  • Example: Bestiary files may include type and size while Spells may contain school and Class Tags.
• Do not over clutter the frontmatter. If it can be done as a Dataview Inline Inquiry, prefer that.

Links

• Wikilinks are allowed.
• Wikilinks with Absolute Paths should be used. This prevents overwriting content with the same name when importing within the vault.
  • Example: the entity [[Ancient Black Dragon]] exists in multiple games, and Obsidian will update all links to the most recent [[Ancient Black Dragon]] unless it has an absolute or relative link.

Typography

Headers

• Headers should increment one at a time for readability. Additionally, due to the inline title added to Obsidian, Headers should start at H2. Linter Rule: Header Increment
• There should be a space before and after headers. Linter Rule: Heading Blank Lines

Plugins

Calendarium

Calendarium support is a mixed bag. Either the calendar is super easy and already available, or it needs to be built from scratch. As such, is not expected that a calendar would be in a 0.1.0 release.

Calendarium support for new calendars should be something to strive for in later releases.

Dataview / Datacore

Dice Roller Support is common enough, and out-of-the-way enough, that we ought to implement it by a 0.1.0 release. Some of it is already taken care of in frontmatter, but to avoid over-clogging frontmatter.

Guidelines

• When possible, utilise existing instances of Item: Text to turn that into an Inline Dataview Key.
  • Example, on a spells block, the Ritual: Yes can become Ritual:: Yes.
• Dataview code blocks should not be used by default. They can, however, be added as optionals in a file replacement instance.
  • Example: If you have a note for a large table, and want to make a dataview version, you would ass your dataview version of the note in ./Upgrades/path/to/file/dataview-table.md

Dice Roller Support

Dice Roller Support is common enough, and out-of-the-way enough, that we ought to implement it by a 0.1.0 release.

Guidelines:

• Instances of XdX should be converted to dice roller. For example "2d6 or 4d12" should be "dice: 2d6 or 4d12".
• Instances of "Roll a dx" should not be converted, because it usually has an accompanying table.
• Tables headed with dX, should be converted. For example | d6 | should become | `dice: 1d6` |

Fantasy Statblocks

Fantasy Statblocks Support is common enough, that we ought to implement it by a 0.2.0 release. 0.1.0 is better, but depending on how many entities you have, it would hold up a release by weeks.

Guidelines:

• There should be one entity per note.
• Entities should be in code block form and not frontmatter form. Additional frontmatter rules are found in the Frontmatter Section above.
• If a layout is not created and is needed, create a Feature Request in Fantasy Statblocks Repo and Link To The Vault Project you are working on. This puts that layout request at extremely high priority.

[sigrunixia]

After messing with a few new SRD's... yeah, we have to do this on a case by case basis. :)