I’m working through Aaron Reed’s awesome book, and have a really basic question:
Is “x is scenery” equivalent to “x is undescribed and fixed in place?” If so, then why not just make things scenery?
“Undescribed” is deprecated in the current version (though I believe you can still use it). That said, I’m not sure what you mean by your question; why not just make things scenery in what context?
I believe Rymbeld is referring to the instance in the book where Reed explicitly declares the yellowing weeds fixed in place and undescribed (on page 53 in Creating Interactive Fiction with Inform 7).
The only difference I can think of is the message you get when you try to take “x”. However I would suggest using scenery rather than undescribed and fixed in place.
When you say “current version” what version are you referring to? I heard that “undescribed” will be deprecated in the next version of inform.
No, It’s been deprecated for several versions now. What I said is that I think it might be removed completely.
As I said in another thread: scenery objects are normally not described, but they do not rely on (or have) the “undescribed” property.
“Undescribed” is not currently formally deprecated, but it is mentioned in the documentation (3.24) as “intended to be used only as a last resort”. I have the notion that it will be deprecated next version, but I don’t remember where I remember that from.
The current Standard Rules only apply “undescribed” in one case: the current player object always has it. If you pick up an object, the “undescribed” property is automatically removed from it.
The Standard Rules respect “undescribed” in several places, mostly to remove it from room descriptions, but it has a couple of other effects: You can’t go through an undescribed door. Undescribed objects are excluded from “all” commands. Undescribed objects are penalized (but not excluded) during disambiguation.
This is a bit of a grab-bag, which is the big argument for deprecating it – do you really want all of those effects in any given case? However, it is currently difficult to add a door to a room during play by any other means. So if “undescribed” goes away, it will probably be in conjunction with a new door feature. (There’s a feature request posted for that.)
That clears up a lot of confusion, since inform does not complain about using “undescribed” when using the no deprecated features. I think the point is clear though, avoid the “undescribed” feature. As I mentioned above, it’s best to use the “scenery” option and “portable scenery” for items that need to be portable.
That’s what I’d meant to say. Apologies for the miswording. 
Well, after all that, I’d be inclined to believe Zarf rather than what I said.
Thanks. And yes, for the record, I was thinking of page 53 when Reed introduced described/undescribed, in his discussion of properties. He says,
That makes sense to me. But then he introduces the scenery property on p. 76:
That naturally made me wonder why one would bother saying something is undescribed anyway. I suppose he was just going through various ways to do it as a teaching strategy…
Yeah, that’s not the world’s most awesome example; there is no reason why the yellowing weeds and huge electrical tower shouldn’t be scenery, and it’s better practice to do it that way. (If you make a supporter fixed in place + undescribed instead of scenery, for instance, anything placed on top of it will become rather difficult for the player to find again.)
What the book’s suggesting is kind of a hacky suggestion: it’ll work fine in that particular example, but it’s not general good practice, nor is it easier than using scenery. My best guess is that it’s introduced as one of a bunch of either/or properties, like portable/fixed in place, and scenery doesn’t quite fit into that pattern.
Bear in mind that Creating Interactive Fiction With Inform 7 is as much a reflection of Aaron’s personal style of coding as it is an objective didactic work. There are some things about it that I find pretty strange (it never gets around to mentioning tables, and BENT is not for everyone). That’s okay! People have different coding styles and learning styles. (A number of people have trouble with the I7 documentation; I found it a perfectly fine way to learn the system.)
Yeah, I don’t remember off the top of my head why I chose to do it that way now. It might be an artifact of my feckless younger days in I6, where I was in the habit of using undescribed a lot. Probably something to be revisited if there is ever a second edition of the book.