A touchable thing can be neither

Well, that’s fascinating, I wonder what the implications of that could end up being, and whether it would be fun to use in designing a game.

And if you unlisted the “Can only take things rule” would you be able to lug rooms around?

(I’m already trying something similar with doors, and now this leads to all kinds of possibilities…)

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.

1 Like

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.


Our very own @otistdog. :slight_smile:

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.

Thanks for clearing this up for me.

Actually I think [something] is an object, but [thing] is a thing.

Edit: I thought I remembered discusssing this before. Found it: https://intfiction.org/t/i7-using-the-current-room-as-a-noun-for-an-action/13100/6


You are correct! Every day a school day :grinning: Again, I had incorrectly believed thing/something to be exact synonyms in grammar lines…

Clearly, this is how I had previously in testing come to the conclusion that both were equivalent to ‘things’ not ‘objects’…

To further clarify your explanation in that link:

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)

1 Like

To make matters worse, the following:

Understand "explore [object]" as exploring.

elicits the unhelpful response

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 :upside_down_face:


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.

1 Like

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]”
“[something]” - same as “[thing]”
“[something preferably held]”
“[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…

Double sigh

1 Like

I don’t think that [something preferably held] matches objects.

Understand "foo [something]" as examining.
Understand "bar [something preferably held]" as examining. 
>foo north
You see nothing unexpected in that direction.

>bar north
You can't see any such thing.
1 Like

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!


Ah yes, you’re right.

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.]


Yeeeesh. The unintuitiveness is extreme; I’m not even following it any more. And I often want to put rooms in scope.

Is it possible for the community to come up with a desired specification, and possibly a set of patches, and ask Dr. Nelson to straighten this out?

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

(domain1 == actors_location)

to something like

((domain1 == actors_location) || (domain2 == actors_location)).

(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.

1 Like

good idea, but it looks like you can’t use a kind of action directly as a condition like that, so…

Smelling is applicable to intangibles.
Listening to is applicable to intangibles.

The basic tangibility rule does nothing when the current action is applicable to intangibles.