So, if an “Instead” rule runs to its default outcome of failure, then the action it was called from will automatically end in failure, but if it ends in an “instead,” then the rule fails, but the outcome of the action will depend on the last rule that runs… which will be the last rulebook that gets invoked by the new action being tried? Something like that?
I guess that’s consistent with the differences between “instead” and “rule fails” that zarf explained here (I had to deal with some tricky aspects of this stuff here). The documentation is, erm, pretty subtle on this I find.
Since zarf says no and zarf is always right, maybe what this means is that when the instead rule triggers a check rule, and the check rules sets a “reason the action failed” global (just by being invoked?), the action processing doesn’t clear the global when exiting the instead rulebook? So it just looks like it’s abiding by the check rule since the “actions” command reports the reason for failure whenever it’s populated and the action as a whole failed?
From experimenting here, it looks like – even if the check rule in question forces a successful action result with “rule succeeds” at its end! – whenever the invoking instead rule fails then the invoked check rule is listed as the reason for failing by “actions.” Interesting… kind of useful for some cases, maybe.
Here’s a question I’ve run into recently that is somewhat related to this discussion: if I want to repurpose one of the default actions that only prints text (does not change the world state, like examining or smelling) in a specific case, should I use a report rule that ends in “rule succeeds” or an instead rule to suppress the default “nothing interesting” report rule from running?
Both are fine. I’m in the “use insteads sparingly” camp. If you’re going to be creating a lot of smells then you’ll want to have a more fully implemented response rather than lots of piecemeal instead rules.
You should use an after rule, which comes just before the reporting rules and automatically returns success.
CAVEAT: Examining is kind of an odd case. It prints text, but it does so in the carry out rules, not the reporting rules – presumably the logic being that to “carry out” examining IS to print the object’s description. So if you have a situation where you want to change an item’s description under certain circumstances, you need to either use conditional text substitutions in the item’s description property, or write a “carry out examining” rule that ends in rule succeeds.
Yes, thank you for bringing this up. I had a story with changing scenes and often things would happen a turn later than I needed them to, etc. and it was hard for me as a beginner to really track that stuff down.
Part of the problem with the “recipe book” approach to teaching is that it is results-oriented, and glosses over instances like this, where two ways to do the same thing have very different impacts on design.
Though in this particular case, as we discussed in the thread, this behavior only happens if you have the Modified Timekeeping extension installed.
The scene-changing machinery may be an independent thing. I don’t really use scenes much, though that’s in part because they seem finicky to get to work right, in the way you describe.
The scene-changing machinery happens at end-of-turn whether the action succeeded or failed.
You can write code like “Scene foo begins when we have examined the lamp”. Then it matters whether the action succeeded, but it won’t be happening a turn late. If the action fails, the scene won’t begin at all.