[ d20statblock.org ] a grammar

[smetzger]

Virtual feats, now there's an issue... I wish I had a quarter for every *page* I've written about virtual feats and their place (or lack therof?) in a stat block. This is ambiguous in the format itself and will have to be decided.

It's not an issue for the parser, but it's a major issue for the format itself.

If I were to parse a statblock it would be an issue for me.

What about racial 'Feats' which aren't actually Feats? Like the Elf proficiency in longsword and bow? There is not a feat for a single martial weapon proficiency. Are these to be listed?

 

[jmettraux]

(on virtual feats)

Originally posted by smetzger

If I were to parse a statblock it would be an issue for me.

What about racial 'Feats' which aren't actually Feats? Like the Elf proficiency in longsword and bow? There is not a feat for a single martial weapon proficiency.

* Implementing a bit of common sense in a parser is not that hard.

For example, the attack modifiers stated in a stat block are not necessary for a program as it can compute them from abilities, classes and feats. If the computed result is different than the statistic, the parser can add spontaneously the missing feat.

For dgsh, I simply added a delta, which keeps track of the difference between a computed modifier and a stated one.

* Correcting the character/monster after it's generated is not forbidden either.

 

[CRGreathouse]

If I were to parse a statblock it would be an issue for me.

I understand that. It's not an issue for this parser, since it's 'dumb', but it would obviously be an issue for any meaningful input program.

What about racial 'Feats' which aren't actually Feats? Like the Elf proficiency in longsword and bow? There is not a feat for a single martial weapon proficiency. Are these to be listed?

If they aren't feats, don't include them under any circumstances. (Martial Weapon Proficiency with a single weapon, incidentally, is a feat. Simple Weapon Proficiency is the only one that covers the whole field.)

Edit: I don't recommend including weapon proficiencies (except those bought with feats) in the feats section at all. They are included in the stat block, though - class proficiencies follow from the class section, and racial weapon proficiencies go under SQ (elf traits). Example:

Character, male elf War1: CR 1/2; ECL 1; Medium-size Humanoid (elf); HD 1d8-1; hp 3; Init +1; Spd 30 ft; AC 11 (+1 Dex); Melee unarmed strike +0 (1d3); SQ elven traits; AL N; SV Fort +1, Ref +1, Will +0; Str 11, Dex 12, Con 8, Int 11, Wis 11, Cha 11.
SQ--Elven Traits (Ex): Sleep immunity, +2 save vs. Enchantment, low-light vision, proficient: longsword or rapier, proficient: longbows and shortbows.

 

[CRGreathouse]

The skills and feats section may be ugly, but it seems it's the best way to define it. Well done.

Thanks!

Charles, could you attach your new versions ? It will be easier for me to commit it. Thanks in advance.

Oh, sure. I originally posted them because I thought you'd just go over it & copy in what I changed - I expected to make many mistakes since I didn't know about EBNF until you brought it to my attention. Now it looks like I have a good understanding of how to use it, so attaching it would be best. (I'll have to make it a txt, though; I can't attach an ebnf file here.)

 

[CRGreathouse]

I've attached my latest version of the grammar. Changes: masive revision of all things numeric, continued effort to specify strings more closely*, grouping of related elements, minor spell revision.

Edit: What about other symbols, like the slashed O? What are we missing?

* I want to find a good common theme to all the specific coding I'm doing (feats, gods, etc.) with strings, but I'm not sure how best to go about it.

 

[jmettraux]

New revision of the grammar :
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup
diff :
http://cvs.sourceforge.net/cgi-bin/...rt_samples/standard.ebnf.diff?r1=1.11&r2=1.12

In fact, internationally speaking, a lot of characters are missing. Names in french, italian, german and of course english are currently possible, but as an example, the "n~" is missing, so not all spanish names are expressable.
I wonder about portuguese (brazilian) as there are more and more people role-playing in Brasil.

We should take a look at the UTF-8 standard (unicode for short), there is certainly a short way of describing what we want with our string stuff.

 

[hong]

Okay, I'll preface this by saying that I'm not a computer geek. I'm a different subspecies of geek, a D&D geek.

That said, I'm thinking like Smetzger: why do you need a precise format for a statblock? A statblock is just a condensed summary of a character sheet, meant purely for human consumption. I just don't see the need to go to the trouble of a formal grammar, except as an intellectual exercise. Human beings tend to have a better ability to disambiguate information from context, unlike computers.

In any case, the information in a statblock is incomplete, which makes life difficult sometimes, especially when dealing with buffing spells. For example, suppose someone has a Reflex save of +10. This doesn't tell you what components went into it. They might have a resistance bonus, a morale bonus, or a luck bonus, or any combination (or none) of the three. This sort of information is important when you have a bard in the party, or spells that give various typed bonuses: sometimes they count, and sometimes they don't. The statblock doesn't tell you any of this, as far as I can tell.

Now, what I _would_ like to see a standard, open format for, is a character file. This would include all the various factors that are present behind the scenes, but don't appear in the statblock:
- breakdown of each bonus (attack, damage, saves, skills, etc) by type (base/ranks, ability, competence, morale, dodge, luck, untyped, etc)
- which skills are class/cross-class/excluded
- XP spare for item creation purposes
- grapple check bonus
- proficiencies
- virtual feats
- etc, etc.

If necessary, a program could take such a file as an input and _generate_ a statblock, and the precise format of that statblock would be as the programmer desired (perhaps using any guidelines published by the SSBF). As long as it was recognisably a statblock, with all the entries in the right places, I wouldn't be too concerned if they used commas instead of semicolons, or inserted spurious linebreaks, or whatever.

Is there something like this already? Is, say, PCGen's file format an accepted standard that can be read by any other character generator program/DMing tool out there?

And BTW, XML isn't readable. At least not to me.

 

[jmettraux]

That said, I'm thinking like Smetzger: why do you need a precise format for a statblock?

I've reread everything Smetzger wrote in this thread and he never said this.
As I understand his opinion, he thinks we shouldn't focus on statblocks readable by computers, but rather on statblocks readable by people.

And BTW, XML isn't readable. At least not to me.

Kanji isn't readable for me, though I'm human and it is human-readable .


Your post is valuable, though you should read the grammar and perhaps you'll have direct ideas to bring to us.

EBNF is a computer science technique for expressing languages. Being used for generating parsers is considered by us a second effect as the first goal is to set a precise format. This has been stated at the beginning of this thread.

 

[CRGreathouse]

EBNF is a computer science technique for expressing languages. Being used for generating parsers is considered by us a second effect as the first goal is to set a precise format. This has been stated at the beginning of this thread.

I would've written a long response to hong's post, except that your post really sums up my feeling well.

*****

I have some other minor changes to make, but it seems to be getting close. I've sent a copy to Florian to look over - maybe he'll see something I missed.

 

[hong]

I've reread everything Smetzger wrote in this thread and he never said this.
As I understand his opinion, he thinks we shouldn't focus on statblocks readable by computers, but rather on statblocks readable by people.

But that's my point. You don't _need_ a formal grammar to make statblocks that are readable by people. The main use of formal grammars is in language specifications, to allow generation of code that's readable by computers. If your final objective doesn't involve making statblocks that are readable by computers, I still don't see why you need a grammar.

Not to mention that I also don't see why you need a statblock that's computer-readable anyway. As said before.

Kanji isn't readable for me, though I'm human and it is human-readable .

Ah, but a statblock isn't kanji. It's just an abbreviated form of a character sheet. Are you suggesting that regular D&D gamers should need to learn kanji (or XML) to read a statblock...?

EBNF is a computer science technique for expressing languages. Being used for generating parsers is considered by us a second effect as the first goal is to set a precise format. This has been stated at the beginning of this thread.

I'm aware of what EBNF is. I just don't know why it's relevant here.

As I said before, working towards a standard character file format is something that I think _would_ be very valuable. It's there that all the language tools would come in handy (grammars, parsers, lexers, go wild).