RoomDesc Parsing

[BryanSchuetz]

I've noticed that at times the "also here" and "obvious paths" are either nested under .roomDesc or set off as sibling <pre> elements. I haven't been able to figure out any rhyme or reason as to why it switches around, would be nice if it was always set apart, so we can style them to distinguish from the description.

Was also noticing that roomlinks and players seem to all have negative [exists] attributes—am I understanding that right? If so, that's nice—so we can also better distinguish them from all the other crap that might be in a room.

[ondreian]

That would be a good enhancement, I'll look into it, odds are they are sometimes chunked together and sometimes not by the game engine.

re: negative ids Negative ids are sticky in that those objects are never garbage collected internally by the game engine (but they may be reassigned a new sticky id), they are used for permanent portals, versus ephemeral ids like boxs/loot/etc

[ondreian]

Just to confirm, this is on the latest master branch with the parser rewrites?

[BryanSchuetz]

Yes, I want to say it used to be consistently set apart in it's own element before—but I'm not positive.

[chriscoyier]

That would be cool if "Also here" and "Obvious paths" were in their own distinct blocks. And maybe even the "You also see" stuff could be split out.

[ondreian]

The previous parser would (for better or worse) treat new lines as a "close tag" directive so:

<room>
   <description>This is a description\n
   <loot>This is loot\n
   <paths>This is paths\n
</room>

would have implicitly been closed the tags <description> <loot> and <paths> at the \n character.

I had worked around this by merging tags where this was not true, but obviously there were a lot of bugs with it which resulted in unrecoverable errors.

The current logic is much, much simpler and as a result more grokable/maintainable (I hope). I think this is probably a tricky change

[ondreian]

It seems like when Also here is present, the <compass> comes between them and the parser flushes the currently open <pre> it should probably be fixable now