Did either of you guys test that? (I can’t, right now.) I don’t see why it wouldn’t work, given that the object is literally named “your eyes”. I suppose it’s possible, but that’d be a serious curve ball from Inform. Anyway, have you made sure that the player actually has eyes? I seem to recall there being several Inform bugs/quirks that could cause a body part that’s supposed to be part of all people to be missing from the player (the foremost being that, IIRC, by default the player is a male person, but not actually either a man or a woman).
I do know that the way the parser treats “my” is kind of weird – it’s basically taken as a hint that the player wants to refer to something they carry, wear or incorporate, but if there’s nothing matching that, Inform will just ignore it. I believe this is ostensibly so that the player could keep referring to, say, “my key” even after dropping the key or giving it to someone else, although I’ve never really found that justification entirely convincing.
Anyway, if Inform really doesn’t understand “your” as referring to the player’s body parts by default, you could always use the example rule from Chapter 16.17. “Context: understanding when” to make it do so. (Offhand, I’m not sure if you’d need to replace “held by” with “part of”, or if the rule will actually work as is.)
Yeah, the player has eyes. “Examine my eye” works, but “Examine your eye” doesn’t though… I think I understand what Felix is saying is that the name of an object having the word “your” in it is interfering with the normal use of the word “your”… so when the word “your” is found, it looks for the next word. If, for example, I have a thing simply called “eyes” “your eye” would find it, but because I have a thing called “your eyes”, the only way to reference it would be “your your eye”, but that doesn’t work either for the same reason that a single your doesn’t.
In short, an object named with multiple words where one of those words may be another thing or have some other meaning to the parser is a bad idea. I guess this is one of the reasons why auto-generating assemblies is a sticky business.
I can get it to work by “Understand “your eye” as your eyes”, but it virtually defeats the purpose of making an auto-generated assembly if I have to run around qualifying every item like that. Oh well.
No, that’s not it. If you create an object simply called “eyes” or “grue” or whatever, the player can’t refer to it as “your eyes” or “your grue”.
The point is that there is a standard presupposition behind interactive fiction to the effect that the actual player is identified with the player character: so the player’s commands isn’t the actual player issuing commands to the PC; it’s the PC issuing commands to himself/herself (or vocalizing his/her own conations or decisions to act in certain way or whatever). The actual player is supposed to identify with the PC as in a game of make-believe: therefore the PC is “I” and “me” to the actual player (just as if the player was acting his/her character in a good old fashioned role-playing game) but “you” to the game parser (who acts the part of the Dungeon Master).
Indeed, even if you create an object called “your wedding ring” that is the only wedding ring in the game and which is not part of the PC, the actual player would have to refer to it as “my wedding ring” in input.
This is a very special case, and I couldn’t find any code in the I6 templates to explain this behaviour of “your” and “my”: it might certainly be there anyway, but it might also be coded into Inform on an even more basic level than the I6 templates (as the generation of names of assembly parts are).
In most cases, it’s not so bad; but the situation can give rise to nasty disambiguation problems. E.g. if you have one object simply called “key” and another called “silver key” and both are lying in the same room, there may easily be no way for the player to interact with the one simply called “key”.
Wow, that is weird. I’d never realized that before, but I finally managed to test it, and it indeed seems like the Inform compiler simply ignores the word “your” (for purposes of understanding) if it appears as the first word in the name of a thing. For example:
The Testing Chamber is a room.
Your hat is in the testing chamber. It is wearable.
The player wears someone else's hat.
The player carries the keys to your house.
Test me with "x hat / x your / x your hat / x my hat / x this hat / x that hat".
(The behavior of “my”, “this” and “that” is specified in Parser.i6t, though; they’re all parsed as “descriptors”, which are used to weigh the parser’s choice towards or away from certain objects, as the example above also demonstrates. The table of actual descriptor words is found in Language.i6t.)