Problem with topic understood ("text A" is text B")

Authoring Inform 7
1

[topic merged and title updated by mod]
Under which circumstances can we test whether “a text ‘is’ a text?”

I see that this does not produce the desired results:

Wizard's Dream is a room.

The Pharaoh is a man in the Wizard's Dream.

After asking the Pharaoh about something:
	if the topic understood is "boo", say "Yes!";
	else say "No!!!"

while this works fine:

Wizard's Dream is a room.

The orb is in the Wizard's Dream.

The aura is a text that varies. The aura is "mystifying".

After examining something:
	if the aura is "mystifying", say "Yes!";
	else say "No!!!"

I haven’t read Chapter 20 of Writing With Inform yet, but §20.5 starts with:

I try to remember where “texts being equal” was analysed in the previous chapters, but it evades me. What should I read on the subject?

Thanks.

Edit/Addition:

Actually, “matches” is really interesting.

From what I’ve understood, “matches” is different to “matches the text.”

The following, Code 1, says “Yes!” only if the player asks about “boo,” while Code 2 says “Yes!” even if the player asks about “the big boo” or anything that includes “boo.”

[rant=Code 1][code]
Wizard’s Dream is a room.

The Pharaoh is a man in the Wizard’s Dream.

After asking the Pharaoh about something:
if the topic understood matches “boo”, say “Yes!”;
else say “No!!!”
[/code][/rant]

[rant=Code 2][code]
Wizard’s Dream is a room.

The Pharaoh is a man in the Wizard’s Dream.

After asking the Pharaoh about something:
if the topic understood matches the text “boo”, say “Yes!”;
else say “No!!!”
[/code][/rant]

Is “matches” the very same with “exactly matches the text,” then? What is the difference with “is?”

2

The first problem is that “topic understood” isn’t a text. It’s a snippet. Different behavior.

3

“Matches” drives me absolutely up the wall. It is in fact different from “matches the text.”

From §18.33 of Writing with Inform:

This is what you use when you’re dealing with snippets, which as §18.33 says are fragments of what the player typed. The most common snippets are “the topic understood” and “the player’s command,” and in some circumstances “matched text.” A snippet is internally represented as a single number which tells you what word of the command it starts at and how many words it is, so it really has to be something from the player’s command. (I think. Trust someone like zarf more than me about internals.)

Now, the infuriating thing is that when you’re dealing with texts–as per §20.5–you have:

if (text) matches the text (text): This condition is true if the second text occurs anywhere inside the first.

and

if (text) exactly matches the text (text): This condition is true if the second text matches the first, starting at the beginning and finishing at the end.

So… when you’re doing a snippet-to-topic comparison, it’s “matches” when they’re exactly the same and “includes” when the first includes the second. When you’re doing a text-to-text comparison, it’s “exactly matches the text” when they’re exactly the same and “matches the text” when the first includes the second. This is constantly tripping me up.

Anyway, I believe that

if "[the topic understood]" exactly matches the text "boo"

will wind up being the same as

if the topic understood matches "boo"

because saying “[the topic understood]” turns the snippet into a text.

4

I can see the light!

Thank you both so much!

5

In continuation with our texts vs. snippets bonanza, why does this not work?

[rant=Random Password][code]
“Random Password test”

Section 1 - Setting the Password

The current password is a text that varies. [The password is chosen randomly, at the beginning of the game.]

The password-asked is a truth state that varies. [By default, this starts as false. When the player is asked for the password, this value becomes true.]

When play begins:
choose a random row in the Table of Passwords;
now the current password is the pass entry.

Table of Passwords
pass
“boo”
“ding ding”

Section 2 - Actions

Saying the password is an action applying to one topic. Understand “[text]” as saying the password when password-asked is true.

Carry out saying the password:
if the topic understood does not match “[current password]”:
if the topic understood includes “[current password]”: [This condition is true for example if the player types THE PASSWORD IS BLAHBLAH.]
say “You have to be more specific. Just give the password, straight, no chaser.”;
else: [and this condition is true if the current password is just wrong.]
say “‘Nah-huh,’ the voice replies and goes silent.”;
now the password-asked is false;
else:
say “'Well done. Buzz again, anytime.”;
now the password-asked is false.

Section 3 - Scenario

The Green Room is a room.

The buzzer is in the Green Room.

There is an apple.

Instead of pushing the buzzer:
say “‘Hey, what is the password’?’ someone asks.”;
now the password-asked is true.
[/code][/rant]

I’ve tried it with and without “” around current password. The first gives a compiler error message:

while the second gives a run-time problem:

so I suppose I have to stick to the first. Why does it not recognise ‘current password’ as a token, since I have define it as a text, at the beginning?

6

This is probably not very orthodox and I apologise for starting a new post; this is actually an attempt to draw attention to my last reply on this post, which has been left unanswered. I am really stuck with my code.

Thank you. I appreciate the help.

7

The whole issue of texts versus topics is under-documented, and I’ve never completely understood it. I think this is the deal:

  1. “X matches Y” is an operation on X, a snippet, and Y, a topic.

  2. (if the player’s command matches “boo”) makes sense, because “boo” can be a topic.

  3. (if the player’s command matches the current password) doesn’t make sense, because the current password is a text variable, not a topic. There is no such thing in Inform as a topic variable.

This does more or less what you want, I think.

Carry out saying the password:
	let T be "[the player's command in lower case]";
	unless T exactly matches the text current password:						
		if T matches the text current password: 
			say "You have to be more specific. Just give the password, straight, no chaser.";
		else:
			say "'Nah-huh,' the voice replies and goes silent.";
			now the password-asked is false;
	else:
		say "'Well done. Buzz again, anytime.";
		now the password-asked is false.

It’s not quite the same as what you wanted, because “matches the text” doesn’t behave like “includes” (it doesn’t only match complete words). If you want to mimic that behaviour then you’ll have to muck around with regular expressions.

8

Thanks, jrb, I’m happy I am not the crazy one. The issue is quite confusing, I must say.

I guess, my question now is: what on earth is a topic?

I understand that it is something between “some text” and “a thing,” since Writing With Inform says in §7.6:

but at the same time we use the expression:

and, as we know, something = a thing.

So, the weird thing about this evasive concept called topic is that it only appears as a specific piece of “text” (in quotes), but we can’t compare it to a text that varies, right?

Moreover, it seems that turning the “topic understood” snippet into a text (in order to compare / test it—as you’ve done in your code on my example) has to use the whole “[player’s command]”, since something like “[topic understood]” (in quotes and square brackets) is not accepted. (Which is weird, since “[the noun]” snippet is.) And that may be OK in my example, where the player’s command is the actual password, but what about commands that include action verbs? We will need to strip the command from everything other than the “topic understood” snippet.

I think I will simply create kinds of thing/value for everything (subjects of conversation, passwords, etc.) and completely avoid the muddy waters of the… topic misunderstood. :smiley:

9

Topics are notably confusing and not documented very well. There’s a uservoice suggestion about them which explains some of the issues.

One way to think about what is special about topics is to look at this:

[code]Test Space is a room.

Giannis is a man in Test Space.

Instead of asking Giannis about something when the topic understood matches “boo/yikes/ouch”, say “Giannis says ‘That is how I feel about topics.’”[/code]

Here “boo/yikes/ouch” is a topic, which means that as long as the topic understood (a snippet!) matches “boo” or “yikes” or “ouch” the rule will fire. Topics in this way work somewhat like the things in Understand statements–they’re functions for evaluating text. This is also why topics are not printable, even though they often look like they should be.

As in Understand statements, bracketed expressions in topics have to be grammar tokens. So I think the issue with your original code is that you can’t put a variable name in quotes and brackets in a topic like that. “[number]” would be fine, and “[apple]” would be fine I think, but the variable doesn’t work.

You can in fact turn the topic understood into a text with “[topic understood]”. This works:

Carry out saying the password: unless "[the topic understood]" exactly matches the text "[current password]": if "[the topic understood]" matches the text "[current password]": [This condition is true for example if the player types THE PASSWORD IS BLAHBLAH.] say "You have to be more specific. Just give the password, straight, no chaser."; else: [and this condition is true if the current password is just wrong.] say "'Nah-huh,' the voice replies and goes silent."; now the password-asked is false; else: say "'Well done. Buzz again, anytime."; now the password-asked is false.

One thing that caught me here is that you can’t say “does not exactly match the text” simply because that’s not a defined phrase (unlike “does not match” for snippet/topic comparisons). But the “unless” works.

I think that when it says “a piece of text” it doesn’t technically mean the text kind, and that it accepts “something” even though topics aren’t things because there’s no more convenient way to refer to topics in these things.

Still, if you decide it’s best not to deal with these things that’s understandable!

10

I was unfortunate to use that very phrase, “does not exactly match the text,” when I tried turning the topic understood into a text, with “[topic understood]”. That’s why I didn’t make it work.

Thanks, everyone. Matt, I’ll use your code after all. I think turning the topic understood into a text for comparison purposes will work in most cases. In any case, texts have great flexibility and whole chapters written about them. Topics, on the other hand… :question:

11

Me too. This should be a defined phrase.

12

There’s an old suggestion I put on the suggestions forum (well, everything on the suggestions forum is an old suggestion…)

inform7.uservoice.com/forums/57 … ide-whethe