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]”
“[somebody]” - same as “[someone]”
“[something]” - same as “[thing]”
“[something preferably held]”
“[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;
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);
stop the action;
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.