I suggest you ...

Parse valid responses to disambiguation requests as disambiguation requests rather than new commands

When a disambiguation request is printed, Inform decides whether to process the next input as a response to the request or as a new command by checking to see whether the first word of the input is a verb. Ordinarily this works well, but it will break when an object's name contains a verb. See http://inform7.com/mantis/view.php?id=1127 for an example.

In comments there, zarf says:
"This has been the intended behavior since the I6 days. It would be bad if a disambiguation prompt made some other command untypable, by stealing its verb. (It is less bad if a disambiguation fails, because the player can always make themself clear by typing the complete intended command.)"

I respectfully disagree with this evaluation. This behavior:
"What do you want to take, the buy chip or the sell chip?
>buy
What do you want to buy?"
seems worse to me than temporarily foreclosing the "buying" action, as the game has asked a question and refused to understand one of the answers it offers. People who know how the parser internals work can make themselves clear by typing "take buy chip" out in full, but this behavior is unfriendly to people who don't know this.

(Note that the "command has become untypable" problem only applies when the player changes her mind after seeing the disambiguation prompt, and thus will be much rarer. In any case, a player who knows how the parser internals work can recover her intended command by typing an invalid response to the disambiguation prompt and then typing the new command.)

So my proposal is that, at a disambiguation prompt, the game should always try to process the command as a response to the disambiguation first and, if that fails, try to process it as a new command.

1 vote
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    matt weiner shared this idea  ·   ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Adminemshort (Admin, Inform 7) commented  · 

        Whatever solution is adopted (or not), it would be really bad if it were possible to get stuck in a disambiguation loop. Just occasionally one encounters a game state that asks "Which do you mean, the spoon or the spoon?" -- where it's not clear what to type to disambiguate -- and currently it's at least possible to leave that situation by typing another verb instead. (One can also try "both" or something, but most novice players are probably unaware of that.)

      • matt weiner commented  · 

        For a more plausible use case, see the very bottom of this post about the Threaded Conversation extension: http://www.intfiction.org/forum/viewtopic.php?p=55429#p55429

        In a situation where the game has asked, "What do you want to ask Bob about: what it might be worth or who would buy it?", the player cannot type "buy." It wouldn't be feasible to expect that valid verbs not appear in conversation topics.

        Another worry is that the existing strategy for dealing with disambiguation prompts also fails on commands that do not begin with verbs, in particular on directional commands. This:

        Playroom is a room. A green block is here. A red block is here. Kitchen is north of Playroom. Test me with "x block /n".

        yields "I only understood you as far as wanting to examine north," so the new command's non-verb has effectively been stolen by the disambiguation request. It is possible to get the same effect by "go north," but again that's something that you would be unlikely to type if you didn't understand how the parser internals work.

      Feedback and Knowledge Base