Undescribed, scenery, portability, and fixed in place, once and for all

As described in §3.8. Scenery, sometimes you want something to not be mentioned in its own descriptive paragraph. Marking something scenery also makes it fixed in place.

As described in §3.24. Concealment, undescribed allows you to similarly make an object not be mentioned in its own descriptive paragraph. Marking something undescribed doesn’t make it fixed in place.

However, it also has an unintended side-effect of making an undescribed thing invisible to examine - or at least prone to some unnecessary disambiguation. I can demonstrate here:

Testthing1 is a thing in Room1.
Understand "weirdthing" as testthing1.

Testthing2 is a undescribed thing in Room2.
Understand "weirdthing" as testthing2.

Room1
You can also see Testthing1 here.

>x weirdthing
You see nothing interesting about Testthing1.

>teleport to Room2
Room2

>x weirdthing
You look around, but don’t see Testthing1. Last you remember, it was at Room1.

Is that a bug?

Others have mentioned that in some unspecified way undescribed is dodgy, even going so far as to suggest using scenery in combination with portable rather than undescribed, which seems pretty hacky. So my observation is that undescribed is indeed dodgy.

It seems both undescribed and scenery set some “don’t show this in the room listing” property (along with other side effects each). What is that property and can I just set it directly? My hope was that undescribed would do exactly that.

You have specified to understand “weirdthing” as two separate objects. I believe since testthing2 is undescribed, the parser weights the disambiguation toward a described object since you are (it sounds like, essentially) wanting to hide the undescribed thing from the player - perhaps the parser infers it is dropped from general scope for disambiguation?

I am not sure if the parser “remembers” the understood name you referred to an object as similar to a pronoun - where if you say EXAMINE GUM, TAKE IT, the parser infers “it” is the gum.

1 Like

I’ve used undescribed a bunch and haven’t found anything too tricky – the issue you’re describing above I think is arising because you must have done something like implement an alternate examine action that can apply to any thing. Then since “weirdthing” applies equally to testthing1 and testthing2, Inform is defaulting to whichever is listed first in the source code. You could probably get around this behavior with a does the player mean statement, but I wouldn’t think described vs. undescribed has anything to do with it, albeit I can’t say for sure without looking at the rest of the code!

Anyway, there are other hooks to getting at whether or not something is described; you can muck about with whether something is marked for listing, and if the idea is you want to mention an object in the room description without a redundant paragraph being written about it afterwards, you can just enclose it in square brackets in the description.

EDIT: actually I might be wrong in paragraph 1 - I know scenery items get a slight downward bump in disambiguation priority, but on reflection that might apply to undescribed items too. Either way a DTPM rule is the solution!

EDIT AGAIN: you can also try the “set the locale priority to 0” approach, it occurs to me. Like, this should work:

Rule for writing a paragraph about the testthing2:
     set the locale priority of testthing2 to 0.
1 Like

Mike may be right here A clearer example would be:

Room1 and Room2 are rooms.
Room2 is west of Room1.

Testthing1 is a thing in Room1.
Understand "thing" as testthing1.

Testthing2 is an undescribed thing in Room2.
Understand "thing" as testthing2.

With results:

Room1
You can see Testthing1 here.

>x thing
You see nothing special about Testthing1.

>w
Room2

>x thing
You see nothing special about Testthing2.

So tracking down why undescribed acts differently than scenery is some detective work.

I regularly add objects that are asides in the description paragraph, so making special rules for each one is pretty clunky. Definitely, adding a single word like unmentioned to the object definition is about as complicated as it should be.

Scenery is a property that directions and things can have. It translates to the I6 property “scenery”. Directions are always scenery; things aren’t scenery unless you make them so. Things that are scenery are usually fixed in place, but can be made portable, which isn’t useful unless you also unlist or tweak the can’t take scenery rule. A backdrop is usually scenery but a backdrop can be set to be not scenery.

Places being scenery plays a role:

  • not considered for inclusion in “all” when taking, taking off, or removing
  • not mentioned automatically in room descriptions unless it’s a supporter that has something that isn’t undescribed on it; it will be mentioned even if everything on it is concealed with “On the [supporter] is nothing.” which is less than great
  • if you examine or search a container or supporter, scenery things inside them aren’t mentioned
  • taking, pushing, pulling, turning all have rules blocking scenery
  • counts as equivalent to concealed when you list the contents of the [thing], not listing concealed items.; it does get mentioned if you omit not listing concealed things
  • also considered in parsing and I’m not going to try to figure out exactly how.

An undescribed thing is supposed to be invisible to examining; that’s not a bug. I don’t think its use should be viewed as dodgy, though, as you’ve seen, 3.24 describes at as a “last resort”. The docs have stronger words against writing I6 inclusions, and I do that all the time.

It’s a property things can have. It translates to the I6 property “concealed” which is a little confusing coming from I7 'cause none of the things I7 means when it talks about concealment directly involve this property. The only thing that’s undescribed by default is the player. (You can make the player described and I7 will say, e.g, “You can also see yourself…”) If you change the player to another person, one of the things that happens is the previous player becomes described and the new player becomes undescribed.

Places undescribed plays a role:

  • doesn’t get mentioned in room descriptions (via locale priority being set to 0), not even if they’re a supporter with stuff on it; however, they’re still in scope, and a player might be surprised by a disambiguation question referring to them
  • an actor can’t go through an undescribed door: (“You can’t go that way.”)
  • not mentioned when searching or examining a container they’re in or a supporter they’re on
  • same as scenery, counts as equivalent to concealed when you list the contents of the [thing], not listing concealed items.; it does get mentioned if you omit not listing concealed things
  • also plays a role in parsing; I’m also not going to try to figure out how

Because undescribed things remain in scope, it shouldn’t be viewed as a way to keep something secret. Either leave the thing out of play altogether or use the Scopability extension to make it unscopable (or both!)

If I just want something not to be mentioned, I like:

For writing a paragraph about testthing2: now the testthing2 is mentioned.

but setting locale priority to 0 is just fine.

3 Likes

But are they portable objects? If they’re not, they’re scenery.

If they are portable, you’re already committing to a bunch of special cases, because they could be in the same room as whatever description paragraph you were writing – or not. That’s inherently messy.

2 Likes

If you’re doing this a bunch, it’s easy to have something like:

A thing can be backgrounded or foregrounded.

For writing a paragraph about a backgrounded thing (called the item):
  now the item is mentioned.

Here’s an additional tip for seeing how Inform is ranking objects in response to certain actions.

Behind the scenes, things are given priority scores. So being scenery will give something a lower score than another thing in the room that’s not scenery. If the player holds something, it gets a big boost. Using Does The Player Mean Rules give additions or subtractions to the scores.

If you’re having trouble making the game respond the way you want to a certain action (I type X TREE and I’m getting the wrong tree at this particular moment) you can look at the actual scores to get a better idea what’s going on.

Enter the testing command TRACE 4. At level 3 or lower you don’t see the scores. Now enter your command as usual, and scroll down to the bottom of the TRACE output where you will see each score listed and what decision Inform made.

Here’s a demo set up. Without the DTPM rules, the lego tree would have the highest score; it gets favoured because the player’s holding it. Using the DTPM to alter the scores, we can make X TREE look at a backdrop tree instead by default.

-Wade

Summary
living room is a room.

a plastic christmas tree is in living room. it is scenery.

player holds a lego tree.

a hanging deodorant tree is in living room.

a family tree is a backdrop in living room.

Does the player mean examining the family tree: it is very likely.

Does the player mean examining the plastic christmas tree: it is unlikely.

Test me with "trace 4/x tree".
1 Like