Weird crash when excluding kinds of behavior

Authoring Inform 7
1

As I’ve been learning more about Inform and what other authors do, I’ve been using ‘instead of doing anything other than…’ a lot.

I’ve also been using kinds of behavior a lot.

I had a weird crash I found today that really freaked me out due to just giving a ‘code 10’ error; I thought I had run out of data or something or that I had a hardware problem (which older stuff suggested), but I was able to narrow it down to a minimum example:

Toyroom is a room.

Looking is curious behavior.

The ball is a thing.

Instead of doing anything other than curious behavior to the ball:
	say "You're not interested in the ball";

This is before Inform 10. I plan on reporting it, but I don’t have Inform 10 installed. Does anyone who has it know if this still gives a crash?

1 Like
2

Hmm, I’m guessing it’s a typing issue, since looking doesn’t take an object. Or does it show up if you sub in an action that applies to one thing, like examining?

2 Likes
3

I tried it in 10.1.2. There, the compilation gets blocked with "**Problem.** You wrote 'Instead of doing anything other than curious behavior to the ball', which seems to introduce a rule taking effect only if the action is 'doing anything other than curious behavior to the ball'. But that did not make sense as a description of an action. I am unable to place this rule into any rulebook."

If I set 10.1.2 to act like 6M62, then we get a more cryptic fail with a code 11.

"**Translating the Source - Failed**

The application ran your source text through the Inform 7 compiler, as usual, but the compiler unexpectedly failed. This should not happen even if your source text is gibberish, so you may have uncovered a bug in the program..."

etc.

So I figure it won’t compile per se, it’s just that in 10.1.2 you get a more helpful fail message.

-Wade

1 Like
4

Changing it to examining doesn’t change the crash! But I didn’t know that until I tried it after your message.

Okay, the error message in 10.1.2 is great in my opinion, Wade, since that would have fixed my problem (i.e. not knowing which line had the error).

3 Likes
5

You can get the effect you want like this (if you haven’t already got it figured).

Toyroom is a room.

Examining is curious behavior.
Searching is curious behavior.
Looking under is curious behavior.

The ball is a thing in the toyroom.

Instead of doing anything with the ball when not curious behavior:
		say "You're not interested in the ball.";
		
Test me with "jump/x ball/search ball/look under ball/take ball".
2 Likes
6

Hmm, interesting. I wouldn’t have thought it would work like that!

7

You can put any condition you like in a when clause, but the compiler is more picky about what it will allow when parsing the earlier clauses of an action pattern- particularly when a named action pattern such as ‘curious behavior’ is involved.*

This works as written because a named action pattern on its own is a valid condition- ‘if curious behavior’ means the same as ‘if the current action is curious behavior’ or ‘if we are curious behavior’

These forms make more natural grammatical sense in English if the named action pattern is named with a gerund/present participle, e.g. ‘examining is behaving curiously’ => ‘when behaving curiously’, ‘if behaving curiously’ ‘if we are behaving curiously’.

* EDIT e.g. as noted recently, you can restrict actors using a ‘when’ clause even when they’re not allowed to be stated in the usual place when using a named action pattern:

Instead of Bob behaving curiously: say “Bob seems very interested in [the noun].” => not allowed

Instead of an actor behaving curiously when the actor is Bob: say “Bob seems very interested in [the noun].” => fine

3 Likes