I recently received a bug report for my Numbered Disambiguation Choices extension that is driving my crazy. Here is the test case:
[code]Include Numbered Disambiguation Choices by Aaron Reed.
The Ballroom is a room. In the ballroom is a person called the butler.
The player is carrying a red ball. The player is carrying a yellow ball.
[/code]
If you type “show ball to butler,” then press 1 (to indicate the red ball) things behave as expected; however, if you choose 2 (or any higher number, if you add more objects) you instead get the perplexing message “You can only do that to something animate.”
The extension works by understanding a numeric property as the item: during disambiguation, that property gets filled with a sequential set of numbers. So the command that actually gets parsed is “show 1 ball to butler” versus “show 2 ball to butler”. My guess is Inform is perhaps confusing this with something like “show both balls to butler,” but I don’t know why a) things work normally in every other case (“examine 2 ball” works fine), or b) You don’t then get the message “You can’t use multiple objects with that verb.”
Leads: the ANIMA_PE parser error (Misc #37) only seems to be used in Parse Token Letter D (on p.123 of the Appendix-B document). I can’t work out exactly what’s going on here, but it seems to be checking whether the thing the player’s talking about is referring to a creature… are numbers other than “1” being misinterpreted in the case of a grammar line with a second noun?
That appears to be the case. I tried the same example after changing the disambiguation numbers to (n * 100). The first choice (number 100) then gives the same response as the second choice (200).
I have no idea what that portends, though…
–Erik
EDIT: I also tried making the disambiguation ID an indexed text representing a number (“1”) instead of a number (1). It failed in exactly the same way. This probably just means that the distinction between indexed text and number doesn’t matter by the time it’s been tokenized…
For what it’s worth:
I ran the example through an earlier build of Inform (5Z71) (commenting out the extension’s chapter on parser errors) and came up with this:
It perhaps suggests that the current build of Inform doesn’t discriminate between “2 ball” and “2 balls” in a way that it used to.
Below are the trace records for SHOW 2 BALL TO BUTLER and SHOW 2 BALLS TO BUTLER in 5Z71:
[rant]>trace 4
[Parser tracing set to level 4.]
show 2 ball to butler
[ “show” show / “2” ? / “ball” ball / “to” to / “butler” butler ]
[Parsing for the verb ‘show’ (2 lines)]
[line 0 * creature held → Show reverse]
[line 0 token 1 word 2 : creature]
[Object list from word 2]
[Calling NounDomain on location and actor]
[NounDomain called at word 2
seeking definite object
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 1 Pass 2: 2
[ND made 1 matches]
[ND returned the yellow ball]
[token resulted in failure with error type 4]
[line 1 * held ‘to’ creature → Show]
[line 1 token 1 word 2 : held]
[Object list from word 2]
[NounDomain called at word 2
seeking definite object
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 1 Pass 2: 2
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 1 Pass 2: 2
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
[ND made 1 matches]
[token resulted in success]
[line 1 token 2 word 4 : ‘to’]
[token resulted in success]
[line 1 token 3 word 5 : creature]
[Object list from word 5]
[Calling NounDomain on location and actor]
[NounDomain called at word 5
seeking definite object
Two-pass parse_name called
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
Pass 1: 1 Pass 2: 1
Two-pass parse_name called
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
Pass 1: 0 Pass 2: 0
[ND made 1 matches]
[ND returned the butler]
[token resulted in success]
[line 1 token 4 word 6 : END]
[Line successfully parsed]
The butler is unimpressed.
show 2 balls to butler
[ “show” show / “2” ? / “balls” ? / “to” to / “butler” butler ]
[Parsing for the verb ‘show’ (2 lines)]
[line 0 * creature held → Show reverse]
[line 0 token 1 word 2 : creature]
[Object list from word 2]
[Calling NounDomain on location and actor]
[NounDomain called at word 2
seeking definite object
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 1 Pass 2: 1
[ND made 1 matches]
[ND returned the yellow ball]
[token resulted in failure with error type 4]
[line 1 * held ‘to’ creature → Show]
[line 1 token 1 word 2 : held]
[Object list from word 2]
[NounDomain called at word 2
seeking definite object
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 1 Pass 2: 1
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 1 Pass 2: 1
Two-pass parse_name called
[Read number as 2]
[Read number as 2]
Pass 1: 0 Pass 2: 0
[ND made 1 matches]
[token resulted in success]
[line 1 token 2 word 3 : ‘to’]
[token resulted in failure with error type 3]
You can only do that to something animate.[/rant]
I am the guy who wrote the bug report. It definitely seems to be a general problem when having two nouns. The same error occurs when trying to put a ball into a container, and selecting the second option, although the error message in this case is simply “I didn’t understand that number.”.
When I tried it earlier to day (I can’t check that now) I think I saw that SHOW 2 BALL TO BUTLER would yield an error message, whereas SHOW BALL 2 TO BUTLER worked as intended.
If that is so, I suppose a possible solution might be to hack NounDomain to have it insert the disambiguation id number after (the first word of) the object’s name rather than before it.
Hmm. When this code runs (from the end of Parse Token Letter D) with a command in the form show [number] [thing] to [person]'':[code] ! The following moves the word marker to just past the named object... wn = oops_from + match_length;[/code]oops_from is set to 3, because [thing] is the word to replace if the player types oops. But match_length is 2, because the custom parse_name backtracked one word to match the numeric property. That means that the parser looks for the prepositionto’’ one word too late. (Try the command ``show [number] [thing] to to [person],’’ for instance.) Because the preposition doesn’t match,
Understand "show [something preferably held] to [someone]" as showing it to.
is rejected outright, and the error for the partially successful
Understand "show [someone] [something preferably held]" as showing it to (with nouns reversed).
is shown instead. It’s definitely an Inform bug (now filed here), and Felix’s suggestion is probably a good option in the meantime.