While touching up an IFComp entry, I noticed a case where I was trying to squash report/after rules, but I couldn’t.
The problem is this: if I exit from a “carry out” rule, the report/after rules fire no matter how I try to quash said “carry out” rule.
r1 is a room.
mycmding is an action applying to nothing.
understand the command "mycmd" as something new.
understand "mycmd" as mycmding.
carry out mycmding:
let Q be the remainder after dividing turn count by 5;
if Q is 0, do nothing instead;
if Q is 1, the rule fails;
if Q is 2, stop the action;
if Q is 3, the rule succeeds;
if Q is 4, reject the player's command;
say "Report MYCMDING fired.";
continue the action;
say "After MYCMDING fired.";
continue the action;
If I try typing in MYCMD after building, the REPORT and AFTER rules always fire.
Is there any way to stop “after/report” rules from firing once a “carry out” has been executed? (Besides, say, using a boolean e.g. “after mycmding when cmd-successful is true”?
In my case, I found a check rule that gets around this. It requires scanning through a small table twice, but that’s not a big deal.
Still, I feel like I’m missing something here, that there should be a way to bail from a “carry out” rule without the after/report rules firing.
But if it’s no possible, that’s okay, too, and good to know. Thanks!
I don’t think so. The way the rulebooks are defined, “carry out” is for carrying out an action that is definitely happening – it’s too late to cancel it at that point. Stopping a “carry out” rule merely prevents any other “carry out” rules from also executing, which can be useful since Inform executes more specific rules before more general ones, so you can do case-by-case overrides of the generic carry out rules this way.
If you want to cancel an action you have to do it in one of the Before/Instead/Check rulebooks.
Conversely, After/Report happen after the action, with After superseding Report.
Typically Check/Carry Out/Report are used by the generic actions in the Standard Rules while Before/Instead/After are reserved for your story-specific contextual overrides. But that’s mostly a convention – it’s useful to follow it when writing new custom actions but it’s not enforced.
You could just store whatever result you get from the table the first time in an action variable and use it again later in the action.
I’d considered something roughly like this before, but I always used globals. I assumed it was part of Inform’s weakness & Inform just didn’t have it, but it turns out I didn’t read the documentation carefully. I suppose it’s too impractical to wipe the globals now, but it’s great to know going forward.
@mirality, thanks for the verification.
The reason this response is so late is, your two responses put my mind at ease about a few things and helped me plow into some other code.