Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000303Core InformActionspublic2010-09-24 12:452010-10-28 00:31
Assigned Tograham 
Platformx86OSMac OS XOS Version10.5
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000303: Incomplete line is printed when examing a supporter with only undescribed objects
DescriptionIt appears that the "examine supporters rule" checks only if there is a non-scenery object on a supporter, not whether there is a described non-scenery object. If the supporter has only undescribed objects on it, the message "On [the noun] ." is printed.
Minimal Source Text To Reproduce
The Study is a room. 

The table is a supporter in the Study. 

The hammer is on the table. The hammer is undescribed.

test me with "x table"
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
related to 0000038closedemshort Bad output from examining enterable supporter 

-  Notes
emshort (administrator)
2010-09-25 02:53
edited on: 2010-09-25 03:06

This involves the use of described/undescribed, which we've been having an ongoing argument about for years.

It was left in for a few specialized needs of the Standard Library (I think for keeping the player from being listed in room descriptions) but was otherwise an essentially buggy translation of the essentially buggy "concealed" flag from I6. So my understanding was that we were not to discuss this item in the manual or to expect authors to use it.

For my reasons, see discussion here: [^] , and the long discussion of traps and flaws with the concealed attribute here: [^] .

However, some authors clearly do use described/undescribed, which must reflect a strong sense that such a flag is needed -- strong enough that they go looking for it even though it's not really presented to them, and even though the Inform examples systematically avoid it and use other methods for common related tasks.

So I'm willing to go either way on this -- either more overtly discouraging its existence to the point of helping dig it out of its remaining refuges in the Standard Rules, or else giving it a bit of a clean-up; but in the latter case we should also be adjusting the documentation and several examples, because this would be an overturning of policy, not just a bug fix.

capmikee (reporter)
2010-09-25 05:46

I've been using "undescribed" to mean "scenery but not fixed-in-place." If there's a better way to handle that, I would gladly do without "described."

This goes along with the question I asked on the forum about printing the initial appearance of unhandled objects on a supporter. In fact, I would venture to guess that most of the time "undescribed" is used, it's to get around the default behavior of describing unhandled objects on supporters.
capmikee (reporter)
2010-09-25 06:00

As far as documentation goes, I have two thoughts:

Firstly, I think this points out the need to revise the documentation, possibly even before further changes to I7 are established. There seem to be some volunteers who would be willing to work in parallel with core and IDE developers.

Second, perhaps it's better to mention "undescribed" as a deprecated or dangerous feature than not to mention it at all, including references to alternate solutions for common situations. Partly this is due to the fact that I (and I imagine other users too) tend to assume that just because I can't find something in the documentation doesn't mean it's not there. Which brings me back to the first issue...
emshort (administrator)
2010-09-25 06:13

"I think this points out the need to revise the documentation, possibly even before further changes to I7 are established. There seem to be some volunteers who would be willing to work in parallel with core and IDE developers."

The documentation does need revision, but there is simply no way to do this (regardless of the amount of volunteer interest) that would not require significant work from me and from Graham -- because anything written would have to be proofread and formatted for I7's internal presentation format; because examples would have to be moved around and revised; because revising the examples would mean revising the test harness that uses them, etc. etc. This would essentially shut down all other core work on Inform for some time -- probably months -- and then the language would return to evolving, so that we'd need to keep doing substantial updates. So we are not going to do this immediately.

I set the status here to "feedback" because I wanted Graham's ruling on which tack we should take before I worked on any patches for the Standard Rules.
Ron Newcomb (reporter)
2010-09-26 16:52

"It was left in for a few specialized needs of the Standard Library (I think for keeping the player from being listed in room descriptions)"

Possibly useless trivia, but:

I seem to remember the undescribed property first appearing in Inform 7 around the time that the player could be set to a pre-existing Person -- "The player is Bob." -- and rules that could apply to "an actor". This was around 4K41 or so. A problem involving Your Former Self appearing in room descriptions and in descriptions that negate a relation, such as "every person not in the location", would introduce YFS to the reader. Even now, the rule to not list undescribed things in a room description is only used by the player object, and if we set the scenery property on the player, the rule can be removed.

Andrew Plotkin said on that there might be fallout from declaring the player scenery, but he said it was only in very "arcane" circumstances, and didn't elaborate. This was in response to me trying to speed up a WIP.
graham (administrator)
2010-10-10 15:11

The handling of "undescribed" has been made more consistent, and it has been documented thus:

There is also an either/or property called "described"/"undescribed", intended to be used only as a last resort, but which has the ability to hide something from room descriptions. This not really hiding: the idea is that "undescribed" should be used only for cases where some other text already reveals the item, or where its presence is implicit. Even then, it should only be used when the item is intended to be taken or moved by the player at some point - if the item isn't intended to move, it's much better to make it "scenery". (There's only one commonly-found example - the player's own body, the "yourself", is undescribed.)

Note that the "undescribed" property is automatically removed from anything carried by, worn by or part of the player, even indirectly; and that nothing on top of an "undescribed" supporter will be visible in a room description, even if it itself is "described". (Scenery supporters don't suffer from that restriction, which is one reason scenery is a better option when possible.)

- Issue History
Date Modified Username Field Change
2010-09-24 12:45 capmikee New Issue
2010-09-25 01:26 jmcgrew Relationship added related to 0000038
2010-09-25 01:26 jmcgrew Status new => acknowledged
2010-09-25 02:53 emshort Note Added: 0000582
2010-09-25 02:54 emshort Assigned To => graham
2010-09-25 02:54 emshort Status acknowledged => feedback
2010-09-25 03:06 emshort Note Edited: 0000582 View Revisions
2010-09-25 05:46 capmikee Note Added: 0000583
2010-09-25 05:46 capmikee Status feedback => assigned
2010-09-25 06:00 capmikee Note Added: 0000584
2010-09-25 06:13 emshort Note Added: 0000585
2010-09-25 06:13 emshort Status assigned => feedback
2010-09-26 16:52 Ron Newcomb Note Added: 0000600
2010-10-10 15:11 graham Note Added: 0000688
2010-10-10 15:11 graham Status feedback => resolved
2010-10-10 15:11 graham Resolution open => fixed
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:31 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker