I think this is the last serious non-performance related issue in Counterfeit Monkey.
Basically it very often selects option 2 when you type 1 at a numbered disambiguation prompt. I’m having a hard time investigating this or coming up with ways around it.
Here is a test build in case you don’t want to compile your own. Just TEST SOUVENIRS after the intro.
Here is a test case. Note that the numbers are correctly understood after the disambiguation. It is only during the actual parsing phase that it gets them wrong.
EDIT: It has to do with the postcards being on the wire racks. If I change it to “Some postcards are in Cathedral Gift Shop” it works as intended.
[code]“NDC Test Case”
Include Numbered Disambiguation Choices by Aaron Reed.
The Cathedral Gift Shop is a room. Understand “narthex” as the cathedral gift shop. The description is “This area used to be a sort of antechamber where the priests and choir might gather for processions into the church, but it has now been done over for retail purposes. This is one of several schemes to make the New Church pay for its own upkeep: a problem is that people somehow feel everything associated with a church ought to be free, including lunchtime concerts, potluck suppers, and Thursday-night lecture series.”
The gift-shop counter is a scenery supporter in the Cathedral Gift Shop. The description is “The usual arrangement for making purchases.”
Some wire racks are scenery things in the Cathedral Gift Shop. The description is “They’re designed to hold postcards or other similar small merchandise.” Understand “rack” as racks.
Some postcards are on the wire racks. The description of the postcards is “You may be a tourist in these parts, but I, my curious friend, am not: so I find these pictures all rather foolish, and not at all representative of the town as it really is.” The postcards are scenery. Understand “pictures” or “harbor” or “city walls” or “walls” or “fortifications” or “ancient fortifications” or “cards” or “harbour” or “postcard” or “picture” or “architecture” or “souvenirs” as the postcards.
Some paper models, some souvenir tea towels, and some shot glasses are scenery in the Cathedral Gift Shop. Understand “model” or “souvenirs” or “paper” or “models” as the paper models. Understand “towel” or “souvenirs” or “towels” or “tea” as the tea towels. Understand “glass” or “souvenirs” as the shot glasses.
The description of the paper models is “With four or five hours labor, and a quantity of white glue and toothpicks, you too could assemble your very own rendition of the church, complete with windows and a printed-on version of the inscription over the altar; in fact, the model is so cleverly made that it can be taken apart to allow a view in cross-section.”
The description of the souvenir tea towels is “Embroidered with gaudy logos.”
The description of the shot glasses is “Printed with various Biblical verses related to drinking.”
Test me with “examine souvenirs / 2 / examine souvenirs / 1 / examine 1 / examine 2”[/code]
I think the underlying issue here (and I think this has come up with NDC before) is that the command gets reparsed as “x 1 souvenirs,” and that “1 souvenirs” is a valid way of referring to anything that matches “souvenirs”–because there’s only one of it. Then Inform disprefers referring to something that’s on a supporter to something that’s just in a location–this is annoyingly difficult to override–so when it parses “x 1 souvenirs” it bumps the postcards down the match list. Why it automatically picks the tea towels I don’t know; I think this is probably a behavior that happens specifically when disambiguating, which is why “examine 1” works as intended.
In fact, here’s something interesting: comment out the inclusion of Numbered Disambiguation Choices, and “x souvenirs/1” will still settle on the paper models. Basically, I think the parsing of “1” generally doesn’t go through the NDC mechanism, because “1” can be understood as anything; but because disambiguation in that sort of situation automatically settles on the first thing in the match list, which is usually the thing that got labeled “1,” it works out. But when the first thing on the match list gets dispreferred because it’s on a supporter, we get this stuff.
As of right now, I’m not sure how to fix this. I tried a Does The Player Mean rule:
Does the player mean doing something with a thing (called the first choice) when the player's command matches "1":
if the disambiguation id of the first choice is 1, it is very likely;
if the disambiguation id of the first choice is not 1, it is very unlikely.and it stood there like a gawm, gaping at me uselessly, which is the usual behavior of DTPM rules in my experience. [EDIT: But this time it is because I messed up, see two posts below.]
I also tried editing the number 1 in the command to a different number:
After reading a command when the number of entries in list of disambiguables > 0 (this is the convert 1 to -1 rule):
let disam-cmd be the player's command;
if disam-cmd matches the regular expression "\b1\b":
replace the matched text with "-1";
change the text of the player's command to disam-cmd.
Understand "-1" as 1 when the number of entries in list of disambiguables > 0.and it produced “*** Run-time problem P40: Attempt to splice a snippet value which is currently invalid: words 0 to -1,” and also still picked the models instead of the postcards. It’s not the number -1 that’s the problem, because I had the same issue when I used 86.
I’ve sometimes thought that it might work better to use letters rather than numbers, but “a” would probably have exactly the same problem that “1” does.
Whoa! Stop presses! This DTPM rule worked!
Definition: a thing is primed if the disambiguation id of it is 1 and the number of entries in the list of disambiguables > 0.
Does the player mean doing something with a primed thing: it is very likely.This might cause some problems if you have something like this:
A red 2 balloon is in the Gift Shop. A red 2 light is in the Gift Shop.when “x red/2” will produce the red 2 balloon rather than the red 2 light, but don’t do stuff like that.
Anyway, the moral IMO is that there is some very fiddly stuff hard-coded in the parser, especially about disambiguation.
Woohoo! Impressive work as usual.
I wonder how difficult it would be to hack the i6 code to simply decide on the object corresponding to the number the player typed rather than parse for it all over again. Though I suspect the answer is: hard, or somebody would have done it already. Or is it that nobody has tried because NDC usually works well enough?
Well, it’s not something that I could do myself, but I don’t know any I6. Part of the reason not to do that might be that Aaron wanted to accept answers like “2) the paper models” (there’s a rule to edit out the parenthesis), which is a lot easier to do if you work through the parser rather than try to go straight to the disambiguation answer.
Also I realized that the failure of the first DTPM rule was my fault; I checked whether the command “matches” 1 rather than whether it “includes” 1. So this seems to work properly:
Does the player mean doing something with a thing (called the first choice) when the player's command includes "1":
if the disambiguation id of the first choice is 1, it is very likely.
(Well, I feel this is not entirely my fault, because “matches” when applied to snippets means “exactly matches,” and “matches” when applied to texts means “includes,” and that’s confusing. But it’s not the Does The Player Mean rule’s fault.)
And thanks!
Somewhat amusingly, I can fix the PURLOIN BROCK bug in the Github bug report by adding a rule like this:
Does the player mean doing something with a thing (called the second choice) when the player's command includes "2":
if the disambiguation id of the second choice is 2, it is very likely.
I wonder how many of these I should make.
You could try this:
Does the player mean doing something with a thing (called the numbered choice) when the player's command includes "[number]":
if the disambiguation id of the numbered choice is the number understood, it is very likely.
…though PURLOIN isn’t going to be in the release version anyway.
The difficulty being…
It doesn’t discriminate as to which part of the command the number is in. (On the other hand, this is an edge case that I doubt ever arises in CM.)
There is a filing cabinet where you can look up years, and then there is the ten-object, but they are unlikely to cause trouble in practice.
More likely to cause problems is the fact that “Does the player mean doing something with a thing” won’t work for the second noun, unless I’ve misunderstood something. So I came up with this:
Does the player mean doing something when the player's command includes "[number]":
if the noun is not nothing and the disambiguation id of the noun is the number understood:
it is very likely;
if the second noun is not nothing and the disambiguation id of the second noun is the number understood:
it is very likely.
I’m not getting a problem with your example, Draconis… well, I’m not getting the problem I expect.
"NDC TV Test Case"
Include Numbered Disambiguation Choices by Aaron Reed.
The Cathedral Gift Shop is a room.
Does the player mean doing something with a thing (called the numbered choice) when the player's command includes "[number]":
if the disambiguation id of the numbered choice is the number understood, it is very likely.
A television set is in the Gift Shop. A television camera is in the Gift shop.
Instead of setting the television set to something:
say "You set the set to [the topic understood]."but:
Since the disambiguation IDs don’t reset until NDC is sure that you’re done disambiguating, you get something weird here.
That’s perhaps an even edgier case, though. We could take care of it perhaps by resetting the disambiguation IDs in an Every Turn rule as soon as a successful parsing occurs, as in the NDC documentation (though Aaron said testers would try to keep typing numbers for things after getting the disambiguation question, which is why this isn’t default behavior).
[Requoting because of page jump]
Though even if this isn’t causing a problem right here, it reminds me that one of my wish lists is a parser that lets the code figure out the actual worlds in the command that are being used to pick out an object. IIRC this is pretty much impossible for the Inform maintainers to do in the language as it is.
An excellent idea! Though I’m seeing two separate use cases:
For now I’m focusing on the former, with the latter suffering in that edge case. If this is unacceptable I can expose them both as separate variables.
Hello Numbered Disambig. investigators. I just bumped into the ‘you type 1 and you get choice 2’ bug myself in my WIP today, and found this topic. And I wondered if you had settled on the best way to fix it. Btw, I am already using the modified version of NDC, touted locally (which accepts room, and uses ‘disvalues’ etc.). Thanks.
-Wade
This never seems to happen anymore in Counterfeit Monkey, and I think it is because of this rule (adapted from Matt’s reply above):
Does the player mean doing something when the player's command includes "[number]":
let N be the corresponding disvalue of the number understood;
if the noun is not nothing and the disambiguation id of the noun is N:
it is very likely;
otherwise if the second noun is not nothing and the disambiguation id of the second noun is N:
it is very likely;
I’m pretty sure that there is a good reason why the above code was not included in the new modified Numbered Disambiguation Choices extension, but I can’t recall it at the moment.
EDIT: Oops, I now see that it is included. I was looking at the actual Counterfeit Monkey version, where it is not. Sorry about that. It was a while ago since I wrote it.
So your problem must be caused by something else, possibly another Does the player mean rule that takes precedence. Note that I had to write a special Does the player mean rule for quips. Perhaps something like that could fix your problem?
Thanks a lot for the info. It will help me investigate.
-Wade
I think, when I first began investigating problems with the extension, I was recommended to use the Counterfeit Monkey version. So I’d already taken that and adapted it a bit for my WIP before I became aware of the newer generalised version. Therefore, my WIP was missing the DTPM bit, and having just added it, it does the trick.
-Wade
Glad to hear you worked it out!
Sorry about the confusion. I really should put some kind of warnings in those CM extensions that no longer work as standalone, with links to the standalone versions.