How is a player normally supposed to abandon entirely when the parser asks which do you mean? I’m not going to post half of my application again, as it doesn’t seem to help anyone want to answer my questions… so it’s kind of hard to describe, but sometimes, if I enter “no” or something irrelevant, it spits back a parser error or check rule result that ends the process, but sometimes it asks “What do you want to [action]?”…
How can I make it never ask “What do you want to [action]?” in the middle of asking which do you mean? I guess that’s my question. I’m not sure I understand the point of that injected there, as if someone has entered something nonsensical at this juncture, it should just abandon. Any thoughts?
Edit: Instead of code, here’s the output that’s irking me:
kitchen
You can see a woman, Bob and a being here.
>look arm
What do you want to look: 1) your left arm, 2) your right arm, 3) woman's left arm, 4) woman's right arm, 5) Bob's left arm, 6) Bob's right arm, 7) being's left arm or 8) being's right arm?
>no
That was a rhetorical question.
>look his arm
What do you want to look: 1) your left arm, 2) your right arm, 3) Bob's left arm or 4) Bob's right arm?
>no
What do you want to look?
>arm
I only understood you as far as wanting to no.
>look his arm
What do you want to look: 1) your left arm, 2) your right arm, 3) Bob's left arm or 4) Bob's right arm?
>no
What do you want to look?
>no
That was a rhetorical question.
>
Something that would help with debugging this is to come up with something that prints the command that’s being processed every time it disambiguates. (Maybe with a “before reading the player’s command” rule?) I think the expected behavior here is that if you enter something that begins with a verb at the disambiguation prompt, it processes it as a new command, and if you enter something that doesn’t begin with a verb, it sticks your answer before the disambiguated noun and tries to reparse. So if you type “x silver key” and then type “bright silver key” at the disambiguation prompt, it processes the new command as “x bright silver key silver key.” Which usually works OK because all those words match the bright silver key object.
The behavior there looks pretty weird. As a totally wild guess, it seems like some of the time “no” is triggering the response for the action “answering that no” (or something like that; “no” is a valid command), and other times it’s getting written into the command buffer but the game has for some reason processed the command as if you’d entered “look.” So if “no” is in the buffer and it’s asking you what you want to look, when you say “arm” it will process this as “no arm” which gets you the “I only understood you as far as…” message. But I have no idea why this might be happening. Maybe it’s some interaction of Numbered Disambiguation Choices with other stuff you might be doing or other extensions you might have.
Yeah… without posting the entire, very large pile of code, it’s hard to ask questions. Things are very interconnected… I solved it like this, though it may or may not make sense without the rest of the code (these are not next to each other like this in the real application):
Rule for asking which do you mean while the player's command includes "no":
say "Decisions, decisions... none of these will do for now.";
follow the put temporarily descoped for pronouns things back in scope rule;
A thing can be temporarily descoped for pronouns.
This is the put temporarily descoped for pronouns things back in scope rule:
now everything that is temporarily descoped for pronouns is scopable;
Last after reading a command while the player's command includes "his":
repeat with x running through relevant things that are held by a person:
if the holder of x is not male or the holder of x is neuter:
now x is temporarily descoped for pronouns;
now x is not scopable;
Now… on to the very next and immediate bizarre problem…
Ok, this open-ended which do you mean question is popping up again in a different use case:
>look at
What do you want to look at?
>look hat
You can't see any such thing.
>look hat
What do you want to look: 1) woman's hat, 2) Bob's hat or 3) your hat?
>
Here, we see that there are indeed 3 hats, but after the typo “look at”, which was meant to be “look hat”, it is very easy for the player to not notice that this is a special circumstance where they should have just typed “hat” and instead type in a full new command “look hat” and end up being told there are no hats when there in fact are.
Is there a way to just suppress this “what do you want to x?” feature? I’d rather if the parser is so confused about what the noun is that it can’t even offer suggestions that it abandons entirely and starts an entirely new turn. Any thoughts?
In other words, I would want this to happen:
>look at
[Parser error (perhaps can't see any such thing error, perhaps custom)]
>look hat
What do you want to look: 1) woman's hat, 2) Bob's hat or 3) your hat?
>
The standard behavior of the parser is that any command starting with a verb will pre-empt disambiguation. For example:
The Kitchen is a room.
A hat is a kind of thing.
Bob's hat is a hat in the Kitchen.
Steve's hat is a hat in the Kitchen.
>look at
What do you want to look at?
>look hat
Which do you mean, Bob's hat or Steve's hat?
>look
Kitchen
You can see Bob's hat and Steve's hat here.
>look hat
Which do you mean, Bob's hat or Steve's hat?
>bob's
You see nothing special about Bob's hat.
You must have something in your code that changes this.
I have things placed out of scope until a command is read that makes sense to scope them back in, to support there being so many things at once. This works fine when it’s read initially, but it seems it doesn’t fire when the command is being read during a which do you mean sequence:
After reading a command while the player's command includes "[hat]" (this is the scope hats rule):
repeat with x running through relevant list:
if x is hat subcategory:
now x is scopable;
Why doesn’t this trigger when “reading a command” during asking which do you mean, and how can I fix that?
By the way, how do you handle a case where there are a black hat, a white hat, and a black bat in the room and the player types “look black”? I haven’t been able to get your scope hats rule to work in a reduced test case at all, but I’d be concerned that the scopability rule wouldn’t know to put the black hat (or black bat) in scope because of “black,” so it would wind up choking.
I suppose there would have to be a separate rule to put all black things into scope if the word “black” is found in the input.
At this point you might be better off writing your own parser. If each object has a binary flag for “name contains black”, one for “name contains white”, one for “name contains hat”, and so on, the task of creating a reasonable parser is made much easier. When you need to look for a noun, set a flag on every object in the room. Then, as each word is parsed, remove the flag from things without that property. If there are multiple objects left at the end, ask the player to disambiguate, and go through the process again (skipping the give-everything-the-work-flag step). When only one thing is left, you have your noun.
Yeah, one of the historical uglinesses of the I6 parser. The big loop has one read-line call at the top, and then a couple more read-line calls partway down that are called only if disambiguation is needed. Only the top one is wrapped in the “reading a command” activity.
Well, based on that, I ran “rules” and realized this might help. It seems to have worked so far:
Before deciding the scope of the player while the player's command includes "[hat]":
repeat with x running through relevant list:
if x is hat subcategory:
now x is scopable;
The deciding the scope of the player happens mid-parser, unlike reading a command it seems. Haven’t fully tested yet, but so far it’s working as expected again with this change.
Edit: OK, this only partially works:
Before deciding the scope of the player while the player's command includes "[hat]":
repeat with x running through relevant list:
if x is hat subcategory:
now x is scopable;
Before deciding the scope of the player:
say "[the player's command]";
This results in:
>look at
look atlook at
What do you want to look at?
>hat
look atlook atYou can't see any such thing.
>look at
look atlook at
What do you want to look at?
>look hat
look hat
What do you want to look: 1) woman's hat, 2) Bob's hat or 3) your hat?
>
If a full new “look” is initiated after “What do you want to look at?” it works, but just adding “hat” still isn’t triggering anything because it seems that there is no rule to attach it to. Man… I realize the normal behavior is to do this, but given my tweaks to the system for performance reasons for lots of objects, I’d really like to change the behavior such that if there is no noun on the first pass that it throws up a parser error immediately… that would require changing the parser i6 code wouldn’t it… crud.
