Any other DDI Character Builder Sheet Templates?

[luide]

It has been few years since I last played around with XSLT and XPath, so it actually took me almost an hour to make this crude proof of concept:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

    <xsl:template match="/">
        <xsl:copy-of select="/"></xsl:copy-of>
        <xsl:for-each select="D20Character/CharacterSheet/StatBlock/Stat">
            <xsl:choose>
                <xsl:when test="@name = 'Strength'">
                    <xsl:element name="{@name}">
                        <xsl:attribute name="value">
                            <xsl:value-of select="@value"></xsl:value-of>
                        </xsl:attribute>
                    </xsl:element>
                </xsl:when>

                <xsl:when test="@name = 'Constitution'">
                    <xsl:element name="{@name}">
                        <xsl:attribute name="value">
                            <xsl:value-of select="@value"></xsl:value-of>
                        </xsl:attribute>
                    </xsl:element>
                </xsl:when>

                
            </xsl:choose>        
        </xsl:for-each>
    </xsl:template>
</xsl:stylesheet>

This piece of code first copies all elements to the output file and then processes the Stat elements via <xsl:choose> and <xsl:when> methods and creates new element named as Strength etc.

I'm still checking how can I make the creation of stats completely automated but current version is easy enough to expand via use of copy-paste.

If you want the "new" elements named in some other way, now is good time to say it

Note: heavily edited from first version

 

[luide]

So far I haven't managed to completely automate the process, looks like it has to be done with just copy-pasting the <xsl:when ..> parts and changing the test = "@name = ..." for each stat.

Funnily enough, looks like Wotc has decided that pretty much everything is stats.

Other option is to check if Adobe Live-Cycle supports XPath properly and use
D20Character/CharacterSheet/StatBlock/Stat[@name = 'Strength']
as the qualifier like Thanlis suggested

 

[Mustrum_Ridcully]

The new XML, unfortunately, is bad XML. (IMO.) Bizarrely, some sections that you don't need use decent XML... but the bits you need are coded such that using, for instance, Adobe Live-Cycle Designer to build a PDF form for it are at a minimum bloody tricky, and quite possibly undoable without Javascript.

For example, there's a section with the base ability scores (before even racial modifiers). That section would be quite usable, if we cared, but we don't. For example, the <AbilityScores> tag here contains a tag called <Strength>, done up with an attribute (in the XML sense) into <Strength value="16" /> or the like. This, we could extract with PDF data bindings. Not too bad. It would have been even better if the tag had actually been a normally closed tag with the value as its contents, like this: <Strength>16</Strength>... but the one they've used is okay.

However... when it comes time to get the values we actually WANT, they've used a completely back-asswards XML setup which renders the data practically inextricable. Here's the data for the actual Strength score:

         <Stat name="Strength" value="16">
            <alias name="Strength" />
            <alias name="str" />
            <statadd value="14" />
            <statadd Level="1" value="2" charelem="a171cd0" />
         </Stat>

This doesn't look so bad, and indeed is pretty easily parsed by eye... but to the data binding it's practically opaque.

Even <Stat strength="16" /> would have been a better way to do it.

To retrieve the data from my preferred form it'd look something like this:
.CharacterSheet.AbilityScores.Strength.value

To retrieve from the this-isn't-so-bad version they've used for the pointless pre-modifier values, you'd use something like:
.CharacterSheet.AbilityScores.Strength.getAttribute("value")

Neither of those is too bad, because the name of the tag is indicative to us.

But for the actual one they used? Don't be confused by the name attribute. The actual name of a <Stat ... /> tag is Stat. But there are many "Stat" tags. How do we tell them apart? By the "name" attribute.

How shall I put this... this is terrible code. Because you can't, as far as I can tell in a couple hours of looking at the PDF XML spec, actually sort by attribute value. I can pull out, say, "the first 'Stat' tag which has an attribute named 'Strength'." But here they're obliging us to ask the code the following question:

"Go through all your tags named 'Stat' with the attribute 'name.' Pull up the value of this 'name' attribute, and compare them to a constant I will tell you - in this case it's 'Strength'. Once you find the one which matches this, then pass the tag (not the attribute, nor its value) to a call which will actually extract the value of the attribute 'value'." Yech!

Imagine you're running a party. You have a guest list; your staff can quickly find each guest by name. Each guest holds a placard which could hold a number. And you get to the question, "Okay. What's Bob's number?" In good XML, this is easy as pie.

Here? WotC has supplied us with the following fancy dress party:
- Every guest is named Sam. Each and every one of them.
- Every guest's placard is inexplicably blank.
- Every guest has a card in their right-hand pocket, in Arabic. On the card is their secret name for the event. You have one staff member, Alain, who picks pockets and reads Arabic.
- Every guest also has a corsage which encodes to their number in the Victorian 'language of flowers'. You have a second staff member, Judith, who can understand this code.

So in order to get Bob's number, you must:
- Tell Alain to go up to every Sam in the room, and pick their pocket.
- Once he finds the one whose card says "Bob", point that person out to Judith.
- Judith looks at that person and infers the number, and tells it to you.

Compare and contrast to the 'guest list and placard' model that XML is supposed to be.

Worse, in the case of PDF forms, as far as I can tell, you don't even have Alain on staff. You have to go hire an external company, Javascript Inc., to send Alain to your party. And you can only communicate with Alain using the company's official forms - no talking to him directly.

Epic. XML. Fail.

(Note - I am relatively new to XML. I understand the theory better than the practice. It may easily be the case that Alain was hiding under the table and I missed him. It may be the case that the guest list, indexed by secret name, is hiding in the refrigerator. And it is possible, even likely, that for some situations (WotC knows that an unknown number of persons named "Pow Ercard" will be coming to the party, but not what their secret names will be), the approach used may be necessary. But for the most part, in a situation like this where all we want to do is ask Strength Smith his number, and we know he'll arrive and there's only one of him? Freakin' horrible.)

I don't think that's bad XML. From an object-oriented point of view - Strength, Constitution and Dexterity are all objects of the class Stat. That's how I would implement it. Strength, Constitution, Dexterity, Intelligence, Wisdom, they can all be described in similar ways - they have a base value, they have modifiers based on race, they have modifiers due to leveling, they might have modifiers due to epic destinies or similar things.
If you give the element a different name every time, you would need to redefine this data structure every time.

The only sensible alternative would be to use inheritance.
But that only makes sense if you want to implement different behaviors for the different attributes, but that's certainly not true. Strength works the same way as Dexterity for the purposes of this model.

 

[Nytmare]

I don't think that's bad XML. From an object-oriented point of view - Strength, Constitution and Dexterity are all objects of the class Stat.

Some other things that are currently the object "stat":

• Attributes
• Attribute modifiers
• Armor Class
• Remaining Death Saves
• Level
• Half Level
• Hit Points
• Level 1 Hit Points
• Healing Surges
• Fortitude Defense
• Reflex Defense
• Will Defense
• Initiative
• Misc Initiative Values
• Ring Slots
• Every Skill Value
• Every Skill's Trained Value
• Every Skill's Misc Value
• Every Skill's Armor Penalty
• Healing Surge Value
• Speed
• Average Height
• Average Weight
• Size
• Character Class
• Every At Will Power
• Every Daily Power
• Every Encounter Power
• Every Utility Power
• Hit Points Per Level
• XP Needed
• Weight of all Equipment
• Attack Rolls
• Resistances
• Shield Bonus

That leaves what unaccounted for: race, feats and equipment?

And why the hell don't they have ability descriptions in the freaking XML? Who is that supposed to be protecting?

 

[jlhorner1974]

This is no knock on the developers that work on Builder, as I believe they have all given a lot of effort and have put out a good product despite apparently severe restrictions on budget and time.

It seems to me that their XML output closely reflects the internal data structure of their program. Any calculated number is a stat, and stats can have any number of modifiers to them (statadd in their lingo). This certainly makes sense from a programming standpoint, but it creates havoc on those trying to consume the information, as was said.

My guess is that they are just programmatically looping through all of the stats and spitting out XML based on each particular item. But they haven't given any real context on what stat is what -- you see stats like "Bluff", "initiative", "Speed", and "Saving Throws" all tossed in the same section.

Some things have been changed for the better -- short descriptions for feats, class abilities, can now be found with the item instead of having to search through the textstring section for an ITEM_NOTE_ entry that matches the name of the item (which is a pain). Also, the new Powers section is helpful, giving a breakdown of power data by weapon.

But some information completely missing -- there used to be a RulesElementField section that let you know what item slot a magic item used, but now it seems to be gone. Right now, there is insufficient data in the file to determine what the currently equipped Arms slot item is, for instance (I guess that the Viewer is looking up the item in the database to figure this out.) It's also a pain to figure out what powers or magic items were used.

I think one of the biggest problems is that the .dnd4e file consists of some sections with choices that were made when creating the character (the "internals", that comprise what Builder and the Viewer *actually* need to reconstruct the character) interspersed with "user friendly" sections (calculated values that Builder/Viewer do not really need to load). It is clear that Viewer has its own ability to calculate things, or else you wouldn't be able to pencil in your own numbers on the sheet and have things recalculate. So why store calculated values at all, unless you are intending on having third parties look at or consume them?

It's also clear that Viewer also has access to the rules database, as things like the Regional Benefit, power, and magical item full descriptions can be seen (and printed) in the Viewer, but this information does not show up in the .dnd4e file (which is understandable).

IMO, if Builder/Viewer are going to store calculated results in the .dnd4e file, there should be two distinct sections in the file -- one for internals (that the builder/viewer actually look at) and one for the actual character sheet in XML form. The character sheet section should have enough information in it that you can easily use an XSLT to create a sheet that contains all the information on the standard sheet with a different look and feel. This XML should be hierarchical and follow the layout of the standard sheet -- Skill stat data should go under a <Skills> section, for instance. Also, the output should reflect what state the sheet is in when it was saved. Powers should output stats for the weapons that appear on the standard power cards that print with the sheet (taking into account user customizations that hide cards or determine which weapons' stats appear on which power cards). Don't tell us that there is a penalty to a stat if heavy armor is equipped or if the character does not have a certain weapon/armor proficiency -- we can't change what things are equipped or what proficiencies a character has from within the builder anyway.

It would be even better if the viewer accepted a custom XSLT so that it would apply the formatting for us and let us print custom power cards and magic item cards, because there is no way Wizards will ever export the descriptions for those in XML form. (It'd be way to easy for others to use it to generate their own electronic tools that way.)

My point is that the Viewer holds all of the information on what needs to be displayed on a character sheet -- the "XML Output" feature of Builder/Viewer should simply output all the information needed to reconstruct the standard built-in sheet. Just tell us what belongs in every box and on every line of the sheet without having to apply any logic!

 

[Nytmare]

It would be even better if the viewer accepted a custom XSLT so that it would apply the formatting for us and let us print custom power cards and magic item cards

Randy had alluded to this at Gencon, but the last time I brought it up here I was called a liar, a crybaby, and possibly an idiot.

 

[jlhorner1974]

Randy had alluded to this at Gencon, but the last time I brought it up here I was called a liar, a crybaby, and possibly an idiot.

From my experience, it doesn't take much to provoke a reaction like that.

Who knows what's actually happening right now? The landscape has changed a lot since then. But it seems relatively clear that the only way custom magic item and power cards will happen is if we tell builder how to format them, since there is no way builder will give us the details (which is understandable) to format ourselves.

Whether this will actually happen or not remains a mystery. This would seem to be a good month for it, as this month is a comparatively light month for data updates. But I wonder if they are really going to pull the trigger on it. I wonder if they are terrified that doing this opens them up to a flood of "your XSLT format doesn't work" when the problem is that the XSLT itself is bad.

More than likely, the development is probably well on its way to being done for this month, given the lead time they need for testing. It'll be interesting to see what they do.

 

[BlindGeekUK]

It might not be of any use (and might be highly illegal) but you can decompile the exe to get at the xaml files that define the char sheet and power cards...

 

[Taltos1964]

Stated one

I haven't seen what I want either in playing a character so I've started building a Game Night Tracker. I'll be using the XML from the Character Builder to read in a character. I'm using tabs across the top to avoid scrolling since I hate having to scroll way down the page to get to what I want. First tab is all the combat related info like the stat block, defenses, initiative, movement, hit points, and a good power list (including item powers). Other tabs right now are skills and feats, equipment, couple others that I forget right now. There will be a preferences/settings tab also. I want to be able to quickly and easily manage all the details of my character during the game without having to have a stack or spread of power cards in front of me.

What are you guys looking for? I have just gotten a decent start so I am easily a month or two away from anything useful as I'm doing it in my small amount of spare time. Let me know what you're interested in and it may be something I need to add.

 

[Luca]

Does anybody figured out how to display the details of a single power? I tried to fetch data from the compendium (via authentication), but this method is not good if you play (like me) in a room without internet connection (so i drop it very soon). For now, me and my players are using the printed power cards, but all of these papers are pretty annoying for me...

I haven't seen what I want either in playing a character so I've started building a Game Night Tracker. I'll be using the XML from the Character Builder to read in a character. I'm using tabs across the top to avoid scrolling since I hate having to scroll way down the page to get to what I want. First tab is all the combat related info like the stat block, defenses, initiative, movement, hit points, and a good power list (including item powers). Other tabs right now are skills and feats, equipment, couple others that I forget right now. There will be a preferences/settings tab also. I want to be able to quickly and easily manage all the details of my character during the game without having to have a stack or spread of power cards in front of me.
What are you guys looking for? I have just gotten a decent start so I am easily a month or two away from anything useful as I'm doing it in my small amount of spare time. Let me know what you're interested in and it may be something I need to add.

I'm quite interested in your work. Can you post some images of what you have done?
I'm doing something similar and everyday is a neverending fight with the .dnd4e files... I set up a local web application using php, mysql, xml and xslt. Here i attached some screens...
As you can probably see in these pics, there is a "DM view" and a "Player view". A player can login to use his configuration or use the default one logging as guest (as in the screens). If i'd like i can delegate some DM powers to any player, giving one or more of my buttons. The site is reachable even via mobile or iPod/iPhone with an own custom view (maybe i'll post some pics...)

PS: i forgot to tell you that the complete character sheets are just the pdf of the ones generated by the builder... I didn't make them, just saved the originals in pdf.