Open miscoined opened 3 months ago
Here's an example of what the statblock looks like currently. This should include all available fields.
layout: Experimental Pathfinder 2e Layout
source: B2
sourcebook: Bestiary 2 p. 87
name: Some Name
level: Creature 1
alignment: alignment
rarity: unique
size: size
traits:
- "[[trait]]"
modifier: 0
senses: senses
languages: languages
skills:
- Skill: 1
- "Lore: Lore": 2
skillsNote: skill note
abilityMods: [0, 0, 0, 0, 0, 0]
speed: speed
ac: 0
saves:
- fort: 1
- ref: 1
- will: 1
savesNote: save note
hp: 0
hpNote: health note
immunities: immunities
resistances: resistances
weaknesses: weaknesses
items: items
abilities_top:
- name: "[[Top Ability Name]]"
desc: "([[trait]]); ability text"
abilities_mid:
- name: Mid Ability Name
desc: >
⬲;
**Some Text** This can be freeform text input;
**Effect** It's markdown-rendered and no escaping is required.
abilities_bot:
- name: Bot Ability Name
desc: >
⬺ ([[trait]]); You can even use multi-line text here if you use two
newlines and indent correctly. For example, here's a list:
- List item
- another item
and here's a callout
> [!note]+ FYI
> I didn't add this, this is just YAML features :)
attacks:
- name: ___Melee___ ⬻ name
desc: ([[trait]])
bonus: 0
damage: 1d100+0 damage type plus 3d4 another type
- name: ___Ranged___ ⬻ name
desc: ([[trait]])
bonus: 0
damage: 3d8+12 slashing plus some effect
spellcasting:
- name: Spellcasting name
desc: >
DC 0, attack +0;
**1st** [[some spell]] (×3);
**Constant (3rd)** [[constant spell]]
This seems much better than the current format! For the sake of generating discussion, I have a couple things that I'd note, but I could absolutely be wrong:
savesNote: save note
I believe you can have notes on each different save type, ie. one for Fort, one for Ref. In that case, it might make sense to put the note under the save like so:
saves:
- fort: 1
- ref: 1
- will: 1
saveNotes:
- fort: "+2 circumstance against flying"
- ref: "+1 when using Guiding Ward"
or
saves:
- fort:
- value: 1
- note: "+2 circumstance against flying"
- ref:
- value: 1
- note: "+1 when using Guiding Ward"
- will:
- value: 1
- note: ""
The same thing might apply for skills, but not sure on that.
attacks: - name: ___Melee___ ⬻ name desc: ([[trait]])
The format here seems great, but my concern would be that the
[[trait]]
would not have an actual file in the vault that someone is using. If someone creates a new vault and puts this statblock in it, the[[trait]]
would link to an empty file. I suppose this is solved using a hyperlink? Like[trait](https://2e.aonprd.com/Rules.aspx?ID=2918)
, but that seems a little strange to me. Another way would be to just italicise it, like*trait*
or something. The empty-file way might just be fine, though :)spellcasting: - name: Spellcasting name desc: > DC 0, attack +0;
Would it make sense to move the DC and attack numbers out into the spellcasting object? Like
spellcasting: - name: Spellcasting name - DC: 0 - attack: 0 - desc: >
A lot of this could be absolutely bad suggestion (and to be honest, I don't really know YAML), so take all of that with a grain of salt. Again, thank you, the work you're all doing here is great and has been such a use to me!
Thank you for the suggestions!
For save notes and skills, I considered the notes and at the moment you can enter it like this, which will render as expected:
saves:
- fort: +10 (+12 vs poison)
- will: +7 (immune to illusions)
skills:
- Athletics: +10 (+12 for jumping)
I fall back to the text-based freeform entry method, basically. This means that if you were doing data stuff you'd need to do some parsing, but I'm trying to find a balance between readability and structure. Ideally this is what I'd like to do:
saves:
- fort: 10
vs poison: 12
note: some other note
- ref: 12
- will: 8
skills:
- Cult Lore: 10
note: lore on their cult
- Athletics: 10
in forests: 12
but this would require callbacks for the "Save" layout block, which isn't currently implemented. I considered implementing it but I've been going back and forth on whether this is going too far into the structure side and losing out on readability. I also know that a lot of folks have trouble with nested YAML syntax.
For the trait hyperlinks, the desc: ([[trait]])
is a holdover from the CLI-generated statblock, which automatically includes links traits to the relevant note. If you don't have linked traits you could just as easily do this:
attacks:
- name: ___Melee__ ⬻ name
desc: (trip, agile)
Thanks for pointing out the spellcasting DCs and bonuses! I'll pull those ones out.
If you're interested, this is the template that I'm currently using to generate statblocks in my local branch. (it uses some nested templates which can be found here: ability, action)
Please make sure that anything with name: can be a link. E.g. you show it for ability_top, but want to make sure it applies for ability_mid, ability_bot and attacks.
Scope
Improve the Pathfinder 2e creature layout to reduce duplication and boilerplate, and make it easier to access the underlying data without resorting to regex on the formatted strings.
Discovery
Primarily the Pathfinder 2e layout but I'm expecting this to require touching several different repos to do properly. This seemed like a decent place to track the changes and allow feedback on how I'm going about this.
Validate
I have a local vault which contains statblocks generated using a local branch of ttrpg-convert-cli which I've added pf2e bestiary statblock support to. I've been working on the changes using a local branch of rhe Fantasy-Statblocks-CSS-Development repo.
My current plan is to first add an Experimental layout with a different name to the default to use so I don't break people's vaults while I'm adding support in the upstream repos. This is probably also going to be different enough that I think it's worth making a separate layout entirely rather than trying to do it piece-by-piece.
This is my current list of repos/projects which will need modifications of some type if I want this to become the new default layout. Please let me know if there's anything I've missed:
This bug is mostly to have somewhere somewhat centralised to track changes, since I know there's a lot of different repos involved here.
I'd appreciate feedback on whether this seems like a reasonable approach to trying to get this done, or whether I'm barking up entirely the wrong tree here.