Reworking the "can't see any such thing" parser error

Authoring Inform 7
1

Hello everyone,

I’ve been trying to do something in my game and I’m wondering if it is possible rework the “can’t see any such thing” parser error to make it specific to certain actions.

For example, if I wanted “Examine lampp” to return one response, but “Eat cheeese” to return a different one.

I’m running into some trouble. I’d rather not use “if the player’s command includes…” line, because that would make it difficult to refer to actions that have short synonyms (like “x” for “examine”).

I actually want to do this for some actions that I’ve created, because sometimes “You can’t see any such thing” doesn’t make a lot of sense with some of my custom verbs.

But I’ll stick to using standard actions for my examples to keep this simpler.

This is what I tried, but it didn’t work:

Rule for printing a parser error when the latest parser error is the can't see any such thing error:
	if the current action is examining:
		say "I'm not sure what you're trying to examine." instead;
	otherwise:
		say "You can't see any such thing." instead;

“Examine (gibberish)” just defaults to the “You can’t see…” response.

So I decided to try this, just to see what would happen:

Every turn:
	if the current action is examining:
		say "You saw it!";

That produced the correct response to “Examine me,” but not to “Examine (gibberish).”

So my assumption is that Inform is preventing a current action from being stored if there is a parser error. I think the documentation said something about waiting being the default current action. So, I tried this:

Rule for printing a parser error when the latest parser error is the can't see any such thing error:
	say "[the current action]" instead;

That did produce “waiting” as the response to “x (gibberish).”

So, is there a way to do what I’m trying to do?

2

There are ways, and which one to go with depends on how complex your needs are.

The mistake mechanism is the easiest:

Understand "examine [text]" as a mistake ("I'm not sure what you're trying to examine.").

(search the phrase ‘as a mistake’ in the docs for more examples)

This way also has the benefit that shorthand versions of commands that are replaced by Inform with their longer versions, like “x” for examine, also trigger the same mistakes.

So if the actions you want custom responses for aren’t of the form (verb text), it’s easy to write a bunch of mistake catches for them and not even fiddle with the Rule for printing a parser error when the latest parser error is the can’t see any such thing error.

The next resort might be fiddling with that rule. You can use regular expressions if you can stomach them, or just scan the command for matching words. The ‘player’s command includes’ check that you were mentioning can be too broad a sword. There are other match tests, like

if word number 1 in the player's command is "examine":

where you at least know that you’re getting text that is a word bounded by spaces, or the start or end of the command. I know the case of ‘examine’ is a redundant one here because that’s probably easier to handle as a mistake, but I’m just sharing the ‘word number blah’ parlance. Have a look at Chapter 20 in the docs on Advanced Text for more such tests.

-Wade

1 Like
3

You can try using this I stole from @Draconis 's post here.

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

As in:

The Lab is a room.

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

Before printing a parser error:
	say "(working on [action-to-be]).".
	
Rule for printing a parser error when the latest parser error is the can't see any such thing error:
	if the action-to-be is the examining action:
		say "I'm not sure what you're trying to examine." instead;
	otherwise:
		say "You can't see any such thing." instead.
		
test me with "x box / get box / take box / drop box".

Note that the action-to-be will be whatever the parser tries first, which won’t necessarily be the one you might assume. Note how the example treats “get/take” and “drop” as “removing it from” and “putting it on” respectively.

2 Likes
4

When a parser error is triggered, parsing has not been completed, so the current action is not set.

BadParser already mentioned action_to_be, and its drawback.

You might instead set up a “catch-all” object:

The nonsense item is thing. Understand "[text]" as the nonsense item.

After deciding the scope of the player:
	place the nonsense item in scope.

Before examining the nonsense item:
	say "*You can't see any such thing."; [better to use the normal response text, perhaps]
	stop the action.

Before taking the nonsense item:
	say "There's nothing like that to take around here.";
	stop the action.

Test error with "x xyzzy / take plugh".

(Note use of the before rulebook to get ahead of accessibility checks.) The drawback here is that a complete action is parsed, so the normal turn sequence rules will apply, unlike with a genuine parser error. There are ways around that:

Doing something to the nonsense item is imaginary action.
Doing something with nonsense item is imaginary action.

The advance time rule does nothing when imaginary action.
The declare everything initially unmentioned rule does nothing when imaginary action.
The generate action rule does nothing when imaginary action.
The every turn stage rule does nothing when imaginary action.
The timed events rule does nothing when imaginary action.
The advance time rule does nothing when imaginary action.
The update chronological records rule does nothing when imaginary action.
The adjust light rule does nothing when imaginary action.
The note object acquisitions rule does nothing when imaginary action.
The notify score changes rule does nothing when imaginary action.

And you will probably want a catchall rule as a backup:

Last before imaginary action:
	say "I'm not sure what you're referring to.";
	stop the action.

EDIT: For anyone looking at this, be advised that it causes problems with conversation. The reason is that it can cause entire sentences to be matched as the noun being addressed, e.g. >ALICE, TELL ME ABOUT BOB can match all six “words” (including the comma as its own word) to the nonsense item, resulting in failed parsing. Oh, well.

2 Likes
5

First, thank you so much for replying!

This solution that you provided worked with “examine” and “x.”

It also worked with my created verb, but not its shorthand. As an experiment, I tried this:

blorking is an action applying to one thing.

Understand "blork [something]" and "glark [something]" as blorking.

Carry out blorking:
	say "Nice blorking. Well done.";

Understand "blork [text]" as a mistake ("What are you doing?")

This is what happened when I tested it:

blork me

Nice blorking. Well done.

blork qd

What are you doing?

glark me

Nice blorking. Well done.

glark asd

You can’t see any such thing.

Why does it work with “X” when I only referenced “examine [text]” as a mistake, but it won’t recognize “glark [text]”?

6

Try this:

Understand "blork [something]" as blorking.
Understand the command "glark" as "blork".
7

Yes! That worked! Thank you so much for your help!

8

Well, I learned something new too. When you use a statement like:

Understand "blork [something]" and "glark [something]" as blorking.

Inform creates two verbs:

Verb 'blork' 
	* noun -> A_blorking 
	* Mistake_Token1 topic -> MistakeAction;
Verb 'glark' 
	* noun -> A_blorking;

While the statement I suggested creates a verb and a synonym:

Verb 'blork' 'glark' 
	* noun -> A_blorking 
	* Mistake_Token1 topic -> MistakeAction;

In case you were wondering why.

1 Like
10

Sorry, I messed up my first reply.

Thank you for sharing this, that’s a nifty bit of code. I’m going to keep that in mind for future use.

11

Thank you! There have been a lot of clever solutions here. I really appreciate everyone’s input.

12

Ah, I see.

The I7 documentation is great, but this is the kind of thing I’d never get on my own. Thanks so much for your help!