Insteads are Generally Bad Practice

Yes, but I got the impression that Rasputin’s main complaint was that Insteads are a crude and frequently misused tool because “behind the scenes things aren’t operating as they should,” i.e. “as actions are designed to be implemented.” To me, that narrowed the category to “Insteads that try to do something in the model world,” though I guess I should have made that clearer. (And, in light of his edit, that may not have been the kind of “bad practice” to which he was pointing.)

Your example is very much in keeping with the spirit of proper use of action processing rules, I would think – a reroute instead of a short circuit.

I was using that technique for some time, but “Before , try instead” seems to work a lot better. I was running into the Instead being preempted by other Insteads related to , which doesn’t make sense because ultimately we’re aiming for a direct action substitution (as if the player had actually typed at the parser) that has logically nothing at all to do with .

It seems to me that action substitutions should be one of the very first things to happen after a command has been entered.

As a non-sequitur, this is by far the best forum I’ve ever been a part of. Lots of knowledge, lots of help, super-quick replies, and high signal to noise. Pretty much everything you could ask for.

Thank you all for the continued responses.

That was my main complaint, although like I said in my edit, some of the particulars of my gripes don’t really apply unless you’re using Modified Timekeeping. But you’ve put your finger on far more proper examples where not actually implementing actions (like the standard library does) creates issues.

I guess another example where Insteads are bad practice is when they apply to actions that NPCs follow. If you’re in the habit of using them then you’ll expect something like,

[code]Forest is a room.
A man called Burt is in Forest.
an apple is a thing in Forest.

Persuasion rule for asking Burt to try doing something:
persuasion succeeds.

Instead of Burt eating the apple:
say “He bites into the apple, and then throws away the core.”;
now apple is off-stage.[/code]

to come out properly, but really it will run the Instead but still result in failure for Burt.

Is the “instead” before “try” necessary? I thought those inline “instead” meant “end the rule in failure,” and that that isn’t necessary in Instead rules because the rulebook has default failure anyway.

I think the underlying issue here is that most of the time, what you do in Inform will proceed happily whether or not your action succeeded or failed. Text will print, world state will change, and so on; as long as you avoid the “check” issue that Otis mentioned, and you’re not using slightly more esoteric stuff like “if we have…” or “reason the action failed” or things that depend on rule success, then you’ll be OK. But if you start using that kind of stuff, you have to be very very careful.

(Also, in the “eating the apple” case, the Standard Rules for eating something already have a Carry out eating rule that removes the noun from play! So all you have to do is change the printed message with an After or Report rule.)

For trying an action, instead basically means “abide by whatever rules apply to this action,” I think. See the result of the instead rule in output from this example:

[code]“Example” by Otis

Icy Meadow is a room. A fixed in place container called an oak tree is in Icy Meadow. “The kite-eating tree is here, looking dangerously thin this late in the winter.”

Check inserting something into the oak tree (this is the can’t reach branches rule):
say “It’s a tall tree; you can’t reach the branches unaided.”;
rule fails.

The player carries a stick. The player carries an enterable supporter called a stepladder. Understand “ladder” as the stepladder. The player carries a burning torch. The player carries an edible thing called an apple.

Check inserting the burning torch into the oak tree (this is the don’t burn tree rule):
say “I don’t think so. Trees are flammable, you know.”;
rule fails.

Instead of eating something (this is the better the tree eats it rule):
say “You decide the tree needs it more than you do.”;
try inserting the noun into the oak tree instead.

The can’t reach branches rule does nothing when the player is supported by the stepladder.

Every turn when something (called the snack) is in the oak tree (this is the tree eats things in it rule):
try the oak tree eating the snack.

Check the oak tree eating something not edible (called the tidbit) (this is the trees can’t eat inedible things rule):
say “The tree gnaws on [the tidbit], but [they’re] too tough to eat.”;
rule fails.

Check an actor eating (this is the revised can’t eat portable food without carrying it rule):
if the actor is not a person:
continue the action;
if the noun is portable and the actor is not carrying the noun:
carry out the implicitly taking activity with the noun;
if the actor is not carrying the noun, stop the action.

The revised can’t eat portable food without carrying it rule is listed instead of the can’t eat portable food without carrying it rule in the check eating rulebook.

After the oak tree eating something (called the snack) (this is the trees can eat edible things rule):
say “The tree gratefully chomps down [the snack].”

test me with “put stick in tree / put torch in tree / actions / eat apple / actions off / drop stepladder / stand on it / put stick in tree / put torch in tree / actions / eat apple”[/code]

No, but it’s easier to always write “instead try fooing” than to remember when the “instead” is optional. (I use this sort of action redirection in both Instead and Check rules.)

Yes. I long ago made the executive decision to never rely on the action success result.

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.

No. “Instead” as a phrase modifier just means “phrase; stop the action”.

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.

For this reason, I prefer to write the phrase as “[do a thing] instead;” rather than “instead [do a thing];” to make it clearer what’s going on.

Absolutely a matter of personal style. My eye tends to lose the “instead” when it’s at the end of the line.

Sure, this is just what I find helpful.

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.

Try rule succeeds:

Instead of Burt eating the apple:
	say "He bites into the apple, and then throws away the core.";
	now apple is off-stage;
	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.