Is there a way to make I7 always print a clarification message for a particular thing?

As an example: Let’s say I have a noteworthy book in the game. In any context where Inform would consider printing a clarification message for the book because the player is doing something with it,

(the book)

I want it to decide, YES, print that message.

Rules for clarifying the parser’s choice… only seems to be relevant once the parser has decided it is going to print such a message.


So you want it to be printed any time the book is involved in a parsed command?

Hm. There’s actually two separate mechanisms for printing clarification messages.

  • If the command is entirely missing a noun (“GET”), but only one noun is available, the parser picks it and prints “(the noun)”.
  • If the command has an indefinite article (“GET A BALL”) and several objects match, the parser picks one at random and prints “(the noun)”.

(EDIT: Both involve the “clarifying the parser’s choice” activity, which I think I wasn’t aware of.)

Which are you thinking of?


@zarf Your hm leads to my own ‘hm’… from what you said about the mechanisms, maybe what I want is for it to print a clarification in any circumstance? Because looking at my WIP, in the circumstance I tested, it doesn’t match either of the mechanisms you described. I type X BOOK and it just gives the description of the book. I’m sure nothing else that could match “book” is in contention in this particular moment, so it does the healthy thing and doesn’t print a clarification. Except that with the book, I want it to print one anyway.

So I think I’m asking what @Draconis has suggested, even while I’m wary of opening some Pandora’s Box of circumstances I haven’t considered (second noun? weirdo inferred noun?)


I think I’ve worked out a non-deep, non-system-wide way to do this for this book.

The book is subject to an ‘Instead of doing anything…’ rule, and has only two actions that work with it.

What I could do is set the ‘Rule for clarifying the parser’s choice of book:’ to ‘do nothing’. Now the default is there will never be a clarification message where the book is involved.

Then, I can manually print “(the book)” in the case of the only allowed actions.

I’ll still be interested if anyone comes up with a more fundamental system (that isn’t too invasive :wink: )



Maybe something like the following (which I think is what Draconis was hinting at)?

First Before doing something when the current action involves the special book:
	unless the implicitly taking activity is going on or the number of entries in the multiple object list is at least 2:
		say "([the special book])[command clarification break]".

You would want to retain your “do nothing” clarification rule, so you don’t get two messages when the parser does choose it.


This may be stupid but what if you made a part of the object that has the same or similar name as the object, told the compiler it was unlikely to ever do anything with it, and redirected any actions toward it to the main object?

Kind of like if the object was “golden sneaker”, you could have a “golden sneaker aglet” that’s part of it whose only purpose is to serve as a disambiguation prompter.


I did have thoughts along those lines but they were too kludgy for even my taste :slight_smile: Though they wouldn’t have been had we not come up with a couple of other ways.

I’ve got my way, which suits my situation but isn’t a systemic solution, and now otis’s suggestion, which is pretty good and which I’ll mark as a solution.



otisdog’s solution looks like the tidiest approach. The “deep, system-wide” solution would involve hacking bits of code in Parser Letter G, and possibly elsewhere.

(The low-level parser feature isn’t actually “print an inferred object”. It’s “print the inferred command starting at word N.” If it doesn’t have to infer an object, it never sets N.)


Yep! Basically that, plus some way of making sure it only triggers off “top-level” actions so that an implicit action doesn’t print it every time. But that’s a lot more work for not a lot more benefit.

Good point. The most likely to be a problem is implicitly taking, which is straightforward to handle. I’ve edited my post above accordingly.

I’ve edited the solution post above again because the pseudo-clarification looks odd when it happens within multiple action processing. And I’ve also discovered that there are times when the parser issues a clarification but doesn’t execute the clarifying the parser's choice of something activity (so you get both the real clarification and the pseudo-clarification). There’s no way to really tell when that is going to happen without digging into the guts as zarf said, so really that approach doesn’t seem to be working out very well in practice.

However, after some study, and even though I’m not sure that I really understand what @severedhand is trying to do, it looks like it’s relatively straightforward to modify NounDomain() so that it treats specially-marked objects as though they have been inferred even when they have not. This change seems to plays nicely with does the player mean rules and other built-in functionality around inference.

I’ve worked out versions of this suitable for 6M62 and 10.1, but I’m not posting it because by its nature it can cause some silly-looking repetition:

>PUT SPECIAL BOOK ON TABLE				! <-- only one "special book" and only one "table"
(the special book on the wooden table)	! <-- parser-emphasized book means entire command from that point on repeated anyway
(first taking the special book)
You put the special book on the wooden table.

After pondering your original post, it seems as though what you may have been thinking about when you wrote it was something more like:

>PUT BOOK ON TABLE		! <-- only one "book" (the special book) and only one "table", but player didn't use full name of special book
(the special book)		! <-- parser-emphasized book is repeated but unemphasized table is not
(first taking the special book)
You put the special book on the wooden table.

If the latter case is closer to what you meant, then it may be possible to build something like that using Draconis’s Subcommands extension.


Yeah, when you spell it out like that, it is.


Yeah, subcommands might be perfect for this. If the action involves the special book, and the subcommand of the special book is not empty, that means it’s actually been typed by the player. Then set the subcommand of the special book to the empty snippet again.