The part where it says ‘the rulebook being worked through will also end’ - in your example, that rulebook is actually the check taking rulebook. You’re not up to the part where the player acquires the object yet.
The theoretical arrangement is that the check rulebook tests if an action is possible, then further down the line, the carry out rulebook will carry out the action if it wasn’t redirected or closed off at the check stage. Issuing a ‘Rule succeeds’ (and rule fails, too) ends the whole cascade through the rulebook sequence immediately, and actually performs no other action like you might think it might. The difference between success and failure with those two commands is simply how Inform records the result of the action.
So that’s to answer your question about ‘rule succeeds’, but the issue of setting things up so a person can grab a particular object wherever it is in the game actually requires you to fiddle with ‘scope’ (search for that word in the docs). Possibly someone else will come along and give an example in this topic.
I noticed that it was abide there. I changed the rule to consider, and tried to read the result, but it seems that the standard rules do “stop the action” instead of “rule fails”.
This makes a difference, even though the documentation says that stop the action is equivalent to rule fails.
x is a room.
o1 is in x.
o2 is in x.
o3 is in x.
o4 is in x.
check taking o1: stop the action;
check taking o2: rule fails;
check taking o3: rule succeeds;
The modified check stage rule is listed instead of the check stage rule in the specific action-processing rules.
A specific action-processing rule (this is the modified check stage rule):
consider the specific check rulebook;
if the rule succeeded, instead say "succeeds[line break]";
if the rule failed, instead say "failed[line break]";
instead say "no decision[line break]";
and the result
o1: no decision
o4: no decision
So this means I can’t modify just check stage rule. I’m not going to investigate this further, but it’s interesting to learn the inner workings of Inform7.
I thought that more than scope is involved; you also need to deal with reachability.
I had thought that “scope” affects what you can see (which in turn affects what the parser will consider to be a possible object for your command when it tries to figure out what you want to do). Once it does so, for most actions (including taking) the object also has to be reachable, which is controlled by another set of rules. Thus, even if you place an object in another room “in scope” you still can’t take it unless you also create a specific “reaching” rule which overrides the general rule that you can’t reach into another room. Am I misunderstanding the way the process works?
No. You are correct. (Although I would clarify the use of the word “see” above by adding that objects manually placed in scope are “visible” to the parser, but not visible in the sense that they automatically show up in room descriptions, etc.)