The new Writing Parser, and where it’s going

I realize I left off with some “what I have planned” and “what I’m thinking” for the writing parser a while back, and never posted about where I’ve ended up with it.

Especially with the tools out, some of the writing parser content looked really complicated since it was made before there was this new, improved parser. Well, like I said, I wanted something where writers can just write.

Though that old way of using a bunch of “psuedocode” blocks to check how a player’s stuff is arranged is still there and works because of just how the underlying system works, there’s tons of sort of shortcuts that work more naturally.

In most parsers, they use something like %descstring, or [object.descstring] to have some canned description replace what’s there. LEWD‘s is a heck of a lot more complicated.

Old and Busted / New Hotness.

Here’s a good example of the old:

Briefly, her eyes wander down to your (if naked){bare body}(if !naked){(if !top){%chest(if !bottoms){ and }}(if !bottoms){%bottomHalf}}.

Some writing in the game is like that simply because I didn’t go back and simplify it after the changes. It works either way.

Now, you’d just write:

Briefly, her eyes wander down to your bottom half.

See, now all the descriptions of anatomy is handled automatically because the parser can see that the player’s anatomy is being talked about.  You don’t need a “%desc” markdown to make it happen.
You also don’t need all those psuedocode blocks to decide which descriptor to show, because it already figures out that by saying “bottom half” it should describe that whole tree of things, or some condensed amount of it, for the writing.

“bottom half” is essentially a tree that contains all the lower anatomy in it. Of course it doesn’t describe it all, all the time, as that’d be monotonous. It will figure out the tense, and all that. It varies what it outputs by forming its own phrase. Perhaps in the future, I can have it look at its surrounding to see if there is a certain way it should style the description it creates.

So in general, there are no more %desc. They’re there, and will come even more into play with special variables supplied from the server, but most of the time the parser can figure out things automatically without that special markup.

Also, those psuedocode blocks are still there for lots of other things.  It can’t automatically change sex around for someone with a cock instead of a pussy; that must be hand written, still.

The “automatic parsing” instead of having a markdown may sound dangerous, but you can stop it from happening with something like “your \thighs”. The backslash will escape the parser’s wraith in that instance. So hand written descriptions for things can still be added.
In far, far more cases than not, you probably want the automatic parsing instead of having to throw in a % to make it happen. So it makes more sense to escape it when you DON’T want it.

Text Walking

Another difference is that before the parser just looked down text for things to replace (the psuedocode blocks, or %desc strings) based on the state at the start.

Now it “walks” down the text, one sentence at a time. It tries to understand each sentence, and how a state will be changed based on what is written there.
A good example of that, is it can tell that some clothing is entirely removed, or simply moved/torn/etc away from an area, based on the previous sentence. From then on, it knows that area should be bare.
Well, sort of. It’s still a work and process and doesn’t always work, and there’s some flags to force it to happen when the parser doesn’t currently understand, or if it’s changing it when it shouldn’t. Still considering changes on the best way to go about this, and I still need more content to see where it works/fails.

I had thought about some one word at a time parsing, where it’d identify what’s a noun, adjective, verb, what might be a descriptor to parse, etc. I’m not sure at this point if there is an actual benefit, though. It would be much slower.

Debugging

I’ll be adding some debugging mode that’ll highlight what things that parser has done, to make it clearer to see what it’s doing to a writer’s content.
Say someone writes:

While looking into your eyes, the…

… would show in debugging mode like:

While looking into your red eyes, the left of which is covered by an eye patch(eyes), the…

… to help figure out why something may not display like expected.

Client Modding

I’ve mentioned this before, but the whole descriptions thing will remain moddable. The text parsing is done on the client, so it can be changed for crazy stuff.

Bookmark the permalink.