[one of] in mistakes with multiple responses

Authoring Inform 7
1

I’ve recently found what may not be a bug, and there’s an easy enough workaround, but I’m confused. This code snippet with 2 very similar-looking pieces of code shows what I saw.

understand "try 1" and "try 2" as a mistake ("[one of]First response[or]Second response[or]Third response[or]Fourth response[stopping].").

understand "try 3" and "try 4" as a mistake ("[the-text].").

to say the-text:
	say "[one of]First response[or]Second response[or]Third response[or]Fourth response[stopping]"

Here is a short test script.

>try 3
First response.

>try 4
Second response.

>try 1
First response.

>try 2
First response.

>

“try 3” and “try 4” behave as expected. However, I would expect try 2 to give “second response” based on my understanding of how [one of] works. But it does not. What I’m assuming is, “try 2” and “try 1” give different but identical “first/second response” text when run through the interpreter. Is there a reason for this? Or did it just happen?

The test case I found with try 1/2 is where I saw something unexpected, and try 3/4 makes for a trivial workaround. So I can’t say it’s a very big bug even if it is a bug. There are much more important things the Inform team wishes to address.

But I suspect someone else may run across it, so I wanted this up here. Plus I’m just generally curious what’s going on here, though it’s not a killer question.

2

What’s happening is that both >TRY 1 and >TRY 2 are being given their own independent version of the code set up by the mistake. Instead of sharing the same code (and therefore the same counter to keep track of which response to use), each command is getting its own counter.

It’s clearer if you attempt one of the commands several times before the other:

>TRY 1
First response.

>TRY 1
Second response.

>TRY 1
Third response.

>TRY 2
First response.

>TRY 2
Second response.
2 Likes
3

Thanks. I just looked into the I6 code and it’s neat to see what happens. It’s probably good to have that flexibility just in case, (e.g. we can be very granular and decide if we want to have a different counter for each possible text) so, after a bit of though, it seems like a good design choice.

For those curious about the guts of the auto.inf file, there’s Mistake_Token_163 (or some number) mapping to understand_as_mistake_number = 263 mapping to ParserError(text_routine_3).

1 Like