Programming error: tried to find the "." of (something)

#1

Hello,

After the most recent change in my code, I got the following error message:

Please note that this message appears in the actual game, not during compiling. After the player writes a specific action, this message appears in between brackets and then the action continues without other problems.

What does this mean? I managed to cut my code down, in order to demonstrate this:

[code]“Test Error”

A thing can be known or unknown. A thing is usually unknown. After printing the name of a thing (called item): now the item is known.

After asking a person about “[any unknown thing]”:
say “You have no reason to ask [the noun] about something you haven’t seen around [their] place.”

After deciding the scope of the player while asking a person about “[any known thing]”:
place the second noun in scope.

Colin’s Studio is a room. Colin’s Ensuite Bathroom is north from Colin’s Studio.

The magazine is in the Bathroom.

Colin is a man in Colin’s Studio.

After asking Colin about “[magazine]”:
say “Magazine… Ahhh…”

Test me with “ask colin about magazine / n / s / ask colin about magazine”.
[/code]
The error message started after I added the line about the scope of the player.

Oddly, in this test code, I get the “There is no reply.” answer, when the player asks about the (known) magazine, so the line about the scope doesn’t seem to work either…

0 Likes

(Andrew Plotkin) #2

I haven’t taken a close look, but this is almost certainly because the asking action doesn’t apply to a second noun. The second argument is a topic. Even though you’re using “[any known thing]” as the topic, it doesn’t get stored into the second noun variable, so “place the second noun in scope” is probably trying to operate on nothing.

0 Likes

#3

The problem is with the term “second noun”. The grammar for the “asking it about” action does not accept a second noun; it accepts a noun, and some text. You have done some clever magic with substitution tokens that lets the parser understand that text as if it were referring to a specific object in the game, but at no point does the game actually set the second noun. Thus you referring to the “second noun” sends the program into a tailspin of confusion.

In the code sample above, you can work around the problem by replacing your deciding the scope of the player rule with this:

After deciding the scope of the player while asking a person about "[any known thing]": repeat with item running through known things: place the item in scope.

This puts every known thing into scope without trying to guess what the player might be referring to. This can come in handy if you have, say, a fashion magazine and a sports magazine in the same game – ASK COLIN ABOUT MAGAZINE will generate a “Which do you mean” message if both are known.

However, you may still find yourself having to build awkward workarounds because you will never be able to refer directly to whatever the game decides the player meant for a given command. Also, putting every known thing in scope might impact the performance of your game if you end up having a lot of known things.

If you are planning a game of any significant size, and you want to be able to refer to objects during conversation, you would probably do best to define a new action that is set up to handle both a noun and a second noun. Consider this adaptation of your code:

[code]“Test Error”

A thing can be known or unknown. A thing is usually unknown. After printing the name of a thing (called item): now the item is known.

Querying it about is an action applying to one thing and one visible thing.

Understand “ask [someone] about [any known thing]” as querying it about.
Understand “ask [someone] about [any unknown thing]” as a mistake (“You have no reason to ask [the noun] about something you haven’t seen around [their] place.”).

Colin’s Studio is a room. Colin’s Ensuite Bathroom is north from Colin’s Studio.

The magazine is in the Bathroom.

Colin is a man in Colin’s Studio.

After querying Colin about the magazine:
say “Magazine… Ahhh…”

Test me with “ask colin about magazine / n / s / ask colin about magazine”.[/code]

The [any known thing] and [any unknown thing] tokens are built into the grammar definitions of the action, which means you don’t have to mess around with scope – it’s handled automatically.

0 Likes

#4

Hi Mike,

Although I am sure that your code is the solution to my problem, I don’t understand why the second noun is given as a “visible thing” in the definition of querying it about. I can see it is working, but I don’t understand why, since the magazine is known but not visible, when we ask Colin the second time.

If I delete the word “visible” from the querying-it-about definition, I get (once the magazine is known):

… which doesn’t make much sense to me either.

0 Likes

(Brian K) #5

“Visible thing” has kind of a weird meaning in Inform 7. See this chapter of the manual: inform7.com/learn/man/WI_12_17.html

0 Likes

(Andrew Plotkin) #6

A common question, because the word “visible” is used in a confusing way here.

In the definition of an action, objects can be marked as “touchable” (the default) or “visible”. “Touchable” means “For this action, check that the object is within reach”, that is, in the same room and not sealed up in a container or anything like that. “Visible” means “Skip the reachability check.”

(It’s hard to come up with better terms without using double negatives. “Reachable-only” and “reachable-or-not”, I suppose. You want reachable-or-not for this action.)

The “any” expands the definition of what the action can see (to the entire game), but doesn’t affect the definition of what it can reach.

0 Likes

(Andrew Plotkin) #7

Note that we’re just talking about action definitions here. If you write a rule like “Every turn when the basilisk is visible”, the word “visible” means what you’d expect.

0 Likes

#8

Hey, thanks,

I read about 20 times Brian’s link (§12.17. Visible vs touchable vs carried) as well as zarf’s reply and I think I understand the tricky definition of visible when defining actions.

So the “any” is the one doing the trick, since it works as bringing the item in scope, right?

Zarf, I didn’t get this part. I can see what you mean by “reachable-only,” although I don’t know how inform would understand this -as something reachable but not visible? Due to darkness, for example?

I don’t understand what you mean by “reachable-or-not,” though.

Are you talking hypothetically or is “reachable-only” something that one can actually define as a noun for action?

0 Likes

#9

Oh, another question is, I guess, why do we need the first noun of “querying it with” to be touchable? The default for talking to a character is for the character to be touchable? Can’t we talk to a character when she is in a transparent container, for example?

0 Likes

(matt w) #10

Well, not quite. As I understand it, this is how things work:

Some things are in scope. These include things that can be seen according the normal visibility rules (in the same room, not in opaque containers, and so on–it’s pretty complicated), as well as things that we have placed in scope with an “After deciding the scope of the player” rule. These are also the things that count as visible. (So in this way the word “visible” in “visible thing” does mean the same thing as "if the basilisk is “visible”–they’ll both work whenever the thing in question is in scope.)

Ordinarily, the parser will only bother to check things that are in scope, and anything else will yield a “you can’t see any such thing” error. That’s because an Understand line that contains a “[something]” token only works on things that are in scope. But if you define an Understand line with “[any thing]”, the parser won’t bother with the scope check and will run through every thing in the model world, in scope or not.

This all happens when the command is being parsed into an action. Once it’s parsed into an action, if the action is defined as applying to “one thing,” it goes through reachability checks to see whether you can touch the object. If it’s defined as applying to “one visible thing,” it doesn’t bother with the reachability checks–as long as the command is parsed into an action, the action can proceed.

Maybe think of it this way:

“a thing”=a thing that is reachable. (What zarf defined as “reachable-only,” meaning “only reachable things can be used.” This isn’t a technical Inform term.) These will almost always also be visible.
“a visible thing”= a thing that is in scope, whether or not it’s reachable. (What zarf defined as “reachable-or-not.”)

Which basically gives three layers of accessibility:
“[any thing]” token + action defined on “a visible thing” = the parser doesn’t bother to check scope and the action rules don’t bother to check reachability, so the action really works on anything.
“[something]” token + action defined on “a visible thing” = the parser only goes over things in scope, but then the action rules don’t check reachability. So the action will work on things in transparent closed containers and things that have been added to scope, but not on things that are just far away.
“[something]” token + action defined on “a thing” = the parser only goes on things in scope, and then the action rules check reachability. So if you have something in a transparent container, or something that’s been placed in scope but in another room, the acciton will fail with a message about how you can’t reach into the container/other room (unless you make reaching inside/outside rules that allow access).

Here’s an example of those three kinds. Scrying is defined with an “[any thing],” so it works even on the rock which isn’t in scope; examining is defined with “[something]” and applies to one visible thing, so it works on the beacon which is added to scope but not the rock which isn’t in scope; taking applies to one thing, so it fails for the beacon (although it’s understood). Note that when we scry the rock, it’s invisible, because it’s not in scope.

[code]Lab is a room. Closet is a room. A rock is in closet. A brightly glowing beacon is in closet.

Scrying is an action applying to one visible thing. Understand “scry [any thing]” as scrying.

Report scrying: say “[The noun] is [if the noun is not visible]in[end if]visible.”

After deciding the scope of the player: place the beacon in scope.[/code]

[Edited on Sept. 9, 2017: Deleted a stray sentence and a half at the end.]

0 Likes

** Programming error: tried to find the "." of (something) *
commands referring to things not present
#11

The way I understand it, adding “any” to a grammar token means that when the parser is working out what you mean, it considers anything that matches the token’s description to be in scope for the duration of that action. So when you use a token like [any known thing], all known things are considered to be in scope for the purposes of that action.

That’s why you specify a “visible” thing in the action definition, because when considering that grammar line, every known thing is visible (because it’s in scope). Yeah, the touchable vs. visible distinction is sort of weird. Touchable is a subset of visible; if a thing is touchable, it is always visible, but the reverse is not always true. A thing could be in a closed, transparent container, for example, or it could be brought into scope by a rule or an [any] token. One way to look at it is: when an action applies to “one touchable thing” and “one visible thing”, what that really means is “one thing that must be touchable” and “one thing that need only be visible”.

By the way, to answer your question: the first noun of the querying it about action doesn’t need to be touchable. I was just being lazy, assuming that the conversations in your game would always be with NPCs who are in the same room as the player. But you can just as easily define querying it with as an action applying to two visible things, and then use situational rules to bring Colin into scope when you’re talking to him over an intercom.

0 Likes

#12

Guys, thank you all; this is pure gold!

0 Likes