Kinds of Actions

There seems to be an issue with using multiple kinds of actions in a rule. Given the following:

The Theater is a room.
The Backstage is a room. It is south of the Theater.
The Curtain is a backdrop. It is in the Theater and the Backstage. 
The description is "The dust-filled, 69,105 ounce curtain hangs from several threads in the rigging." The printed name is "curtain".

Climbing the Curtain is curtain-disturbing.
Pulling the Curtain is curtain-disturbing.
Pushing the Curtain is curtain-disturbing.

Rubbing the Curtain is curtain-testing.
Touching the Curtain is curtain-testing.
Turning the Curtain is curtain-testing.

Instead of entering the Curtain in the Theater:
	try going south.

Instead of entering the Curtain in the Backstage:
	try going north.

test one with "x curtain / climb curtain / push curtain / pull curtain / clean curtain / touch curtain / turn curtain / open curtain / close curtain / enter curtain".

I can write a rule that includes more than one action name:

Instead of opening or closing the Curtain in the Theater:
	say "You have to move backstage (south) to do that."

Instead of closing the Curtain in the Backstage:
	say "The only apparent way to close it is to pull it."

Instead of opening the Curtain in the Backstage:
	say "It is."

I can write rules that refer to a kind of action:

Instead of curtain-testing in the Backstage:
	say "You [parser command so far]. In response trillions of dust particles float down and bury you."

Instead of curtain-disturbing in the Backstage:
	say "You [parser command so far]. In response the threads holding it in place snap and the entire weight comes crashing down and crushes you."

What I can’t do, apparently, is write a rule that refers to more than one kind of action:

Instead of curtain-testing or curtain-disturbing in the Theater:
	say "I wouldn't do that if I were you!"

This rule compiles without incident, but the result is not what I expected. That is, only curtain-testing actions get the response “I wouldn’t do that if I were you!” Curtain-disturbing actions get the standard action response.

The I6 code generated for the above rule is:

[ call_U1961;
    if ((((call_U1970)()) && ((((actor == player)) && ((real_location == I_theater_U1)))))) {
        (self = noun);
        if (debug_rules) {
            DB_Rule(call_U1961, 800, 0);
        }
        (say__p = 1);
        ParaContent();
        print "I wouldn't do that if I were you!";
        print "^";
        RulebookFails(0, 0);
        rtrue;
    } else {
        if ((debug_rules > 1)) {
            DB_Rule(call_U1961, 800, 2);
        }
    }
    rfalse;
];
[ call_U1969;
    if ((((action == ##Climb)) && ((noun == I_curtain_U1)))) {
        rtrue;
    }
    if ((((action == ##Pull)) && ((noun == I_curtain_U1)))) {
        rtrue;
    }
    if ((((action == ##Push)) && ((noun == I_curtain_U1)))) {
        rtrue;
    }
    rfalse;
];
[ call_U1970;
    if ((((action == ##Rub)) && ((noun == I_curtain_U1)))) {
        rtrue;
    }
    if ((((action == ##Touch)) && ((noun == I_curtain_U1)))) {
        rtrue;
    }
    if ((((action == ##Turn)) && ((noun == I_curtain_U1)))) {
        rtrue;
    }
    rfalse;
];

Running the test script shows that curtain-testing actions get the response “I wouldn’t do that if I were you!”, while curtain-disturbing actions get the default action response. So, is this a bug or a feature?

I’m not sure I understand the issue:

What I can’t do, apparently, is write a rule that refers to more than one kind of action:

Instead of curtain-testing or curtain-disturbing in the Theater:
	say "I wouldn't do that if I were you!"

This rule compiles without incident, but the result is not what I expected. That is, both curtain-testing and curtain-disturbing actions get the response “I wouldn’t do that if I were you!”

Since the rule preamble says it applies to both testing or disturbing, and the output fires for both testing and disturbing behavior, the result seems like what I would expect – what were you hoping this rule would do?

EDIT: wait, I see in your final line that when you test it looks like the rule isn’t firing for disturbing actions, so maybe there was a missing “not” in the above? Either way I’m still a bit confused since when I paste in your code I get the custom response both times.

1 Like

The expected result is:

>climb curtain
I wouldn't do that if I were you!

>touch curtain
I wouldn't do that if I were you!

The actual result is:

>climb curtain
Little is to be achieved by that.

>touch curtain
I wouldn't do that if I were you!

I should point out that the following produces the desired effect.

Instead doing something with the Curtain in the Theater:
	if the current action is curtain-disturbing or the current action is curtain-testing:
		say "I wouldn't do that if I were you!" instead;
	otherwise:
		continue the action.

My only question was whether the construction I used was broken or unsupported.

Yes. I only proof-read the post three times.

1 Like

This is what your code is producing in 6M62:

Theater

>TURN CURTAIN
I wouldn't do that if I were you!

>PULL CURTAIN
I wouldn't do that if I were you!

>s

Backstage

>TURN CURTAIN
You turn the curtain. In response trillions of dust particles float down and bury you.

>PULL CURTAIN
You pull the curtain. In response the threads holding it in place snap and the entire weight comes crashing down and crushes you.

The equivalent logic for testing the action is:

[ R_839 ;
	if (((((NAP_0()) || (NAP_1())) &&  (actor==player) && ((real_location == I148_theater) && (true))))) { ! Runs only when pattern matches
	...
	say__p=1;! [3: ~I wouldn't do that if I were you!~]
	ParaContent(); print "I wouldn't do that if I were you!"; new_line; .L_Say8; .L_SayX8;RulebookFails(); rtrue;
	...

where NAP_0() and NAP_1() are the equivalent of call_U1969() and call_U1970().

If you’re sure that you’re looking at the right I6 segment (i.e. no stray rule definitions with the same response), then it does look like buggy output from the 10.1.2 compiler.

P.S. If there was a typo in your original post, you can edit the post to correct it. I was having trouble understanding the problem, too.

1 Like

Ah yeah, I tested in 6M62 as well, where this works, but in Inform 10 I’m also getting the same incorrect result. So looks like maybe something broke between versions – tagging in @Zed to see if this is already being tracked!

I’m not seeing this. The posted code gives me:

Release 1 / Serial number 250116 / Inform 7 v10.1.2 / D

Theater

>climb curtain
I wouldn't do that if I were you!

>touch curtain
I wouldn't do that if I were you!

>turn curtain
I wouldn't do that if I were you!

>pull curtain
I wouldn't do that if I were you!

>s

Backstage

>turn curtain
You turn the curtain. In response trillions of dust particles float down and bury you.

>pull curtain
You pull the curtain. In response the threads holding it in place snap and the entire weight comes crashing down and crushes you.

EDIT: Okay, I just tried it in the Borogove app and got the buggy output.

just filed I7-2586

3 Likes

When I use this code (from your bug report):

lab is a room.
thinking is arid.
jumping is dank.
instead of arid or dank: say "foo"

test me with "jump / think / z"

I get this (using the IDE):

Intfic2
An Interactive Fiction by Bad Parser
Release 1 / Serial number 250116 / Inform 7 v10.1.2 / D

lab

>test me
(Testing.)

>[1] jump
foo
>[2] think
foo
>[3] z
Time passes

This appears to be the correct, intended behavior. The behavior in the Borogove app is indeed incorrect, but I thought that wasn’t using the latest compiler. Is that not true? In both cases I’m compiling to Glulx. Why would the outputs be different?

My bug report was based on a recent development version. Borogove offers all of 8.5/6G60, 9.3/6M62, and 10.1. You can choose which in Settings. It defaults to 6M62. This code behaves in 6M62 but not in 10.1+.

Oh, okay, that explains your bug report – thank you for that.

But it doesn’t explain the OP’s original issue (unless @A_J_Mako is using the development version) or @DeusIrae’s confirmation. What I’m saying is that the code behaves in 10.1.2 (see above) just not in the Borogove app. When I go to settings there, it lists “10.1.0” as a compilation option, but the output indicates it’s using 10.1.2:

Untitled
An Interactive Fiction
Release 1 / Serial number 250116 /  Inform 7 v10.1.2 / D
 
lab
 
>test me
(Testing.)
 
>[1] jump
foo
>[2] think
What a good idea.
1 Like

I’m using the Windows IDE, version 10.1.2.20220830, if that helps (just triple-checked and nope, doesn’t work).

Yeah, same here with Windows 10.1.2, ng

1 Like

Windows IDE, version 10.1.2.20220830, language version “Current”.

1 Like

Using:
Inform 7 v10.1.2
Mac IDE 1.82.3

This bug does not present itself when compiling either to Glulx or Z-code (v.8). Can anyone with a mac version of Inform confirm this for me?

This is important because it indicates that the compilers shipped with the mac and Windows versions are slightly different.

I checked this on 10.1.2 on both Mac and Windows, and got the same result:

lab is a room.
thinking is arid.
jumping is dank.
instead of arid or dank: say "foo"

test me with "jump / think / z"
>test me
(Testing.)

>[1] jump
foo
>[2] think
What a good idea.

>[3] z
Time passes.

1 Like

Okay, I’m obviously going crazy. Can anyone explain this?

nope, I’m stumped. Mind posting your auto.inf (you’ll have to add a .txt suffix) please?

Ok.
auto.inf.txt (2.3 MB)

Well, your auto.inf has what looks like the correct logic:

    if ((((((call_U1963)()) || ((call_U1962)()))) && ((actor == player)))) {

Whereas mine does not:

    if ((((call_U1963)()) && ((actor == player)))) {

There are no other differences between the auto.inf files (except the UUID).

I don’t think there’s any way you could be using a different version of the I7 compiler. Maybe it has some nondeterministic behavior? (That is, a bug where it’s relying on an uninitialized variable.)

1 Like