Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000977I6 LibraryGeneralpublic2012-08-08 16:122015-05-10 17:47
Assigned ToDavidG 
PlatformOSOS Version
Product Version6/11 
Target Version6/12Fixed in Version6/12 
Summary0000977: 'multiheld' can match unholdable objects
DescriptionOriginally reported by Nathan Summers as Issue L61115

Contrary to the DM4, multiheld sometimes matches objects that are not held. This would be OK if the objects were then implicitly taken, like they are for held, but they are not.
Minimal Source Text To Reproduce
Include "Parser";
Include "Verblib";
Include "Grammar";

[ Initialise; location = theroom; ];

Object  theroom "Frobnization Room"
    with  description "You feel like frobnizing everything! Even the mountain!",
    has   light;

Object  -> "enormous mountain"
    with  name 'enormous' 'mountain'
    has   scenery;

Object  -> "gigantic skyscraper"
    with  name 'gigantic' 'skyscraper'
    has   static;

Object -> "teddy bear"
        with name 'teddy' 'bear';

[ FrobnizeSub; "You frobnize ", (the) noun, " you are currently holding."; ];

Verb 'frobnize' 'frob'
    * multiheld -> Frobnize;
Additional InformationHere's a sample transcript:

  Frobnization Room
  You feel like frobnizing everything! Even the mountain!

  You can see a gigantic skyscraper here.

  That's hardly portable.

  You frobnize the enormous mountain you are currently holding.

  That's fixed in place.

  You frobnize the gigantic skyscraper you are currently holding.
TagsNo tags attached.
Attached Files

- Relationships
related to 0001353closedDavidG Problems with DROP 

-  Notes
DavidG (developer)
2014-05-11 16:26
edited on: 2014-05-11 16:26

I have traced the problem to around line 2046 in parserm.h. There we see this if statement:

  if (not_holding ~= 0 && actor == player) {

Suppose we process a held verb. The variable not_holding will contain the name of the object of the action. For example:


Then not_holding will contain "cookie". With a multiheld verb (like frobnize), not_holding contains "nothing" and that's how the bug shows itself.

Question: Where is not_holding set?

DavidG (developer)
2014-05-11 17:35

I think I squashed this bug. See [^] Please comment.
DavidG (developer)
2014-07-12 01:05

Bug originally reported at [^]
DavidG (developer)
2014-07-12 02:49
edited on: 2014-07-12 02:57

Reopening this because it's causes problems when no_implicit_actions is active and interferes with the DROP verb.

DavidG (developer)
2014-07-22 14:52

Notes from Nathan Schwartzman:

Ok. I remember this bug. So your commit on May 11 fixed it, but had the knock-on effect of causing DROP to generate inappropriate implicit takes. That can be fixed by placing this line in ImplicitTake():

[ ImplicitTake obj
    res ks supcon;
    if (obj in actor) rfalse;
+    if (action_to_be == ##Drop) rtrue;

Then you have the problem of the inappropriate message, "What do you want to drop that in?" because the parser now thinks you're trying to generate an INSERT action. This happens regardless of whether no_implicit_actions is true or false, because INSERT uses multiexcept token and the May 11 commit doesn't account for that. So, you can tweak it:

- if (l ~= nothing && l notin actor && token == MULTIHELD_TOKEN) { 
+ if (l ~= nothing && l notin actor && token == MULTIHELD_TOKEN or MULTIEXCEPT_TOKEN) {
     if (ImplicitTake(l)) {
         etype = NOTHELD_PE;
         jump FailToken;

...and now the parser thinks you're trying to generate a THROW action because drop is currently a synonym for throw, and THROW uses held token. This could be fixed by making 'drop' and 'throw' separate actions:

Verb 'drop' 'discard'
    * multiheld                                 -> Drop
    * multiexcept 'in'/'into'/'down' noun       -> Insert
    * multiexcept 'on'/'onto' noun              -> PutOn;

Verb 'throw'
    * held 'at'/'against'/'on'/'onto' noun      -> ThrowAt;

Now DROP seems to work correctly. This doesn't guarantee that there won't be similar surprises in the future. But I think this is the simplest fix without large-scalle revision of parser code that was created without the intention of allowing lots of implicit actions.
DavidG (developer)
2014-07-23 14:41 [^]
jmcgrew (administrator)
2015-05-10 17:47

Closing all resolved issues from 2014 and earlier.

- Issue History
Date Modified Username Field Change
2012-08-08 16:12 DavidG New Issue
2012-08-09 16:29 DavidG Status new => acknowledged
2012-08-09 21:18 DavidG Steps to Reproduce Updated View Revisions
2012-10-07 18:15 DavidG Assigned To => DavidG
2012-10-07 18:15 DavidG Status acknowledged => assigned
2014-05-11 16:26 DavidG Note Added: 0002757
2014-05-11 16:26 DavidG Note Edited: 0002757 View Revisions
2014-05-11 17:34 DavidG Note Added: 0002758
2014-05-11 17:34 DavidG Note Deleted: 0002758
2014-05-11 17:35 DavidG Note Added: 0002759
2014-05-11 17:35 DavidG Status assigned => resolved
2014-05-11 17:35 DavidG Fixed in Version => 6/12
2014-05-11 17:35 DavidG Resolution open => fixed
2014-07-12 01:05 DavidG Note Added: 0002925
2014-07-12 02:49 DavidG Note Added: 0002926
2014-07-12 02:49 DavidG Status resolved => confirmed
2014-07-12 02:57 DavidG Note Edited: 0002926 View Revisions
2014-07-12 02:57 DavidG Note Edited: 0002926 View Revisions
2014-07-12 03:10 DavidG Relationship added related to 0001353
2014-07-22 14:52 DavidG Note Added: 0002956
2014-07-23 14:41 DavidG Note Added: 0002958
2014-07-23 14:41 DavidG Status confirmed => resolved
2015-05-10 17:47 jmcgrew Note Added: 0003603
2015-05-10 17:47 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker