"rule succeeds" in check stops the whole action

I was reading the documentation (18.10)

So I thought I could make a bypass, for instance if I want to make it possible to always take a certain object, regardless of where it is:

However, it seems that “rule succeeds” not only stops the check rulebook, but it stops the whole action! I would have thought that only “rule fails” would do that.

Does anybody know why the behavior is like that?

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.

The game “abides by” the check rulebook. This means that the action ends when the check rules either succeed or fail, and goes on if they do not produce an outcome.

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

>take all
o1: no decision
o2: failed
o3: succeeds
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 hear that the next version of Inform will allow modification of existing rule conditions:

inform7.uservoice.com/forums/573 … ?ref=title

Until then, you have to replace the rule that’s stopping your action, or use an Instead rule to manage the whole process.

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?

Robert Rothman

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.)