|Anonymous | Login | Signup for a new account||2020-07-03 13:11 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001888||I6 Library||General||public||2016-03-30 15:23||2019-04-09 02:00|
|Target Version||6/12||Fixed in Version|
|Summary||0001888: Responses in DropSub need work|
|Description||Starting 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 Information||When 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?
|Tags||No tags attached.|
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.
|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.|
|It looks like this is okay|
|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|