New experiment: Parser Overrides

Authoring Inform 7
1

Given all the recent discussion of overriding Inform’s parser, I’ve built a new, safer way to do that.

Include this extension (Parser Overrides by Daniel Stelzer), and you can now write “parser override” rules, which circumvent the parser in specific circumstances. The result of these rules should be an action, and Inform acts as though this action had come straight from the parser; the action processing and turn sequence rules run like normal.

For example:

Blaspheming is an action applying to nothing.
Parser override when the player's command includes "ialdabaoloth":
	override blaspheming.

Now, any command including the name “Ialdabaoloth” is parsed as blaspheming, and this blaspheming action is processed just like any other action coming out of the parser. You can intercept it with “instead” rules, time will pass, and so on.

Please try it out and let me know how it works. I’ll put it on Github once a few people other than me have used it and found success.

Parser Overrides.i7x (6.3 KB)

One word of caution: for complicated technical reasons, this doesn’t work.

Override asking Helen about "syzygy".

Instead, you need to do this:

Override asking Helen about overridden topic "syzygy".

This sets the player’s command to whatever text you gave, and sets the topic understood to the player’s command.

Blame Inform’s handling of topics in stored action literals. The way stored actions are handled under the hood, this could work just fine—but the syntax for a stored action literal (i.e. an action spelled out in the code, like “asking Helen about whatever”) doesn’t set the STORA_COMMAND_TEXT_F value properly, and that’s not something I can change in an extension.

16 Likes
2

This is really nifty. I could imagine using it for things for which my thought process would otherwise have gone:

  • I’d need an After reading a command rule to look at the exact text of the player’s command, and then…
  • ugh, that’ll turn into a fragile mess
  • I guess I don’t really want to do this after all
4 Likes
3

I’ve also added some new functionality to Subcommands for those messy situations. My eventual goal is to stamp out parsing in “after reading a command” rules once and for all!

Now with Subcommands you can look at the exact wording used for the verb (“the subcommand of the verb”), in case you want to make “get” act differently from “take” in one specific circumstance. This will be empty if the action was triggered by anything other than the parser.

>[1] x me
Verb subcommand: x.
Noun subcommand: me.

As good-looking as ever.

>[2] look at me
Verb subcommand: look at.
Noun subcommand: me.

As good-looking as ever.
4 Likes
4

(What would this be useful for, you might ask? An instance I’ve run across before: suppose you have a pill that can be picked up and dropped, and you want TAKE to work just like GET in all circumstances, because that’s what parser players are used to. At the same time, TAKE PILL is a reasonable syntax for swallowing it. So you could write a rule that fires after taking the pill, which checks if the subcommand of the verb includes “take” and tells the player to SWALLOW PILL if that’s what they intended to do.)

6 Likes
5

I feel like I’m almost grokking this, but I’m not entirely certain.

>[1] Get Pill
Verb subcommand: Get
Noun subcommand: Pill

You take the pill.

>[2] Take pill
Verb subcommand: Take
Noun subcommand: Pill

Do you mean to get pill or swallow pill?

Would that be an example of how to actually use the extension? I apologize for not following 100%.

6

Pretty much!

This would be a use case for Subcommands rather than Parser Overrides, but it would be something like…

Before taking the pill when the subcommand of the verb includes "take":
    say "(assuming you wanted to pick it up[--]if you want to swallow it, say EAT PILL)[command clarification break]".
1 Like
7

Now I’m going to contradict the author of the extension and say it is a good use case!

pill-disambig is initially false.

Before taking the pill when the subcommand of the verb includes "take":
  now pill-disambig is true;
  instead say "Do you mean to get pill or swallow pill?"

Parser override when pill-disambig is true:
  now pill-disambig is false;
  if the player's command includes "swallow" or the player's command includes "eat", override eating pill;
  if the player's command includes "get", override taking pill.

(Not tested.) OK, as written this is naive, especially given how many words “eat” could be a part of; a response to the disambiguation could contain both “get” and “take”, putting this in an infinite loop, etc. But with effort you could offer disambiguation instead of calling on the player to just not say “take pill”.

5 Likes
8

True! I hadn’t realized that this could be used as a way to create your own pseudo-disambiguation prompts.

1 Like