Suppose we have four keys: “key”, “iron key”, ruby key", and “gold key”. Now the player types TAKE KEY. The parser will then ask which is meant:
Which do you mean, the key, the iron key, the ruby key, or the gold key?
If the player types KEY, then this causes the question to be asked again. Ordinarily I’d say that the author should avoid naming things like this, but I just want to solve this and be done with it. I can get the short_name of the object being considered into an array. From there I can address each individual character. I can also print the word or words that the player typed when trying to take an object. In this example, print (address) x; will resulting in key being printed. However, and this is my big sticking point, I cannot figure out how to address the individual characters in x. If I can accomplish this, then I can compare these two strings and have the parser pick the “key” if the player says TAKE KEY rather than return an irritating disambiguation question like above.
Speaking as the one who maintains the Standard Library, I should know how to do this, but I don’t.
When I played through the early MDL Zorks I encountered a nasty bug. (it’s important to know that once a treasure is deposited in the trophy case, it’s not possible to retrive it.)
In the early, 285 point, version there is a treasure called “diamond trident”. When the game was expanded to 387 points, the coal mine area was added with a new “diamond” treasure. The “diamond trident” was renamed to the “crystal trident”, but still had the synonym “diamond” associated with it. The “diamond” had no adjectives or synonyms.
So if you deposit the “crystal trident” in the trophy case first it is impossible to deposit the “diamond” thereafter.
There is also all the cakes of different colors and the “Eat Me” cake. The “Eat Me” cake has the adjective “eatme” associated with it, which isn’t entirely obvious… I saw one walkthrough that used the sack to hide all the colored cakes to be able to type “eat cake” without disambiguaty.
You return “2” as if it was a score here, which it is not. This may still work for some cases, depending on the implementation details of the parser, but you shouldn’t depend on it. And it most definitely won’t work for commands where the key doesn’t come last in the sentence, like “put key in sack”.
As for a solution that the library can supply, I can’t see a clean way to do it. With some objects having a name property and some a parse_name routine, the library can’t know if a certain match is perfect or not, unless you extend the protocol for parse_name so that it can also set a global to signal how good the match is.
The object name is just as messy. It may be the object name string, or a short_name routine which may use any conditions it likes to print the object name. There may also be adjectives mentioned in the description which are not in the object name but can help to describe the object more precisely. So the short name of the ruby key may be “red key” but the description says it has a large ruby on it, and “ruby key” or “red key” should be considered a perfect match, but there’s no way for the library to know that.
Another option would be to number the options, so the parser asks “Which do you mean, (1) the key, (2) the iron key or (3) the ruby key?” and the player can type either an adjective or a number to answer the question. But maybe this breaks mimesis.
Of course, the game author could also write a ChooseObjects routine to help the parser out here.
Federick: IMVHO Numbering the options should be confined to talking to NPC… (yes, I like the RPG method here…)
On the disambiguation, the best handling of the infinite loop should be having the noun as default adjective (I’m not sure of having explained well… the featureless (that is, no adjective) noun should be considered the default when there’s more keys in scope); of course, only one key must be “featureless”, because well, the “you mean the key, the key, the key ?” infinite loop is always lurking like a grue, ready to jump on the unwary Imp…
Hope to have explained well my opinion on disambiguation, and
Best regards from Italy,
What I want to do here is accomplish a very narrow task of comparing the single-word noun supplied by the player with the short names of possible matches before the parser decides whether or not to ask a disambiguation question. I can access the individual letters in the player-supplied noun. My core consternation is how to access the individual letters of a string that’s printed with print (address) foo;. Doing this with a parse_name routine isn’t what I have in mind, since I want the Library to behave like this for all objects. So far, @auraes’s PrintDictWord() looks like it might be the solution. More testing…
Sounds to me like you don’t really need to handle dictionary words at all here. You want to compare a word that the player has typed (which is stored with one ZSCII character per byte in an array) to the short name of the object (which you can print with one ZSCII character per byte to an array). No dictionary words involved.
This tries to match an object p_obj to input word number p_word_no. Only tested for Z-code. It prints the length of the word typed and the short name. If they are different, it returns. Then it compares them character by character, but only up to a maximum of nine characters, since the player may have skipped typing the last part of a word longer than the dictionary resolution. And it prints every character that matches, until it finds a character that doesn’t match.
That’s what I do. It’s pretty simple, but it’s not general purpose. Essentially, what you’re trying to do is come up with the best match, rather than any match. Let’s look at the following three scenarios:
Scenario 1: Only the key is in scope. If you enter ‘key’, then that’s a 100% match, so the key is a match.
Scenario 2: Only the iron key is in scope. If you enter ‘key’, then that’s a 50% match, but there is no other key in scope, so the iron key is a match.
Scenario 3: The key and the iron key are in scope. If you enter ‘key’, then that’s a 100% match on the key and a 50% match on the iron key, so the key is the best match.
I can’t see why you need to start looking at individual characters. You only need to do a match on the number of unique words in the input that are matched against the name list vs the number of words in the name list. Or am I being naive?
The problem with that approach is that the name list can be large and the player doesn’t necessarily see it. That is, the author could wind up giving different keys synonyms like “rusty”, “corroded”, “cold”, “heavy”, “elaborate”, “long”. It would be surprising if this changed the parsing of “get key”. Especially since you often wind up adding synonyms late in development (after playtesting).
I think there’s a confusion here between the name list (which can be large and contain long-shot synonyms) and the printed name (which is presented directly to the player). There’s an argument for taking both into account, but the Inform parser has never done it because it’s so much extra work.
Historically, the parser does check whether two objects have exactly the same name list. That usually means the author has a class (“gold coins”) with a bunch of objects which are meant to be indistinguishable. In that case, they probably also have the same printed name – the parser doesn’t check that but it’s a pretty safe assumption.