The final problem (being able to touch objects on the floor while on the mantelpiece) is very tricky to solve. Inform doesn’t support the idea of `physically reachable from here’ [since this tutorial was first written, it has done just that – GN]…
What does “it has done just that” refer to? Compiling with Inform 6.36 using library 6.12.6, if I “push chair” then “get in chair” and “climb mantel” I can “take wool” even though it is on the floor. So, this says to me there is something I’m expected to implement to make the “unreachable from here” work. The chair and mantel are both: supporter enterable.
I found the ObjectIsUntouchable() function but it seems to only apply when containers are involved? The objects in Alice are not containers. The note from Graham seems to imply that objects that are not containers (i.e. those objects being referenced at the point he makes the comment) would benefit from this new check. Or is this saying “Now that ObjectIsUntouchable() exists make the Alice objects into containers to take advantage of it.” ?
It’s quite unclear what Graham’s comment means and how to enact the described behavior.
In the fragment of code that follows that paragraph, you’ll notice that there are two usages of an Inside function. That function is defined at the bottom of the page. I think Graham’s italicised comment is referring to that function. In essence, he’s saying that it is no longer necessary to define that function, as you can now use the ObjectIsUntouchable function, albeit in a slightly different way.
Keep in mind that the Alice example was based on Gareth Rees’ tutorial program from 1995, but that has since been updated. If you look at the version 3 source code, which was published on 1 May 2003 (and I presume is on the IF Archive), you’ll see that this fragment of code is considerably different and doesn’t use either Inside or ObjectIsUntouchable.
Regarding ObjectIsUntouchable and containers, this is dealing with scope. There are two forms of scope. Is an object visible and is an object touchable. When people talk about scope, they are normally talking about the former. Consider a ball inside a closed glass box. The ball is visible, so it is in scope and you can refer to it. However, it is not touchable, because the box is closed, so you can’t take it. ObjectIsUntouchable is a convenience function for allowing you to make the distinction between visible and touchable. It will fail if the object being tested is not in scope (not visible) or not touchable because it’s in a closed transparent container or inside something else that’s in a closed transparent container.
And, no, you don’t have to make the mantelpiece a container, but there might be something else on the mantelpiece that is inside a closed transparent container, such as a bird in its cage and the ObjectIsUntouchable function will take care of that.
Yes, I did look at Alice v3 and that only confused the issue more to me, in a way. It looks like the check now happens in a before on the Drawing_Room. However, the method doesn’t appear to use any techniques that weren’t previously discussed in the Alice tutorial up to that point. So that solution doesn’t support the idea that Inform can now do something that it couldn’t do when the tutorial was written.
So I think my confusion is just that Graham notes that “since this tutorial was first written, it has done just that” and “that” seems to equate to the addition of ObjectIsTouchable(), BUT that has nothing to do with the puzzle being discussed. That seems to just be an aside whose location within the text makes the context confusing.
ObjectIsUntouchable() is not customizable in the I6 library. It checks a fixed set of conditions. Basically it looks at everything the player is on/in, and everything the target is on/in, and checks “no closed container barriers”.
However, you could replace ObjectIsUntouchable() and add conditions. “Can’t reach the floor from a tall supporter” is the kind of condition that you could easily add. This is a normal way to customize I6 games.
A related case is mentioned in the DM4, chapter 25:
“The player cannot touch any object on fire unless (say) wearing the asbestos gloves.”
[This rule] in its fullest form is more problematic, and means replacing the ObjectIsUntouchable routine. Giving any object on fire a before rule preventing the player from using any of the “touchy” actions on it would go some of the way, but wouldn’t handle subtler cases, like a player not being allowed to reach for something through a burning hoop.
So I think that’s what Graham was gesturing at. The library has this feature (as of 6/9, when the DM4 was last updated) but customizing it takes some effort.