Random question about generating a parser error response

At the recommendation of a tester, I’m reviewing parser responses in my game. I’m having difficulty soliciting one (or more).

How does the parser error internal rule response (D) get triggered (“I didn’t understand that number.”)?

Sorry if this is obvious, I poked around in the Standard Rules, but this is out of my wheelhouse.

It’s triggered when you’ve got an action applying to a number, and the player enters something that’s not a number.

The example “Safety” from 9.2. Bags, Bottles, Boxes and Safes contains this action:

Spinning it to is an action applying to one thing and one number.
[...]
Understand "spin [something] to [a number]" as spinning it to.

If the player enters “spin safe to bla”, for example, then the game will respond “I didn’t understand that number.”.

I don’t know if there are other circumstances which also trigger the message.

Great! I don’t know why that didn’t occur to me.

Thanks. I’ll mark this as solved, but may ask about other responses if I get stumped.

1 Like

To elaborate @StJohnLimbo’s point, the place I’ve often seen it come up is if you use menus (or extensions involving menus) – they usually allow the player to just type a number to select a menu option, which means there’s usually a “understand “[number]” as menu-selecting” statement or something like that. But that means if the player just types “bla” – usually when trying to enter a single-word command - you’ll likely get the confusing “I didn’t understand that number” response.

Solutions include either making sure that understand statement is conditional, so it’s only applied when the player’s actually looking at a menu, or just rewriting the parser response text so it’s more general and doesn’t specifically name-check a number.

2 Likes

In spite of my oversight, it’s generated by mangled footnote lookups in my game. Definitely could come up! I’m glad I asked.

Fortunately, the menu system I’m using is solid in that sense (I can’t take credit for that, of course).

1 Like

A few more. As always, apologies if I ought to know these.

The parser error internal rule response (F) “You seem to have said too little!”
The parser error internal rule response (G) “[We] [aren’t] holding that!”

Also, TIL learned that SAILOR, HELLO is a substitution for ANSWER HELLO TO SAILOR.

E: others

The parser error internal rule response (O) “That’s not something you need to refer to in the course of this game.”
The parser error internal rule response (P) “I didn’t understand the way that finished.”
The parser error internal rule response (R) “That noun did not make sense in this context.”

These are a pain to track down. After you find, say, The parser error internal rule [...] "That’s not something you need to refer to in the course of this game." (O) in the Standard Rules, you have to look for PARSER_ERROR_INTERNAL_RM('O' in Parser.i6t and then look for the associated etype, in this case SCENERY_PE and then look for where that’s assigned.

And F → TOOLIT_PE, G → NOTHELD_PE, P → JUNKAFTER_PE, R → NOTINCONTEXT_PE.

NOTINCONTEXT_PE only comes up, so far as I know, with a command with an understand line with an any token.

Lab is a room.
box is a container.
understand "xyzzy [any container]" as entering.
test me with "xyzzy box / xyzzy plugh / xyzzy me"

>xyzzy box
That isn’t available.

>xyzzy aoeuaoeu
That noun did not make sense in this context.

>xyzzy me
That noun did not make sense in this context.

So far as I’ve been able to tell (having done an exercise of trying to produce all the Standard Rules’ responses a while back), the others are vestigial. TOOLIT and JUNKAFTER don’t even appear to have been in use in the Inform 6 Library for years and years.

3 Likes

Thanks for this!

I seek these out in parser.i6t and am only finding TOOLIT_PE (for instance) in association with the error that led us to search out (F) and a constant, 6. Is that where the trail goes cold? I’m probably just beyond my skill ceiling at this point.

1 Like

Pretty much. When the parser produces one of these errors, it sets the etype variable to that constant. Then the “printing a parser error” activity looks at etype and prints the appropriate “parser error internal rule” responses. So to find what causes that error, you need to look for the place where etype is given that value.

Which, as you’ve found out, is never for most of these! These are not errors that the parser can actually produce in Inform 7. They are, as Zed put it, vestigial.

The only one that I have some interesting comment on is SCENERY_PE (not something you need to refer to in the course of this game). This was used back in the era of the early Z-machine, when object slots were precious, to give a more satisfying error than “you can’t see any such thing”. Instead of dedicating an object to it, you would tell the parser that those words were names for the room. Then, if the parser ended up with a room where an object was supposed to be, it would produce that error. A very clever solution, since the only room that’s in scope by default is the location, so only the scenery intended for the current location would be recognized.

2 Likes

I appreciate all the responses! I enjoy learning about this stuff, even if I don’t need to worry about getting the responses in-game.

Thanks everybody.

Being pedantic, no room is ordinarily in scope, including the location. At least not nowadays :wink:

Yeah, nowadays rooms aren’t in scope by default in I7. But in I6, the name and parse_name of the current room are(/were?) considered by NounDomain for the purpose of SCENERY_PE.

2 Likes