I’m planning a game that involves a long hotel corridor which is four locations. I’d like npc’s and objects to be visually in scope from anywhere, but of course not reachable to take or otherwise operate unless sharing a location.
Is there an easy way to handle this? Anything to watch out for?
I actually just created a system similar to this, but on a much bigger scale. I did it by creating a kind of room, then a repeat loop to search through all the rooms of that type. Then, I created another loop within the first to check for any NPCs that are present in any of the rooms of the selected type and report them to the player with various messages.
Does that help? 
The Inform Recipe Book has several examples of this sort of thing. Look at section 3.4, “Continuous Spaces and the Outdoors”. inform7.com/learn/man/Rdoc11.html
I think that might be a good option - don’t deal with scope at all, but mention things in the other locations. Although if the player tries LOOKing at something it would fail “You can’t see any such thing.”
I’m thinking perhaps I should make the four rooms a region, and then write “Before examining something inside HallwayRegion: place the noun in scope.” Does that sound feasible? That would hopefully eliminate taking or fiddling with something far away naturally.
(That code was off the top of my head and might not be Inform-grammatic; I tend to shy away from scope at all.)
This won’t work. Inform has to check whether things are in scope in order to generate the action, so manipulating scope in action rules won’t work. If you’re trying to examine something in another Hallway room then you’ll fail with a “You can’t see any such thing” error before you get to this rule. You need to be modifying the scope with “After deciding the scope of the player” rules.
Anyhow, zarf’s advice to look at that section of the recipe book is good (especially “Rock Garden” and “Stately Gardens” if you’re ambitious; I’d also look at the section on windows), but the way to do this is to place rooms in scope. This will automatically make the things inside the rooms visible, meaning that examining them can succeed (as can doing any other action defined as applying to a visible thing), but attempting to take them will fail. I don’t see any reason not to use scope here, as it does exactly what you want! An example:
[code]“Long Corridor” by Matt Weiner
Long Corridor is a region. Western Corridor is in Long Corridor. Central Corridor is east of Western Corridor. It is in Long Corridor. Eastern Corridor is east of Central Corridor. It is in Long Corridor. Chamber is east of Eastern Corridor.
After deciding the scope of the player in Long Corridor:
repeat with area running through rooms in Long Corridor:
place area in scope.
Definition: a thing is corridor-bound if it is in Long Corridor and it is not the player.
After looking in Long Corridor when a corridor-bound thing is not in the location:
repeat with item running through corridor-bound things that are not in the location:
say “To [the best route from the location to the location of the item] you can see [an item].”
A flowerpot is in Eastern Corridor. An acacia is in Western Corridor. A ficus is in chamber.
test me with “x flowerpot/x acacia/take flowerpot/take acacia/drop it/e/e/x flowerpot/x acacia/take flowerpot/drop it/take acacia/x ficus/e/x acacia”.[/code]
The messages you get when trying to take something in another part of the corridor are icky. The best hook for that is a “Rule for reaching inside,” probably:
Rule for reaching inside a room in Long Corridor that is not the location: say "You're not close enough to touch that."; deny access.Access would be denied anyway; what “deny access” does is stops the normal rule from reaching inside from running, thus suppressing the “You can’t reach into…” message that normally gets printed.
Anyway, this is just a sketch, but hope it helps.
Thank you for the detail. I’ve had horrible nightmares with scope so I appreciate it, and I will read that section again. It will help to have your code in mind as I do.
I hear you. Fortunately, it seems to me that you’re working on one of the most natural applications of scope. You want your things to be visible but not touchable, and adding something to scope makes something visible but doesn’t change its touchability, so you’re OK there. Also you want to add whole rooms to scope at once, and that’s easily done. And best of all, you don’t need to worry about the particular action you’re attempting when considering whether to add things to scope, because the visible vs. touchable distinction takes care of that. (Doing something where you can, say, throw something at distant objects but not touch distant objects seems like it’d be really annoying.)
Oh, and good news: When you’re running the accessibility rules the action is defined and stuff, so you can use things like “the noun” to write more sensible messages:
Rule for reaching inside a room in Long Corridor that is not the location: say "You're not close enough to reach [the noun]."; deny access.Though I guess you need some way of figuring out whether the noun or the second noun is the one that’s inaccessible? Hm, that might be a bit trickier.
Anyway, it seems to me that the hardest part of this is probably figuring out how to make a sensible room description that talks about what’s in the rest of the corridor, and to do that you don’t have to worry about scope at all.