|Anonymous | Login | Signup for a new account||2018-12-09 15:33 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000303||Core Inform||Actions||public||2010-09-24 12:45||2010-10-28 00:31|
|Platform||x86||OS||Mac OS X||OS Version||10.5|
|Target Version||Fixed in Version||6F95|
|Summary||0000303: Incomplete line is printed when examing a supporter with only undescribed objects|
|Description||It 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"
|Tags||No tags attached.|
|Effect||(serious/mild) Game compiles but misbehaves|
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: http://www.firthworks.com/roger/informfaq/oo.html#3 [^] , and the long discussion of traps and flaws with the concealed attribute here: http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/da42765a26f1882f/5facf48867062f2e?lnk=gst&q=concealed+plotkin#5facf48867062f2e [^] .
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.
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.
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...
"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)
"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 intfiction.org 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.
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.)
|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|