This was going to be a coding question, but now I’m thinking it might be more of a design question.
The parser automatically assumes the player means examining a held object. Is this ideal? To me, it seemed at first that the parser should instead assume the player means examining an unexamined object (which I think would be easy to set up, using an after rule to give examined things a property and then making the player less likely to mean things with that property). But after a bit more thought, I’m not sure that’s right either. Now maybe I think that it would be best if the parser make no guesses at all about disambiguation of the examine command. (Which is something I can’t quite see how to set up.) Has anyone else – players, designers – thought about this? Which behavior of examine seems best to you?
Here’s a bit of code which illustrates:
[code]“Books” by Z.
Attic is a room.
A red book is in Attic. The description is “It’s red.”
Loft is north of Attic.
A green book is in Loft. The description is “It’s green.”
test me with “x book / take book / north / x book”[/code]
As is, the second “x book” assumes the player means the (carried) red book. It could instead assume the (unexamined) green book. Or it could make no guess. I’m not sure which is best, though I’m leaning towards no guess.
No, the current behavior is not ideal. It’s an old approximation (dating from I5/I6 days) which has been updated but never redesigned from scratch. It makes sense for PUT and DROP actions. Also for any action that requires a held object (WEAR, perhaps READ for books, etc.) But that last bit has gotten less important as implicit TAKE has become standard.
I like the idea of disambiguating towards “more natural” choices – examining the unexamined, opening closed things, putting/dropping held things. (Note that this is not the same as rejecting “OPEN SWORD” as a parse error just because the sword isn’t a closed container! We’re just talking about disambiguation.)
(Then there’s preposition-based disambiguation, i.e. “EXAMINE BOOK ON SHELF”. I7 doesn’t do that at all, except for “REMOVE BOOK FROM SHELF”, which is a special grammar case and runs into the aforementioned parse-error problem anyhow.)
I like the does-the-player-mean model, because you can express all of these biases in nice independent rules. I know people have said they have trouble with it, but I don’t know the details.
The main trouble I’ve had with does-the-player-mean rules is I have a lot of trouble getting them to do what I want. Here’s some rules I had in 6G60 (this is spoily for Faithful Companion):
[spoiler][code]Does the player mean doing something to the granite door in the Reliquary: It is likely.
Does the player mean locking the granite door with the iron key: it is very unlikely.
Does the player mean closing the marble door: it is very likely.
Does the player mean locking the marble door with something: it is very likely.[/code][/spoiler]
And this was the result:
[spoiler]
[quote]
lock door
(the granite door with the iron key)
That doesn’t seem to be something you can lock.[/spoiler]
I think the problem here is that the first DTPM rule counts as more specific because it has an “in [room]” clause. Nevertheless, I’d have figured that that rule would assign [object 1] as “likely,” the fourth rule would’ve assigned [object 2] as “very likely,” and object 2 would’ve won. Apparently not.
Another issue (I think) is that DTPM only works if there’s a unique best result. If you have two closed chests and nine open chests, and you have a DTPM rule that assigns “unlikely” to opening a thing that’s already open, after DTPM fails to choose a unique closed chest I think the disambiguation rules will list all eleven chests as alternatives. That’s not really germane to the current issue though (it’s more to do with disambiguation, which I’ve already complained about elsewhere).
In general the way that DTPM works internally seems very obscure and not as easy to customize as we might want. I usually wind up using Disambiguation Control.
Thanks – I made a few DTPM rules which alleviate the particular problem in my case, but I think I don’t need to go the Disambiguation Control route. This problem only happens at all if the player goes around using the vague noun instead of the adjective, and even then only in certain cases. So it’s not really a big enough deal to justify anything major, I think – sometimes I seem to get fixated on perfecting small, odd, slightly non-ideal interactions that are unlikely to come ever actually come up.