So I have some code to strip down parser errors as follows, so the player knows there are only a few verbs to try. And I have this, and it works, but it’s obviously a cheap trick.
[code]rule for printing a parser error when player is not off-stage (this is the simplify parser errors rule):
say “(general advice).”;
[/code]
I’d like to eliminate the “when” clause, because it’s sloppy.
The problem is, I’ve tried stuff like
the simplify parser errors rule is listed after the parse command rule in the turn sequence rulebook.
But that prints a parser error every time the player makes a recognizable move.
I haven’t fiddled with rulebooks much. What is it that I should be doing here? I’ve looked into Standard Verbs, but I can’t figure everything out.
My understanding of this is that your original declaration of the rule is enough to place it in the rulebook for the “printing a parser error” activity. Then your next line of code places it also in the turn sequence rulebook, where it fires whether or not that activity is taking place.
As far as I can see, the when clause is simply redundant; why can’t you just say this?
Rule for printing a parser error:
say "[Good advice]"
Yeah, I should kill the when clause. But I’m not sure 1) why the more general rule fires first even though it’s listed 2nd (even though a check going west will fire before a check going rule) and 2) how to order the rule in the rulebook.
Things work ok here, but I feel like I’m looking at something that, if I understand it better, might help me do more powerful stuff or even just organize code better in the future.
This really isn’t a rules order issue. When you explicitly placed your rule in the “turn sequence” rulebook, it fired every turn no matter what – because that’s what the turn sequence rulebook does. It runs through all of its rules every turn no matter what.
The “printing a parser error” activity only fires when a parser error is printed. It also starts out empty. When you declare a rule “for printing a parser error,” it automatically gets placed in the “for printing a parser error” rulebook, and since it’s the only one there, it doesn’t matter how it gets ordered.
The player can never be off-stage, and if something in your game tries to move the character off-stage it will cause a run-time error, so specifying “when the player is not off-stage” is also redundant.
So the simplest way to forumlate your rule is:
Rule for printing a parser error:
say "[Good advice]"
This will cause your [Good advice] message to print when (and only when) there is a parser error. That’s really all there is to it.
If I’m not mistaken (and I can be), the general pattern for activities is that any For (activity) rule that you write will run before the default behavior. This seems like it’s hitnted at in Writing with Inform §18.3 (emphasis added):
Since only one “for” rule ever runs for an activity, and the default behavior rule (if there is one) won’t have any “when” clauses attached, it wouldn’t be sensible to have a rule you write slotted after it.
…looking at the Standard Rules, it seems like for some activities the Standard Rules take care of this by explicitly declaring the standard rule to be last in the rules for the activity:
The standard name printing rule is listed last in the for printing the name rulebook.
The standard name printing rule translates into I6 as "STANDARD_NAME_PRINTING_R".
but there’s no such declaration for printing a parser error, which I suspect is handled at a somewhat deeper I6 level.
Oh wow, thanks for pointing me to where things were in the manual, Matt W! I still have parts of it I didn’t really look through, and I try, but after 15-30 minutes I figure it’s better to ask. I was looking in the wrong place.
Having an example like this helps me get my foot in the door to understand other stuff.