TL;DR – Do visible and touchable mean anything in a DTPM rule? In other words, are they accurate?
Details: I’ve got something way too big to share, and my small examples don’t exhibit the same problem. The problem being that if I print the list of visible or touchable things in a Does The Player Mean rule, it’s showing me the contents of some other room. When the same list is printed as the output of a command, it’s correct. When I try the same thing in a tiny example, the DTPM rule prints the correct list. Note the contents it does show are all the same kind, which is referenced by a grammar token ‘Understand “ask [any quip]” as bleeping’, and the DTPM rule is disambiguating quips.
I’m afraid I don’t have much more detail than that. Maybe someone’s comments will lead me to the important details I’m missing.
The definition of a visible thing, as you probably know, is that the player can see it.
The player can see any object in scope so long as the player is illuminated (i.e. not in darkness)
To be touchable a thing must be in scope for the player and pass the not ‘untouchable’ test.
The only unusual thing I’m aware of regarding the DTPM rules is that they always have the actor requesting the planned action temporarily set to be the player- usually the actor requesting the action is nothing unless the player has asked someone else to perform the action. I’m not sur how that could interfere with the meaning of visible or touchable.
Really difficult without a minimal working example, but try the following and see if anything unexpected shows up:
To decide whether (o - an object) is in scope for (p - an object): (- TestScope({o},{p}) -).
actor-requesting is an object that varies. The actor-requesting variable translates into I6 as "act_requester".
Does the player mean bleeping <insert something to disambiguate here>:
say "Disambiguating...";
say "The player is: [player].";
say "The requesting actor is: [actor-requesting].";
repeat with o running through objects:
say "[o] is [unless o is visible]not [end if]visible; [unless o is touchable]not [end if]touchable; [unless o is in scope for the player]not [end if]in scope.";
it is likely.
The player and the requesting actor should both be yourself- unless the player might not always be the default player object in your story, maybe?.
The lab is a room. The garden is a room.
The television is in the lab.
Bob is a man in the Lab.
a ball is a kind of thing.
The yellow ball is a ball in the garden.
The red ball is a ball in the garden.
The blue ball is a ball in the garden.
bleeping is an action applying to one thing. Understand "bleep [any ball]" as bleeping.
Does the player mean bleeping a thing (called X):
repeat with T running through touchable things:
say ">> [T].";
it is likely;
frumping is an action applying to nothing. Understand "frump" as frumping.
report frumping:
repeat with T running through touchable things:
say ">> [T].";
Rule for reaching inside the garden:
allow access;
Try bleep ball and frump.
Note that bleeping prints out all the ball object, while frumping prints out the objects in the lab.
Pretty sure this is the culprit - using “any” as part of a token like this exempts it from the usual scope rules, so the parser will accept whatever matching input the player types regardless of where it is.
What I didn’t expect is that the scope apparently would only consist of those matches, and not anything in the room with the player. This doesn’t happen when you use “bleep [a ball]” – the list of touchable/visible things is not restricted to only balls, for instance.
Right. The issue here is that your grammar token ‘[any ball]’ is governing scope during parsing of the command and it’s excluding anything that’s not a ball from scope.
The balls are in scope and therefore touchable and visible; Bob and the television are out of scope and therefore neither visible or touchable.
Change it to ‘[any thing]’ and all is as expected.
That said, is there any reason to have ‘[any quip’]?
It’s usually best to make grammar tokens as broad as possible (e.g. ‘[any thing]’ or ‘[any object]’) and disallow things other then quips (or whatever else shouldn’t be permitted) in your Check rules,where you have transparent and granular control over what happens and what the responses are.
That rule makes everything in the garden touchable all the time. (Or anything in scope, at least, and as has been noted, [any ball] makes, well, any ball in scope.)
Are you familiar with the I6 side of the parser? If so, the key is that “any ball” translates into a scope= token—in other words, it replaces the usual scope rules with a special one that includes all balls and nothing but balls while trying to match that token.
It’s a little interesting that there is no provision for grammar tokens that expand but do not replace scope determination rules. This is allowed in I6 by returning false from a scope token while scope_stage == 2.
Your current approach is the closest thing to that, but note what drpeterbatesuk said above regarding scope-limiting tokens and Check rules. It may be better to rely on a Check bleeping when the noun is not a ball... rule in conjunction with a generic Understand "bleep [something]" as bleeping. grammar. Otherwise, you can see parser errors such as:
>BLEEP ME
That noun did not make sense in this context.
This makes sense in most cases, but I’m doing something a bit different that requires a “typical” “accurate” scope while in the DTPM rules. For instance consider a scenario in which the player would like to suggest a ball to a person, with the rule that balls they can see take precedence, so that the person doesn’t have to go find the suggested ball, if possible.
Does the player mean suggesting a ball to a person:
if the noun is visible:
it is likely;
it is unlikely;
In that case it appears that any tokens aren’t going to work without some I6 parser trickery.
There are a few of them in the I7 CommandParserKit, but the main documentation can be found in the DM4 (scroll down to <Routine>). Basically, a GPR is a routine that looks at words starting at wn (the current word number, i.e. the number of words the parser has already handled) and decides whether it matches or not. If it does, it’s supposed to leave wn advanced past the words it parsed, and return either the object that matched (if it wants the parser to make it the noun or second noun) or GPR_PREPOSITION to mean “I handled this already, and saved any results I need for later, don’t worry about it”.