There is a bug report for Counterfeit Monkey about the item with the printed name “ten” (internal name ten-object): the command PUT TEN IN BUCKET will be understood as “put ten random carried objects in the bucket”, rather than the desired “put the ten-object in the in bucket”.
This only happens if the player is actually carrying at least ten things. The ten-object will always end up as the first item in the multiple object list.
It is fairly straightforward to hack around this in this particular case: we can check in a multiple action processing rule whether the first entry of the multiple object list is the ten-object, and whether the number of entries is exactly ten, and if so, redirect the action.
However, it is a bit ugly, and there is a non-zero chance the player has actually specified ten objects (“PUT TEN AND WEIGHT AND STICK AND BALL AND CAT AND ROCK AND TROLL AND GEM AND TIN AND CAN IN BUCKET”.)
Does anyone know of any other, perhaps more general, way to avoid TEN being understood as “ten random carried objects”?
Honestly, I’m amused at your list of ten more or less improbable objects in bucket example. I can say that perhaps the non-zero chance is more precisely epislon (mathematical sense) ?
Is that the normal Inform behaviour? I don’t know as I rarely use multiple object commands with any precision. I’m just all like GET ALL, DROP ALL, WEAR ALL, GET ALL FROM… etc.
Yes. It’s rarely a problem, because it only applies to verbs with multiples. (So PUSH TWO works fine in an elevator with numbered buttons.) And not always then, either.
I don’t know a tidy way to avoid the problem when it is a problem.
I had this problem in Never Gives Up Her Dead where you’re in the crown of the Statue of Liberty and need to put coins into a telescope but they all have names like ‘twenty-cent coin’ and people would type ‘put 20 in slot’ and cause a lot of shenanigans.
I ended up using a special rule for just that object and just that room:
Rule for deciding whether all includes physical things enclosed by crown-room while inserting (this is the fix that dumb slot rule):
if the second noun is the crown-slot:
it does not;
(It turns out that ‘put ten in slot’ triggers the ‘whether all includes’ code).
(The ‘physical’ stuff is from an extension that lets you carry concepts).
I don’t personally see much value in numbers being parsed as multiple random things, so I’m fine with sacrificing it, as long as it doesn’t interfere with anything else, needless to say.
I believe the culprit is this block of code in the Descriptors routine, which handles modifiers like “a” or “some” or “two”. (Or, for weird historical reasons, “lit”.)
if (allow_plurals) {
if (NextWordStopped() ~= -1 or THEN1__WD) { wn--; n = TryNumber(wn-1); } else { n=0; wn--; }
if (n == 1) { indef_mode = 1; flag = 1; }
if (n > 1) {
indef_guess_p = 1;
indef_mode = 1; flag = 1; indef_wanted = n;
indef_nspec_at = wn-1;
indef_type = indef_type | PLURAL_BIT;
}
}
In other words, if we’re currently parsing for a [things] token, and the next word isn’t “then”, check to see if it’s a number. If it is (that is, n is not zero):
If it’s 1, set indef_mode, which means the parser should grab an arbitrary object instead of asking the player to disambiguate.
If it’s more than 1, set indef_mode, and additionally set indef_wanted, which specifies how many objects the player wants.
The point of this is to save the player from disambiguation hell involving identical objects. But nowadays, I don’t think most users even know that TAKE A CANDLE instead of TAKE THE CANDLE will bypass disambiguation.
So if you’re fine sacrificing this feature (which I certainly would be!), you can replace Descriptors and dummy out this whole block by changing it to if (0 && allow_plurals).
The big thing to test is to make sure it didn’t break actually indistinguishable objects—that is, if you make multiple copies of the same thing through letter-manipulation, can you still TAKE TWO CARP?
But I think that should be okay with this modification.
Actually, that seems to be broken. What a pity! Apparently this is not covered by the automated tests. (This is a situation that rarely comes up in the game, despite the large number of indistinguishable objects.)
When carrying two cans of oil:
>drop 1 oil
(I only understood the first part of that — trying anyway. Retrying that as "drop 1".)
I don't know what you think you're talking about, because we can't see any such thing here
