Omit contents

I have a simple question, should have a simple answer, but with Inform…
I want to omit a list of objects after LOOKING in the room. I know making the objects scenery will do it but I can’t use scenery for these objects. I could also go around the LOOK action and write my own rule, but that sidesteps many other pre-LOOK checks, which I don’t want to do.

The documentation says that omit contents can work for room descriptions, but nothing I tried seem to work. What is the magic passphrase that allows the room description to omit the list of objects in it?

Do you want to hide some particular objects (the ones that belong in the room, perhaps), while still showing anything the player has dropped there? Or do you want to remove everything unconditionally?

Both are possible but they need slightly different approaches.

I want to hide the original objects because I have text that follows to describe them. I have tried text for “initial appearance” but that doesn’t work as I expected. It has side effects–but shouldn’t it work that way?

Check the recipe book for different variations: 3.1. Room Descriptions

Then Inform carries out the writing a paragraph about… activity with anything that provides one; anything it prints the name of, it tags “mentioned”. Thus

Rule for writing a paragraph about Mr Wickham: 
    say "Mr Wickham looks speculatively at [list of women in the location]."

will count Wickham and everyone he looks at as all having been mentioned, and will not refer to them again through the rest of the room description. More complicated uses of writing a paragraph abound. A developed system for handling supporters that don’t list contents appears in The Eye of the Idol.

Inform then prints the initial appearances of objects that are marked for listing but not already mentioned; and then it performs the listing nondescript items activity, collating the remaining objects into a paragraph like

You can see a dog, a hen, …

We can pre-empt items from appearing in this paragraph or change their listing by intervening with a Before listing nondescript items… rule, as in

Before listing nondescript items when the player needs the watch: 
    if the watch is marked for listing: 
        say "The watch catches your eye."; 
        now the watch is not marked for listing.

Read the recipe book for more, often the easiest is to give an initial appearance which overrides the nondescript items listing until the item is picked up and dropped somewhere else.

1 Like

From what you’re describing, the easiest way to do this is probably just to write the name of the objects in square brackets inside your location descriptions - this will have Inform include the printed name of the object, and then since it knows the player’s already seen the thing, it won’t include it in the “you can also see…” line.

If the objects are portable or not always present, you’ll probably want a different approach, though.


There are four or five ways to omit printing a non-scenery thing in a room, or otherwise manipulate what/how Inform goes about doing so. Most of them are found in Chapter 18, Activities. I’m not recommending the whole chapter, which is large. Just the bits about locale description, locale paragraph, and writing a paragraph. Writing a paragraph will usually be enough. Inform 7 will only mention a non-scenery thing once. If you tell Inform something is mentioned, it won’t mention it.

The easiest way (I dislike the bracket option because you can’t really ctrl-f “[” in an Inform story) is probably this? You can turn it on or off, which might be handy.

a thing can be obfuscated or in plain sight.

rule for writing a paragraph about something obfuscated (called the omission):
	now the omission is mentioned.

You can make these statements conditional, either limiting the rule or else creating multiple cases.

So far as initial appearance goes, I couldn’t tell if you meant for the object or the room. “If unvisited” is one way. I usually do everything this way:

the description of the ball is "[one of]Round, very round, and red.[or]How many times can you examine a ball?[stopping]"

That will print the first one, then the second from then on.

There’s also

"[first time]say this the first time[only]say this every time, even the first time"

or even
"[if the ball is obfuscated][otherwise]Finding that ball was quite a discovery."

I’m pretty sure that last one is fine, but I haven’t double-checked.


Could you elaborate on the brackets / ctrl-f comment? I didn’t quite follow.


The solution I almost always use is “undescribed”. It hides a noun from the “You can see” list, but you can otherwise interact with it normally.

Lab is a room.

The description of the lab is "You're in the lab.  A giant ray gun stands waiting."

The ray gun is a fixed in place thing in the Lab.  It is undescribed.  The description of the ray gun is "One ray gun, waiting to be turned on and fired."

Instead of switching on the ray gun:
	say "You blow up planet Xernon!";
	end the story finally.

Undescribed has as its opposite “described”:

After examining the ray gun:
    now the ray gun is described.

That bit of code will then show the ray gun in the “You can see” list after examining it.

I’m talking about the practice of bracketing nouns that are included in room description text. Inform considers those nouns “mentioned” and omits them from the locale description.

lab is a room.

an apl is in lab.
the printed name of apl is "apple".

the description of the lab is "There's nothing here, save for one [apl]."

I prefer things I can search for in code, and brackets are ubiquitous. For this and other reasons, I’ve gotten in the habit of making rules for this kind of stuff. It works fine though!

1 Like

This “undescribed” phrase seems like a very useful piece of code. Why is it not more visible in the documentation?

My guess is that it’s because it tends to have unwanted behavior. For instance, everything on an undescribed supporter is always invisible. Also, taking an undescribed thing makes it described, which usually is what you want but not always.

And making something undescribed, but mentioning it in the room description, means that once you take it, it will still be in the description. So if you say ‘This is a room. There is a bucket on the floor.’, then it will still say ‘There is a bucket on the floor’ after you pick up the bucket.

I find it easier to work with initial appearance, or, more generally, ‘rule for writing a paragraph about’, which is great when combining similar objects. These two properties are better because they only print when the object is present and hasn’t been taken yet.

Outside of that, I think mentioning it with the name in brackets is the third best option.

I really think this is Graham Nelson trying to nudge authors away from having that problem I mentioned (putting item descriptions in the room text). Each language pushes people towards certain paradigms, and I think this is one of those pushes.

1 Like

Tiny tweak – writing a paragraph about works forever. But yeah, initial appearance only works when the item hasn’t been handled.

I view the main reason to use brackets as when you want an item’s description to be part of the flow of the room description’s prose. If you’re going to change the room’s description in-game, after that , the item can leave its brackets and start appearing on its own, powered by its own initial appearance or ‘writing a paragraph’ about rules. In the end, items are either bound up in the room body prose, or they aren’t.

It’s usually easier/safer to use any of these methods before undescribed, but sometimes undescribed is the tool you need.

Almost nobody thinks about BRIEF mode these days, but for anyone who is – bracketed items will still be mentioned when not LOOKing, which is what you want. Undescribed items may easily be forgotten or overlooked. And scenery items should certainly be unimportant in this scheme, not just things you want to put in prose but not list separately.



Thanks for this. I will revise my code accordingly, because up til now, I hit one deadend or another with unwanted side effects. ;-(

1 Like

The other problem I ran into with Undescribed is that you cannot use doors that are undescribed. I can’t remember WHY I need a door to be undescribed - but I did - and then I found out I couldn’t use it. :slight_smile:

Also can’t remember how I worked around it … and I’m at work so I can’t go and have a look at my story to reminds myself!


I suspect that’s by design in the I6 library (where “undescribed” is the concealed attribute) and was never removed in I7 where the only undescribed thing is generally the player.

It was. It’s even mentioned in the DM4 (appendix A1, describing concealed.)

The real point is that in I6, concealed is a confusing mashup of about three different useful features. So any attempt to use it leads to this long annoying conversation where you find out all the things you forgot it did.