So somehow the amulet is not portable. Can you text-copy the rules or rule right before it gives you the refusal message (instead of needing to get everything in-frame for a screenshot)?
This may sound dumb like “have you tried unplugging and plugging it back in” but can you do a global search for AMULET and see anyplace else it might be hiding in code?
Here is the rule list when I try to TAKE AMULET.
The SHOWME AMULET says that it IS portable and wearable.
Aha! What does the “Instead of taking something…” rule apply to?
“That’s not something you can take.” is not a standard message for non-portability. So something else is going on. I don’t actually know what fires “that’s not something you can take.”
Aha! “Instead of taking something” was a non-localized rule with a response that was similar to the default response. I localized it (Instead of taking something in the stables), and making the response very non-default sounding. It finally worked!
Thanks so much for helping with this. I am trying to get the final bugs out before the parser competition.
While you can cut off default responses with action processing, it’s easy to get tripped up.
The best way is just to rewrite the response, for example:
the can't take scenery rule response (A) is "That isn't something you can take.".
the (A) applies to the protagonist. If you had NPCs trying to take scenery, you’d probably want to write a (B) response for them.
You can find the names of rules in both the index and the Standard Rules. I prefer looking at the Standard Rules, myself.
Drew,
Thanks much!
I’m folding this since it’s my personal opinion and there’s better advice later in the thread from people who know what they’re actually doing. Feel free to skip forward.
[Cue Hanon Sermon #93 - not to @Falsoon2 but to new Inform authors who may be reading]
This is exactly why you’ll frequently hear us crotchety old-timers heavily advising against using INSTEAD rules if you can use another type of rule. It’s not that you shouldn’t use INSTEAD when it’s warranted, but it’s easy-to-understand simplicity lures new authors into using it as a catchall monkey-wrench without understanding it’s deceptive power.
Falsoon got stuck because of an “instead of taking something” rule intended for one specific use-case, but he inadvertently didn’t limit it to that scenario, thus causing a mystery situation where the parser was disabled from letting the player take an item elsewhere and it wasn’t at all obvious why.
One thing about INSTEAD rules, you cannot stack them. (Can you even continue the action after an instead? Not sure.) You cannot write.
Instead of taking something:
say "Foo!".
Instead of taking something:
say "Bar!"
Those won’t both fire because INSTEAD temporarily shuts off the parser, fails the action, and follows the instructions the author writes directly.
In the aforementioned case, since the compiler stacks the rules in code-order you’ll probably only get the “Bar!” message.
INSTEAD is a manager override that allows the author to do anything even if it’s not logical based on game-world model or game state that the parser would normally not allow:
The Gothic Mansion is scenery in Graveyard.
Instead of taking Gothic Mansion:
say "All right, Hercules..."
now the player carries Gothic Mansion;
say "(Taken.)";
But the regular action-handling rules can stack and you can have multiples:
Check taking:
if the player does not have hands:
say "YOU MAY NAHT." instead.
Check taking:
if the noun is lava:
say "YOU MAY NAHT." instead.
Note that “instead” is very useful appended to rules to stop the action if a situation applies. If I write
Instead of taking:
if the player does not have hands:
say "YOU MAY NAHT.";
if the noun is lava:
say "YOU MAY NAHT.";
That might seem like the same exact thing, but the preceding “instead” (without a condition like “when the location is The Barn”) has already marked the action as failed and is only going to run the commands in THAT rule. I’ve effectively disabled taking for the entire game by telling the parser “Instead of processing any rules for taking, do only this…”
Usually the best use for instead is when you intend to blanket-disallow or redirect a general or specific action for the entire game.
Instead of attacking:
end the story saying "I won't support your violent tendencies."
Instead of jumping when can-fly is true:
try flying up.
In most circumstances, almost any INSTEAD can be written as a check rule.
The block attacking rule does nothing.
Check attacking something:
if the noun is the adorable puppy:
say "YOU SHALL NAHT." instead;
Many new authors will use instead because they want a special circumstance but otherwise want things to work normally. That’s what the phases are for.
Instead of attacking the burly orc:
if the player wears the Amulet of Orcbane:
say "HUUAARRGGGHHH!";
increase atk-power by 3;
otherwise:
[I've got to duplicate the remainder of the attack action here]
Since the parser been told to go on break, it can’t take up the rest of the “attack” rules and functions I may have written.
Whereas if I’ve set up my attacking rules correctly, adding a side effect is merely:
Carry out attacking the burly orc:
if the player wears the Amulet of Orcbane:
say "HUUAARRGGGHHH!";
increase atk-power by 3.
And that doesn’t stop the action and continues with all the other rules that might apply.
This isn’t quite right.
Although by default an Instead rule will stop the action in failure, you can override this by writing continue the action
So you could achieve the effect you’re looking for (i.e. the rest of the action rules apply if your specific case does not) in this way:
Instead of attacking the burly orc:
if the player wears the Amulet of Orcbane:
say "HUUAARRGGGHHH!";
increase atk-power by 3;
otherwise:
continue the action.
or you could just write:
Instead of attacking the burly orc when the player wears the Amulet of Orcbane:
say "HUUAARRGGGHHH!";
increase atk-power by 3;
so that the Instead rule only fires at all when your specific case applies.
Or, if you’re looking to modify what happens later in the action rules, which should continue to run:
Instead of attacking the burly orc when the player wears the Amulet of Orcbane:
say "HUUAARRGGGHHH!";
increase atk-power by 3;
continue the action;
Although if you’re not looking to bypass the usual action check rules, the more natural place to put this kind of thing is, as suggested, at the start of the Carry out rules once the action has passed all check rules.
Hanon, DPB:
Thanks for this “soapbox”. I found the principles enlightening and should improve my stories. 
I wouldn’t go quite that far. What I’d say is: make sure you’re using the right kind of rule for what you’re doing.
The point of Instead rules is to override the default behavior of an action, when basic feasibility has been checked (can you touch the objects that need touching? do you have enough light?), but action-specific requirements have not (for taking, is this thing portable? for eating, is this thing edible?).
Which is generally a very useful place to override things for your game! If you want to write a special message for trying to eat a rock, you’ll want that message to appear when the action is considered broadly feasible (the rock isn’t in a locked display case) but the specifics of “eating” have not yet interfered (which would stop the action and say this rock isn’t edible).
The flow goes:
So just make sure you’re putting your rules in the most appropriate rulebook: Before to redirect one action to another before doing any checking, Instead to override the default behavior completely, After to let the default behavior happen but change the way it’s described. (Precondition, Check, Carry Out, and Report you usually don’t need to add your own rules to, unless you’re making a new action: these are where the default behavior goes, while Before, Instead, and After are for the exceptional behavior that makes your game your own.)
By default the Precondition rules aren’t actually a rulebook. They’re just a couple rules, like the basic accessibility rule and the carrying requirements rule, which appear on their own at this point in the processing. Certain extensions, like Implicit Actions by Eric Eve, put an actual rulebook here called Precondition and move these rules into it. That’s why I’m using that name here.
These are the Basic visibility, Basic accessibility, and Carrying Requirements rules. There are rulebooks associated with the first two, and the docs even talk about them: Basic visibility follows the Visibility rules (unless the action doesn’t require light or the actor is an NPC); Unless the action doesn’t require a touchable noun, Basic accessibility follows the Reaching Inside and Reaching Outside rules (I’m eliding some details here).
Implicit Actions doesn’t move anything, it just makes it so that its Precondition rulebook is followed between the Basic Visibility and Basic accessibility rules.
Oh, huh, I thought it moved those three rules into the Precondition rulebook. I guess it makes sense not to mess with their positioning, though.
This is a treasure trove of Inform authoring, tips, and tricks. Thanks so much. Do others know about this?