...instead

[VictorGijsbers]

Let’s look at these two pieces of code. First piece:

A piercing rule: say "FAIL!" instead.
Second piece:

A piercing rule: say "FAIL!"; rule fails.
Now, the manual section 18.10 says

… instead; means “end this rule in failure”

and it also says:

[“rule fails”] causes the current rule to end immediately, with its outcome considered to be a failure.

So these two pieces of code should be identical. Right? But they are not. If I consider the piercing rules, and then have an “if rule failed” clause, the clause will fire when the second piece of code is used but not when the first piece of code is used.

This leaves me confused. Is there an explanation for this phenomenon?

[Ron_Newcomb]

possible bug? The first is missing it’s RuleFails() call … or a RuleSucceeds() call, or whatever.

! No specific request ! This is the first-piercing rule: [ R_740 ; ! phrase 1 ! [1: say ~FAIL!~ instead] say__p=1;ParaContent(); print (PrintText) SC_32; new_line; rtrue; .L_Say47; .L_SayX47; rtrue; rfalse; ]; ! No specific request ! This is the second-piercing rule: [ R_741 ; ! phrase 1 ! [1: say ~FAIL!~] say__p=1;ParaContent(); print (PrintText) SC_32; new_line; .L_Say48; .L_SayX48; ! phrase 2 ! [2: rule fails] RulebookFails(); rtrue; rfalse; ];

[zarf (Andrew Plotkin)]

There are two cases here, although the manual isn’t clear about it.

“instead …” means to exit the rule, with a value that halts the rulebook. “rule fails” means to end rule and the rulebook, setting the rulebook’s result to failure.

“stop” is equivalent to the “instead …” case.

[VictorGijsbers]

Hm, I guess I should file a report about the documentation then. Is there a reason for this behaviour? I.e., would anything be broken is “… instead” behaved just like “rule fails”?

[Ron_Newcomb]

That makes me nervous since whether an NPC’s Check rule ends with rule fails or rule succeeds determines whether the Unsuccessful Attempt rules fire. A bare rtrue isn’t setting the success/fail value one way or the other.

[capmikee]

In light of this discussion, I’ve decided to always use “stop the action” when a check rule prints a refusal, and only use “instead” in a check rule when trying a different action.

[bukayeva]

@capmikee

In light of this discussion, I’ve decided to always use “stop the action” when a check rule prints a refusal, and only use “instead” in a check rule when trying a different action.

Here’s another really useful heuristic based on how Inform works. I asked this in another thread but I’ll ask here as well: are any of these little design notes or design considerations documented anywhere? It sounds like the manual may not always be the best place to go for this kind of thing.

[VictorGijsbers]

@bukayeva

are any of these little design notes or design considerations documented anywhere?

Not really; there is no Inform Designer’s Manual for Inform 7 yet. (As there was for Inform 6.) I suspect this will come once Inform 7 is out of beta, but who knows how long that will take?

[bukayeva]

@VictorGijsbers

Not really; there is no Inform Designer’s Manual for Inform 7 yet. (As there was for Inform 6.) I suspect this will come once Inform 7 is out of beta, but who knows how long that will take?

Interesting; I didn’t even see that Inform was in beta. Is the “Writing with Inform” or the “Recipe Book” manuals that come with Inform 7 not meant to be the equivalent of the older “Inform Designer’s Manual”? I think it still might benefit people for those who know the design heuristics to write them down in one central place. That central place can be updated if something changes as a result of moving from beta to general release. Maybe a wiki page or even a sticky forum thread?

[Erik_Temple]

Graham Nelson’s chapter in the IF Theory book seems to indicate that I7 is actually no longer in public beta, having “graduated” a few build ago. Still, I think that the primary development thrust remains on the software rather than on a complete retooling documentation, which as others have said will likely wait until the pace of addition of new features has slowed.

–Erik

[bukayeva]

@ektemple

Graham Nelson’s chapter in the IF Theory book seems to indicate that I7 is actually no longer in public beta, having “graduated” a few build ago. Still, I think that the primary development thrust remains on the software rather than on a complete retooling documentation, which as others have said will likely wait until the pace of addition of new features has slowed.

Given Inform 7’s emphasis on executable documentation within the manual, I would think it would actually be smarter to have an acceptance-based development approach, where the documentation guides the development of the software features. Then the documentation always serves as a true test, both feature and regression. It seems like this is sort of done but not as a full design process. So documentation should definitely come first but I also don’t really know the makeup of Inform’s development team. If the team has any understanding of agile practices, that would probably be the way to go.