Based on post-comp feedback, I’ve done a major revision pass on Smarter Parser. While Smarter Parser is designed to ease novice players into IF more gently, I realized I’d lost sight a little bit of the needs of experienced players and the authors themselves, so this update mostly focuses on them. Major changes:
Better documentation, with a summary of each parsing rule and instructions for changing the message and removing it. In general, the attitude is less “set it and forget it” and more “with interesting power comes interesting responsibility.”
Rules referring to specific types of nouns (body parts, clothing items, and general surroundings) have been spun off into a new plug-in extension, to reduce potential conflicts with your own implementations.
In general, a trimming back of overly ambitious behaviors: for instance, now looks for only a specific set of adverbs, rather than anything ending with “-ly.”
Several new ways to customize output, including replaceable overrides for exactly how reparsed commands are displayed.
The NOVICE OFF and CORRECT OFF commands are now better advertised to the player the first time Smarter Parser kicks in, and preferences are stored in an external file when possible. Any future stories using Smarter Parser will automatically honor this file if it exists.
Major speed improvements, including rewriting some low-level matching algorithms in I6, and several other tricks here and there to improve performance.
No longer tries to recognize swear words, in line with the next I7 update which no longer responds to these either.
The new Smarter Parser is temporarily on my web space, along with the new extension for unimplemented stuff (which has a mechanism for authors to remove individual words from the match patterns, if your story has, say, noses but no other body parts). Posting here for feedback on the changes before submitting to the extensions site. Thanks to everyone who provided ideas and suggestions!
Being far less sophisticated in literary matters than Maga is, I immediately thought not of Shakespeare but of The Three Stooges. In Disorder in the Court, there is a scene in which which Curly is taking the oath before testifying in a courtroom. “Do you swear . . .” the bailiff starts to ask. Without allowing him to finish the question, Curly responds “No – But I know all the woids!”
Quick bug I’ve found: the documentation, including the prewritten link to remove the rule from the rulebook, consistently refers to “The unnecessary possessives rule”. Problem is, only “The stripping possessives rule” exists in the rulebook.
Aaron, sounds like an awesome update. Will you be updating the Player Experience Upgrade later on as a result? I’m using V1 and there are some minor things that happen behind the scenes that I can’t quite figure out.
For example, I defined some Understand as a mistake rules as follows:
Understand “yes” as a mistake (“That was a rhetorical question…”) when Monica is visible.
and instead of these rules firing I get “Saying yes here has not effect.” I’m sure there’s a quick solution to ensuring my rules fire, but I’m not sure what it is or whether this is a Smarter Parser issue or somewhere else.
I’ve seen a couple of other confusing messages about body parts, but now I’ve forgotten the details. (I’ll try to pay attention next time I see anything odd though.)
It might not be an issue with Player Experience Upgrade. At least, this works swell for me:
Include Player Experience Upgrade by Aaron Reed.
The beginning is a room.
The end is north of the beginning.
Monica is a woman in the end.
Understand "yes" as a mistake ("'That was a rhetorical question ...'") when Monica is visible.
Test me with "yes / n / yes"
Zack-- None of the extensions in Player Experience Upgrade modify the saying yes action, except to change the library message and extend it to also respond to “okay” and “ok”. So it looks like the problem must be elsewhere. The conflicts with body parts should be gone in the new version. And yeah, I’ll push out a version 3 of P.E.U. shortly. (I really should have come up with something that made a better acronym.)
Check answering someone that when a thing (called the subject matter) is the known thing identified with the topic understood (this is the convert answering it that to exclaiming rule):
If the number of known things identified with the topic understood is 1:
instead try exclaiming the subject matter to the noun;
The rule posted above would translate it into exclaiming hello to the fat cat.
It depends on whether or not the parser can process the phrase after the comma as a command. If it can, the convert answering it that to exclaiming rule never runs. So if “hello” is parsed as a “saying hello” action, then it will be parsed as a request for the fat cat to try saying hello. But if there is no such grammar line it will fall back to answering it that, which will then be redirected as long as there is a known thing called “hello.”
This is all reflected in Speech Motivations currently. Without going into too much detail, I am planning to change Speech Motivations so that every speaking action calls the “speaking out loud” activity during its report phase, and moving all the different reports into the activity itself based on what action is going on (or what the speech motivation of the current interlocutor is, which should amount to the same thing).
Yeah, sorry for being dense earlier-- this does sound like a great solution. In general there are way too many conversation and NPC-related actions (up to 20! if you count things that NPCs should reasonably respond to, like touching) and coming up with a simpler set for authors to build on, rather than having to strip down, would be great.
I would love to be able to point people towards a nice friendly conversation system in the Player Experience Upgrade documentation, and work to make the extension compatible with such a system… so definitely keep us posted as you continue working on this.
Almost forgot: Mike, I’m thinking of putting Scope Caching in the next version of Player Experience Upgrade, and rewriting some scope checks in the existing extensions to optionally make use of it. Would this be okay with you, and/or do you forsee any problems with including it in a general-audience extension like that?