Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001886I6 LibraryGeneralpublic2016-03-16 14:362016-03-20 20:00
ReporterDavidG 
Assigned ToDavidG 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version6/12 
Target Version6/12Fixed in Version6/12 
Summary0001886: Problem with DropSub and ImplicitTake
DescriptionAnother one reported by vlaviano (http://www.intfiction.org/forum/viewtopic.php?f=7&t=19461&start=20#p106335 [^])

There's a small issue in DropSub in verblibm.h:

if (noun notin actor && ~~ImplicitTake(noun)) return L__M(##Drop, 2, noun);


Looking at ImplicitTake, it returns true on failure and false on success, so the test above ought to be ImplictTake(noun) rather than ~~ImplicitTake(noun), as it is in all of the other calls in verblibm.h.

I (vlaviano) think that this issue has gone undetected in the past because the grammar for Drop uses the multiheld and multiexcept tokens which cause the parser to generate its own ImplicitTake prior to DropSub ever being called. I (vlaviano) discovered the issue after having extended the grammar for Drop and having adapted DropSub in one of my own programs to handle a special case (of liquid in a container).
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 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 InformationThis has the following behavior:

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

Start Room
This is the starting room.

>i
You're carrying:
a metal tin (which is closed)

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

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

>eat mint
(first taking the breath mint)
You eat the breath mint. Not bad.


I had expected drop to have similar behavior as eat, implicitly taking the mint out of the tin.
However, reading ImplicitTake more carefully, I see that the first few lines are:

[ ImplicitTake obj
    res ks supcon;
    switch (metaclass(obj)) { Class, String, Routine, nothing: rfalse; }
    if (obj in actor) rfalse;
    if (action_to_be == ##Drop) rfalse;


It seems that, in the case of ##Drop, ImplicitTake will always return false before changing the model world in any way.

I overlooked this because, in the program that I referred to in my previous post, I had created a new action with its code based on the existing DropSub impl, so action_to_be wasn't ##Drop. In the case of regular ##Drop, the distinction that I made between multiheld/multiexcept and other tokens is irrelevant since the parser's invocation of ImplicitTake always matches this action_to_be test and returns false, so DropSub's ImplicitTake line is called either way.

In light of this, rather than the ~~ImplicitTake() check in DropSub being reversed, it seems that it's instead superfluous and that the same effect could be achieved with:

if (noun notin actor) return L__M(##Drop, 2, noun);


Evidently, the library explicitly does not want ##Drop ever to do an implicit take, although it's unclear to me why this should be the case given how ##Eat works. I think that maybe it's to prevent the parser's multiheld/multiexcept ImplicitTake, when the user types "drop ", from producing "(first taking the foo) Dropped." ImplicitTake could deal with that by extending its acton_to_be check to:

if (action_to_be == ##Drop && obj in parent(actor)) rfalse;


This should allow the "drop " case to produce "the foo is already here", while allowing items that are indirectly contained in the actor to be implicitly taken and dropped.

All that being said, I'm not sure to what extent existing games rely on the old behavior or if there's a mandate to improve I6 library behavior (assuming that we can agree on what constitutes an improvement) vs. just fixing bugs.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0004400)
DavidG (developer)
2016-03-16 14:37

https://github.com/DavidGriffith/inform6lib/issues/31 [^]

- Issue History
Date Modified Username Field Change
2016-03-16 14:36 DavidG New Issue
2016-03-16 14:36 DavidG Status new => assigned
2016-03-16 14:36 DavidG Assigned To => DavidG
2016-03-16 14:37 DavidG Note Added: 0004400
2016-03-20 20:00 DavidG Status assigned => resolved
2016-03-20 20:00 DavidG Fixed in Version => 6/12
2016-03-20 20:00 DavidG Resolution open => fixed
2016-03-20 20:00 DavidG Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker