Square Brackets for objects in ask/tell


I read about the use of square brackets for matching objects in the InformHandbook I found here
(page 161)

I want to be able to ask about an object called the laser gun with “laser”, “gun” and “laser gun”. I thought I could use “[laser gun]”

However, the short story I wrote below only matches the white glove. If I switch the first two instead statements, it will only match the laser gun. Basically, asking only works for the first statement, and then doesn’t work for square bracket substitutions thereafter. The final statement, using exact string matching, always works.

So, “ask Adam about glove” -> OK
“ask Adam about white glove” -> OK
“ask Adam about laser gun” -> There is no reply.

Thanks for any insight into what’s going wrong here…


“Substitution in Ask” by Christopher

Plaza is a room.

A laser gun and white glove are in Plaza.

Adam is a man in plaza.

[this works]
Instead of asking Adam about “[white glove]”:
say “Glove test.”

[this does not work]
Instead of asking Adam about “[laser gun]”:
say “Laser gun test.”

[this works]
Instead of asking Adam about “exact text”:
say “Exact text test.”

In my view this is primarily a documentation issue. The Inform7 docs are not particularly clear about “topics” e.g. text that’s defined in quotes and used in Ask or Tell About commands. What I do is define a topic explicitly and then use that, e.g.

Understand "war/germany/ww2/army/marines/officer/nazi/nazis" or "the war" or "the germans" or "the army" or "the marines" as "[war]". Instead of asking Sgt Duffy about "[war]": say "'Johnny, I fought in the Army during the war. So believe me, going out to Cabeza Plana to investigate a death is not a big deal to me. Maybe as a team we can figure this out.'"; now Sgt Duffy is Friendly.
This might be overkill, but you could write something like:

Understand "lazer/gun" or "lazer gun" as "[lazer]". Instead of asking Adam about "[lazer]",say "'Get your own darned lazer.'";
Note that I’m kind of a noob myself, but hopefully this points you in the right direction. Also, Aaron Reed’s book “Creating Interactive Fiction” is quite good at explaining all this stuff.
Good luck.

Yes, this is undocumented behavior which I’ve tripped over in the past.

If this is what I think it is, then what’s happening is that when any (yours or the standard library’s) code tries to match against “the topic understood”, I7 places the result of any parsed object into “the noun”, overwriting the previous value. This is problematic in conversation where “the noun” usually refers to the person you’re talking to, not the object you’re talking about.

It’s possible to work around this by saving the value of “the noun” before “the topic understood” is processed, and if necessary restoring it before it’s used later on. (Edit: See the post after this one for a reasonable workaround.)

By the by, I recently raised a request for further documentation on topics which covers this issue and others - feel free to vote it up (or not) as you see fit :slight_smile:

Inform 7 / General / Thoroughly document topics, or make them far more intuitive


On closer inspection you’re hitting more complex issues, so that workaround was poor; sorry.

Here’s a better one:

To decide whether the subject is (x - a topic):
let the former-noun be the noun;
if the topic understood matches x:
now the noun is the former-noun;
decide yes;
now the noun is the former-noun;
decide no.

Instead of asking Adam about when the subject is “[white glove]”:
say “Glove test.”

Instead of asking Adam about when subject is “[laser gun]”:
say “Laser gun test.”

Instead of asking Adam about when the subject is “exact text”:
say “Exact text test.”[/code]

Why does the noun/former noun business work? I’ve tested that it doesn’t work when you take it out, but I don’t understand what it’s actually doing.

UPDATE: Ah, I see, from your uservoice suggestion:

This might be overkill, but you could write something like:

Understand "lazer/gun" or "lazer gun" as "[lazer]". Instead of asking Adam about "[lazer]",say "'Get your own darned lazer.'";

Thanks - this works, but it doesn’t allow you to say “Ask Adam about the lazer gun”.


This works but I also don’t understand why. I’m still not sure why in my original version it appears to stop processing after the first ask statement with square brackets. If it doesn’t match on that, why not continue to try to match on the next one? It appears that the first statement with square brackets is consuming the input somehow.

I’ll just use this workaround for now.

Thanks again everyone!

What’s happening is when you write something like ‘Instead of asking Adam about “[white glove]”’, Inform 7 is quietly changing which object is “the noun” half way through handling the asking about action, which causes some apparently strange behaviour.

With the rules as originally written, Inform 7 causes the game to run code which you could imagine looked roughly like this:

Read the player's command; Work out what verb, noun and second noun are used; if the verb is "ask": ... [1] if the noun is Adam and the topic understood matches "[white glove]" [This CHANGES "the noun" to white glove if the noun is Adam] say "Glove test." [2] otherwise if the noun is Adam and the topic understood matches "[laser gun]" [This CHANGES "the noun" to laser gun if the noun is Adam] say "Laser gun test." otherwise if the noun is Adam and the topic understood matches "exact text": say "Exact text test." otherwise: say "There is no reply." ...

So when Inform hits point [1], the noun is Adam. But the phrase “the topic understood matches…” sneakily changes the noun to white glove. So the test at point [2] will always fail because the noun isn’t Adam any more.

The workaround works by ensuring that we remember what the noun was before we try any “the topic understood matches…” business, and put the noun back afterwards so all is well.

Arguably it’d be nicer if matching topics against objects set something like “the topic noun” rather than “the noun”; I’m not even sure that its changing “the noun” is intentional. It may just a side effect of the way parsing works, or it may be a bug.

I would file it as a bug report (and if it’s intentional, they can let you know).

I like your thinking. Filed here: http://inform7.com/mantis/view.php?id=642

Genstein thanks for explaining it so carefully - now I see what the problem is and why the workaround works.

Also, cheers for filing the bug report.