Visibility Checks Relative to Before Rules

In §12.2. How actions are processed, the manual shows a graphic that says “Can we see or touch things?” checks come after the Before rules. However, in my class, a student did this:

[code]The Lab is a room.

A container called the glass case is in the Lab.
The glass case is closed.
A flaming torch is in the glass case.

Before taking the flaming torch:
say “I’ve got a bad feeling about this.”

Instead of taking the flaming torch:
say “You would burn your hands.”[/code]
If the case is made transparent, the Before rule fires because the torch can be seen even though it’s in a closed container.

However, with the text as given above, the Before rule never fires. Clearly because you can’t see the torch at all.

Yet that seems to contradict the manual, which says that “Can we see or touch things?” comes after the Before rules. Further, §7.3. Before rules says that

But, again, that doesn’t seem quite true because clearly the torch not being visible at all is being checked. Yet … checked by what?

I ask that because when you play the above source text, and you use the RULES and ACTIONS, you get this:

So my class was curious in that the Inform manual says all actions go through the “web of rules” but here, nothing at all is indicated as part of the action processing or rule books. Combined with the other information from the manual referenced here, I wasn’t exactly sure how to respond to this.

The gist is that the grammar for TAKE only applies to items in scope, and the torch isn’t in scope, so the parser doesn’t understand the command. The game never gets to action processing because it doesn’t know what action to process.

If you add this line:

Understand "grab [any thing]" as taking.

…which makes the parser look for a match anywhere, not only in scope, and then try GRAB TORCH:

Just to clarify: when you say the parser doesn’t know what action to process …

… it does know to process a “taking” action, though, right?

But it seems “scope” (which is actually operative before the Before rules) immediately rules out any processing because the flaming torch can’t be found. But, of course, that’s not world model considerations because, after all, the torch is in the model world. Which means it seems like this is talking about visibility and touchability. (But those checks come after Before.)

So maybe the question I need to be investigating is really: how is scope distinct from visibility and touchability, particularly when it seems like those two elements are arbiters of what “scope” means in the first place.

I’m guessing that the “Can we see?” part of this refers to checks on whether there is sufficient light rather than visibility/scope, since as Juhana says that applies at parser level, which has to happen before there’s an action to process at all. But I don’t have time to check with this. I agree that it could be phrased much more clearly. (Touchability is distinct from scope; that’s taken care of by the reaching inside/outside rules and like that.)

That’s actually good to know right there! That distinction seems really important, although maybe it doesn’t necessarily come up all that much except in conditions like the one I’m describing. But it also sheds light, perhaps, on this statement from §12.19. Changing visibility:

This is a great example overall for the class. In case what I often micro-focus on seems strange, part of what I’m doing with Inform, in this context, is having the class look for ambiguities, inconsistencies or outright contradictions (perceived or otherwise) in the “requirements” (in this case, the manuals). Which builds up good skills for a testing mind-set. A side benefit is that it helps people understand Inform more deeply and make less assumptions about how things work.

This is a simplification, but basically what happens when you type TAKE TORCH is that the parser looks at the first word which is TAKE, and it has two actions that could potentially match, taking and taking inventory. The grammar for taking inventory is TAKE INVENTORY and the second word doesn’t match, so that option is discarded. The grammar for taking is TAKE + [a thing in scope] so it goes through all the things that are in scope (i.e. visible to the player) and tries to match their grammar to the word “torch”. It doesn’t find a match so it concludes that the verb part was correct but the noun part was invalid, so it prints the “can’t see such thing” error.

Even if you forced the action rulebook to run, the “before taking the flaming torch” rule wouldn’t match because the parser didn’t recognize the noun so it doesn’t know that the player is talking about the flaming torch.

I believe TADS has a more complex parser (or an extension that does it? not sure) that then tries to match the noun to all items in the game world so that it can then print a more accurate error message, like “you can’t see the flaming torch here” or something to that effect.

Note that you really don’t want the before rules to run even when the parser decides the noun isn’t accessible: having the thing inside a container in the same room is an edge case, usually it really is somewhere inaccessible like in another room or out of play. You would have to add a condition like “Before taking the flaming torch when the player can see the flaming torch” to almost every single before rule, which would be silly.

Great context. I appreciate the information.

Indeed. The same process I’m doing with Inform, I’m also doing with TADS. It’s been very interesting to compare and contrast how both systems allow mapping from human-intuitive to machine-expressive. This is particularly the case when you consider the alleged (in both cases) “simplicity” of Inform and “complexity” of TADS.

I don’t think anybody claims Inform is a simple system internally. :slight_smile:

I’m not sure “more accurate” is quite it. It seems more like a gameplay/fairness consideration, coding it that way. Inform does not distinguish between nonexistent things and things that exist in the model world, but just are not present at the moment; the error message for each is thus the same.

This prevents cases where a naive or careless author might code things with similar names, or with the same synonym, and inadvertently spoil (or confuse) the player via an overenthusiastic parser error message. Say, if the player has forgotten they left their eggs in the kitchen:
[rant=transcript]An egg carton is on the countertop.


Living Room

The clock chimes twelve.

get egg
You can’t see the Great Crystal Egg of Cuayahoga anywhere.[/rant]

I’ve seen this happen a lot in Adrift games, for example. It’s amplified there because the parser autocompletes your words using dictionary words from the game.

Even Crowther’s original Adventure printed different messages for nonexistent and nonpresent items.