Synonyms for text tokens

I am trying to set up text with synonyms for use with an NPC. I want to ASK BARTENDER ABOUT which in general can be food or drink, but the player may enter numerous words meaning the same thing. ASK BARTENDER ABOUT dinner, meals, eating, something to eat, etc.
For normal objects or scenery I can define NUTRITION as scenery with a description and then use UNDERSTAND “dinner” or “meals” or eating" as nutrition. If someone asks the bartender about any of these, I can give the same response:

say "[description of nutrition]".

However, this doesn’t work for text tokens. Is there a similar mechanism to list synonyms? Otherwise I am stuck with this abominable code:

Nutrition is scenery. Description of nutrition is "He looks annoyed, sighs, then replies as if he is doing you a great favor. 'Kitchen's closed now. Breakfast is available at dawn.'".

Instead of asking bartender about "food": say "[description of nutrition]";
Instead of asking bartender about "dinner": say "[description of nutrition]";
Instead of asking bartender about "meals": say "[description of nutrition]";
Instead of asking bartender about "something to eat": say "[description of nutrition]";
Instead of  asking bartender about "eating": say "[description of nutrition]";

Yup, this is easy to do - for minor cases you can just use the slash to establish synonyms, but for more elaborate ones you can define new text tokens and just refer to those, per this bit of the docs:

Edit: also fyi just as a point of nomenclature, “dinner”, “food”, etc. are just texts, not text tokens - a text token is something like “[nutrition]”.

Edit the second: oh, and also, you probably don’t want to run all this dialogue as instead rules - I did that in one of my games, only to realize halfway through that I needed to check whether the player was speaking. And since all my asking it about rules were instead of rules, the action was never actually firing and I couldn’t check it!

I understand the slash notation, but when I apply it to ASK BARTENDER ABOUT (something? what?), the parser throws an error. What is the conditional, ala:

Understand "dinner/meals/eating" or "something to eat" as nutrition.
After asking bartender about nutrition:   [this doesn't work]
    say "[description of nutrition]"; 

Should this work?

That would work if there was a nutrition object somewhere in the world model – which I know is an approach some conversation extensions use – since that understand statement gives a bunch of synonyms for a nutrition object. But to create a text token, you need to use the “[]” syntax. There are more examples in the docs, but this modification should work:

Understand "dinner/meals/eating" or "something to eat" as "[food]".
After asking bartender about "[food]":   
	say "[description of nutrition]"; 
To say description of nutrition:
	Say "This should be working now?"

OK, I tried a few things and I got this to work:

Understand "food/dinner/meals/eating" or "something to eat" as nutrition.

Before asking bartender about [nutrition]:
	say "[description of nutrition]";

How to tell when to use the brackets around an item, e.g. nutrition in I7?
Isn’t there an internal mechanism to say the description of something when asking about it, as if I was examining it, instead of writing a new rule?

The quotes plus square brackets are the syntax that denotes a text token; without those, the compiler understands you to be referring to an object. Square brackets by themselves are just comments, so the revised excerpt you posted doesn’t actually compile.

Nope, that’s not part of the standard rules – out of the box I think the only thing that hooks to the asking it about action is the generic block asking rule. So you’d need to write that.

Well ASK BARTENDER ABOUT [nutrition] does NOT work. I have a few of these ASK ABOUT’s and I get the same message no matter what I ASK ABOUT. It seems to be the first message that I define in the source code. Where is the rationale for this? This is SO Frustrating!

If I ask for a test string, e.g. ASK BARTENDER ABOUT “sky”, these all work. I cannot use anything that uses an Understand statement.

So we’re back to the first question: What can I use to refer to ASK ABOUT something that has/needs synonyms?

Before asking bartender about nutrition doesn’t work, and neither does [nutrition], What does?

You need the quotes and the square brackets to tell Inform that you’re creating a text token. Here, I wrote it up as a Borogrove snippet so you can play around with it and see the output:


This is great! Seems like exactly what I was looking for. I’ll give it a try and let you know.

Yes, it works perfectly. Now, WHY does it work? I guess it is because the text in brackets (i.e. food) becomes a variable, but since brackets are reserved for comments, they must be put within quotes to convert it to a text-type variable. Yes?

Yeah – brackets in quoted text denote tokens, brackets outside of quotes just lead to comments. The docs talk through how they work, in case that’s a helpful reference – 17.4 and 17.5 are the relevant ones.

1 Like

On the flip side, you don’t need quotes and square brackets to just say a phrase.

After asking bartender about "[food]":   
	say description of nutrition; 
To say description of nutrition:
	Say "This should be working now?"

Not directly relevant to the question, but people often get this wrong and put in unnecessary punctuation.


It was all about the ASKING person ABOUT text token. I couldn’t figure out how to use/create a text token to allow synonyms. Text tokens seem to work differently than other rules. Usually for NPC questions, I used a table or a text string (e.g., ASK BORK ABOUT “whiskey”) which both work differently yet.
Thanks to both of you for getting me going again.

Yes, I read through 17.4 and 17.5 but it didn’t help with synonyms, or speak specifically to how to create one. Your example solved the problem.

Right, those are just about text tokens generally. 17.13, which I linked in my first reply, is about creating new text tokens, with an example of doing that to create a bunch of synonyms - now that you’ve got it working it might be useful to read it over again since it might make more sense (or, now that it’s working, you might of course prefer just to move on!)