Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000433Core InformActivitiespublic2010-11-21 13:042014-05-07 07:33
Assigned Tograham 
Platformx86OSMac OS XOS Version10.5
Product Version6F95 
Target VersionFixed in Version6L02 
Summary0000433: Deciding whether all includes does not occur when the player is alone
DescriptionWI 17.34 says the following:

- - - -
1. When it happens. When parsing a command such as "take all", where the player uses "all" to signify everything within reach.
- - - -

But the I6 routine Adjudicate contains this line:

- - - -
if (good_ones == 1) return last;
- - - -

So that deciding whether all includes doesn't happen when there is only one object possible---the PC.

The statement is also responsible for a surprising response to ``drop all'' in the attached source:

- - - -
>drop all
You lack the dexterity
- - - -

rather than the usual

- - - -
>drop all
There are none at all available!
- - - -
Minimal Source Text To Reproduce
There is a room.
Before deciding whether all includes:
	say "(deciding whether all includes)[line break]".
A widget is a thing.
Instead of jumping:
	now the widget is in the location of the player;
	try looking.
Test me with "drop all / jump / drop all".
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
has duplicate 0001054closed Rules for deciding whether all includes are not consulted if only one thing is present 

-  Notes
EmacsUser (manager)
2012-12-06 10:21

See 0001054 for another manifestation.
vyznev (reporter)
2012-12-07 13:03

Pending a proper fix, one way to work around this bug is to ensure that there are always at least two objects in scope:

A kluge is a kind of thing. There are two privately-named kluges.
Before reading a command: now all kluges are carried by the player.
Before taking inventory: now all kluges are off-stage.
Rule for deciding whether all includes a kluge: it does not.
graham (administrator)
2014-01-25 16:11

These decisions are tricky, because any change to the parser pleases some and not others. In the end I agree, and have strengthened the activity so that it can reject a single match (though this does not, as suggested, always happen in Adjudicate). But the consequences can be a little surprising, as autocompletions made funny things happen with other grammar lines for the same verb which used different actions. In the end, I had to modify all of the SR's "deciding whether all includes" rules. I'm still not sure whether all this was wise.

- Issue History
Date Modified Username Field Change
2010-11-21 13:04 EmacsUser New Issue
2010-11-21 19:34 jmcgrew Status new => confirmed
2012-12-06 10:21 EmacsUser Note Added: 0001935
2012-12-06 10:21 EmacsUser Relationship added has duplicate 0001054
2012-12-07 13:03 vyznev Note Added: 0001937
2014-01-25 16:11 graham Note Added: 0002375
2014-01-25 16:11 graham Status confirmed => resolved
2014-01-25 16:11 graham Resolution open => fixed
2014-01-25 16:11 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