PDA

View Full Version : 4eParser Help



TrinityBlood
May 23rd, 2010, 22:27
I am new to the community. My group and I recently purchased licenses about a week ago for FGII. We are currently running a 3.5 adventure to get used to the program, but in the near future will be starting a 4e campaign. Being the more computer savvy one of the group I have been delegated the job of parsing the info we need to play 4e in FGII. So far I have had very little trouble parsing 4e core books using 4e parser and compendium mode. But, parsing Deaths Reach gives me this error:

5/23/2010 2:49:13 PM : ERROR:System.Xml.XmlException: The 'li' start tag on line 3380 does not match the end tag of 'b'. Line 3380, position 640.

<id-00002>
<name type="string">Stasis Vault B Attack</name>
<shortdescription type="string">Action: Opportunity; \rRange: Melee 1; \rAttack: +27 vs. Will; \rTarget: Triggering creature; \rHit: 2d10 damage, and the target is stunned until the start of its next turn.; \rMiss: No damage, and the target is slowed and must succeed on a DC 24 Athletics check to move 1 square. For every 5 points by which the check result exceeds the DC, the character can move another square. (The character can still run, if the check allows enough movement.)</shortdescription>
</id-00002>
</powers>
*** <text type="formattedtext"><p><b>Perception</b></p><p><list><li><b>DC 29:</b> The character spots the astral diamonds that serve as the anchors for the stasis vault, and can target those anchors.</li></list></p><p><b>Additional Skills:</b>Arcana </p><list><li> <b>DC 16: </b>The character senses the magic of the stasis vault’s walls. The check isn’t possible from more than 5 squares away. </li><li> <b>DC 24: </b>After detecting the stasis vault or seeing it in action, the character identifi es it, and understands how it attacks and that it has anchors that must be disabled to breach it. </li><li> <b>DC 29: </b>(trained only): </b>The character can see the stasis vault walls and understands its weaknesses. Such a character knows where the anchors are and gains +2 on any countermeasure check.</li></list> <p><b>Trigger</b></p><p>A When a creature tries to enter a stasis vault square without using a countermeasure, or ends its turn adjacent to but not inside the vault’s perimeter, the vault uses attack A. When a creature ties to teleport into the vault, it is shunted to the nearest square outside the vault, and the teleporting creature is attacked in that square.</p><p><b>Countermeasures</b></p><p><list><li> Acrobatics DC 29: A successful check allows a character to move by any means through the stasis vault’s perimeter into its area without triggering trigger A. </li><li> Arcana DC 29: A character adjacent to an anchor point can disable it with a successful check. If half the anchor points are disabled, the vault collapses and all its effects end. </li><li> If a creature leaves the stasis vault with the last of the vault’s contents, the vault collapses and is destroyed. All its eff ects end.</li></list></p></text>
<flavor type="string">Silver-blue lines of glowing energy form a floor-to-ceiling box in the center of this ovoid-shaped chamber.</flavor>
<trapdesc type="string">The stasis vault is meant to keep its contents in and trespassers out, but its semivisible shell allows would-be looters to see within.</trapdesc>
</stasisvault>
<kineticarches>
<name type="string">Kinetic Arches</name>

Any help would be greatly appreciated.

PublicJohnDoe
May 24th, 2010, 08:21
I guess the problem is here:

... <b>DC 29: </b>(trained only): </b>...

You have two </b>, where you only opened one.

tdewitt274
May 24th, 2010, 13:59
Yep, the beauty of HTML. While the parser is great, there's always something that WotC can do to muck up something as accurate as XML.

You should be able to remove that second bold closure and re-run the parse.

EugeneZ
May 24th, 2010, 23:52
As much as it's tempting to blame issues like this on WotC, the reality is that FG is the "consumer" here. In my humble opinion, the real issue lies with the design of FG. There is only one data structure for describing objects, but it is also used to describe formatting. This is a mistake. Creating a DTD for db.xml would make that quite clear, as you'd need to describe formattedtext-type fields within the DTD. Once you start doing that, you realize you've made a mistake.

That said, this is a solved problem. Formatting is not supposed to be done via XML. The W3C tried it with XHTML and the poor results of that are well documented. Instead, simply place the content of formattedtext entries in a CDATA block. This exempts the content of the block from being treated as XML and it instead becomes a long string. Then an internal formatting engine can consume this string. Simply use one of the many compliant web formatting engines out there and they will render WotC's mistakes just fine.

Edit: I forgot to mention that one of the many benefits of my approach is that it would allow for far more HTML-like layouts in story and other formattedtext entries. As it is, FG2 is re-inventing the wheel, but it stopped in 15,000 BC. It supports a small handful of tags, and does even that poorly.

TrinityBlood
May 25th, 2010, 01:35
Thank you all for the replies. I will try removing the extra "/b" and re-parsing.

Thank you EugeneZ for your response, but it went completely over my head. Is there an example that you can give me of what you suggest doing?

EugeneZ
May 26th, 2010, 02:03
I probably shouldn't have bothered posting that. It was a comment about the way FG2 is designed and is a completely unhelpful comment in every other way. I'm sorry about that. :p

What I was saying is that if FG2 treated certain parts of the data differently, you wouldn't be having issues like this, and we'd be able to have more advanced and more reliable formatting in FG2. But that's neither here nor there.

You need to remove that closing tag. FG2 requires that all data be valid XML. That means, among other things, that all opening tags need to have closing tags, and must be closed in the order they were opened. WotC uses HTML, which is not XML, and because of that sometimes when you scrape, the output won't work in FG2 (something Tenian's parser detects.)