Don't ask which do you mean when all names are the same

How can I prevent the following:

The kitchen is a room.

The player is in the kitchen.

Understand the printed name property as describing a thing.

apple1 is in the kitchen. the printed name of apple1 is "red apple".

apple2 is in the kitchen. the printed name of apple2 is "red apple".

Result:

kitchen
You can see red apple and red apple here.

>take red apple
Which do you mean, red apple or red apple?

>

In this use case, where all options fed into the asking which do you mean list have identical printed names, I would like it to not ask which do you mean, and instead select the first item in the list. How would one go about that?

You could try this:

[code]Include Disambiguation Control Fix by Jon Ingold.

The kitchen is a room.

The player is in the kitchen.

Understand the printed name property as describing a thing.

An apple is a kind of thing. Understand “apple” as an apple.

apple1 is an apple in the kitchen. the printed name of apple1 is “red apple”.

apple2 is an apple in the kitchen. the printed name of apple2 is “red apple”.

apple3 is an apple in the kitchen. the printed name of apple3 is “green apple”.

To decide if the match list is homographic:
repeat with the item running through the match list:
unless the printed name of the item exactly matches the text printed name of entry 1 of the match list, no;
yes.

Should the game choose doing something with entry 1 of the match list when the match list is homographic: it is an excellent choice.

Test me with “take apple/take red apple”.[/code]

(“Disambiguation Control Fix” is the name of the 6L02-compatible version of Disambiguation Control I have on my computer. If you’ve got a properly-named 6L02 Disambiguation Control, try that.)

I spent a lot of time trial-and-erroring this before I remembered that string comparison usually needs “exactly matches” rather than “is,” so there may be simpler ways to do this. You might even be able to do this with the built-in disambiguation rather than Disambiguation Control (EDIT: except the match list isn’t exposed in I7 if you don’t include Disambiguation Control, so never mind).

Thank you! This works perfectly.

Also, general thank you rant below:
[rant]I know I’ve asked some pretty detailed and annoying questions in the past, but that’s just because I’m so much more used to working in Javascript, which is an interpreted language, and only work in C# in more formulaic ways that support what I’m doing on the front-end… I get frustrated with strongly typed languages and struggle greatly because it is hard to pass data from one object to another in a fluid way or to simulate/fake objects (at least I find it hard) like you can with interpreted languages. In any case, what I’m trying to say is, even though I’ve probably been annoying at times, this forum has always been very helpful. This response is only one example of a question not only being answered, but the code directly provided that works right out of the box.

For example, matt w here not only answered this question, but actually provided Disambiguation Control Fix which I’m already using in another topic. Not that matt w is the only one answering questions… there are lots of helpful folks here, and thanks again to all. This forum is as or more helpful than any other I’ve ever posted in.

Thanks again, I would never have figured this or many other things out, and given up on IF coding by now without this forum.[/rant]

What you should have done with this is define apples as a kind, or red apples as a kind.

Won’t work for his use case – he’s working on a system where you have a bunch of props off-stage that you cycle back on-stage with different dynamically generated printed names to simulate many more things. So the two things whose printed names are both “red apple” this time won’t necessarily both be red apples another time, and the kind hierarchy won’t work.

Perhaps then make them privately-named and define appropriate plurals.

(They weren’t combining initially because they could be distinguished by the “apple1” and “apple2” names.)

Well, he can try it in his own code; but that’s relying on the way Inform handles anonymous instances of a kind to solve the problem, and the way Inform handles anonymous instances of a kind can cause lots of other problems in cases where you do need to distinguish them somehow.

I don’t know, maybe “understand the printed name property as describing a thing” would do the trick now in cases in which the printed names are different, since understanding a property is enough to allow disambiguation between anonymous instances when they differ between the respective property. (This doesn’t work for understanding related objects, unfortunately.) Looking through the archives I see that we started talking about this back in the 6G60 days when you had to jump through a lot of hoops to simulate understanding the printed name of a thing. Right now this works a charm:

[code]The kitchen is a room.

The player is in the kitchen.

Understand the printed name property as describing a thing.

A prop is a kind of thing. The printed name of a prop is usually “apple”. The printed plural name of a prop is usually “[printed name of the item described]s”.
Understand “thing” as a prop.
When play begins:
let orange be a random prop;
now the printed name of orange is “orange”.

Three props are in the kitchen.

Test me with “take apple/drop it/take thing/apple”.[/code]