Looking at yourself

Well, that solves it for the conditional issue! Thanks! I can see how I’m not the only one who wouldn’t know intuitively that “the noun” would reference back to the noun in the before premise, or that “a” and “the” are so interchangeable. That explains a lot of things.

As for redefining a human, I wasn’t so much trying to redefine a human as to bring humans and non-humans under the same umbrella in some cases. I wanted a human and a fish to share in having eyes, without having to separately declare each as having eyes. So, I made them both “beings”. In the standard rules, is there a kind that includes both persons, humans, and animals? Is a fish already a kind of animal in the standard rules? Actually, what I really need to understand is the standard rules. This may seem like a dumb question, but as you may have already guessed, I’m not good at reading documentation, only at learning by doing, so I must have missed where I can learn all about the standard rules. Instead of telling me the answers to these questions directly, can someone outline the best way I can go about researching something specific like this in the standard rules on my own?

I also am still having the problem where trying to examine the hands or eyes of the characters is resulting in a prompt to examine the hands or eyes. The game never understands that a hand is a hand, it thinks a hand might be a hand or an eye, and vice versa. Still stumped here.

I also still can’t seem to figure out how to not have Hook Hand Man have a right hand or Eye Patch Man not to have an left eye. I want them to be humans, which have these things, but to have these specific humans not have them. I’d like to avoid having to create a special kind for each of these conditions, and instead benefit from the “normally” used to give them these things in the first place to be able to remove them. The game seems to not want to remove them at the start of play, however.

The I7 kind “person” is intended to be used for any animate being, which is why animals are a subkind of person. If you wanted to simply things, I’d replace “Section SR1/12 - Animals, men and women” of the Standard Rules to add in an extra subkind called human between person and man/woman.

The best place to learn about the standard rules is to simply read them. You can open them like any other extension.

Thank you. I thought that was a compiled part of the program that was invisible. That is very helpful.

I have made some (possible) progress on my own on the issue of hands being referred to as eyes and vice versa, but there are some gotchas still.

If I set the understands about hands in the code like this:

Understand "hands" as hands. Understand "examining [someone]'s pair of hands" as pair of hands. Understand "examining [someone]'s left hand" as left hand. Understand "examining [someone]'s right hand" as right hand.

This makes it possible to examine a specific person’s hands instead of their eyes. There are several things that confuse me about this. First (and again) why should I have to do this at all? This seems like it should already be the case. The above seems redundant to what I’d expect the logic of the system to already do. The above seems like it could just be simply: Understand “[someone]'s [something]” as someone’s something… but where the two outside the quotes are also variables. This just seems very odd, as it seems this should already be happening.

Second, if I do need to define this, I don’t understand why the player isn’t a “someone”. If I try “look at your pair of hands” with the above code, it asks which character’s hands I mean… ? I have to explicitly add back in code like Understand “examining your pair of hands” as your hands. Is there a way to include yourself in [someone]'s so as to not be repetitive?

Finally, and perhaps most importantly, if I do the following, the game crashes. I don’t want to just have this understanding when “examining”… I want these nouns to be understood no matter what command is given. I don’t want to have to separately define the understanding when examining, pushing, taking, etc. I just want the noun itself to be understood in the context of its owner…

Understand "hands" as hands. Understand "[someone]'s pair of hands" as pair of hands. Understand "[someone]'s left hand" as left hand. Understand "[someone]'s right hand" as right hand.

I think at least one of the above problems has something to do with the terms “right” and “left”…

If I change things so that instead of:

A left eye is a kind of thing. 
A left hand is a kind of thing.

I have this:

A lefteye is a kind of thing. Understand "left eye" as lefteye.
A lefthand is a kind of thing. Understand "left hand" as lefthand.

I can now get results in checking each individual item when it is part of one of the characters. However, this makes the item actually named “lefteye” or “lefthand” as in “You see nothing special about Eye Patch Man’s lefthand.” This is unfortunate, because I would want it to say “You see nothing special about Eye Patch Man’s left hand.” with the space. I tried looking in the standard rules, but couldn’t make out any reason why the term “left” or “right” would interfere with the declaration of a noun. Can nouns not be composed of multiple words separated by a space?

Inform understands all and any word in the name of a particular object as that particular object. But it doesn’t automatically understand the name of a kind as particular objects of that kind.

So if you have A finger is a kind of thing. A thumb is a kind of finger. A pinky is a kind of finger. A thumb is part of every person. A pinky is part of every person.the game will understand X PINKY, because there is a particular object called “your pinky” in the game (the line “A pinky is part of every person”, automatically creates a pinky called “your pinky” as part of the object called “yourself”, which is the default player), but it won’t understand X FINGER, since there is no particular object with the word “finger” in its name.

To make the game understand the word “finger” in a command as the name of any particular object of the finger kind, you need to explicitly tell it to.A finger is a kind of thing. A thumb is a kind of finger. A pinky is a kind of finger. A thumb is part of every person. A pinky is part of every person. Understand "finger" as a finger.
In contrast this will work as expectedA hand is a kind of thing. A right hand is a kind of hand. A left hand is a kind of hand. A right hand is part of every person. A left hand is part of every person.since the names of both objects of the hand kind (they are automatically called “your right hand” and “your left hand” respectively) contains the word “hand”.

Also, use the singular when you create kinds. Inform will then automatically understand the plural when used in source code, which lets you write code like: Instead of examining a finger that is part of the player when exactly two fingers are part of the player: say "Both your fingers are in perfect working order."

You can indeed use spaces in names, but if distinct objects have names that contain the same words, that word will be ambiguous between the objects. The game can’t automatically guess whether the word “left” is the name of “your left hand”, of “your left eye”, or of “left hand path”.

In addition to what Felix wrote, I’d suggest not getting too carried away with assemblages if you can avoid it. Inform’s support for them is rather limited, and they work best when kept simple. Does your game really require the ability to refer to any random person’s left foot? (Off the top of my head, I can think of only two kinds of games that might: “adult” ones, or possibly a really detailed personal combat simulation.) If not, I’d suggest just ignoring them.

If you do want to go with assemblages, I’d suggest keeping things as simple as possible: just declare a kind for each body part you want to refer to, and attach it to all sub-kinds of “person” (which, as Felix notes, is really Inform’s base kind for any animate beings) they should apply to. In particular, I’d avoid using sub-assemblages (“A nose is part of every face.”) – they do work, but produce silly printed names for the parts (“Joe’s face’s nose”). You could (probably) work around that, but it wouldn’t be a trivial exercise. Instead, I’d just do it something like this:

"Lefty" by Vyznev Xnebara

The story headline is "An Interactive Test".

The Testing Chamber is a room.
Susie is a woman in the testing chamber.
Joe is a man in the testing chamber.
A dog is a kind of animal. Fido is a dog in the testing chamber.

A human is a kind of person. A man and a woman are kinds of human.
Yourself is a human.

A body part is a kind of thing.

A head, a face, a mouth and a nose are kinds of body part.
A head, a face, a mouth and a nose are part of every person.

The eyes and ears are a kind of body part.
The eyes and ears are usually plural-named.
Some eyes and ears are part of every person.

A hand is a kind of body part.
A left hand and a right hand are kinds of hand.
A left hand and a right hand are part of every human.

A foot is a kind of body part. The plural of foot is feet.
A left foot and a right foot are kinds of foot.
A left foot and a right foot are part of every human.

A paw and a tail are kinds of body part.
A left front paw, a right front paw, a left rear paw and a right rear paw are kinds of paws.
A left front paw, a right front paw, a left rear paw, a right rear paw and a tail are part of every dog.

Test me with "x foot / left / Joe's / x eyes / my / x tail".

(Note the trick for declaring a new “human” kind that groups men and women together, and also for declaring that the player belongs to this kind. Inform allows you to slide new kinds “between” existing ones like that, as long as they don’t conflict with the established kind hierarchy.)

And yeah, dealing with the possibility of specific people lacking body parts gets messy too, especially if you want to produce useful error messages if the player tries to refer to them. If you really want to do that, I’d suggest applying the trick I described in an earlier thread, where you simply mark the body part as “nonexistent” (and also matt w’s recommendation of the Disambiguation Control extension, which really makes it work a lot better).

Oh, and don’t forget that, for a real game, the real work is going to be in describing all those body parts you just created. Sure, it’s possible to automate some parts of it to some extent, but I can almost guarantee that you’re going to get tired of writing descriptions for random people’s random body parts if you go that route.

Wow, ok, so Inform is at once both very powerful and flexible in that it is actually “trying” to make sense of ambiguous information, but this also is limiting in some ways as it can be difficult to chase down all the ambiguous stuff one might create in their code. A “left eye” not being a perfectly distinct thing separate from “eye” or, as I’ve now discovered thanks to this feedback “Eye Patch Man” certainly can be tricky!

As far as what kind of game I’m trying to make, I don’t know if I’d use these assemblies for real… this is more of an exercise. I wouldn’t limit myself by saying I would never make a detailed combat game, or even a game with some AIF, hypothetically, but right now I’m not making any game in particular. The reason I’m going with hands and eyes right now, is that the only piece of this puzzle that I’m really interested in translating to a real game potentially is the effect of a true first-person perspective. I like a story where the reader/player is given the greatest opportunity to feel like the character, and see from the character’s perspective, instead of observing the player character from the “third person”. Not being able to look at your own head, but being able to look in a mirror has many interesting possibilities I think. I’m sure there are cleaner and more programmatic (in other languages one might call them loops or functions) ways of creating assemblies like these only when needed, instead of globally, but I’ll get around to optimization after I even understand non-optimized code first! :stuck_out_tongue:

In any case, I tried to disambiguate what I have in this example game, and, though I’m sure this is very non-optimized, I have it mostly working now, but I have this problem now… because Eye Patch Man has the term “Eye” in his name, and “Hook Hand Man” has the term “Hand” in it, they trigger the engine to think that the player may be talking about each the other’s hand or eye when actually referring to the opposite. So, to solve this, I changed “Eye Patch Man” to EPM, and “Hook Hand Man” to HHM… and then am trying to change the printed name. This does work except in the case of the “which do you mean” display. So, I tried to explicitly add changing the printed name during the which do you mean, but this doesn’t work. The below still results in printing stuff like “Which do you mean, EPM’s pair of hands, EPM’s left hand, or EPM’s right hand?” What am I missing here?

EPM [Eye Patch Man] is a human. EPM is in the pirate ship deck. Rule for printing the name of EPM: say "Eye Patch Man". Rule for printing the name of EPM while asking which do you mean: say "Eye Patch Man". Understand "Eye Patch Man" as EPM.

Edit: Ugh… it doesn’t work at all yet actually, I thought it did, prematurely. It works when things are ambiguous, but the player cannot use the term “Eye Patch Man”, they’d have to still know to use “EPM”… the mini-tutorial I got the idea to mask the printed name with, I’m not sure I’m understanding all the nuances here.

Part of the art of writing with Inform is understanding that similarly-named objects behave this way. In most cases, you’d avoid calling someone “eye patch man” since “man” and “eye” cause such namespace clashes with assemblages you are also creating. Outside of an exercise, you’d likely give eye patch man a more useful moniker such as “pirate” or an actual name.

The problem you’re having isn’t with “which do you mean” per se. It’s that the printed name of EPM isn’t actually part of the name (or printed name) of EPM’s left hand.

When you create an assembly with a line like “A left hand is part of every person,” Inform automatically creates a bunch of left hands for you and automatically names those left hands. The left hand that is part of Bob will be named Bob’s left hand, the left hand that is part of Alice will be named Alice’s left hand, and the left hand that is part of EPM will be named EPM’s left hand. These are the “real names” of the left hands, not just the printed names; and they refer back to the “real names” of the people rather than the printed names. (Since printed names can change in the course of play but “real names,” which are the sort of thing you can refer to in source code, aren’t allowed to change in the course of play.)

So when the game prints the name of a left hand, it just looks at the hand in question and prints its name, which is “EPM’s left hand.” It never has any reason to look at the printed name of EPM himself.

A way to solve this would be by setting the printed name of the body parts themselves. So you could say:

The printed name of a left hand is usually "[the random person incorporating the item described]'s left hand".

Unpicking that a bit: the word “the” there isn’t actually applying to “random person”; it ensures that a definite article will be printed if necessary. (If you define a person as improper-named, like “the ensign is a woman in The Bridge,” then Inform will try to print “the” where it needs to; this code will ensure that you get “the ensign’s right hand” rather than “ensign’s right hand.”)

“incorporating” is the relation that holds between a things and its parts. So a person will incorporate her left hand.

“random person” is necessary because Inform doesn’t know that every left hand is incorporated by one and only one person. So you have to ask it to pick one person, any person, that incorporates the left hand – if you don’t have conjoined twins in your game this will always pick the right person. (But if you have detached body parts this will produce errors when there isn’t anyone who incorporates the left hand! In that case you need to do something more complicated.)

And “the item described” is a locution (sort of like “the noun”) that refers to the thing we’re talking about in certain contexts. In particular, when you’re talking about the property of a thing (and “printed name” is a property), “the item described” will pick out the thing whose property it is – in this case the left hand.

The problem you have with allowing the player to refer to EPM’s left hand is similar. The hand is named “EPM’s left hand,” and your extra understand line only allows the player to refer to EPM as “Eye Patch Man”; Inform doesn’t know this transfers to EPM’s left hand. You can take care of this thus:

Understand "eye/patch/man" as EPM. Understand "eye/patch/man/man's" as a thing when EPM incorporates the item described.

The first line, with its slashes, just means that the player can use any of these individual words to refer to EPM; she won’t have to type out the whole phrase “eye patch man.”
The second line means that the player can use any of those words to refer to any of EPM’s parts. We need “man’s” as well as “man” so “Eye patch man’s left hand” gets matched! Fortunately, Inform is smart enough that it knows that we’re more likely to want to refer to EPM than EPM’s left hand, so “x eye patch man” gets redirected to EPM rather than the left hand.

Hope this helps. As you can see, you’re doing something that’s very complicated for a beginner!

Your actual problem with the “EPM” is the way Inform builds assemblages (in fact, I’d say that’s the source of most of your difficulties in this thread): when you say that every man has a left hand, and then create a man named “EPM”, then Inform automatically creates a left hand named “EPM’s left hand” and makes it a part of EPM.

In fact, the Inform 7 parser doesn’t really understand the “s” genitive! The only reason you can refer to, say, “Joe’s left hand” is that the name of that object literally includes the word “Joe’s”, apostrophe and all. In fact, out of the box, the Inform in-game parser doesn’t really understand the “of” genitive either (even though the compiler does), although it’s possible to fix that with a rule like:

Understand "of [something related by reversed incorporation]" as a body part.

We can do something similar for the “s” genitive, although that takes a bit more work since the Inform parser doesn’t normally recognize apostrophes as word delimiters, so we have to get rid of them. Fortunately, there’s a built-in extension that can do that:

Include Punctuation Removal by Emily Short.
After reading a command: remove apostrophes.
Understand "[something related by reversed incorporation] s" as a body part.

You might also want to tell Inform to understand certain words as describing kinds of people (which Inform doesn’t do by default), so that a command like, say, “examine dog’s nose” will work:

Understand "man" as a man. Understand "woman" as a woman.
Understand "human" as a human. Understand "dog" as a dog.

If you add all that code to the example I posted above, the command “examine dog’s nose” should now print “You see nothing special about Fido’s nose.”

Anyway, back to your Eye Patch Man, I think the easiest solution to the “eye” problem would be simply to change his name to “Eye-Patch Man” with a hyphen. This will cause all his body parts to be given hyphenated names too, so that “Eye-Patch Man’s left foot” won’t match the word “eye”. You can then tell the parser that the player is allowed to drop the hyphen with a statement like:

Understand "eyepatch" or "eye patch" as Eye-Patch Man.

If you use the “s” genitive parsing trick I showed above, that will then let this understanding rule apply to the eye-patch man’s body parts too.

Also, I think I figured out a simpler way to handle missing body parts – just move them off-stage at the beginning of the game with a rule like:

When play begins: remove the Hook Hand Man's right hand from play.

or more generally with:

A body part can be missing.  Hook Hand Man's right hand is missing.
When play begins: now all missing body parts are off-stage.

Anyway, here’s some almost complete test code demonstrating these things that you can append to the example code (“Lefty”) in my previous post:

A body part can be missing.
When play begins: now all missing body parts are off-stage.

Understand "human" as a human. Understand "dog" as a dog.
Understand "man" as a man. Understand "woman" as a woman.
Understand "of [something related by reversed incorporation]" as a body part.

Include Punctuation Removal by Emily Short.
After reading a command: remove apostrophes.
Understand "[something related by reversed incorporation] s" as a body part.

Eye-Patch Man is a man in the Testing Chamber.
Understand "eyepatch" or "eye patch" as Eye-Patch Man.

Eye-Patch Man's eyes are missing.
A body part called Eye-Patch Man's right eye is part of the Eye-Patch Man.
Understand "eyes" as Eye-Patch Man's right eye.
Understand "left eye", "right eye" or "eye" as eyes.

Test eyes with "x eye / x eye patch / x man's nose / eye patch / x dog's nose / x left eye / x right eye / x eyes / eye patch man's".

(Ps. Matt w posted his message above while I was writing this, so there’s some duplication. I didn’t feel like revising this post further, so I just posted it as I was originally going to. Anyway, it might be useful to compare our approaches.)

This is without a doubt one of the most, if not the most, helpful and responsive forum I have ever joined! Many places where I am a “noob” online I feel ignored or ridiculed, and wonder why I even bothered joining the community. You are all very helpful!

Again, I learned a ton from these latest posts. I have a lot to think about, not just in terms of what to do, but what not to do. There are many options to explore now.

Always wanting to learn to fish instead of just be given a fish though, my one follow up at this juncture would be how I could have figured out that the terms “random person”, “incorporation”, and “reverse incorporation” were things the game would understand without being told by you guys, without reading every piece of documentation end to end, and without being a savant? I’m sure there are things I’ll be wanting to try in the future, and I wonder if anyone has a method for translating ideas from English to Inform.

Maybe a simpler example of what I’m asking above is how to remove something globally declared from play… In truly plain English, my blind attempt at the syntax was just “Eye Patch Man does not have a left eye.” The real syntax being to “remove the noun from play” or “When [condition]: now [the noun] is off-stage.” These are fairly intuitive in a sense, but still are a specific syntax and wording, whereas human language could try to describe this in ways that are incorrect for Inform. Again, I’m just wondering if there is a good methodology short of asking this forum for help that I can learn to better deduce the correct Inform language for my plain English concepts. It will come with practice and time, but does anyone have any tips for accelerating the advancement of this skill?

What you’re trying to do is really quite obscure, so reading the whole of the manual is really the appropriate thing to do. I know you’ve said it’s just an experiment, but modeling body parts will almost always be a mistake, so although it’s unfortunate that it’s so complicated, I don’t know if I’d want it to be easy or else every new author would do it!

As you’ve already intuited, practice definitely helps. But it needs to be focused practice and study in order to accelerate learning. So these are my tips, in no particular order:

  • Choose a small project, then start coding. I’m not talking about a production game, but a modest scenario to let you apply various tools of Inform 7. The idea is to give you a context for how those tools would be employed, and for the particular “flow” that Inform 7 programs have.
  • Learn the I7 idiom. A language usually has its own way of doing things, and Inform 7 is no different. If you strive to code “into” the language rather than fight the system, you’ll see rapid improvement in terms of what you can do.
  • Read the source of various games. It’s said that the source never lies, and in a way it’s true – you’ll learn tons of things just by studying how The Reliques of Tolti-Aph or Bronze do it.
  • Read different manuals. I’ve occasionally found Writing with Inform to be puzzling and confounding, particularly when it comes to learning specific syntax. Good news is, there are other sources. See the sticky post in the Inform 7 forum for a list; I particularly recommend Inform 7 For Programmers for precisely understanding the syntax.
  • Read the forums. Many questions have been addressed already, often from several different angles. If you’re frustrated by some fine point of the language, chances are you’re not alone, and that there will be indepth (and occasionally witty) discussions on the matter.
  • Learn Inform 6. If you haven’t already, you may want to learn I6 which is the basis for I7. Today, Inform 7 is mature enough that you no longer need to drop down to I6 for the tricky stuff, but knowing what happens under the hood can give you a kind of confidence and security with the language that you might not otherwise attain.

Honestly, I’d recommend just sitting down and reading Writing with Inform from start to finish. That’s what worked for me, anyway. You don’t have to read it very carefully, but just pay enough attention that you get a vague idea of what’s possible and what isn’t. In particular, reading the summaries at the end of each chapter is highly recommended.

Once you’ve got that, Google is your friend. The Inform 7 manual itself doesn’t have a built-in search function, but just Googling for, say “inform-7 part of relation” gives this summary page as the first result.

Anyway, I did mean to include documentation links in my post, but sort of forgot. So, have some links:

Chapter 2.2. “Varying What Is Read” in The Inform Recipe Book also summarizes a lot of the stuff about parsing and understanding. In particular, it shows how to make the in-game parser understand, say, “man” as referring to any man, something which Writing with Inform seems to only mention in examples and in summary chapters (although, admittedly, it’s found several times in those).

I was also going to link to the documentation for the built-in Punctuation Removal extension by Emily Short, but it doesn’t seem to be available anywhere on the web. :frowning: However, you can find it through the built-in help system in the Inform IDE. The “after reading a command” rules are documented in Chapter 17.31. “Reading a command”, and the general text manipulation facilities of Inform 7 are found in Chapter 19, “Advanced text”.

Ps. While looking up these links, I noticed that Chapter 16.9. “Understanding kinds of value” in Writing with Inform demonstrates a different way of implementing body parts (not making them actual objects, but simply named values that custom commands can refer to), which is somewhat more limited, but could be useful in some cases.

I’m another one who learned Inform by reading Writing with Inform from end to end, over a very long time. But for your style of learning, you could maybe try looking at things in the Recipe Book. When you find an interesting example and you want to dive into it a bit more, you can open up the example and click the “WI” button. This will open up the relevant section of Writing with Inform.

So you could open up The Human Body, click the “56” to expand “The Night Before,” become intrigued by assemblies, and click the “WI” button next to the title “The Night Before” to wind up at the section on Assemblies and Body Parts.

Not to take away from the other documentation suggestions, but this might be a way of diving in and learning new things without having to read a manual cover to cover.

I’m pretty sure there is no rough and ready way to deduce the correct I7 syntax or the keywords of the language (though there are a few rules of the kind, like definite and indefinite articles never makes a difference (except in a few set phrases)).

Inform 7 for Programmers and the I7 Cheat Sheet (as well as the Rules Chart) provide good overviews of the language and the way Inform works. You’ll find links to them here: [url]Inform 7 documentation and resources].

I’m also fond of the extensively commented official pdf version of the I7 Standard Rules, called Appendix A, that can be found here: http://inform7.com/sources/src/stdrules/Woven/index.html.

And this all circles back - the recipe book and “Writing With Inform” are the best sources to handle “I don’t know how to do this one specific thing…if only I could see an example…” Some concepts in Inform can be explained until someone is blue in the face, but make sense completely once you see them in code.

Also - this might be awfully meta. As far as dealing with a “missing left hand” as if on a pirate. If you remove it from play you’re going to get “You can’t see any such thing” as a response. I almost think stylistically you’d do better to leave the left hand on the pirate and just describe it as missing. The description of the EPM’s left hand is “You look for a hand, but shudder as you notice his arm ends at the wrist in nothing but a bloody stump.” Sometimes in the world of Inform you almost need something to exist for you to specify it’s non existence!

Well, if nothing else, I’m learning to try not to fight Inform. After getting rid of left and right body parts, and just using smoke and mirrors like descriptions of “pairs” of body parts, a lot of stuff is much cleaner now. However, to do this in a way that makes sense, I am still currently doing something that was suggested against… declaring a kind as the plural (in plain English) of the kind. As in, “a eyes is a kind of body part”, instead of “a eye is a kind of body part”. This is because in play I’d expect nouns that normally come in pairs and groups to be referenced as such 99%+ percent of the time as opposed to being referenced individually.

This extends beyond body parts… say, I wanted to make a part of a vehicle “wheels”, as in “a wheels is a kind of vehicle part”. I’d do this, because unless I had a very specific reason to, I wouldn’t want the player to have to specify what wheel they are looking at, just that they are looking at the cars wheels and report back something like “This car has some stylish custom wheels!” If a specific wheel had a flat tire, this thread has taught me there is no reason to actually make all 4 specific tires, but do some functions and description setting behind the scenes that describe to the player the scene as if there is a specific flat tire. Similarly, it should be intuitive to a player that you look at someone’s eyes, instead of look at someone’s eye, and if there is something special about a particular character’s eye, this can be handled special for that specific eye.

However, I want to reduce frustration for the player as well. In some cases, I can see how other text displayed to the player might make it seem like the singular is something that can be entered as part of a command. In that case, I would want the player to be able to enter “Look at so-and-so’s eye” and get the result from “Look at so-and-so’s eyes”. Unfortunately, just adding “Understand “eye” as eyes” does not accomplish this. What am I missing?

A body part is a kind of thing. A body part can be head-based. A body part can be back-based.
A eyes is a kind of body part. A eyes is head-based. A eyes is normally a part of every person.
Understand "eye" as eyes.
A hands is a kind of body part. A hands is normally a part of every person.
Before examining a body part that is part of the player:
if the noun is head-based, say "You can't look at your own head." instead.
The pirate ship deck is a room.
The captain's cabin is a room.
Yourself is in the pirate ship deck.
Eye Patch Man is a person in the pirate ship deck.
The description of Eye Patch Man's eyes is "Eye Patch Man's left eye is covered by an eye patch!"
Hook Hand Man is a person in the pirate ship deck. Hook Hand Man is in the pirate ship deck. 
The description of Hook Hand Man's hands is "Hook hand man doesn't have a right hand. He has a hook!"
A dead fish is an animal in the pirate ship deck.

The part you don’t like is this, right?

Inform’s method of parsing nouns isn’t super super sophisticated – if the player types a string of words, each of which can refer to a certain thing, Inform thinks the player is talking about that thing. For instance:

So here, you have two things, whose names are “eye patch man’s eyes” and “eye patch man’s hands.” Every word in the string “eye patch man’s eye” can be understood as either of these, because “eye” matches the “eye” in “eye patch man’s hands”! (You’ll notice that “x hook hand man’s eye” works as desired.)

This can be taken care of to some extent with something called a “Does the player mean” rule, which lets the game make a choice among ambiguous things under certain circumstances:

Does the player mean doing something to an eyes when the player's command includes "eye": it is likely.

This makes the eyes a better match than the hands whenever the player has typed the word “eye.” However, this can have undesirable effects in some circumstances, because sometimes the player will have typed “eye” as part of “eye patch man”:

The first two are fine – “eye patch man” doesn’t get understood as “eye patch man’s eyes” because “man” doesn’t fit (it’d have to be “man’s”). And in the first case, since that could match either eye patch man’s eyes or hook hand man’s eyes, the parser doesn’t make a decision for you and gives you all the possible choices. But the last two are undesirable.

I think we could solve this by using something to check whether “eye” is the last word of the command, but I also think we would have to do some fairly advanced stuff involving indexed text and regular expressions to do that, and I ought to get back to work.

Ok, I’ve been making some progress here. I actually feel pretty good about having figured out how to make the mirror work :slight_smile: I had set it up so that you can’t look at your own head-based body part (eyes), but now with a new command “reflection-examining” you can bypass this by the command resulting in directly printing the description of your eyes, while you actually didn’t enter a command about yourself, technically. There are several conditions accounted for in the command…

So, I am learning, I think… but, I have several other questions. I tried to expand the complexity to learn more still, and ran into some other issues. I added conditions for two different mirrors. One is small-sized and hand-held, and one is large and not hand-held. You can examine yourself in full in a large mirror, but not a small one. You can reflection-examine yourself in a hand-held mirror only if you are holding it. The problem is, the conditional that makes you need to hold the hand-held mirror to use it is also making the full sized mirror require the player to hold it to use it, but this shouldn’t be. How can I fix that?

Also, I added a condition that the mirror has to be lit to work. I wanted to make it so that it could just work if the room was lit too, and I thought all rooms were lit by default… but it doesn’t seem that being in a lit room lights a thing? How can I go about making a thing be lit if it is in a lighted space? I tried several things and looked at documentation and tutorials online and it didn’t help.

A thing has an indexed text called indexed printed name. Understand the indexed printed name property as describing a thing.
When play begins:
	repeat with item running through things:
		now the indexed printed name of the item is "[item]".

A body part is a kind of thing. A body part can be head-based. A body part can be back-based.
A eyes is a kind of body part. A eyes is head-based. A eyes is normally a part of every person. The description of a eyes is usually "You gaze into [the random person incorporating the item described]'s eyes. [the random person incorporating the item described] averts [the indefinite article of the random person incorporating the item described] gaze uncomfortably.". The description of your eyes is "It's a little unnerving to stare into your own eyes, but they are gorgeous!"
Understand "eye" as eyes.
A hands is a kind of body part. A hands is normally a part of every person. The description of a hands is usually "You notice [the random person incorporating the item described]'s hands."
Before examining a body part that is part of the player:
	if the noun is head-based, say "You can't look at your own head!" instead.

A thing can be large-sized or small-sized. 
A thing can be hand-held. A thing is usually not hand-held.
A thing can be reflective-surfaced. A thing is usually not reflective-surfaced.
A mirror is a kind of thing. The description of a mirror is usually "It's a frame containing a reflective surface." A mirror is normally reflective-surfaced.

After examining a thing (called the mirror):
	if the mirror is reflective-surfaced: 
		say "You can 'reflect something in [the mirror]'".

Reflection-examining is an action applying to one visible thing and one visible thing. 
Understand "reflect [the thing] in [the mirror]" as reflection-examining.
Before reflection-examining:
	if the mirror is unlit and the mirror is not in a lighted room:
		say "It's too dark to use a mirror.";
		stop the action.;
	otherwise if the mirror is not reflective-surfaced:
		say "That isn't a reflective surface.";
		stop the action.;
	otherwise if the mirror is hand-held and yourself is not holding the mirror:
		say "You'll need to pick it up to get a good angle.";
		stop the action.;
	otherwise if yourself does not incorporate the noun and yourself is not the noun and yourself is not holding the noun and yourself is not wearing the noun:
		say "That could be tricky!";
		stop the action.;
	otherwise if the mirror is reflective-surfaced:
		continue the action.
		
Carry out reflection-examining:
	if the mirror is not small-sized:
		say the description of the noun.;
	otherwise if the mirror is small-sized and the noun is yourself:
		say "It's hard to get the full view.";
		now the noun is your eyes.;
		say the description of the noun.;
	otherwise if the mirror is small-sized and the noun is not yourself:
		say the description of the noun.;

The Pirate Ship Deck is a lighted room. "You find yourself on a pirate ship deck".
Yourself is in the pirate ship deck.
EPM [Eye Patch Man] is a man in the pirate ship deck. The printed name of EPM is "Eye Patch Man".
The description of EPM's eyes is "Eye Patch Man's left eye is covered by an eye patch!"
HHM [Hook Hand Man] is a man in the pirate ship deck. The printed name of HHM is "Hook Hand Man".
The description of HHM's hands is "Hook hand man doesn't have a right hand. He has a hook!"
A dead fish is an animal in the pirate ship deck.
The Captain's Cabin is a room. "The Captain's Cabin is spotless, and full of ornate objects, novelties, and decorated to the point of being gaudy. Right now, all you can think about is getting a good look at yourself...". The Captain's Cabin is east of the Pirate Ship Deck.
A captain's desk is a supporter in the Captain's Cabin. The printed name of the captain's desk is "ornate desk".
A handheld mirror is a small-sized hand-held lit mirror on the captain's desk. The description of the captain's hand mirror is "This ornate mirror has a brass handle in the form of a serpent which seems to slither its way all around the frame."
The large mirror is a large-sized lit mirror in the captain's cabin. The large mirror is fixed in place. The description of the large mirror is "Affixed to the rear wall is a floor-to-ceiling mirror set in a dark wooden frame which is decorated with floral inlays made of pearl."