(I know @McTavish is pretty experienced, so this may be wildly missing the point, but is always a good thing to keep in mind…)
Authors should be careful to avoid the habit of relying on INSTEAD rules since an instead rule will ignore all other rules that might be involved in your world model, such as checking if objects are in scope, or if there is darkness, etc.
Check inserting something into the tree:
if the noun is not the ring:
say "No." instead;
continue the action. [<-this is implicit in a Check rule and not necessary to include]
That does what you want - it blocks inserting anything into the tree but the ring, and allows all other normal parsing (is the tree here? is the ring here? is it too dark to see the tree?). You can include “continue the action” but the natural behavior of Check is to continue action unless the rule fails by hitting “instead” or is redirected.
If you use an INSTEAD rule, you probably also need to include all the checks the parser normally does: "is the player in the location of the tree? does the player have the ring? is the ring already in the tree? etc…) That’s why Check rules are better for this.
(It’s very likely @McTavish is aware and this was pseudocode for a different bug issue, so apologies if this is an unhelpful interjection!)
I’m not sure this is quite right. Rulebooks regarding basic visibility, basic accessibility and carrying requirements run after the Before stage, but before the Instead stage (as can be seen by expanding ‘action-processing rules’ in the Index, and demonstrated by making the Garden dark- in which instance attempts to insert the ring into the tree elicit the expected ‘You can’t see any such thing’.)
Consequently, the following isn’t true (unless, in some instances, you’re using a Before rule, which will run before scoping-type rules)
What you do pre-empt by using the Instead stage is all the standard Check stage rules, which may or may not be important depending on the context.
Yeah – I’ve found Instead rules really helpful for cases like the player trying to open a desk, when the desk isn’t openable (like, the player thinks there’s a drawer, but actually there isn’t). The fact that it bypasses the Check rules is useful, since that means you can spit out a custom Say command without needing to actually make the desk openable, while still playing nice with the regular scope rules.
Instead rules can definitely get you into trouble if you use them to cavalierly instead of check/carry out ones, though – for example, since the action doesn’t successfully conclude, a condition like “if the desk has ever been opened” will continue to be false even if the player has typed OPEN DESK.
That said, commands that breach really basic scoping rules as declared in the action definition, e.g.:
Photographing is an action applying to one visible thing and requiring light
won’t even get as far as generating an action and running the action-processing rules, being rejected by the parser at an even earlier stage and therefore not even reaching the Before stage.
EDIT- to be even more specific, something being out of scope for the actor will prevent the action being generated with ‘You can’t see any such thing’, Photographing something in scope albeit in darkness will generate an action, run the Before stage, but then (potentially) fall foul of the basic visibility rule if the action is declared as requiring light with ‘It is pitch dark and you can’t see a thing’. If the action declaration requires the object to be touchable or carried, (assuming the object is in scope and the action is generated) these are also tested for between the Before and Instead stages.
In a nutshell, with regard to action definitions-
scope is tested for before the action is generated;
touchability, the need to be carried and a specific requirement for light are tested for after the action is generated, specifically between the Before and Instead stages.
I’ve actually helped an author once who had written an entire small game using nothing but Instead rules that were increasingly confusing and tangled. Instead of opening the door: if the door is closed: now the door is open; say "You opened the door!"; otherwise: say "The door is already open!"
In most cases, an Instead rule should be a quick denial that fails the action completely or redirects to a new action. It’s easy for bugs to crop up if an Instead rule modifies the world-state in any complicated way.
I feel seen! In my first (slash only so far) game, I did all the character dialogue as a million different “Instead of asking CHARNAME about ‘blarg’…” rules – and then I realized I had a puzzle where it was important to remain silent, and the only way I could figure out how to flag the player as noisy after dialogue was to paste “now the player is noisy” into every single one
(Thanks to this thread I’m now realizing I could have probably patched this via a Before rule, though if I’d known enough to do that, I’d have known enough not to get into that mess in the first place).
I’ve ended up with one pronounced opinion here: if you’re redirecting to another command then using Instead instead of Before seems to just get you a gratuitous second trip through the basic visibility, basic accessibility, and carrying requirements rules. (I suppose there could be some weird situation where the first command has more stringent requirements you want applied before considering the redirect… but nothing’s coming readily to mind.)