Check rules don't seem to be sorted?

Hi, all. I’m using the Linux command line version of Inform 7, the “i7” utility. Is it just me, or are check rules not sorted by specificity?


"Example" by "Jaime".

Using is an action applied to one carried thing.
Understand "use [something]" as using.
Check using something: say "Can't get it to work." instead.
There is a room called the Test Room.
In the Test Room is a Test Thing.
Check using the Test Thing: do nothing.
Report using the Test Thing: say "It worked.".

Typing “use test thing” produces “Can’t get it to work.”

Workarounds I know of:

  • Instead of carry out and report, use instead rules to provide specific implementations of actions. This workaround seems to be standard, but I dislike it because it doesn’t make sense semantically for someone to successfully do a thing “instead of” doing that same thing.
  • Give things properties indicating whether particular actions are possible on them and simply account for these properties in the generic check implementation. This workaround works fine for single-object actions, but falls short for multiple-object actions, because to my knowledge, multiple things cannot share a property between them.

One idea I had was to simply make a new rulebook and have it somehow be synonymous with instead, so that I could have something like “when using the test thing” equate to “instead of using the test thing” – just for my sanity’s sake --but I can’t find any info on creating any such “rulebook synonym.”

Is this normal behavior for the check rules? It seems undesirable. Does anyone have any other ideas on how to get around it?

The RULES command will reveal what’s happening here: the “check using the test thing” rule will run, then it’ll “make no decision” (aka allowing the action to continue)…so then the “check using something” rule will run, and will end in failure due to the “instead”, stopping the action.

Thanks. That was it, but now there’s another problem. I tried replacing “do nothing” with “rule succeeds” to correct the issue, but now, nothing is printed at all. According to the rules trace, the more general check rule is appropriately skipped – since the more specific one succeeded – but for some reason, the report rule is also skipped. Could you enlighten me as to what’s going on here and how I could fix it?

It’s just that every Check rule for the action runs, in specificity order, unless one stops the action. There isn’t any facility (that I know of) for having a Check rule say “Skip the rest of the check rules and go straight to Carry Out.”

The simplest fix is probably to change the Check rule so it checks whether you’re using the Test Thing:

Check using something when the noun is not the Test Thing: say "Can't get it to work." instead.

…ok, I see that this is basically your second workaround. Although two things can’t share a property, two things can be related by a relation, so maybe that’s what you want here. So you could define a desiring relation with the verb “to desire,” and if you had a “tempting with” action you could do this:

Check tempting someone with something when the noun does not desire the second noun: say "[The noun] spurns your sad offering."

Thank you. That’s a great idea and suits my need perfectly. I must have somehow overlooked the chapter on relations; I was getting ready to go full ham and define a totally extraneous global three dimensional matrix for storing data on what combinations of things were viable for what two-object actions.

The idea of check rules being conjunctive like that makes a lot more sense actually. I’m glad to know that now.

Great, glad to hear it worked!

I forgot to explain the “rule succeeds” thing; “rule succeeds” tells the rulebook to stop with value “success” (or something like that), which makes the entire action stop with value “success.” That’s why none of the carry out rules were running. It’s kind of like you had a “return true” as I understand it.

About conjunctive rules, basically “instead” and “after” rules are the rulebooks that aren’t conjunctive in that sense–every Instead rule fails unless told otherwise (by “continue the action,” usually) and every After rule succeeds unless told otherwise. Other rules will by default make no decision, so the entire rulebook gets run through in specificity order. Also the difference between an action succeeding and failing often isn’t that important.

Here is a way of doing it without resorting to I6 hackery, though it’s clunky–it just hijacks the action processing. (I can’t think of any reason this would be a good idea.)

Check using the test thing:
        abide by the validate action rule.

This is the validate action rule:
	follow the carry out stage rule;
	abide by the after stage rule;
	follow the investigate player's awareness after action rule;
	follow the report stage rule;
	rule succeeds.