SRD 3.5 XML and MySQL Database

[Vascant]

Should I include SA/SQ descriptions at the end as well?

Andargor

I would disagree, though yes the SA/SQ are mentioned in the initial block, the better examples of stat blocks have always included the description below. I also realize, this is highly opinionated. After alot of searching by myself for a set standard in stat blocks for my npc gen, I found there wasn't one. So I went thru both published material and web generated stuff on wizard's site and came up with what I thought were the best examples of a professional stat block and again, this was also very opinionated based on my perception and my needs as a DM. I know from reading some of the discussion in Dungeon mag, they have tooled with the idea of very minimal stat blocks.

If you have seen any examples of the stat blocks created by my npc generator, I have the description of each SA/SQ and pretty much everything. My reasoning was, if there people express a desire for such a tool and I release it to the public, it is far easier for them to remove the descriptions then for them to add it. So to be complete and handle all needs, not just my own, I have added it. What I am doing is this though, in the program I have markers for what kind of description it is, so I can have an option for the user, if the data is presented. Why not do the same here, have the descriptions but not under the stat block element itself, have seperate elements, SA, SQ and Misc or any other topic of information that would be required. Then people do not have to use it, but for the sake of being complete it is available.

 

[barsoomcore]

My opposition isn't to people creating statblocks that include the extended info; it's to including that info between the <stat_block> tags. If you want to create an application that includes that info in a text object and returns it as a StatBlock, knock yourself out. The <monster> element includes all the data you need. But the <stat_block> element is the wrong place for that sort of info. Really, the <stat_block> element is a convenience element, included so that lazy developers like me don't need to write complex parsing code to dig out all the relevant details and assemble our own statblocks.

I guess everybody has their own threshold for how much convenience is too much, but for me, repeating all the extended info, once in the whatever-tag-it's-in-now tag, and once in the <stat_block> tag, is too much.

 

[Vascant]

Now that I didn't disagree with and even stated, perhaps other elements should contain the info.

As for writing stuff to create the statblock, only took half a day from the original XML monster release. Once I know the monster I am creating the statblock for, it pushes all the data into Monster Class and then calls the scripting engine and just used VBScript to piece it back together. Now there are some weak points to the data but the problem is from the original source not the XML, such as alignments. Even those kind of things only needed a single function to take what the data is and create an actual alignment based on it. Example, "Always good", the function would randomly figure out if LG, NG or CG.

Maybe a better idea would be to create an entirely new XML which would be output of Monster.xml data in a structured format for those who do not desire to play with specific data elements.

 

[andargor]

I say no. The information's in the XML already, no?

There's a lot of "format-y" html code inside the xml that should probably get revisited. There's lots of divs and stuff -- I'd like to see most of that pulled out and rawer html provided.

At least I think that's what I want. I'm at work right now and can't review the xml doc so let me get home, have a look and see.

Ok, I understand. Yes, there's redundant info in there, but for now it's somewhat on purpose. I put more info rather than less. Leaves the programmer to remove or ignore anything not needed.

And the extra divs and stuff are very useful to extract bits of data not in the other fields (the HTML is also well formed XML). And they don't appear in the browser. Anyway, I use it, so it'll probably stay that way.

You could use a simple XSLT to clean that out, too.

Yes, the stat block is a convenience feature, which I'm working on for the next release. It'll be a few weeks, since I have a lot of other things on the plate right now.

Andargor

 

[barsoomcore]

I put more info rather than less.

Pretty much always the correct choice.

I really need to look at the provided HTML again and figure out what was actually bugging me about it. One of these days...

 

[barsoomcore]

Oh, and thanks again for such awesome work. I'm sure pleased with what you've done.

 

[andargor]

Pretty much always the correct choice.

I really need to look at the provided HTML again and figure out what was actually bugging me about it. One of these days...

It's probably a stray anchor tag that I've left in there. It's all around the text. Screws up the display, shows as a big hyperlink. The next version won't have it.

Oh, and thanks again for such awesome work. I'm sure pleased with what you've done.

Yer welcome! I aim to please. Well, as long as I'm happy too.

Andargor

 

[barsoomcore]

I aim to please. Well, as long as I'm happy too.

I think that's aiming to please. Just not necessarily aiming at me.

 

[andargor]

Version 1.2 released

Finally found some time to update the database.

Changes:

• Classes in spell levels converted to long names
• Added spell_stat and spell_type fields to classes
• Removed stray anchor tag in full texts
• Fixed monster stat blocks
• Miscellaneous data fixes

Andargor