Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000886Core InformModel worldpublic2012-03-19 06:082014-05-07 07:33
ReporterDavid J Prokopetz 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSWindowsOS VersionXP
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0000886: In-scope doors are always reachable for most actions, including entering.
DescriptionAn 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."
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
has duplicate 0001163closed Basic accessibility rule misbehaves for actions involving doors when the actor is a distant NPC 
related to 0001164closedgraham NPCs cannot touch doors or their parts when on the other side of them from the player 

-  Notes
(0001608)
EmacsUser (manager)
2012-03-20 11:50

Known, I think, but confirmed anyway.
(0001615)
David J Prokopetz (reporter)
2012-03-21 16:03

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.
(0001616)
Ron Newcomb (reporter)
2012-03-21 18:44

"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.
(0001617)
David J Prokopetz (reporter)
2012-03-21 21:52

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?
(0002495)
graham (administrator)
2014-02-14 15:12

Fixed. In fact quite a complicated combination of anomalies concerning two-sided doors, but fixed.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker