intfiction.org

In room descriptions definitely, and also where I'm being lazy with "Look at (person)", IE if the character isn't integral to the story and I'm not creating a separate "Look at" description for them.

Right - you just change your existing rule to this:



The reason the say-phrase works this way is that unlike the rest of Inform, the compiler parses phrases EXACTLY as you've defined them, letter-for-letter. If you create a phrase called "To say Tom's rundown," the compiler does not recognize that Tom is the name of a person, it just accepts the word 'Tom's' in that place and no other phrasing (such as 'X's'). You might have well called the phrase "To say Albuquerque rundown" and it would have been no more or less linked to Tom in the eyes of the compiler. If you want a phrase to accept a variable, even if that variable can only ever have one value, you must put it in parentheses. Once you've done that, phrase overloading works as it would in other object-oriented languages, so you can define any number of phrases with "To say (someone - particular identifier):" This defines a say phrase that takes a parameter called "someone" whose value must be particular identifier.

My WIP has something similar, but I've put it into an activity called "behavior." I'm not totally happy with it, or I would be working on an extension for it. If you're doing something along the same lines, I might think about an extension more seriously. Maybe start a new thread to discuss this?


I think Matt's identified the problem, but I'm not sure if this is the right solution. You need to specify the player's wrist in a way the compiler will understand. If you say:


...the compiler will create one wrist for every person, and it will create a name for each wrist using a specific pattern. For non-player objects, that pattern is "object name's wrist." That means if you have an NPC named "Henry David Thoreau," the compiler will create a wrist called "Henry David Thoreau's wrist." You can refer to that wrist in your code as "Thoreau's wrist" or "Henry David wrist," but not as "Henry David's wrist," because the word "David's" is not part of the name that the compiler created. Similarly, parts of the "yourself" object will be called "your wrist," etc. and "the player's wrist" and "the wrist of the player" will not match, because "of" and "player" and "player's" are not part of the official name.

You're right, of course. If you want to write a rule that captures the player's wrist, one thing you could do is look at the Index (or showme the player) to find out what Inform is calling the object. Or if you need a more general case (if there's a possibility of switching the player from one person to another) then you might need "a wrist that is part of the player" or "a random wrist that is part of the player" or something like that.

How about something like this?



I haven't tested this, but I think it might work.

It worked (with a little fiddling around to control line breaking), and thanks for the explanation. I'm still in the early stages of grappling with Inform's grammar and syntax, so there's a long way to go. Inform is the first Interactive Fiction language I've learned, and as such completely different from anything I've done before.

Possibly, although as a raw novice I wouldn't be able to contribute much myself. Certainly it would be worth attracting opinions, so if you do start a thread on it pls post a link here to the new thread.

I would have expected describing details of NPCs to be sought fairly often, in a game where details of the characters are subject to change. An example of what I could be doing with the three characters at the construction site is for one to be randomly selected as the murderer, with the telltale signs to be a torn section of their overalls and a pocket bulge where they've stowed the murder weapon.

This one is still giving me a headache. I've tried the index and showme command. Nothing appears about wrists in the index, but the Showme command identifies them as:
">showme my wrists
your Wrists - Wrists"

Having learned this I've changed the command to:

This successfully compiles, but unfortunately it appears not to have any effect on gameplay:
">Examine wrists
Which do you mean, your Wrists, Tommy's Wrists, Richard's Wrists or Gertrude's Wrists?"

There's a rather brute-force solution that I found while working on something else.

Not ideal for all situations, but it's one option. This came about while I was getting ahead of myself and trying out ideas for a furry Interactive Fiction game. With different species having different body parts the only way I found to achieve this was to say that all body parts are a part of a person and then to remove from play the incorrect ones.
Simplified example:
A question that might possibly lead to a solution (or maybe more problems): When there are pairs of body parts, what's the correct way to create them?

Wrists are a part of every person.
or
A left wrist is a part of every person. A right wrist is a part of every person. (This produced a compilation error).
or
Two wrists are a part of every person. (This was successfully compiled, but then I couldn't apply the "Remove your Wrists from play" and in gameplay it became impossible to perform actions on anyone's wrists because Inform could no longer distinguish one wrist from another).

I think you're hitting one of the annoyances of DTPM rules. As I understand it, they assign a score to every possible match, and if one object comes out with the best score then they pick that object. But if there's a tie, they ask the player to disambiguate every possible match. So in this case, if there's one NPC in the location I think it will automatically examine the NPC's wrists, but if there is more than one NPC it will disambiguate among everyone's wrists.

You could see if the Disambiguation Control extension helps. I don't know any other way to solve the problem.

Okay that sounds logical.

Not familiar with those terms though. What's DTPM and Disambiguation Control? I couldn't find either of those in the manual.

Sorry, DTPM is "does the player mean," and Disambiguation Control is an extension by Jon Ingold found here.

DTPM is short for Does The Player Mean. Disambiguation Control is an extension by Jon Ingold.

I haven't had much luck with Disambiguation Control. It only does certain things, and I can't remember whether removing an item from the match list is one of them.

I spend a lot of time debugging DTPM. Here are some things I keep in mind:

The DTPM rulebook runs once for every possible action that the parser tries to match against the command. In effect, every noun is tried one at a time. And like any other rulebook, DTPM stops running on the first rule that produces a result. So rule order matters. If you have one DTPM that refers to examining and one that refers to body parts, only one of them will apply to examining wrists, and which one depends on the rule order.

So, two super-valuable things to do:

Turn rules on. This will tell you which DTPM, if any, are running. Unfortunately, you won't be able to see what circumstances they're running on. So the second thing is to add this rule:



That will give you a nice "header" for every block of DTPM that runs, ending with the one that made the decision.

If you get really desperate, you can use the "trace" debug command, but that will give you a lot of I6 parser stuff that's hard to decipher.

My approach to this problem is to make an extra effort to ensure that only one choice scores high - thus avoiding disambiguation completely. A few specific cases that trigger "it is very likely" are much more powerful than a large number of cases returning "it is very unlikely."

Here, you might want something like: