Help needed: Transparent door (RESOLVED)

I am aiming to create a jail cell with iron bars and a cell door, through which the player can view the rest of the jail. I haven’t gotten around to the iron bars yet, but the cell door’s transparency should work? Thus far my code reads:

Jail is a region. Office is a room in Jail. The cell_door is a transparent lockable door. The cell_door is locked. The printed name of the cell_door is “cell door”. understand “cell door” as the cell_door. understand “door” as a door. cell_door is west of Office. Cell is a room in Jail. Understand “jail” as the cell. Player is in Cell. Cell is west of cell_door. The matching key of the cell_door is the cell_key. The printed name of the cell_key is “cell key”. Understand “key” and “cell key” as the cell_key. The desk is a supporter in Office. On the desk is the cell_key.

After looking while in cell:
…place the Office in scope;
…say “You also see [a list of visible things in Office].”

When I run the code and “look,” the last line yields “You also see nothing.” Why don’t I see the desk? Thanks!

P.S. I’ve looked at the Windows section of the Inform manual, as well as the linked examples, and did not find a solution that worked.

Scope doesn’t quite work that way; when you manually change scope, you need to go through and add everything. Just adding the room won’t add everything in it!

So what you want is something like

let L be the list of things enclosed by Office;
repeat with N running through L;
   place N in scope;

There’s a few things going on here. First, scope has nothing to do with what lists of things can be printed; you can always say any arbitrary description of things. Scope purely defines what things a player can refer to in a command. Second, per Wi 17.27, the phrase to place something in scope should only be used in rules modifying the “deciding the scope of” activity. Third, the desk is not a visible thing, it’s a thing. …Which is confusing, because in the context of defining new verbs and checking conditions, “visible” is synonymous with “in scope”, but apparently this is not the case when dealing with descriptions of objects.

Anyway, resolving issues 1 and 2 allow you to get the behavior you want, including extending this behavior to apply to any transparent door:

[code]Lockup is a region. The Office is a room in Lockup.

A door can be transparent. Understand “door” as a door.

After deciding the scope of the player:
repeat with view running through transparent doors in the location:
place the other side of the view in scope;

After looking when a transparent door is visible:
repeat with view running through visible transparent doors:
say “You can also see [a list of things in the other side of the view] in [the other side of the view].”

After examining a transparent door:
say “Through [the noun], you can see [a list of things in the other side of the noun] in [the other side of the noun].”

The cell door is a transparent lockable locked door, west of Office.

Jail is a room in Lockup, west of the cell door. Understand “cell” as the Jail. Player is in Jail.

The desk is a supporter in Office. On the desk is the cell key. The cell key unlocks the cell door.

Test me with “x door/x desk/get key”.[/code]

Err, yes it will? Like it says in the manual, adding a thing (or a room) to scope adds all of its contents unless you tell Inform otherwise.

Thanks Chris, it works great! I learned some things, too.

BTW, I noticed you have a semicolon at the end of your first “After” statement. The code seems to work fine that way, but I would have thought a period was necessary there?

It’s the blank line after the rule that matters there. Inform will treat a blank line as if it were a period. You could leave the semicolon out, too, and the rule would still work as expected.

Yes, this. I tend to end my code blocks with semicolons as often as not; because I forget, because whitespace suffices, and because I’ve been bit in the past by trying to extend period-terminated code blocks without remembering to replace that punctuation with a semicolon. That results in some very confusing error messages until I track down the problem. It’s especially annoying when the terminal period actually lies within quoted text.