|Anonymous | Login | Signup for a new account||2019-02-23 19:00 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000886||Core Inform||Model world||public||2012-03-19 06:08||2014-05-07 07:33|
|Reporter||David J Prokopetz|
|Target Version||Fixed in Version||6L02|
|Summary||0000886: In-scope doors are always reachable for most actions, including entering.|
|Description||An in-scope door that is not connected to the actor's location is treated as reachable for most actions. In addition, such doors can be entered.|
|Minimal Source Text To Reproduce|
The Red Room is a room. The Green Room is a room. It is west of the Red Room. The Wooden Door is a door. It is west of the Green Room and east of the Blue Room. The Blue Room is a room. The player is in the Red Room. After deciding the scope for the player: place the Wooden Door in scope; Test me with "open door. close door. push door. enter door."
|Tags||No tags attached.|
|Effect||(serious/mild) Game compiles but misbehaves|
Known, I think, but confirmed anyway.
David J Prokopetz (reporter)
|I suspected it might be a known issue - I saw the note in the manual about the special handling of reachability for doors due to the locational ambiguity of floating objects. Still, it seems like an oversight in the Standard Rules, at the very least; unless I badly misunderstand the nature of the problem, it should be possible to have a Standard Rule that blocks an actor entering a door when the actor's location is neither the front side nor the back side of that door.|
Ron Newcomb (reporter)
"it should be possible to have a Standard Rule that blocks an actor entering a door when the actor's location is neither the front side nor the back side of that door."
But if the author specifically wishes to allow the player to pull a door out of their pocket and enter it, Alice-in-Wonderland style, the author might write something like your scope rule.
I think the example here just lacks adding a rule of its own to the reachability rules (accessibility rules? I forget the name) rather than have the lockdown behavior as a default.
David J Prokopetz (reporter)
|True, that's a possible use case - but is it sufficiently common to justify making doors the odd one out? For everything that's not a door, you have to both place it in scope and create a specific exception to make it reachable, but for doors (and apparently *only* doors), any in-scope entity is reachable unless you explicitly add a rule preventing it. What's the rationale for having doors in particular work that way?|
|Fixed. In fact quite a complicated combination of anomalies concerning two-sided doors, but fixed.|
|2012-03-19 06:08||David J Prokopetz||New Issue|
|2012-03-19 06:09||David J Prokopetz||Issue Monitored: David J Prokopetz|
|2012-03-20 11:50||EmacsUser||Note Added: 0001608|
|2012-03-20 11:50||EmacsUser||Status||new => confirmed|
|2012-03-21 16:03||David J Prokopetz||Note Added: 0001615|
|2012-03-21 18:44||Ron Newcomb||Note Added: 0001616|
|2012-03-21 21:52||David J Prokopetz||Note Added: 0001617|
|2013-12-25 23:59||EmacsUser||Relationship added||has duplicate 0001163|
|2013-12-26 09:30||EmacsUser||Relationship added||related to 0001164|
|2014-02-14 15:12||graham||Note Added: 0002495|
|2014-02-14 15:12||graham||Status||confirmed => resolved|
|2014-02-14 15:12||graham||Resolution||open => fixed|
|2014-02-14 15:12||graham||Assigned To||=> graham|
|2014-05-07 07:32||jmcgrew||Fixed in Version||=> 6L02|
|2014-05-07 07:33||jmcgrew||Status||resolved => closed|
|Copyright © 2000 - 2010 MantisBT Group|