Preventing duplicate messages

Authoring Inform 7
1

I have a message that needs to be printed about an object every time that same information is not given elsewhere. I can’t seem to figure out the cleanest way to do that:

[code]The Kitchen is a room. The Dining Room is west of the Kitchen.

There is a pie in the kitchen. “A heady aroma of baked apples wafts from a pie on the counter.”

Every turn when not smelling or looking and the pie is visible:
say “The aroma of baked apples tickles your nose.”

Instead of smelling the pie:
say “It smells like baked apples.”;

test me with “z/l/smell pie/z/w/e”[/code]
This prevents the every turn rule from running when the aroma is given by smelling or explicitly looking. But when an automatic look is generated by going, it fails to suppress the every turn rule. Aside from smelling, the only thing I need to worry about is when the pie is mentioned in the locale, but I can’t seem to come up with a way to test that.

2

Will it work if you add “going” to the list of suppressed actions?

Also, there is the Mentioned in Room Descriptions extension.

–Erik

3

Try this. It seems to work for me. It may need further fine-tuning.

[code]The Kitchen is a room. The Dining Room is west of the Kitchen.

There is a pie in the kitchen. “[Aroma-mention]A heady aroma of baked apples wafts from a pie on the counter.”

After reading a command:
now aroma-mentioned is false.

Every turn when not smelling or looking:
if the pie is visible and aroma-mentioned is false:
say “The aroma of baked apples tickles your nose.”

Instead of smelling the kitchen:
if the pie is enclosed by the kitchen:
say “A pie, sez I…”;
otherwise:
continue the action.

Instead of smelling the pie:
say “It smells like baked apples.”

To say aroma-mention:
now aroma-mentioned is true.

Aroma-mentioned is a truth state that varies. Aroma-mentioned is false.

test me with “z/l/smell pie/z/w/e”[/code]

4

I thought I might have to resort to that, but adding a global variable and an ARaC rule seemed kludgy. Is it really the best way?

5

I think you can pretty much trust that I don’t know the optimum way to do stuff. OTOH, the typical IF game puts no strain whatever on a computer’s resources. I’m sure you could write a hundred after reading a command rules without seeing a perceptible slowdown in performance.

The main issue, as far as I can see, is keeping your code organized so that you don’t start to see unexpected interactions among closely related rules. For instance, I would tend to put all of my after reading a command rules into one block, so that they would run in my own preferred order, not in whatever order the compiler happened to improvise. But again, I’m not an expert. I just do it that way because it’s easier for me to understand what’s going on.

–JA

6

Exactly. I’m not concerned about performance, but readability and maintainability.

I ended up doing it the other way around. Something like this:

[code]Every turn when the player can see the hot pie:
say “The aroma of baked apples rises from the hot pie on the counter.”

After choosing notable locale objects when the pie is hot:
set the locale priority of the pie to 0.[/code]