If you try SHOWME DOOR in-game, the result suggests that the door is actually off-stage as long as the player is in the Red Room, and in either the Green or the Blue Room respectively as long as the player is in any of them. So, while in the Red Room you really pull a door out of play into scope.
IIRC Inform implements all objects that seem to be in more than one room (backdrops and two-sided doors) in this way, i.e. by moving them around as needed.
You’re right – I was misreading the way that the index handles doors.
It seems that doors and backdrops are explicitly excluded from the way other off-stage objects are handled by the Access through barriers rule in the I6 Light Template §11 (line 5 of the code for the routine).
That’s interesting. I wonder if there’s a reason for that?
In any case, I’ll have to use some sort of workaround. If the player can see into a room, logically they should be able to examine any doors in that room. matt w’s suggestion seems to work - thanks for that.
Basically, it appears to be a hack. Quote from Appendix B (the annotated Inform 6 templates for Inform 7) under the spoiler tag:
I just realized that my workaround only prevents going through the door, not other actions requiring touchability. So you still would be able to unlock the door from the next room.
The best solution might be to include Flexible Action Requirements and then rewrite my workaround to block any action that isn’t flexible about touching the noun. Or something like that.
Hmm. Possibly just an oversight, then? While we may not know the “real” location of a door (or other floating object) is at any given time, we do always know which two rooms a door is connected to, and it seems simple enough to check whether the actor is actually located in one of those rooms before entering the door. I’m trying to think of a scenario in which this wouldn’t be a safe assumption, and coming up blank.
Or simply block any action other than examining for doors that aren’t connected to the actor’s location, as a quick fix.
That should work if you don’t add any extra actions – all the other actions that apply to “visible things” in the Standard Rules seem to be things we want to block, like “show x to door.” If you define any new actions that apply to visible things (like telling people about things) you might want to use a kind of action.
Hello - I think I just stumbled across something interesting. It seems that two-faced doors don’t float. That is, if you define a pair of doors like this:
[code]The Red Room is a room.
The blue door is a door. It is south of the Red Room. Through the blue door is the Blue Room.
The Blue Room is a room.
The red door is a door. It is north of the Blue Room. Through the red door is the Red Room.[/code]
… then the respective doors aren’t treated as floating objects, and have normal location, reachability and visibility properties regardless of where the player is.
I suspect this is of limited utility in many cases, especially since supplementary code would be required to force their open/closed and locked/unlocked states to remain in sync, but requiring viewports to be defined this way would vastly simplify my code. I could simply check whether a given object is in scope for a viewport’s opposite face, rather than messing about trying to fake it with enclosure rules. As an added bonus, this would allow stuff like one-way glass to be defined with no additional overhead (i.e., by making only half of the door-door pair visually transparent).
As I’m writing this, it occurs to me that there’s probably an existing extension to facilitate handling doors in this fashion.
… yep. Deluxe Doors by Emily Short. Handy, that.
Wow! I’m flattered that people are talking about my extensions, but I’m a little embarrassed that I haven’t really polished any of them.
There’s another one that might come in handy: it’s my update of Conditional Backdrops. The latest version is not up on the inform7 site, but it’s here:
eyeballsun.org/i/Conditional%20Backdrops.i7x
What’s most useful here is not the ability to define your own types of floating objects, but to have better control over when backdrops are moved. You can invoke the “moving floating objects” activity whenever you want and write After rules for the activity to modify how objects are moved or respond to their movement.
I’ll take a look. I’d tried messing with the positioning of floating objects, but I couldn’t get it to work as intended when it came to sensory interaction by proxy; e.g., scenarios where the player in room A asks an NPC in room B to perform an action that requires them to be able to see an item in room C. Setting up non-floating door pairs is a pain for the game designer, but it’s the only way I could get it to work reliably.
On the subject of your extensions, however, I’m having a slight issue with Scope Caching that you may be able to shed some light on. Sorry about the length - I’ve tried to trim out everything that’s not directly relevant.
[code]Include Scope Caching by Mike Ciul.
A thing can be audible only.
A thing can be noisy or quiet. A thing is usually quiet.
A container can be soundproof. A container is usually not soundproof.
Audibility relates a thing (called the listener) to a thing (called the subject) when the listener can hear the subject. The verb to be able to hear (he is heard) implies the audibility relation.
To decide whether (the listener - a thing) can hear (the subject - a thing):
if the listener is the subject:
decide yes;
if the location of the listener is the location of the subject:
if a closed soundproof container that encloses the listener does not enclose the subject:
decide no;
otherwise if a closed soundproof container that encloses the subject does not enclose the listener:
decide no;
otherwise:
decide yes;
otherwise:
decide no;
Definition: Something is audible rather than inaudible if the player can hear it.
The sense-aware can’t reach inside closed containers rule is listed instead of the can’t reach inside closed containers rule in the reaching inside rules.
This is the sense-aware can’t reach inside closed containers rule:
if listening:
if the person reaching can hear the noun:
allow access;
abide by the can’t reach inside closed containers rule;
[This allows the player to listen to things they can only hear.]
After deciding the scope of the player while listening:
now everything is not audible only;
repeat with the noisemaker running through noisy audible things:
if the noisemaker is not marked visible:
now the noisemaker is audible only;
place the noisemaker in scope, but not its contents;
The Green Room is a room. “It’s very green.”
The wooden box is a closed openable opaque container in the Green Room.
The old radio is a noisy thing in the wooden box. Instead of listening to the radio, say “Tinny pop music [if the old radio is audible only]fills the air[otherwise]issues from [the old radio][end if].”
The player is in the Green Room.[/code]
Try listening to the radio twice. As things are set up now, on the second of two consecutive “listen” actions, the marked visible property seems to go wonky for objects that are audible, but not visible. This doesn’t happen if anything - even a “wait” action - comes between the listens. Can you see what I’m doing wrong?
I don’t have an answer right away, but it can help to visualize how Scope Caching works: After reading a command it does the caching scope activity with the player. Normally, scope depends on a number of things: whose scope is being checked, what is the reason for checking scope, and what action is being performed. If you cache scope in one circumstance, the “marked visible” property may not be appropriate in another circumstance. You can usually fix that by manually running the caching scope activity at the proper time.
Okay - here’s where I’m at now (see attached). I’ve made a great deal of progress, but there are still a few things giving me trouble:
1. I’m trying to set up a “sensory occlusion” relation (i.e., “x is visually occluded from y”/“x is aurally occluded from y”) to make it possible to define an object as being impossible to see from a particular vantage point. However, I’ve defined both sensory adjacency between rooms and sensory connections via doors or other sensory connectors, I can’t figure out a way to define the relevant phrases to cover both relationships.
For example, if room X is visually adjacent to room Y, and I want to say that something in room X is visually occluded from a viewer in room Y, the relation needs to be between a thing and a room. However, if room X is visually connected to room Y via door Z, the relationship would need to be between a thing and a thing instead, since the scope is being checked from the viewpoint of the door, not the viewpoint of the room.
I know I could just use two separate relations, but requiring the author to use different phrases depending on the type of sensory connection involved seems inelegant.
2. I’m trying to set up some grammar so that before/instead/after/while examining rules can be defined in terms of the vantage point of the player, the medium of viewing, or both.
For example, I want to be able to say stuff like “instead of examining X via a security camera”, or “rule for printing the name of X while examining via a door”. There’s an example of doing so in the attached file.
I’ve tried it in two different ways: using definitions, and using a series of internal verbs that pass the subject around among themselves (the latter is what you see in the attached example). The problem is that each approach only covers some of the cases involved. If I use definitions, the while rules work, but before/instead/after rules become complicated and unwieldy to write. If I used the action-passing approach you see in the attached file, the while rules don’t work, since by the while “while” is checked, the action has been passed off to the basic “examine” verb.
I’m open to any suggestions - redirecting actions and such is new territory for me, and I’m quite certain I’m Doing It Wrong.
3. Is there a decent guide available that explains the logic behind how the system determines how to display the contents of a room? I’m trying to puzzle out the best way to display a room’s contents when viewing it remotely, but I can’t seem to make heads or tails of the standard rules in this area.
Finally, if anyone has the time to play with the little sample scenario I’ve included and see if they can get it to break, it would be greatly appreciated. Just let me know what you did to bust it. 
sensory-2.txt (34.9 KB)
Just a note: it’s easier to look at your code if you inline it with code tags, rather than attaching it as a file. If it’s really long you can add spoiler tags outside the code tags.
To be frank, it’s really annoying when people do that. The code viewport already has a certain maximum length after which scroll bars appear, so the spoiler tags just add an extra click. Or is it not so in the default theme? (I’m using the whatever the alternative theme is called.)
I’ve never seen scroll bars in the code window in the main theme.
That’s a shame, it’s a really useful feature. Carry on then
I’ll keep that in mind in the future.
As an aside, a third approach to the whole “examining via” thing occurred to me. I could stick a check rule at the top of the relevant rulebook (check examining, check listening, etc.) that determines what the player’s sensory connection to the noun is, and shoves that object in a global variable - call it that “vantage”, say. Then one could write rules like “instead of examining the fountain while the vantage is the second-floor window”, or “rule for printing the name of the intruder while the vantage is a security camera”. That would cover both the instead/after and while cases with a relatively straightforward - albeit somewhat cumbersome - syntax.
The only problem is that you wouldn’t be able to write vantage-based before rules, since before precedes check.
Hmm. Alternatively, a decide rule could be used to determine the vantage on the fly, but then I’m right back at potentially provoking a recursive scope check.
There is Jeff Nyman’s “Descriptions and Locale” at http://zurlocker.typepad.com/files/nyman—inform7-locale.pdf
Wow - that’s very in-depth. Thanks!