Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001888I6 LibraryGeneralpublic2016-03-30 15:232019-04-09 02:00
ReporterDavidG 
Assigned ToDavidG 
PrioritynormalSeveritymildReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version6/12 
Target Version6/12Fixed in Version 
Summary0001888: Responses in DropSub need work
DescriptionStarting at http://www.intfiction.org/forum/viewtopic.php?f=7&t=19461&start=30#p107693, [^] vlaviano points out how some responses from DropSub don't make sense. "But this is not a new problem triggered by the proposed change; it's an existing issue with the test "noun in parent(actor)", which is too weak for its intended purpose.".
Minimal Source Text To Reproduce
Constant Story "DROPSUB IMPLICIT TAKE";
Constant Headline "^An Interactive Investigation^";

Include "Parser";
Include "VerbLib";

Object Start_Room "Start Room"
  with description "This is the starting room.",
  has light;

Object -> table "big table"
  with name 'big' 'table',
  has enterable supporter;

Object tin "metal tin"
  with name 'metal' 'tin',
  has container openable;

Object -> mint "breath mint"
  with name 'breath' 'mint',
  has edible;

[ Initialise;
  location = Start_Room;
  move tin to player;
];

Include "Grammar";
Additional InformationWhen we run this with the unmodified library, we see:

DROPSUB IMPLICIT TAKE
An Interactive Investigation
Release 1 / Serial number 160320 / Inform v6.33 Library 6/12-beta1 SD

Start Room
This is the starting room.

You can see a big table here.

>open tin
You open the metal tin, revealing a breath mint.

>drop tin
Dropped.

>get on table
You get onto the big table.

>drop mint
Perhaps you should take the breath mint out of the metal tin first.

>drop tin
Perhaps you should take the metal tin out of the Start Room first.


So, I think that the issue that you pointed out needs to be fixed regardless. I'd suggest treating it as a separate issue: dropping an object that is not carried by the actor and not directly contained in the parent of the actor produces an inappropriate response. I think that the correct response is arguable depending on how we define "here". Does it mean the immediate parent of the actor, or does it mean in the broader location / in scope?
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0004407)
DavidG (developer)
2016-03-30 15:24

More commentary from vlaviano:

More thoughts on this:

Both of these issues are intertwined.

As far as I can tell, there are 3 things that we need to consider:
1) The ##Drop grammar's multiheld token and the ImplicitTake call that this causes the parser to generate
2) DropSub and its own call to ImplicitTake
3) The body of ImplicitTake

Note that the special case "if (action_to_be == ##Drop)" test in ImplicitTake returns false, while the parser's call to ImplicitTake treats a true return value as failure.

I think that this effectively makes the parser's ImplicitTake a noop for ##Drop and causes us to move on to DropSub, where ##Drop processing (including the ImplicitTake) really happens. We need to keep this in mind when modifying (or removing) that test in ImplicitTake, lest we restore the significance of the parser's ImplicitTake without realizing it.

Not that I'm saying that the current situation is a good thing. It would be nicer if ##Drop were handled more consistently with other actions that require held objects.
(0004408)
DavidG (developer)
2016-03-30 15:24

https://github.com/DavidGriffith/inform6lib/issues/32 [^]
(0004504)
DavidG (developer)
2016-07-30 11:50

It seems like this was caused by an incomplete implementation of Suggestion 122 at http://inform-fiction.org/suggestions/complete.html. [^] I suppose a more proper implementation can be researched and applied later.
(0004846)
DavidG (developer)
2019-04-09 02:00

It looks like this is okay

- Issue History
Date Modified Username Field Change
2016-03-30 15:23 DavidG New Issue
2016-03-30 15:23 DavidG Status new => assigned
2016-03-30 15:23 DavidG Assigned To => DavidG
2016-03-30 15:24 DavidG Note Added: 0004407
2016-03-30 15:24 DavidG Note Added: 0004408
2016-07-30 11:50 DavidG Note Added: 0004504
2019-04-09 02:00 DavidG Note Added: 0004846
2019-04-09 02:00 DavidG Status assigned => resolved
2019-04-09 02:00 DavidG Resolution open => fixed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker