I learned something new: the grammar tokens something/thing don’t actually require thing-ness. They mean any object in scope. Directions are always in scope, but normally rooms and regions aren’t. I knew that when actions required one visible thing it meant potentially any object in the game world, in or out of scope, in or out of play. What I didn’t know is that one touchable thing (i.e., the default if you just say one thingalso does not require thing-ness (i.e., it acts like the grammar token).
If an action requires a “touchable thing”, the basic accessibility rule (one of the rules between the Before rules and the Instead rules) will stop the action if the noun is a direction. And for actual things, it checks whether there’s a reason you can’t touch it, e.g., it’s in a closed container. But it doesn’t block rooms or regions. Hence
Lab is a room.
Conservatory is north of lab.
The map region of the Conservatory is the contrivance.
The Metacontrivance is a region. The contrivance is in the Metacontrivance.
After deciding the scope of the player when the location is the Conservatory, place the contrivance in scope.
After deciding the scope of the player, place the Lab in scope.
The glass case is a transparent closed unopenable container in the lab.
The priceless emerald is in the glass case.
test me with "touch lab / drop lab / get lab / n / get lab / touch contrivance / drop contrivance / get contrivance".
yields
>1] touch lab
You feel nothing unexpected.
>[2] drop lab
You haven't got that.
>[3] get lab
You would have to get out of Lab first.
>[4] n
Conservatory
>[5] get lab
You cannot carry Lab.
>[6] touch contrivance
You feel nothing unexpected.
>[7] drop contrivance
You haven't got that.
>[8] get contrivance
You cannot carry the contrivance.
What led me down the route toward noticing this was noticing that there’s a Can only take things rule. Which seemed redundant – didn’t the basic accessibility rule already take care of that? But no, it didn’t.
For reasons I haven’t chased down, the contrivance has to be within another region. If there’s no metacontrivance regionally containing the contrivance, the actions on the contrivance get “That isn’t available.”
heh, no. The carrying relation is between people and things, and under the hood carrying out taking ends up at the low-level MoveObject routine and that would generate a run-time error. If you wanted to write a game about carrying rooms, it’d almost certainly be easier to have the “rooms” that you carry be things that you describe as rooms rather than to try to swim upstream against the world model that hard.
This, plus your initial observations about thingness, form the approach that Small Kindnesses takes to allowing the player to try to examine whatever room they’re in by name, and not be fobbed off with ‘I can’t see any such thing.’ It then throws up the problem that the room name is highly prioritised by the parser as soon as it gets into scope. Someone gave me a ‘Does the player mean’ adjustment to deal with that.
I had also got this wrong- I obviously hadn’t tested this properly in the past, I thought that while thing in action definitions was actually equivalent to ‘object’ (not ‘thing’), thing in grammar lines was genuinely equivalent to objects that were also things.
Just to clarify, thing/something in grammar lines is also equivalent to ‘object’ (not ‘thing’) and includes directions. It’s just that if an action requires a ‘touchable thing’ the basic accessibility rule specifically excludes directions with the riposte ‘You must name something more substantial.’
If however an action requires a ‘visible thing’, directions can be referred to by, for example, ‘explore north’:
Exploring is an action applying to one visible thing.
Understand "explore [something]" as exploring.
Carry out exploring:
Try going the noun.
in Carry out naming ...something/anything/thing/some thing/a thing are all synonymous restricting the action description to things, (any thing is not allowed here)- but you can if you wish also say Carry out naming object (or some object or an object)
Problem. The grammar token ‘object’ in the sentence ‘Understand “explore [object]” as exploring’ would in some ways be the right logical way to suggest ‘any object at all here’, but Inform uses the special syntax ‘[thing]’ for that. (Or ‘[things]’ if multiple objects are allowed.)
See the manual: 17.1 > 17.1. Understand
when it should say ... but Inform uses the special syntax '[something]' for that... but to add another layer of mind-boggling confusion it is correct about ‘[things]’, which is equivalent to ‘[objects]’… which is also permitted as a token even though ‘[object]’ is not
Yep. The documentation generally is not precise about the distinction between things and objects.
As far as I know, the [something] token is never actually defined in Writing with Inform, though there’s at least one passage that seems to suggests that it is matched only by things. Of course, it’s used to catch non-thing objects often enough in the examples.
I hadn’t asked a question, but I’m marking that as the solution anyway!
6M62 and v10’s Project Indices, meanwhile, tell us under Tokens that both “[anything]” and “[something]” are the same as “[thing]”.
“[anybody]” - same as “[someone]”
“[anyone]” - same as “[someone]”
“[anything]” - same as “[thing]”
“[other things]”
“[somebody]” - same as “[someone]”
“[someone]”
“[something]” - same as “[thing]”
“[something preferably held]”
“[text]”
“[things]”
“[things inside]”
“[things preferably held]”
“[a time period]”
As you know, that’s not true either. ‘[anything]’==‘[any thing]’<>‘[thing]’
Also, ‘[any something]’==‘[any thing]’<>‘[any object]’ (NB ‘[any object]’ is permitted syntax even though ‘[object]’ is not)
So, ‘[thing]’ and ‘[any thing]’ and ‘[any something]’ seem to be a special case.as grammar tokens in restricting their meaning to actual things. Elsewhere, in grammar lines, ‘[something]’ and ‘[things]’ seem to refer to objects, although I haven’t exhaustively tested.
In particular ‘[something preferably held]’==‘[object preferably held]’<>‘[thing preferably held]’ , although the latter two are disallowed syntax and ‘[thing preferably held]’ I think has no equivalent token…
Aaaarggh! But this appears to be a quirk of the treatment of scope with respect to directions, not of the object vs thing restriction created by ‘something preferably held’.
As noted elsewhere, directions are normally hard-coded as being in scope even though they fail the I6 routine TestScope(). Perhaps that’s the reason they are treated anomalously here.
Putting regions, rooms and directions explicitly into scope with ‘After deciding the scope of the player…’ (which mean they all pass TestScope()) allows all to be referenced by ‘something preferably held’.
EDIT: I guess Mr Nelson’s defence for not incorporating the hard-coding of scope for directions into ‘something preferably held’ would be that it’s not easy to conceive a situation where an action using this token might sensibly need to act on a direction. Although I’m sure someone could dream one up!
Edit: I doubt that this behaviour is intended. It looks to me like an accidental consequence of the way that NounDomain is called when parsing held tokens. It might be considered a bug, since the behaviour is not as specified in the documentation.
[The relevant passage is Section 49 “SearchScope” of CommandParserKit, which asserts that directions are always added when searching scope for the room of the current actor, except when parsing multiinside or creature tokens. Parsing a held token does search scope for the room. But because the actor’s possessions are prioritized, the room is passed to NounDomain as the second domain variable rather than the first (see Parse Token Letter D). That prevents the code which adds directions to scope from firing.]
This quirk only affects directions, not rooms, and hardly seems important enough to be worth bothering about. As Peter says, it’s not easy to imagine a case where it would matter. And it’s easy enough for the user to write a rule to add directions to scope if it did matter.
If we were bothered to change it, I imagine it would be easy. It might just be a matter of changing the condition in Parser Template 49 SearchScope (c.2) from
(But that might have effects that I haven’t appreciated; I haven’t gone into this code in detail, and I am not fluent in I6.) More simply, the annotation for that clause could just be changed from “For all other tokens except creature…” to “For all other tokens except creature and held…”.
For my own use, I’ve come up with this to enforce that touchable must be tangible.
To decide what K is a/-- null (name of kind of value K): (- nothing -)
This is the basic tangibility rule:
let intangible1 be the null object;
let intangible2 be the null object;
if the action requires a touchable noun and the noun is not a thing, now intangible1 is the noun;
if the action requires a touchable second noun and the second noun is not a thing begin;
if intangible1 is the null object, now intangible1 is the second noun;
else now intangible2 is the second noun;
end if;
if intangible1 is not nothing begin;
if the action is not silent begin;
if the actor is the player, say "[We] [need] something more concrete than [intangible1][if intangible2 is not the null object] and [intangible2][end if]." (A);
else say "[the person asked] [don't] understand exactly how that would work." (B);
end if;
stop the action;
end if;
The basic tangibility rule does nothing when the action name part of the current action is the listening to action or the action name part of the current action is the smelling action.
The basic tangibility rule is listed before the basic accessibility rule in the action-processing rules.
The can only take things rule is not listed in any rulebook.
One suggestion: I think you could encompass all the different “requires touchable but not tangible” conditions with a class of actions:
Smelling is doing something to intangibles.
Listening to is doing something to intangibles.
The basic tangibility rule does nothing when doing something to intangibles.
Or you could put this into a condition at the top of the rule, but the end result is the same. Makes it easier to define further “doing something to intangibles” actions.
Again, I had incorrectly believed 