[ d20statblock.org ] a grammar

[DMFTodd]

But that's my point. You don't _need_ a formal grammar to make statblocks that are readable by people.

Yes, we do.

Here's a real-world example of why: My program, DM's Familiar, can import stat blocks. As long as the stat block follows a standard format, my program can import it. Where might a stat block come from?

It might come from software: PCGen, E:Tools, etc.

It might come from a human: Typed in by hand, Typed in based on an adventure the user has, scanned from Dungeon mag.

If I had decided on a computer-based import (reading the PCGen file, or the E:Tools file, or some "standard"), then my program wouldn't work for any of the "human" ways of creating a stat block.

If I had decided on a computer-based import, then anything that didn't create the computer file wouldn't work with my program, period (Jamis Buck NPC generator). By using a "English" standard stat block, a user can take the Jamis stat block, tweak it by hand, and then import it. If it was a computer-based format, the Jamis file wouldn't work.

That's why we need a standard.

 

[CRGreathouse]

Yes, we do.

Here's a real-world example of why: My program, DM's Familiar, can import stat blocks. As long as the stat block follows a standard format, my program can import it. Where might a stat block come from?

Thanks, Todd. I actually have similar plans for importing stat blocks, though mine are deep alpha now.

RPM imports stat blocks (Jamis format), as does PCProfiler (standard format). Does anyone know of other programs that import from some stat block?

 

[DMFTodd]

First off, I'd like to say thanks for taking the time to do this stuff. The software community needs it.

Secondly, that grammer is making my head hurt. As someone who has something at stake in this process (please don't blow up the current standard, I'm using it!), I want to get involved but I think you have enough cooks already (and it makes my head hurt as noted). I kinda want to wait til you guys get done then throw in my 2 cents.

Thirdly, do you want comments from the peanut gallery? Assuming you do, here's some thoughts (and since I haven't studied the standard enough, maybe these are there. Keep in my that these suggestions come from real-world users. These are things that the DMF users have asked for in the stat block so they can be imported):

What about a section for "custom" additions to the stat block? Things that I would want to support but that wouldn't be necessarily part of the standard. Should they have their own section or do they get included anywhere in the top portion?

What about people like me who want to create their own unqiue identifiers? Would they get added into the grammer for other people to include down the road?

Here are some that have come up for me with DMF already (these are the identifiers I'm using, they can go anywhere in the statblock is how I support it):

BAB:, Melee BAB:, Ranged BAB:, XP:

 

[CRGreathouse]

Thirdly, do you want comments from the peanut gallery?

Yes, please!

What about a section for "custom" additions to the stat block? Things that I would want to support but that wouldn't be necessarily part of the standard. Should they have their own section or do they get included anywhere in the top portion?

What about people like me who want to create their own unqiue identifiers? Would they get added into the grammer for other people to include down the road?

I'll have to think about this one. Actually, I'll have to think a lot about this one - it's a good point, and raises many other issues.

BAB:, Melee BAB:, Ranged BAB:, XP:

There are no "Melee BAB" and "Ranged BAB" in core D&D. There are only three 'flavors' of base attack bonus: normal, unarmed, and epic (which isn't considered 'base', but acts much like it). Did you mean "Melee AB" and "Ranged AB"?

In any case, I'll get back to you on this. Some things are pragmatic (how many new tags, and how intercompatible) and others are legal (d20 STL and XP - I'll have brush up to see what we can and can't do).

 

[smetzger]

Yes, we do.

Here's a real-world example of why: My program, DM's Familiar, can import stat blocks. As long as the stat block follows a standard format, my program can import it. Where might a stat block come from?

But that is not a human reading the statblock. That is a computer. I am sure that IF e-tools and PCGen exported a character in XML format as well as statblock that you would have used the XML interface.

I don't mind having a standard for a human readable statblock. However, if we are going to have a standard for computers reeading a character I think it should be XML or even comma delimited.

There is not much we can do about e-tools in its present incarnation. However, if an XML standard was made I am sure that most if not all the 3rd party software development people could be convinced to use it. I also think that there is an equal chance to convince future incarnations of e-tools to follow an XML standard as there is of convincing them to follow a statblock standard.

 

[CRGreathouse]

But that is not a human reading the statblock. That is a computer. I am sure that IF e-tools and PCGen exported a character in XML format as well as statblock that you would have used the XML interface.

I don't mind having a standard for a human readable statblock. However, if we are going to have a standard for computers reeading a character I think it should be XML or even comma delimited.

Since we'll have a human-readable format, why not make it computer-readable, too? Todd, along with some others I mentioned, have showed that it's quite possible - and useful - to have such a feature. I intend to follow in their footsteps (though I thought of it independantly, I'm a little slow on implementation).

 

[DMFTodd]

that IF e-tools and PCGen exported a character in XML format as well as statblock that you would have used the XML interface.

You would be wrong.

I wanted an import routine that would work with the widest range of possibilities -- both COMPUTER and HUMAN.

Dungeon Magazine does not provide XML monster stats. My users could not sit down and type/edit XML monster stats.

Dungeon Mag DOES provide stat blocks. My users CAN read/type/edit a stat block. PCGen and E:Tools CAN both create stat blocks as do other programs.

Hence, I decided that my import routine would use stat blocks. That seems like a simple explanation. Am I missing something?

 

[CRGreathouse]

Dungeon Mag DOES provide stat blocks. My users CAN read/type/edit a stat block. PCGen and E:Tools CAN both create stat blocks as do other programs.

Wait a sec - you mean I'm not the only one who's imported a character by manually copying a stat block? Cool!

 

[jmettraux]

However, if an XML standard was made I am sure that most if not all the 3rd party software development people could be convinced to use it. I also think that there is an equal chance to convince future incarnations of e-tools to follow an XML standard as there is of convincing them to follow a statblock standard.

check this :
http://groups.yahoo.com/group/d20-xml/
http://groups.yahoo.com/group/pcgen-xml/

By using a "English" standard stat block, a user can take the Jamis stat block, tweak it by hand, and then import it. If it was a computer-based format, the Jamis file wouldn't work.

Thanks Todd, this use case shows the strength behind the standard.

Does anyone know of other programs that import from some stat block?

My small dgsh has a tool for turning a standard stat block into its own XML.

 

[CRGreathouse]

My small dgsh has a tool for turning a standard stat block into its own XML.

(smacks self on forehead)

Of course!