|Anonymous | Login | Signup for a new account||2018-06-18 01:00 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000280||Core Inform||Understanding||public||2010-09-06 18:56||2010-10-28 00:31|
|Platform||x86||OS||Mac OS X||OS Version||10.6|
|Target Version||Fixed in Version||6F95|
|Summary||0000280: Using multiple synonym words not parsed when they're slash-separated in Understand rule|
|Description||Unless something's gone wrong on my end, it seems as if using multiple synonym words in a command causes the command to no longer be recognized. "examine magnifying glass" is no longer parsed correctly if those two words are both defined in Understand rules, separated by a slash.|
|Minimal Source Text To Reproduce|
Stage is a room. The disc is in Stage. Understand "magnifying/glass" as the disc. test me with "x disc / x magnifying / x glass / x magnifying glass / x glass magnifying / x magnifying glass disc / take magnifying glass".
|Tags||No tags attached.|
|Effect||(serious/mild) Game compiles but misbehaves|
|For what it's worth, on my system at least this happens in released games, as well. (Under Gargoyle on a Mac.)|
|I thought this was the intended behavior? Manual chapter 16.12: "When the alternatives are in any way complicated, "or" should always be used, but a shorthand form is allowed for simple cases where it is only a matter of a single word having several possibilities: Understand "reach underneath/under/beneath [something]" as looking under."|
Ron Newcomb (reporter)
I thought this was intended behavior? As in,
Understand "magnifying/looking glass" as the disc.
will catch "magnifying glass" and "looking glass" but not "magnifying looking glass".
I could be wrong, I suppose, but I'm reasonably certain this is not correct behavior. The example Juhana cites is about understanding new grammar lines, not synonyms for nouns. I disagree with Ron that his example shouldn't understand "magnifying looking glass"; the parser should see two tokens, "magnifying" and "looking glass," both of which match the disc, and therefore the command should be understood. (I believe, however, that this version would be correct in rejecting "magnifying looking" or "magnifying glass," since the space indicates those words are only understood in combination.
Barring interventions by other code, the parser should be able to understand any word in a thing's name, as well as any single words defined as synonyms, as referring to that thing, no matter what order or combination they're used in.
I agree with Ron's example: the slash only combines individual words, not phrases, so "magnifying/looking glass" does not match "magnifying", and therefore "magnifying looking glass" won't match.
However, I think Aaron's report is still valid because he's using single words. My understanding is that "magnifying/glass" should match either "magnifying" or "glass", the same as "Understand 'magnifying' or 'glass' as the disc". AFAIK there's no indication that only one of the alternatives may be used in a given noun phrase.
Ron Newcomb (reporter)
|I just know that the slash and the Or (incl. comma) work differently. It was done that way on purpose, for when a noun is being used as an adjective. Ex: "car/Honda key" allows car/Honda as an adjective, but "key" is required, and the key cannot be referred to as simply "car" nor "Honda".|
I'd expect the slash and "or" to work identically when single words are involved. They're implemented differently, which would be fine except that the current implementation results in some unintuitive, undocumented restrictions on what sort of noun phrases are allowed. The first example under Additional Information at 0000162 demonstrates this too, where "brown stetson hat" fails to match when the hat is understood as "chapeau/hat", but works correctly when it's "'chapeau' or 'hat'".
"car/honda key" should, as I understand it, be identical to "'car key' or 'honda key'". The space is what makes "key" required, not the slash.
|I've always thought the use of slash quite logical in that it means "exactly one of these", where "or" means "one or more of these". I'd find it unintuitive if "magnifying/looking" would catch "magnifying looking" but "magnifying/looking glass" would not catch "magnifying looking glass". It would be yet another exception to remember and there wouldn't be a syntax for "exactly one of these" for single words anymore. What if I didn't want "key/keys" to catch "key keys"?|
Ron Newcomb (reporter)
Yeah, what Juhana said. The explicit or is always an inclusive or. The slash is always an exclusive or.
So this is a feature request, not a bug?
At the very least, it's a documentation bug, because the difference between slash and "or" is not documented. In fact, section 16.12 of the manual ("This/that") implies there is no difference:
Understand "reach underneath/under/beneath [something]" as looking under.
This is shorthand for:
Understand "reach underneath [something]" or "reach under [something]" or "reach beneath [something]" as looking under.
I remain convinced that this is a compiler bug, though. Here's a similar test case:
Home is a room.
A key is here. It is privately-named.
Understand "house/car" as the key.
Understand "key/kee" as the key.
The key can be referred to as:
house, car, key, kee, house key, house kee, car key, car kee
house car, car house, key kee, kee key, key house, key car, kee house, kee car
If you swap the two Understand statements, "house key" becomes invalid and "key house" becomes valid (etc.). The generated parse_name routine only matches a subset of the names that the code implies: it expects all the slashed parts to appear zero or one times, in the order they were defined in the source code. (Also, it seems "name property words" -- defined by simpler Understand statements and the object name -- can appear before or after the slashed parts, but not intermingled with them.)
I really don't think this is a feature request. 16.22 says:
>1. Understanding the names of things. As we've seen since the earliest chapters, we may
>add to the vocabulary used to refer to an object in the game, or to an entire class:
>Understand "fish" as the trout.
>Understand "fish" or "dinner" as the trout.
>Understand "fish/dinner" as the trout.
>Understand "gentleman" as a man.
>If we use an entire phrase, as here
>Understand "red bird" as the robin.
>Inform will match only the full phrase and not its components; so EXAMINE RED BIRD
>would work, but not EXAMINE RED or EXAMINE BIRD.
I certainly read this as implying that the second case (Understand "red bird") is an exception to the default behavior, not the normal behavior, and that the middle two lines in the first block of Understand rules should have the same effect.
General parsing philosophy also seems to be in favor of this interpretation. The DM4 says that the parser "tries to be generous in what it accepts from the player, understanding the broadest possible range of commands and making no effort to be strict in rejecting ungrammatical requests," and gives the example that "'green green tomato green fried green' is considered a very good match indeed" for fried green tomatoes. With this in mind, making the player type 'Understand "fried" and "green" and "tomatoes"' seems like a lot more work for the default behavior than 'Understand "fried/green/tomatoes".'
A separate issue is whether it's confusing that the slash is an Exclusive Or in Understand rules for verbs, and an inclusive one in Understand rules for nouns. Also separate is whether allowing spaces and slashes together in an Understand rule for nouns causes unnecessary confusion. But I think what's going on here is incorrect behavior.
The documentation may be explaining it poorly, but the slash is consistently an exclusive or, and this is intentional.
The issue that Jesse brings up about the ordering of the source text does sound like a compiler bug, however.
This ought to be made much more explicit in the docs, then. I always thought that 'Understand "magnifying/glass" as the disc.' would let "magnifying glass" be understood. Lots of code to fix...
|This is a complicated issue, but I have improved matters by following a maximalist strategy (as in the DM4): one can now use any sequence of Understand lines to refer to an object, so that the sequence of Understand sentences is no longer relevant. (Jesse's examples work as he expected, with house car, car house, key kee, kee key, key house, key car, kee house, kee car all working.)|
|2010-09-06 18:56||AaronReed||New Issue|
|2010-09-06 19:07||AaronReed||Note Added: 0000519|
|2010-09-06 23:27||jmcgrew||Relationship added||related to 0000162|
|2010-09-06 23:27||jmcgrew||Status||new => acknowledged|
|2010-09-06 23:35||jmcgrew||Status||acknowledged => confirmed|
|2010-09-06 23:35||jmcgrew||Steps to Reproduce Updated||View Revisions|
|2010-09-06 23:35||jmcgrew||Severity||serious => mild|
|2010-09-07 02:19||Juhana||Note Added: 0000521|
|2010-09-07 12:38||Ron Newcomb||Note Added: 0000525|
|2010-09-07 13:02||Ron Newcomb||Issue Monitored: Ron Newcomb|
|2010-09-07 13:28||AaronReed||Note Added: 0000527|
|2010-09-07 15:19||jmcgrew||Note Added: 0000528|
|2010-09-07 15:49||Ron Newcomb||Note Added: 0000531|
|2010-09-07 15:58||jmcgrew||Note Added: 0000532|
|2010-09-07 22:58||Juhana||Note Added: 0000538|
|2010-09-08 10:04||Ron Newcomb||Note Added: 0000541|
|2010-09-08 10:27||jmcgrew||Note Added: 0000542|
|2010-09-08 10:34||AaronReed||Note Added: 0000543|
|2010-09-09 05:32||emshort||Note Added: 0000544|
|2010-09-09 11:32||AaronReed||Note Added: 0000545|
|2010-10-10 12:53||graham||Note Added: 0000686|
|2010-10-10 12:53||graham||Status||confirmed => resolved|
|2010-10-10 12:53||graham||Resolution||open => fixed|
|2010-10-10 12:53||graham||Assigned To||=> graham|
|2010-10-25 21:14||jmcgrew||Fixed in Version||=> 6F95|
|2010-10-28 00:31||jmcgrew||Status||resolved => closed|
|Copyright © 2000 - 2010 MantisBT Group|