Hundredth idiotic question.

Authoring Inform 7
1

This doesn’t work.

[code]The Hut is a room. “This is a hut.”

A steel bar is in the Hut.

A cut in the wall is a container in the hut. “There is a cut in the wall.” It is fixed in place.

Instead of unlocking the cut in the wall with the steel bar, say “ok!”.

Instead of opening the cut in the wall, say “Not with bare hands. Impossible.”[/code]
Ofc, I can “unlock” the cut in the wall (“open cut with bar”, don’t mind it actually doesn’t open, the SAY result is enough).

When I try “OPEN CUT” it either says “it’s already open/that’s not something you can open” and so forth, depending if I made it openable, open, closed or whatever.

Keep in mind I don’t want it to really open. BUT, I want a particular thing to fit inside (the bar, in the given example). So, saying it is a closed container will make things difficult and the parser will try to open it when I “put bar in cut”.

— So far I’ve tried a before rule, an instead. Even a check and a carry out.
I don’t seem to be able to give a custom response to the player as the parser keeps doing the job for me.

Where am I wrong?

Thank a lot for the help. :slight_smile:

2

Try this:

Instead of opening when the noun is the cut in the wall, say "Not with bare hands. Impossible."

Don’t know why that syntax is required, though.

3

This also seems to work:

Instead of opening the cut, say "Not with bare hands. Impossible."

So I think what’s going on is that the preposition “in” is confusing the I7 compiler somehow. (This is based on my experiences with a lot of room names with “and” in their names, like “Body and Blood of Christ Church” and “Gun and Knife Emporium,” which seemed to make the compiler cry salty tears unless I used partial names.) At an even less educated guess, maybe the compiler is parsing it as something like this:

Instead of opening the cut [in the wall when] in [the cut in] the wall

– in other words, both “the cut” and “the wall” are separately getting translated as “the cut in the wall,” and the “in” is getting translated as a modifier somehow. But someone would probably have to look at the I6 that this gets compiled to in order to check my hunch.

4

Grrr. Yes, and I shoulda thought about it.

The funny part is that the cut in the wall worked fine with 30 lines of code and goes broken just for the opening instance.

Calling the item cut_in_the_wall with printed name “cut in the wall” and (wtf!) understand “cut/wall”, “cut in the wall” solves it.

Thx for the help guys.

5

Well, I sure wouldn’t have known that this would cause trouble in advance. It was only when Felix posted his solution that I realized what was going on.

(By the way, “Not with your bare hands” is more idiomatic.)

6

Thanks, but I’ve shoulda thought about it. It’s like the 21.563th time I get error messages due to stange object namings. It’s usually about that…
Thx for the comfort, anyway. :slight_smile:

Thanks! I don’t wanna be in my proofreaders’ shoes…