Specificity for scene ending rules works differently than it does for normal rulebooks?

Authoring Inform 7
1

I was trying to work out a scenelet to handle certain interactions:

Shrugging is an action applying to nothing. Understand "shrug" as shrugging.

Saying yes is question-answering.
Saying no is question-answering.
Shrugging is question-answering.

Question posed is initially false.

Awaiting Response is a recurring scene.
Awaiting Response begins when question posed is true.
Awaiting Response ends affirmatively when saying yes and time since Awaiting Response began is 1 minute.
Awaiting Response ends negatively when saying no and time since Awaiting Response began is 1 minute.
Awaiting Response ends inconclusively when question-answering and time since Awaiting Response began is 1 minute.

Every turn when Awaiting Response is not happening:
	say "A question is posed!";
	now question posed is true.

(Yes, I’m aware that this example code creates the possibility for Awaiting Response to never end. This is a stripped down example to show a specific issue.)

The problem is that saying yes or saying no both result in the scene ending inconclusively. This is not expected since the individual actions are more specific than the kind of action (question-answering) to which they belong. The normal rules for rule precedence don’t seem to be applying here.

By comparison, if the following is added:

Response reaction is a rulebook. The response reaction rulebook has default success.

Every turn: follow the response reaction rules.

Response reaction when saying yes: say "react to: Yes."
Response reaction when saying no: say "react to: No."
Response reaction question-answering: say "react to: Shrug."

then rule precedence in the response reaction rules is working as expected:

>Z
Time passes.

A question is posed!

>SCENES
Scene 'Entire Game' playing (for 1 mins now)
Scene 'Awaiting Response' playing (for 0 mins now)
(Scene monitoring now switched on. Type "scenes off" to switch it off again.)

>YES
That was a rhetorical question.

react to: Yes. [<-- the saying yes action gets precedence over question-answering]

[Scene 'Awaiting Response' ends]
[Scene 'Awaiting Response' ends inconclusively] [<-- the saying yes action does NOT get precedence over question-answering]
[Scene 'Awaiting Response' begins] [<-- also aware of this immediate restart; only affects stripped-down example]

Is this a bug?

2

I don’t know if it’s a bug or an undocumented behavior. Looking at the auto.inf file, it looks like these conditionals:

Awaiting Response ends affirmatively when saying yes and time since Awaiting Response began is 1 minute.
Awaiting Response ends negatively when saying no and time since Awaiting Response began is 1 minute.
Awaiting Response ends inconclusively when question-answering and time since Awaiting Response began is 1 minute.

Are being compiled in reverse order of declaration (ignoring precedence entirely).
Moving the last one (“inconclusively”) to first in the code results in:

>y

That was a rhetorical question.

[Scene ‘Awaiting Response’ ends]

[Scene ‘Awaiting Response’ ends affirmatively]

[Scene ‘Awaiting Response’ begins]

>no

That was a rhetorical question.

[Scene ‘Awaiting Response’ ends]

[Scene ‘Awaiting Response’ ends negatively]

[Scene ‘Awaiting Response’ begins]

>shrug

[Scene ‘Awaiting Response’ ends]

[Scene ‘Awaiting Response’ ends inconclusively]

[Scene ‘Awaiting Response’ begins]

So I guess the answer is, “Yes, but I don’t think it should work that way.” :man_shrugging:

1 Like
3

Very interesting! I guess I’ll just have to bear the apparent reverse ordering in mind.

Thanks, BadParser – that possibility didn’t even occur to me.

1 Like
4

That’s not even a rulebook, so I wouldn’t expect it to follow rulebook specificity…