[Bug?] Instead rule doesn't trigger for room with multiple-word name

Authoring Inform 7
1

I’m kind of stumped. This code runs fine:

Museum is a room.

Instead of going west in Museum:
	say "Nope!".

But with this code, the instead rule never triggers:

Entrance to the Museum is a room.

Instead of going west in Entrance to the Museum:
	say "Nope!".

It’s Inform 10.1.2 for Windows. Is this a bug in Inform, or am I doing something wrong?

(It’s easy to work around, of course, by naming the room Entrance-to-the-Museum and giving it the correct printed name. But it bugs me.)

1 Like
2

Huh. I was sure you had created a spurious “entrance” or “museum” object. But that’s not what happened.

Best I can tell, the compiler matches this as “going west in (Entrance) to (Museum)”. But “Entrance” and “Museum” are both shorthand for the same room, the Entrance to the Museum. That is, the rule conditions require that the location and the room-gone-to are the same room. This never happens.

It’s not exactly a bug – it’s a consistent interpretation of what you wrote. Not what you wanted though.

5 Likes
3

This works:

Entrance to the museum is a room.

Instead of going west in (Entrance to the Museum):
	say "Nope!".

Looks like it occurs where there’s a “to” in the middle. Naming the room “To Museum” or “Museum to” works.

All of which follows from Zarf’s comment that included the actual explanation, which arrived right after I finished typing the above…

5 Likes
4

Of course I saw your name flashing the “typing…” signal and typed faster.

12 Likes
5

Thanks, that explains what happens. It’s perhaps still sort of a bug; I’ll report it in Jira, and Graham can decide whether to fix it or not. :slight_smile:

1 Like
6

Unfortunately, the general policy of I7 is that interpreting ambiguities in a valid-but-useless way is not a bug. I ran into an issue long ago where having an object with “inventory” in its name will prevent writing any rules about the “taking inventory” action, since that will always be interpreted by the compiler as “taking the inventory summary list” or whatnot. This was closed as working as intended, because it is a valid reading of an ambiguous description—even though there’s no way to get the intended interpretation (except to remove the word “inventory” from all your object names).

Fortunately, parentheses can resolve this one, even if they look a bit awkward.

2 Likes
7

I decided right at the beginning of I7’s history that I would always use “museum-entrance” hyphenated names, and thus shut off this entire area of potential nuisance.

2 Likes
8

This doesn’t work for me:

Entrance to the Museum is a room.

Instead of going west in (Entrance to the Museum):
	say "Nope!".
9

It doesn’t compile in I7 9.3/6M62, but should work in v10.1.2.

For 6M62, apart from the hyphenated-name method which was mentioned further above, one can alternatively use:

Instead of going west when the location is Entrance to the Museum:
	say "Nope!".

(Works in both 9.3/6M62 and 10.1.2.)

4 Likes