List of Inform 7 questions (several regarding Does the Player Mean)

Hello! I’m sorry for putting all of these in one post, but I feel like I have too many tiny questions to make separate posts. Several of these are things I’ve already found workarounds for, and simply want to understand why the straightforward way doesn’t work.

  1. I’m setting up a spellcasting system where the player can learn new spells, each their own action, and that are responded to with “That’s not a verb I recognize.” before then. This works fine:
Understand "teleport", "cast teleport" as teleporting. Teleporting is an action applying to nothing.
Instead of teleporting when Teleport is undiscovered: say "That's not a verb I recognize."

But I originally tried this, which seems simpler for not having to individually retype a default response for each spell:

Understand "teleport", "cast teleport" as teleporting when Teleport is discovered. Teleporting is an action applying to nothing.

This doesn’t result in an error, but the response is “I didn’t understand that sentence.” instead of “That’s not a verb I recognize.”, which lets the player know that there’s a difference between “teleport” (a spell yet to be discovered) and “fly” (a spell that doesn’t exist). I’m wondering why this is (even though I don’t really need to know).

  1. Another thing I’ve already worked around but would like for the sake of streamlining… Is there a way to group actions? I know I can do this for specific manifestations of actions (taking the ball/taking the bat) but I don’t know how to do it for broad actions. Something like:
Teleporting is spellcasting. Vanishing is spellcasting.
Check spellcasting when the player does not carry the spellbook: say "You need your spellbook to cast that!" instead.

…instead of having to write the same “Check” statements for every spell. This would also be nice for “Instead” rules and such.

  1. Very simple question: how do I print/“say” square brackets ([ and ]) without them being mistaken for a text substitution?

  2. I have several places where I’d like to make interactions with a thing more/less likely, but I’m having a hard time figuring out how. The phrases “Instead of doing something to…” and “Does the player mean doing something to…” only affect one-noun verbs or the first noun of two-noun verbs, and the one page I’ve found about “doing something to” doesn’t seem to mention how to stop the player from using an object as the second noun. So even if I say “Does the player mean doing something to the obvious door: it is very likely.” something like this still happens:

put bread on door
Which do you mean, the obvious door or the hidden door?"

(in my actual code it’s two glowing orbs, one of which is the mirrored reflection of the other, and I don’t want it to let the player know the mirrored version is important until they take it)

  1. Another “does the player mean” issue, which I’ll probably have to restructure my objects to accommodate: I have several identical blocks that I’ve made described by their location (I based the system off of answers from this post), which enables me to differentiate between the objects the way I want to but no longer allows me to interact with their supporters:

put small on right
Which do you mean, the right side or a large block on the right side?
the right side
Which do you mean, the right side or a large block on the right side?

(This is also despite a statement that says “Does the player mean putting something on a supporter: it is likely.”, so I really don’t understand what’s going on.) I’d like it to just pick the right side in this example, but in general I’d like it to only understand “the right side” as the blocks on it when you also say “block”.

Relevant code:

A block is a kind of thing.
A block has a number called weight. The verb to weigh means the weight property.
Size is a kind of value. The sizes are large, medium, and small. A block has a size. Understand the size property as describing a block.
Understand "weight" as a block. Understand "big" as a large block.
Understand "on/from/-- [something related by reversed support]" as a block when the item described is on a supporter.
Understand "in/from/-- [something related by reversed containment]" as a block when the item described is in a container.
Understand "from/in/-- my/-- inventory" as a block when the item described is carried by the player.
Understand "on/from/-- the/-- floor/ground" or "dropped" as a block when the item described is in a room.

I also have a problem which I’m not sure that solution would circumvent: things like “put large on left” are understood as (put the large block that is on the left side on (something)) and not (put the large block that I am holding on the left side).

  1. (another thing I’ve already found a workaround for and am looking for more clarity about) In general, does the player mean statements confuse me because there seem to be defaults for likeliness but no way to figure out what they are. For example, when I create a new action, it seems to be automatically “likely” that the player wants to do it to something in their inventory, at least when there’s only one. Sometimes this becomes confusing (I’ve changed burn to a two-noun command):

burn desk
(with the bread)
The bread isn’t on fire. How do you expect it to light the bread?

But then something like this:

Does the player mean burning something with a thing which is carried by the player: it is unlikely.

results in it defaulting to portable objects not carried by the player (dropped, actually; it ignores those on supporters). Making it “possible” still defaults to objects being carried by the player, so it seems like its default likelihood is between possible and unlikely. This works:

Does the player mean burning something with a thing which is carried by the player: it is unlikely.
Does the player mean burning something with a thing which is not carried by the player: it is unlikely.

But I’m still confused.

  1. Is there a way to make something like the opposite of a conditional paragraph break? I have text and more text that might follow, and if it does then I want it to be in the same paragraph. “[run paragraph on]” doesn’t work because it runs on even if no text follows.

Thanks for any insight!

1 Like
  1. The problem with the second snippet is you’ve only told Inform to understand those tokens as teleporting when that condition is met. Since it isn’t met, Inform doesn’t yet understand what you mean yet.
  2. The problem with your code isn’t the grouping, it’s the formatting of the Check rule. Check rules don’t accept conditions in their definition like that. You’d need something like this:
Check spellcasting: if the player does not carry the spellbook, say "You need your spellbook to cast that!" instead.
  1. You can use [bracket] and [close bracket]
3 Likes

Don’t worry about that – separate posts (for unrelated issues) are better for the community. Someone in the future with the same issue as you will be able to find the solution easier.

As for this:

You’ve defined the grammar to be recognized “when Teleport has been discovered.” In every other case it ignores it as essentially gibberish.

1 Like

For #5, it looks like you may have created a system of impossible disambiguation. Everything that could refer to the supporter also refers to the block, meaning there’s no way to exclude the block from consideration. I might make sure your second and third Understand statements explicitly include the word “block” so that the blocks will only be chosen over their supporters when the player types something like right block specifically.

1 Like

Thanks! For 2, I still get this error regardless of how I write the check statement:
“The sentence ‘Teleporting is spellcasting’ (line 79) appears to say two things are the same - I am reading ‘Teleporting’ and ‘spellcasting’ as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that ‘Adams is Jefferson’. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance ‘Virginia is a lighted room’ says that something called Virginia exists and that it is a ‘room’, which is a kind I know about, combined with a property called ‘lighted’ which I also know about.”

Why is it different from the what it says when I type actual gibberish (“That’s not a verb I recognise”.)?

Did you define Teleporting above the spellcasting definition? It needs to know it’s an action before it can understand it as behavior.

The other thing is, behavior can really only interact with Before and Instead rules. Check, carry out, and report only work for specific actions (I forgot that detail before; my bad!).

This fix complies for me:

Teleporting is an action applying to nothing. Vanishing is an action applying to nothing. The spellbook is a thing.

Teleporting is spellcasting. Vanishing is spellcasting.

Before spellcasting: if the player does not carry the spellbook, say "You need your spellbook to cast that!" instead.
2 Likes

Likely because it knows there is a condition under which it would understand that grammar, so the mechanism that’s blocking it is different than if it reads it as total nonsense.

2 Likes

Re #4 and #6, “Does the player mean…” is notoriously finicky, especially with two-noun actions. I’d recommend reading this reference on it, paying special attention to the part at the end about the [other things] tag.

1 Like

I don’t understand what it means about the [other things] tag. This is helpful for rerouting specific actions (putting, inserting, etc.) but is there not a way to apply this to all two-noun actions at once?

I see. One other question: If I use my “Instead of teleporting when Teleport is undiscovered”, is there a way to make this happen before the really basic checks?
E.g.

vanish
That’s not a verb I recognize.

as opposed to

vanish
What do you want to vanish?
bread
That’s not a verb I recognize.

I guess I could use “Understand [text] as a mistake…”, but I’d like to avoid rewriting all the things that it’s supposed to understand as vanishing.

Right.

The parser organizes the grammar into groups by the verb word. When the player types a command, it runs through all the patterns (“grammar lines”) starting with the verb it sees. If none of those patterns match, it gives the “I didn’t understand that sentence” error.

Your conditional means that none of the grammar lines match when Teleport is undiscovered. But the parser isn’t distinguishing between “failed to match because the player typed the wrong words” and “failed to match because a global condition is not true”.

You could use the “printing a parser error” activity (§18.35) to adjust the wording of that error to say “That’s not a verb I recognize.” This requires a bit of hackery though:

To decide what action name is the action-to-be: (- action_to_be -).

Rule for printing a parser error when the latest parser error is the didn't understand error:
	if the action-to-be is the teleporting action:
		instead say "That's not a verb I recognize.";
	continue the action;

(Really, in this rule, “action-to-be” could be any action that starts with CAST or TELEPORT. You’d have to name all your conditional actions.)

1 Like

Though also, “I didn’t understand that sentence” is a pretty rare error in general. Changing that to “That’s not a verb I recognize” wouldn’t have particularly dire consequences.

It’s rare – I don’t think there’s a way to trigger it with the default library grammar.

However, when it appears, it means “I did recognize the verb, but none of the rest of your sentence.” So I would be wary of changing it except when specifically trying to conceal a verb from the player!

Oh, this works great! Thank you!
Is there any easy way to learn how to use Inform 6 with Inform 7 without having to learn Inform 6 from scratch? I know Writing with Inform has information on how to integrate it, but it seems targeted at people who already know Inform 6, even though it seems like it’s a limited part of the language that is useful when using Inform 7 (I could be wrong about that). Like what does this line do?

Literally, this line just exposes an existing I6 variable to I7. So unfortunately, the only way to learn to do bits like this is to understand the I6 parser machinery well enough to know which variables you’d want to get at from I7.

I would do…

Teleporting is an action applying to nothing.
Report teleporting: say "pouf!".
Teleport-known is initially false.
Understand "teleport", "cast teleport" as teleporting when teleport-known is true.
Understand "teleport", "cast teleport" as a mistake ("That's not a verb I recognize") when teleport-known is false.
Instead of jumping, now teleport-known is true.
Test me with "teleport / jump / cast teleport".
2 Likes

The rules of any rulebook can be stated with a condition using when/while. Looking at the documentation examples might suggest otherwise, because they’re informed by a philosophy that Check rules should be for general cases (thus ones for which it’s less likely for a condition to be relevant) and Instead rules for specific cases. But that’s not a language limitation, it’s a style choice (and not one I follow).

But as you say, if you’re grouping actions together you can’t use Check. Instead rules are the most straightforward second choice for that case.

1 Like

Hey I learned something from this thread too! Thanks!

1 Like

I just realized that while this is working for Teleport, it doesn’t work for another two-noun action I have, unvanishing it to (which allows the player to make an object they’ve vanished reappear in a specific place).
This is the slightly edited version of your code:

To decide what action name is the action-to-be: (- action_to_be -).

Rule for printing a parser error when the latest parser error is the didn't understand error:
	if the action-to-be is the teleporting action or action-to-be is the vanishing action or the action-to-be is the unvanishing action: [ADD SPELL, ADD HERE]
		instead say "That's not a verb I recognize.";
	continue the action;

And this is where I define unvanishing it to:

Understand "unvanish [any thing] to/on/onto/-- [something]", "cast unvanish on/-- [any thing] to/on/onto/-- [something]", "unvanish [any thing]", "cast unvanish on/-- [any thing]", "bring [any thing] back", "bring back [any thing]" as unvanishing it to when Unvanish is discovered.
Unvanishing it to is an action applying to one visible thing and one object.

Typing any one of the unvanish statements (except, for some reason, “bring back [thing]”) returns “I didn’t understand that sentence.” “Cast vanish” and “cast teleport” also return the didn’t understand error.