‘That noun doesn’t make sense in this context’ is one of my least favourite messages, but rather than rewrite it (in case I make a mess of an occasion when I would actually like to see it, that I haven’t seen/anticipated yet), I wondered if I could just divert the parser to custom responses in the case of particular verbs where I know I don’t want to see this message.
I haven’t been able to do this with BEFORE rules, because disambiguation occurs before BEFORE rules.
For instance, with my custom ‘follow’ command, defined as applying to [any person], ‘That noun doesn’t make sense’ is triggered if you try to follow a leaf. So I tried changing it to [any thing], hoping to add a check for inanimate objects, but before it even gets to that check, disambiguation goes off -
follow leaf
‘Did you mean the leaf or a pile of leaves?’
I don’t want to be asked such a question, I want to be immediately told ‘You can only follow people.’
Any advice on how best to attend to this kind of thing?
I think the asking which do you mean activity is triggered even before the parser knows if the noun you want to follow is animate or not; so it would be hard to check at that point.
Is it possible to write something like this? (Which, obviously, I haven’t tested.)
Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error: if the current action is trying following something and the noun is not a person, instead say "You can only follow people."
You could expand the grammar to applying to any thing, and then use check or instead rules to rule out the non-people. Then you won’t ever see the “this noun doesn’t make sense” rule. (I think.)
I already tried changing to ‘any thing’, but I forgot to try an Instead rule. Turns out that that still goes to disambiguation first.
Now I will have a look at what Felix was saying…
I was well impressed that Inform took this line in its stride when I added it:
‘Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error: if the current action is trying following something and the noun is not a person, instead say “You can only follow people.”’
unfortunately though it didn’t go first After ‘get leaf’, disambiguation occurs, then it says ‘You can only follow people.’
Okay, I came up with something that works but could be loopholey.
First I set the command to apply to [any person].
Then -
Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error:
if the player's command includes "follow", say "You can only follow people.";
if the player's command includes "chase", say "You can only follow people."
If you type follow leaf or chase leaf, even though that would normally go to disambiguation, it redirects to these messages.
Since you are able to attempt to follow any person in this game, but not any objects, I don’t see loopholes when the player actually types ‘follow’ or ‘chase’ (object). But I was wondering if there were ways I hadn’t thought of for this ‘includes’ thing to trip me up when the player is using some totally different command.
I think you’re on the right track with an action applying to “any thing” rather than simply “any person.” A “Does the player mean” rule will help you avoid disambiguation:[code]Lab is a room.
The pile of leaves is in the Lab. Understand “leaf” as the pile of leaves.
A leaf is a kind of thing. In the Lab are four leaves.
Following is an action applying to one thing.
Understand “follow [any thing]” as following.
Check following:
if the noun is not a person,
say “You can only follow people.” instead.
Report following:
say “You follow [the noun].”
Does the player mean following the pile of leaves:
it is very unlikely.[/code]This gives you:
If you want to get rid of “(the leaf)”, just add:Rule for clarifying the parser's choice of a leaf:
do nothing.Unfortunately, this isn’t a general solution; you would need to add DTPM rules for each specific case.
Thanks Mike. Your way is looking solid. I guess the new catch is, as you say, having to set each case manually. Anyway, now I’ve got a couple of functional workarounds to play with.
Hmm. Sorry, should have tested it. A couple other things I thought would work didn’t, either.
This is clunky, but appears to work for my test cases.
[code]Following is an action applying to one thing. Understand “follow [any person]” as following.
Test is a room. There is a red ball in Test. There is a blue ball in test. Bob is a man.
After reading a command:
if the player’s command includes “follow”:
if the player’s command does not include “[yourself]” and the player’s command does not include “Bob”:
say “You can only follow people.”;
reject the player’s command.
test me with “follow me / follow ball / follow Bob”.[/code]
You’re welcome. FYI – if you’re going the DTPM route, you probably want to add a qualifier to be on the safe side:Rule for clarifying the parser's choice of a leaf when following:
do nothing.Also, I don’t know if your leaf / leaves scenario was just a contrived example to trigger disambiguation or if you’re actually dealing with duplicate objects which can sometimes be referred to as a group. If it’s the latter, you might want to contact “capmikee.” I’m pretty sure he’s working on an extension for that.
I’ve been feeling a bit discouraged about that disambiguation extension idea. Right now I’m thinking it might be part of a much larger extension that does a big parser rewrite (i.e. not something that will be finished in the next year!)
However, I have been thinking about how to deal with stuff like this. Aaron Reed’s “Remembering” extension has an example of a “refusal to disambiguate.” My own “Lost Items” extension uses some similar techniques.
In this case, you could handle the problem with a fake verb:
[code]Following is an action applying to one visible thing.
Wrong-following is an action applying to one topic.
Understand “follow [any person]” as following.
Understand “follow [text]” as wrong-following.
Check wrong-following:
say “You can only follow people.” instead.
[/code]