I am creating a game where I want to hide some of Inform’s automatic descriptions of objects and doors, but I can’t find out how. Basically I don’t want the “You can see a wooden door here” kind of messages to exist. Can anyone help me with this? Here is a piece of my code.
[code]The Hallway is a room. “There is a door and a box here.”
The wooden door is a closed, locked door. The wooden door is west of the Vault and east of the Hallway.[/code]
I would really appreciate any help.
“It is scenery” will do it for you if you also want the objects to be fixed in place, like the door (see chapter 3.8). It’s a speck more complicated if you want to hide the descriptions of portable objects.
I think I remember reading somewhere that you can mark scenery as “portable”, but I’m not sure if it works.
I believe this is correct – I’m pretty sure scenery is defined as “usually” fixed in place, so that property can be overridden. However, rather than going through the two steps of declaring something to be scenery and then declaring it to be portable, can’t you just use the single “undescribed” property to get where you want?
Of course, in the case of a door, just using the “scenery” property would usually be enough; I imagine it would not be too often that you would want a door to be portable (although one could imagine a Lewis Carroll-type of world where you could carry around a door, set it down somewhere else and create a means of effectively teleporting yourself somewhere).
Robert Rothman
Doors are defined in the Standard Rules as “always fixed in place,” so you can’t set a door to be portable. Also, you can’t move doors in play (I once wrote a bit of code that remapped the exits of a door, and it threw a run-time error), so I suspect that picking up a door would cause trouble even if you rewrote that bit of the Standard Rules. Some more complicated coding would be called on to make a Lewis Carroll-type of door.
Maybe the way to do it would be not to use an “official” door at all, just an enterable container (which is described as a door), combined with an “instead” rule which moves the player to a specified location when he tries to enter the container. If you wanted to make it two-way, you would also move the container itself to the new location (and reverse the “destination”).
Robert Rothman
Yeah, that’s what I meant by “more complicated coding”; I don’t even like to think of what it would take to make an “official” door behave this way.
I don’t know if you remember/were here for Foxaroo’s “TARDIS Adrift” thread, but that’s where this problem came up. My solution was a lot like what you say; Scott Hammack came up with a much nicer solution that simply implemented the TARDIS as an enterable container.
Nooooooo!
I think some of the bugs regarding “undescribed” have been fixed, but it’s only marginally supported, and there’s almost always a better way. The only official use for “undescribed” is for omitting the player from room descriptions, and to be honest, I think it wouldn’t be hard to do away with it for that as well. I’m quietly hoping for “undescribed” to disappear from I7 completely.
I’m partial to the “after choosing notable locale objects” rulebook. You can set the locale priority of unmentioned objects to 0, and you can also use the same rulebook to order paragraphs in room descriptions. You can even cause things to show up that aren’t actually in scope. (Be careful not to do this by accident!) It’s very handy, and deserves more attention in the documentation in my opinion.