The global variables and those built-in rulebooks which do not belong either to specific actions or to specific activities.

§1. The player's situation. A set of global variables defines the player's current situation in space and time.

Although users often think of the protagonist object as a fixed object whose name is "player", this is a variable, and it is possible to change perspective during play and become somebody else — at which point the "player" variable will point to a different object.

Note that "player" is a name given to a variable explicitly defined in the srules template with a given name (in this case player), so it has a "translates into Inter" sentence. 


Part Three - Variables and Rulebooks

Chapter 1 - Variables

Section 1 - Situation

The player is a person that varies.
The player variable translates into Inter as "player".

§2. The I7 variable "location" corresponds to I6's real_location, not location. Its value is never equal to a pseudo-room representing darkness: it is always an actual room, and I7 has nothing corresponding to I6's thedark "room". Similarly, we use an I7 variable "darkness witnessed" for a flag which the I6 library would have stored as the visited attribute for the thedark object. 

The location -- documented at var_location -- is an object that varies.
The score -- documented at var_score -- is a number that varies.
The last notified score is a number that varies.
The maximum score is a number that varies.
The turn count is a number that varies.
The time of day -- documented at var_time -- is a time that varies.
The darkness witnessed is a truth state that varies.

The location variable translates into Inter as "real_location".
The score variable translates into Inter as "score".
The last notified score variable translates into Inter as "last_score".
The maximum score variable translates into Inter as "MAX_SCORE".
The turn count variable translates into Inter as "turns".
The time of day variable translates into Inter as "the_time".

§3. It is arguable that "noun", "second noun" and "person asked" ought to be rulebook variables belonging to the action-processing rules, so that they essentially did not exist outside of the context of an ongoing action. The reason this isn't done is partly historical (rulebook variables were a fairly late development, implemented in April 2007, though they had long been planned). But it is sometimes useful to get at the nouns in an action after it has finished, and making them global variables also makes them a little faster to look up (a good thing since they are used so much), and causes them to be indexed more prominently.

"Item described" is simply an I7 name for self. (This is an Inter variable which refers to the object currently under discussion.) In early drafts of I7, it was called "this object", but somehow this raised expectations too high about how often it would be meaningful: it looked like a pronoun running meanings from sentence to sentence. 

Section 2 - Current action

The noun -- documented at var_noun -- is an object that varies.
The second noun is an object that varies.
The person asked -- documented at var_person_asked -- is an object that varies.
The reason the action failed -- documented at var_reason -- is an action
based rule producing nothing that varies.
The item described is an object that varies.

The noun variable translates into Inter as "noun".
The second noun variable translates into Inter as "second".
The person asked variable translates into Inter as "actor".
The reason the action failed variable translates into Inter as "reason_the_action_failed".
The item described variable translates into Inter as "self".

§4. "Person reaching" turns out to have exactly the same meaning as "person asked" — they are both the actor, in Inter terms, but are used in different situations. 

Section 3 - Used when ruling on accessibility

The person reaching -- documented at var_person_reaching -- is an object that varies.
The container in question is an object that varies.
The supporter in question is an object that varies.
The particular possession -- documented at var_particular -- is a thing that varies.

The person reaching variable translates into Inter as "actor".
The container in question variable translates into Inter as "parameter_object".
The supporter in question variable translates into Inter as "parameter_object".
The particular possession variable translates into Inter as "particular_possession".

§5. Parsing variables follow. The I6 parser tends to put any data read as part of a command into the variable parsed_number, but then, Inter is typeless: we can't have a single I7 variable for all these possibilities since it could then have no legal type. We solve this as follows. Whenever a kind of value \(K\) is created which can be parsed as part of a command, an I7 variable "the \(K\) understood" is also created, as a \(K\) that varies. All of these variables are translated into Inter's parsed_number, so in effect they provide aliases of each possible type for the same underlying memory location. The one exception is for "the topic understood" (for historical reasons this one is not called "the snippet understood", and so we make it by hand). 

Section 4 - Used when understanding typed commands

The player's command -- documented at var_command -- is a snippet that varies.
The matched text is a snippet that varies.
The topic understood is a snippet that varies.
The current item from the multiple object list is an object that varies.

The player's command variable translates into Inter as "players_command".
The matched text variable translates into Inter as "matched_text".
The topic understood variable translates into Inter as "parsed_number".
The current item from the multiple object list variable translates into Inter as
    "multiple_object_item".

§6. 

Section 5 - Presentation on screen

The command prompt -- documented at var_prompt -- is a text that varies.
The command prompt is ">".

The left hand status line -- documented at var_sl -- is a text that varies.
The right hand status line is a text that varies.

The left hand status line variable translates into Inter as "left_hand_status_line".
The right hand status line variable translates into Inter as "right_hand_status_line".

The listing group size is a number that varies.
The listing group size variable translates into Inter as "listing_size".

§7. Now some linguistic variables: 

Section 6 - Language generation

The prior named object is an object that varies.
The prior named object variable translates into Inter as "prior_named_noun".
An object has a text called list grouping key.

§8. ...but they are not the last global variables created by the Standard Rules.

These bibliographic data variables are concealed because they are under a heading which ends with the word "unindexed". There are two reasons why these variables are unindexed: first, they appear in a different guise only a little lower in the Contents index as part of the Library Card, and second, we don't want users to think of them as manipulable during play.

Rather sneakily, we also define a Figure here. This is done in order to make it legal to declare variables and properties of the kind of value "figure name" (because it ensures that such variables can always be initialised — there is always at least one Figure in the world). Of course plenty of Inform projects have no artwork at all: so the cover art figure is unique in that it might refer to nothing. That sounds a little arbitrary but in fact follows a convention used by the Blorb format for binding story files with their resources, which in turn follows Infocom conventions of 1987-89: the cover art always has resource ID number 1, whether it exists or not. Inform creates figures and sound effects counting upwards from 1, giving them each unique resource ID numbers, so the first to be created gets ID number 1: by defining "figure of cover" here, we can be sure that we are first, so everything works. 

Section 7 - Unindexed Standard Rules variables - Unindexed

The story title, the story author, the story headline, the story genre
and the story description are text variables. ****
The release number and the story creation year are number variables. *

The release number is usually 1.
The story headline is usually "An Interactive Fiction".
The story genre is usually "Fiction".

The story title variable translates into Inter as "Story".

Section SR2/6b - Unindexed Standard Rules variables - Unindexed (for figures language element only)

Figure of cover is the file of cover art ("The cover art.").

§9. And we finish out the set with some "secret" variables used only by the Standard Rules or by Inform, and which are therefore also unindexed. Their names are all hyphenated, to reduce the chance of anyone stumbling into them in a namespace clash.

The first set of three secret variables is used by the predicate calculus machinery in Inform. This is the code which handles logical sentences such as "at least six doors are open" or descriptions such as "open doors", by reducing them to a logical notation which sometimes makes use of variables. For instance, "open doors" reduces to something like "all \(x\) such that door(\(x\)) and open(\(x\))", with \(x\) being a variable. When Inform works with such logical propositions, it often needs to substitute \(x=c\), that is, to replace \(x\) with a given constant \(c\). But it can only do this if \(c\) is an Inform 7 value. This is a problem if what it wants is to substitute in something which is only meaningful at the I6 level: say, it wants to substitute a value \(c\) which will eventually translate to whatever, but it can't find any I7 value \(c\) which will do this.

We solve this problem by constructing some unusual I7 variables whose only purpose is that Inform can use them in substitutions. They should never be referred to in I7 source text anywhere else at all, not even elsewhere in the Standard Rules. 

Section 8 - Unindexed Standard Rules variables - Unindexed

The I6-nothing-constant is an object that varies.
The I6-nothing-constant variable translates into Inter as "nothing".

The I6-varying-global is an object that varies.
The I6-varying-global variable translates into Inter as "nothing".

§10. The remaining secret variables are: 

The item-pushed-between-rooms is an object that varies.
The item-pushed-between-rooms variable translates into Inter as "move_pushing".

The actor-location is an object that varies. 
The actor-location variable translates into Inter as "actor_location".

The scene being changed is a scene that varies. 
The scene being changed variable translates into Inter as "parameter_value".

§11. Rulebooks. Whereas Basic Inform equips the language with only a handful of rulebooks to start out, the Standard Rules are replete with them.

Note, however, that many of these have explicit support in the basicinform template and in the compiler itself, and that they must be created exactly in the order below, unless matching changes are made to both other places. In particular, these need to stay in sync:

§12. When an interactive fiction project using the Standard Rules starts up, it does the following:

Briefly, the startup phase takes us to the end of the room description after the banner is printed. The turn sequence covers a complete turn, and runs through from prompting the player for a command to notifying him of any change in score which occurred. The shutdown rules then go from printing the obituary text, through final score, to the question about quitting or restarting. 

Chapter 2 - Rulebooks

Section 1 - The Standard Rulebooks

Turn sequence rules is a rulebook.

§13. Now a set of rulebooks to do with the passage of time. 

Scene changing rules is a rulebook.
When play begins is a rulebook.
When play ends is a rulebook.
When scene begins is a scene based rulebook.
When scene ends is a scene based rulebook.
Every turn rules is a rulebook.

§14. The action machinery requires some 16 rulebooks to work, though that is the result of gradual simplification — in 2006 it required 25, for instance. The "action-processing" rulebook, like the turn sequence rulebook, is a master of ceremonies: it belongs to the Standard Rules and is only rarely if at all referred to by users.

As remarked above, it's something of a historical accident that "actor" is a rulebook variable belonging to the action-processing rules (and thus in scope for every rulebook it employs) while "noun" and "second noun" are global variables (and thus in scope everywhere).

The main action-processing rulebook delegates most of its detailed work to a subsidiary, the "specific action-processing" rulebook, at the point where what rulebooks we consult next depends on what the action is (hence "specific") — see below for more on how check/carry out/report rules are filed. 

Action-processing rules is a rulebook.
The action-processing rulebook has a person called the actor.
Setting action variables is a rulebook.
The specific action-processing rules is a rulebook.
The specific action-processing rulebook has a truth state called action in world.
The specific action-processing rulebook has a truth state called action keeping silent.
The specific action-processing rulebook has a rulebook called specific check rulebook.
The specific action-processing rulebook has a rulebook called specific carry out rulebook.
The specific action-processing rulebook has a rulebook called specific report rulebook.
The specific action-processing rulebook has a truth state called within the player's sight.
The player's action awareness rules is a rulebook.

§15. The rules on accessibility and visibility, which control whether an action is physically possible, have named outcomes as a taste of syntactic sugar. 

Accessibility rules is a rulebook.
Reaching inside rules is an object-based rulebook.
Reaching inside rules have outcomes allow access (success) and deny access (failure).
Reaching outside rules is an object-based rulebook.
Reaching outside rules have outcomes allow access (success) and deny access (failure).
Visibility rules is a rulebook.
Visibility rules have outcomes there is sufficient light (failure) and there is
insufficient light (success).

§16. Two rulebooks govern the processing of asking other people to carry out actions: 

Persuasion rules is a rulebook.
Persuasion rules have outcomes persuasion succeeds (success) and persuasion fails (failure).
Unsuccessful attempt by is a rulebook.

§17. Next, the six classic rulebooks best known to users of Inform. It's perhaps an unfortunate point of the design that there are so many as six: that seems rather a lot of stages to go through, and indeed means that there is sometimes some ambiguity about which rulebook to use if one wants to achieve a given effect. There are really two reasons why things are done this way:

During play, then, the three rulebooks "check", "after" and "report" are completely empty. This is the result of a reform in April 2007 which wasn't altogether popular. Before then, Inform rather cleverly filed rules like "Check doing something with the haddock" in the generic "check" rulebook and ran this rulebook as part of the action processing sequence. But this clearly broke principle (i) above, and meant that the six-stage process — already quite complicated enough — was actually a nine-stage process only pretending, by deceitful syntax, to be a six-stage one. Check rules sometimes appeared to be filed in the wrong order, breaking the ordinary precedence conventions, and this was not due to a bug but because they were only pretending all to be in the same rulebook. Still more clever indexing and rule-ordering tricks ameliorated this a little, but in the end it was just a bad design: withdrawing the ability to make check, carry out and report rules apply to multiple actions resulted in much cleaner code, and also a clearer conceptual definition of what these rulebooks were for. (But users still didn't like the change: actual functionality was withdrawn.)

So if they are always empty and never used, why are the three rulebooks called simply "check", "after" and "report" created in the first place? The answer is that this is a convenience for parsing rule preambles in Inform: it provides a temporary home for such rules before they are divided up into their specific rulebooks, and it also makes it easier for Inform to detect and give a helpful Problem message in response to rules like "Check taking or dropping the perch" which can't be filed anywhere in our scheme, and so have to be forbidden. 

Before rules is a rulebook.
Instead rules is a rulebook.
Check rules is a rulebook.
Carry out rules is a rulebook.
After rules is a rulebook.
Report rules is a rulebook.

§18. The next rulebook in this roundup is one used for parsing ambiguous commands during play. This looks like the job of an activity rather than a rulebook, but (i) we want information in the form of a nicely-named five point scale of responses, rather than wanting something to be done, and (ii) it doesn't really make any sense to split that question into a before, for and after stage. So this is a named rulebook instead.

"Does the player mean" is essentially a front end for the I6 parser's ChooseObjects entry point, which relies on numerical scores to assess the likelihood of possible choices. To facilitate that, the I7 compiler recognises these five outcome names and translates them into the Inter constants RBNO4_OUTCOME, RBNO3_OUTCOME, ..., RBNO0_OUTCOME respectively. So don't change the names of these outcomes. 

The does the player mean rules is a rulebook.
The does the player mean rules have outcomes it is very likely, it is likely, it is possible,
it is unlikely and it is very unlikely.

§19. The following rulebook was added at the (implied) suggestion of John Clemens, whose Consolidated Multiple Actions extension made use of something similar. 

The multiple action processing rules is a rulebook.

§20. And that's it: all of the named rulebooks now exist. There will, of course, be hundreds more rulebooks soon, created automatically as activities and actions are created — when we create the "dropping" action, for instance, we also create the "check dropping", "carry out dropping" and "report dropping" rulebooks — but there are no more stand-alone rulebooks.

§21. Rules. At run-time, the value of a rule is the (packed) address of an I6 routine. In the case of rules created in I7 source text, the body of the rule definition is compiled by Inform to a new I6 routine which carries it out. But there are also primitive rules which are implemented in the template I6 layer, and these need no I7 source text definitions: instead we simply tell Inform the name of the I6 routine which will be handling this rule, and that it need not bother to create one for itself.

An example of this is provided by the first rule we shall create: the "little-used do nothing rule". This is aptly named on both counts. We never follow it, we never put it into any rulebook. It exists only so that variables and properties with the kind of value "rule" can be initialised automatically to a safely neutral default value. It makes no decision. 

Section 2 - The Standard Rules

The little-used do nothing rule translates into Inter as "LITTLE_USED_DO_NOTHING_R".

§22. Startup. Every rulebook contains a (possibly empty) run of "first" rules, then a (possibly empty) run of miscellaneous rules, then a (possibly empty) run of "last" rules. It's unusual to have more than one rule anchored to either end as "first" or "last", but entirely legal, and we make use of that ability here.

The "first" rules here are the ones which get the basic machinery working to the point where it is safe to run arbitrary I7 source text. They necessarily do very low-level things, and it is not guaranteed that I7 phrases will behave to specification if executed before these early rules have finished. So it is hazardous to obstruct or alter them. 

The start in the correct scenes rule is listed first in the startup rulebook. th.
The position player in model world rule is listed first in the startup rulebook. th.
This is the declare everything initially unmentioned rule:
    repeat with item running through things:
        now the item is not mentioned.
The declare everything initially unmentioned rule is listed first in the startup rulebook. th
The update chronological records rule is listed first in the startup rulebook. th.
The seed random number generator rule is listed first in the startup rulebook. rd.
The virtual machine startup rule is listed first in the startup rulebook. nd.
The initialise memory rule is listed first in the startup rulebook. st.

The virtual machine startup rule translates into Inter as "VIRTUAL_MACHINE_STARTUP_R".
The initialise memory rule translates into Inter as "INITIALISE_MEMORY_R".
The seed random number generator rule translates into Inter as "SEED_RANDOM_NUMBER_GENERATOR_R".
The update chronological records rule translates into Inter as "UPDATE_CHRONOLOGICAL_RECORDS_R".
The position player in model world rule translates into Inter as "POSITION_PLAYER_IN_MODEL_R".

This is the start in the correct scenes rule: follow the scene changing rules.

§23. The remaining rules, though, are fair game for alteration, and as if to prove the point they are all written in standard I7 source text. Note that the baseline score is set only after the when play begins rulebook has finished, because games starting with a non-zero score normally do this by changing the score in a when play begins rule: and we don't want such a change to be notified to the player as if it has happened through some action. 

The when play begins stage rule is listed in the startup rulebook.
The fix baseline scoring rule is listed in the startup rulebook.
The display banner rule is listed in the startup rulebook.
The initial room description rule is listed in the startup rulebook.

This is the when play begins stage rule: follow the when play begins rulebook.

This is the fix baseline scoring rule: now the last notified score is the score.

This is the display banner rule: say "[banner text]".

This is the initial room description rule: try looking.

§24. The turn sequence. In each turn, a command is read and parsed from the keyboard, and any action(s) that requested is or are processed. (And may in turn cause other actions, which must also be processed.) There is then a fair amount of business needed to end one turn and get ready for another.

The turn sequences rulebook terminates early if deadflag becomes set at any point, so the last turn of play will be incomplete. Besides that consideration, it can also end early if the command for the turn was for an out-of-world action such as saving the game: in such cases, the "generate action rule" stops the rulebook once the action has been fully processed. All the same, play basically consists of running down this list of rules over and over again.

§25. The "first" rules in the turn sequence cover us up to the end of the events which take place in the model world during this turn's action(s).

An unusual point here is that the "parse command rule" and the "generate action rule" are written such that they do nothing unless the turn sequence rulebook is being followed at the top level (by Main, that is). This prevents them from being used recursively, which would not work properly, and enables a popular trick from the time before the 2008 reform to keep working: we can simulate six turns going by in which the player does nothing by running "follow the turn sequence rules" six times in a row. Everything happens exactly as it should — the turn count, the time of day, timed events, and so on — except that no commands are read and no consequent actions generated. 

A first turn sequence rule (this is the every turn stage rule): follow the every turn rules. th.
A first turn sequence rule: follow the scene changing rules. th.
The generate action rule is listed first in the turn sequence rulebook. rd.
The declare everything initially unmentioned rule is listed first in the turn sequence rulebook. nd.
The parse command rule is listed first in the turn sequence rulebook. st.

§26. Three miscellaneous things then happen, all implemented by primitives in the template I6 layer: 

The timed events rule is listed in the turn sequence rulebook.
The advance time rule is listed in the turn sequence rulebook.
The update chronological records rule is listed in the turn sequence rulebook.

§27. We now come to the rules anchored at the end, using "last". This part of the rulebook is reserved for book-keeping which has to happen positively at the end of the turn. 

A last turn sequence rule: follow the scene changing rules. rd from last.
The adjust light rule is listed last in the turn sequence rulebook. nd from last.
The note object acquisitions rule is listed last in the turn sequence rulebook. enultimate.
The notify score changes rule is listed last in the turn sequence rulebook. ast.

This is the notify score changes rule:
    if the score is not the last notified score:
        issue score notification message;
        now the last notified score is the score;

§28. That's it, but we need to map these I7 rule names onto the names of their I6 primitives in the template layer. 

The adjust light rule translates into Inter as "ADJUST_LIGHT_R" with
    "[It] [are] [if story tense is present tense]now [end if]pitch dark in
    [if story tense is present tense]here[else]there[end if]!" (A).
The advance time rule translates into Inter as "ADVANCE_TIME_R".
The generate action rule translates into Inter as "GENERATE_ACTION_R" with
    "(considering the first sixteen objects only)[command clarification break]" (A),
    "Nothing to do!" (B).

The note object acquisitions rule translates into Inter as "NOTE_OBJECT_ACQUISITIONS_R".
The parse command rule translates into Inter as "PARSE_COMMAND_R".
The timed events rule translates into Inter as "TIMED_EVENTS_R".

§29. Shutdown. Goodbye is not the hardest word to say, but it does involve a little bit of work. It might not actually be goodbye, for one thing: if this rulebook ends in success, then we go back to repeating the turn sequence rulebook just as if nothing had happened. 

The when play ends stage rule is listed first in the shutdown rulebook.
The resurrect player if asked rule is listed last in the shutdown rulebook.
The print player's obituary rule is listed last in the shutdown rulebook.
The ask the final question rule is listed last in the shutdown rulebook.

This is the when play ends stage rule: follow the when play ends rulebook.
This is the print player's obituary rule:
    carry out the printing the player's obituary activity.

The resurrect player if asked rule translates into Inter as "RESURRECT_PLAYER_IF_ASKED_R".
The ask the final question rule translates into Inter as "ASK_FINAL_QUESTION_R".

§30. Scene changing. Scene changing is handled by a routine called DetectSceneChange which is compiled directly by Inform: this is so primitive that it can't even be handled at the template layer. The rulebook is all a little elaborate given that it contains only one rule, but it's possible to imagine extensions which need to do book-keeping similar to scene changing and which want to make use of this opportunity. 

The scene change machinery rule is listed last in the scene changing rulebook.

The scene change machinery rule translates into Inter as "SCENE_CHANGE_MACHINERY_R".

§31. We couldn't do this earlier (because creating a scene automatically generates two rulebooks, and that would have thrown the rulebook numbering), so let's take this opportunity to define the "Entire Game" scene: 

Section 3 - The Entire Game scene

The Entire Game is a scene.
The Entire Game begins when the story has not ended.
The Entire Game ends when the story has ended.

§32. Action-processing. Action-processing happens on two levels: an upper level, handled by the main "action-processing" rulebook, and a lower level, "specific action-processing". This division clearly complicates matters, so why do we do it? It turns out be convenient for several reasons:

This does mean that an attempt by the user to move the before stage to just after the check stage (say) will fail — the before and check stages happen in different rulebooks, so no amount of rearranging will do this.

§33. The upper level of action-processing consists of seeing whether the actor's current situation forbids the action from being tried: does anybody or anything intervene to stop it? Are there are any basic reasons of physical realism why nobody could possibly try it? Does it require somebody else to cooperate who in fact chooses not to?

Doctrinally, the before stage must see actions before anything else can happen. (It needs the absolute freedom to start fresh actions and dispose of the one originally intended, sure in the knowledge that no other rules have been there first.) So before-ish material is anchored at the "first" end of the rulebook.

The other book-end on the shelf is provided by the instead stage, which doctrinally happens only when the action is now thought to be physically reasonable. So this is anchored at the "last" end. (In fact it is followed by several more rules also anchored there, but this is essentially just the clockwork machinery showing through: they aren't realism checks.)

Miscellaneous general rules to do with physical realism are placed between the two book-ends, then, and this is where any newly created action-processing rules created by the user or by extensions will go. 

Section 4 - Action processing

The before stage rule is listed first in the action-processing rules. rd.
The set pronouns from items from multiple object lists rule is listed first in the
    action-processing rules. nd.
The announce items from multiple object lists rule is listed first in the
    action-processing rules. st.
The basic visibility rule is listed in the action-processing rules.
The basic accessibility rule is listed in the action-processing rules.
The carrying requirements rule is listed in the action-processing rules.
The instead stage rule is listed last in the action-processing rules. th from last.
The requested actions require persuasion rule is listed last in the action-processing rules.
The carry out requested actions rule is listed last in the action-processing rules.
The descend to specific action-processing rule is listed last in the action-processing rules.
The end action-processing in success rule is listed last in the action-processing rules. ast.

§34. As we shall see, most of these rules are primitives implemented by the template I6 layer, but five are very straightforward. 

This is the set pronouns from items from multiple object lists rule:
    if the current item from the multiple object list is not nothing,
        set pronouns from the current item from the multiple object list.

This is the announce items from multiple object lists rule:
    if the current item from the multiple object list is not nothing,
        say "[current item from the multiple object list]: [run paragraph on]" (A).

This is the before stage rule: abide by the before rules.
This is the instead stage rule: abide by the instead rules.

§35. The final rule in the rulebook always succeeds: this ensures that action-processing always makes a decision. (I7's doctrine is that an action "succeeds" if and only if its carry-out stage is reached, so any action getting right to the end of this rulebook must have succeeded.) 

This is the end action-processing in success rule: rule succeeds.

§36. The action-processing rulebook contains six primitives: 

The basic accessibility rule translates into Inter as "BASIC_ACCESSIBILITY_R" with
    "You must name something more substantial." (A).
The basic visibility rule translates into Inter as "BASIC_VISIBILITY_R" with
    "[It] [are] pitch dark, and [we] [can't see] a thing." (A).
The carrying requirements rule translates into Inter as "CARRYING_REQUIREMENTS_R".
The requested actions require persuasion rule translates into Inter as
    "REQUESTED_ACTIONS_REQUIRE_R" with
     "[The noun] [have] better things to do." (A).
The carry out requested actions rule translates into Inter as
    "CARRY_OUT_REQUESTED_ACTIONS_R" with
    "[The noun] [are] unable to do that." (A).
The descend to specific action-processing rule translates into Inter as
"DESCEND_TO_SPECIFIC_ACTION_R".

§37. Specific action-processing. And now we descend to the lower level, which is much easier to understand. 

The work out details of specific action rule is listed first in the specific
action-processing rules.

A specific action-processing rule
    (this is the investigate player's awareness before action rule):
    follow the player's action awareness rules;
    if rule succeeded, now within the player's sight is true;
    otherwise now within the player's sight is false.

A specific action-processing rule (this is the check stage rule):
    anonymously abide by the specific check rulebook.

A specific action-processing rule (this is the carry out stage rule):
    follow the specific carry out rulebook.

A specific action-processing rule (this is the after stage rule):
    if action in world is true, abide by the after rules.

A specific action-processing rule
    (this is the investigate player's awareness after action rule):
    if within the player's sight is false:
        follow the player's action awareness rules;
        if rule succeeded, now within the player's sight is true;

A specific action-processing rule (this is the report stage rule):
    if within the player's sight is true and action keeping silent is false,
        follow the specific report rulebook;

The last specific action-processing rule: rule succeeds.

§38. The unusual use of "anonymously abide by" above is a form of "abide by" which may be worth explaining. Suppose rule \(X\) consists of an instruction to abide by rulebook \(Y\), and suppose that \(Y\) in fact fails when it reaches \(Y_k\). If the ordinary "abide by" is used then the action will be deemed to have failed at rule \(X\), but if "anonymously abide by" is used then it will be deemed to have failed at \(Y_k\). (Thus \(X\) remains anonymous: it can never be the culprit.) We only use this at the check stage, because the carry out, report and after stages are not allowed to fail the action. (The after stage is allowed to end it, but not in failure.)

§39. The specific action-processing rulebook is probably more fruitful than the main one if we want to modify what happens. For instance:

This is the sixth sense rule: if the player is not the actor, say "You sense that [the actor] is up to something."

The sixth sense rule is listed before the carry out stage rule in the specific action-processing rules.

...produces the message at a time when the action is definitely possible and will succeed, but before anything has been done.

§40. The only rule not spelled out was the primitive "work out details of specific action rule", which initialises the rulebook variables so that they record the action's specific check, carry out and report rulebooks, and whether or not it is in world. 

The work out details of specific action rule translates into Inter as
"WORK_OUT_DETAILS_OF_SPECIFIC_R".

§41. Player's action awareness. This rulebook decides whether or not an action by somebody should be routinely reported to the player: is he aware of it having taken place? If the rulebook positively succeeds then he is, and otherwise not. 

A player's action awareness rule
    (this is the player aware of his own actions rule):
    if the player is the actor, rule succeeds.
A player's action awareness rule
    (this is the player aware of actions by visible actors rule):
    if the player is not the actor and the player can see the actor, rule succeeds.
A player's action awareness rule
    (this is the player aware of actions on visible nouns rule):
    if the noun is a thing and the player can see the noun, rule succeeds.
A player's action awareness rule
    (this is the player aware of actions on visible second nouns rule):
    if the second noun is a thing and the player can see the second noun, rule succeeds.

§42. Accessibility. The "accessibility" rulebook is not very visible to users: it's another behind-the-scenes rulebook for managing the decision as to whether the actor can touch any items which the intended action requires him to be able to reach.

In its default configuration, it contains only the "access through barriers" rule. This in all circumstances either succeeds or fails: in other words, it makes a definite decision, and this is why it is anchored as "last" in the rulebook. If users or extensions want to tweak accessibility at this general level, any new rules they add will get the chance to decide before the "access through barriers" rule settles the matter. But in practice we expect most users to work with one of the two reaching rulebooks instead. 

Section 5 - Accessibility

The access through barriers rule is listed last in the accessibility rules.

The access through barriers rule translates into Inter as
    "ACCESS_THROUGH_BARRIERS_R" with
    "[regarding the noun][Those] [aren't] available." (A).

§43. Reaching inside. What the access through barriers rule does is to try to construct a path through the object containment tree from the actor to the item needed, and to apply the reaching inside or reaching outside rulebooks each time this path passes inside or outside of a container (or room). (Supporters never form barriers.) 

The can't reach inside rooms rule is listed last in the reaching inside rules. enultimate.
The can't reach inside closed containers rule is listed last in the reaching
inside rules. ast.

The can't reach inside closed containers rule translates into Inter as
    "CANT_REACH_INSIDE_CLOSED_R" with
    "[The noun] [aren't] open." (A).
The can't reach inside rooms rule translates into Inter as
    "CANT_REACH_INSIDE_ROOMS_R" with
    "[We] [can't] reach into [the noun]." (A).

§44. Reaching outside. And, not quite symmetrically since we don't need to block room-to-room reaching on both the inbound and outbound directions, 

The can't reach outside closed containers rule is listed last in the reaching outside rules.

The can't reach outside closed containers rule translates into Inter as
    "CANT_REACH_OUTSIDE_CLOSED_R" with
    "[The noun] [aren't] open." (A).

§45. Visibility. The visibility rulebook actually has the opposite sense to the one the name might suggest. It is applied only when the player (not any other actor) tries to perform an action which requires light to see by; the action is blocked if the rulebook succeeds. (Well, but we could hardly call it the invisibility rulebook. The name is supposed to suggest that the consideration of visibility is being applied: rather the way cricket matches end with a declaration that "light stopped play", meaning of course that darkness did.) 

The can't act in the dark rule is listed last in the visibility rules.

The last visibility rule (this is the can't act in the dark rule): if in darkness, rule succeeds.

§46. Does the player mean. This rulebook is akin to a set of preferences about how to interpret the player's commands in cases of ambiguity. No two Inform users are likely to agree about the best way to decide these, so we are fairly hands-off, and make only one rule as standard: 

Does the player mean taking something which is carried by the player
    (this is the very unlikely to mean taking what's already carried rule):
    it is very unlikely.

§47. And that completes the creation and stocking of the 25 rulebooks. More than half of them are initially empty, including before, instead and after — at the end of the day, these rulebooks are hooks allowing the user to change the ordinary behaviour of things, but ordinariness is exactly what the Standard Rules is all about.

§48. Adjectives applied to values. There is a small stock of built-in adjectives for values. 

Section 6 - Adjectival definitions

A scene can be recurring or non-recurring. A scene is usually non-recurring.
The Entire Game is recurring.

§49. Scene descriptions. And there is one build-in value property for values. 

Section 7 - Scene descriptions

A scene has a text called description.
When a scene (called the event) begins (this is the scene description text rule):
    if the description of the event is not "",
        say "[description of the event][paragraph break]".

§50. Command parser errors. This abstracts a set of return codes from the I6 parser, which are written there as constants with the notation *_ETYPE. 

Section 8 - Command parser errors

A command parser error is a kind of value. The command parser errors are
    didn't understand error,
    only understood as far as error,
    didn't understand that number error,
    can only do that to something animate error,
    can't see any such thing error,
    said too little error,
    aren't holding that error,
    can't use multiple objects error,
    can only use multiple objects error,
    not sure what it refers to error,
    excepted something not included error,
    not a verb I recognise error,
    not something you need to refer to error,
    can't see it at the moment error,
    didn't understand the way that finished error,
    not enough of those available error,
    nothing to do error,
    noun did not make sense in that context error,
    referred to a determination of scope error,
    I beg your pardon error,
    can't again the addressee error,
    comma can't begin error,
    can't see whom to talk to error,
    can't talk to inanimate things error, and
    didn't understand addressee's last name error.

The latest parser error is a command parser error that varies.
The latest parser error variable translates into Inter as "etype".

§51. Internal rules. These rules do nothing in themselves, and are really just hooks on which some response texts can be hung. 

Section 9 - Responses for internal rules

The list writer internal rule translates into Inter as
    "LIST_WRITER_INTERNAL_R" with
    " (" (A),
    ")" (B),
    " and " (C),
    "providing light" (D),
    "closed" (E),
    "empty" (F),
    "closed and empty" (G),
    "closed and providing light" (H),
    "empty and providing light" (I),
    "closed, empty[if serial comma option is active],[end if] and providing light" (J),
    "providing light and being worn" (K),
    "being worn" (L),
    "open" (M),
    "open but empty" (N),
    "closed" (O),
    "closed and locked" (P),
    "containing" (Q),
    "on [if the noun is a person]whom[otherwise]which[end if] " (R),
    ", on top of [if the noun is a person]whom[otherwise]which[end if] " (S),
    "in [if the noun is a person]whom[otherwise]which[end if] " (T),
    ", inside [if the noun is a person]whom[otherwise]which[end if] " (U),
    "[regarding list writer internals][are]" (V),
    "[regarding list writer internals][are] nothing" (W),
    "Nothing" (X),
    "nothing" (Y).

The action processing internal rule translates into Inter as
    "ACTION_PROCESSING_INTERNAL_R" with
    "[bracket]That command asks to do something outside of play, so it can
    only make sense from you to me. [The noun] cannot be asked to do this.lose
    bracket]" (A),
    "You must name an object." (B),
    "You may not name an object." (C),
    "You must supply a noun." (D),
    "You may not supply a noun." (E),
    "You must name a second object." (F),
    "You may not name a second object." (G),
    "You must supply a second noun." (H),
    "You may not supply a second noun." (I),
    "(Since something dramatic has happened, your list of commands has been
    cut short.)" (J),
    "I didn't understand that instruction." (K).

The parser error internal rule translates into Inter as
    "PARSER_ERROR_INTERNAL_R" with
    "I didn't understand that sentence." (A),
    "I only understood you as far as wanting to " (B),
    "I only understood you as far as wanting to (go) " (C),
    "I didn't understand that number." (D),
    "[We] [can't] see any such thing." (E),
    "You seem to have said too little!" (F),
    "[We] [aren't] holding that!" (G),
    "You can't use multiple objects with that verb." (H),
    "You can only use multiple objects once on a line." (I),
    "I'm not sure what ['][pronoun i6 dictionary word]['] refers to." (J),
    "[We] [can't] see ['][pronoun i6 dictionary word]['] ([the noun]) at the moment." (K),
    "You excepted something not included anyway!" (L),
    "You can only do that to something animate." (M),
    "That's not a verb I f American dialect option is
        active]recognize[otherwise]recognise[end if]." (N),
    "That's not something you need to refer to in the course of this game." (O),
    "I didn't understand the way that finished." (P),
    "[if number understood is 0]None[otherwise]Only [number understood in words]nd if
        of those [regarding the number understood][are] available." (Q),
    "That noun did not make sense in this context." (R),
    "To repeat a command like 'frog, jump', just say 'again', not 'frog, again'." (S),
    "You can't begin with a comma." (T),
    "You seem to want to talk to someone, but I can't see whom." (U),
    "You can't talk to [the noun]." (V),
    "To talk to someone, try 'someone, hello' or some such." (W),
    "I beg your pardon?" (X).

The parser nothing error internal rule translates into Inter as
    "PARSER_N_ERROR_INTERNAL_R" with
    "Nothing to do!" (A),
    "[There] [adapt the verb are from the third person plural] none at all available!" (B),
    "[regarding the noun][Those] [seem] to belong to [the noun]." (C),
    "[regarding the noun][Those] [can't] contain things." (D),
    "[The noun] [aren't] open." (E),
    "[The noun] [are] empty." (F).

The darkness name internal rule translates into Inter as "DARKNESS_NAME_INTERNAL_R" with
    "Darkness" (A).

The parser command internal rule translates into Inter as
    "PARSER_COMMAND_INTERNAL_R" with
    "Sorry, that can't be corrected." (A),
    "Think nothing of it." (B),
    "'Oops' can only correct a single word." (C),
    "You can hardly repeat that." (D).

The parser clarification internal rule translates into Inter as
    "PARSER_CLARIF_INTERNAL_R" with
    "Who do you mean, " (A),
    "Which do you mean, " (B),
    "Sorry, you can only have one item here. Which exactly?" (C),
    "Whom do you want [if the noun is not the player][the noun] [end if]to
        [parser command so far]?" (D),
    "What do you want [if the noun is not the player][the noun] [end if]to
        [parser command so far]?" (E),
    "those things" (F),
    "that" (G),
    " or " (H).

The yes or no question internal rule translates into Inter as
    "YES_OR_NO_QUESTION_INTERNAL_R" with
    "Please answer yes or no." (A).

The print protagonist internal rule translates into Inter as
    "PRINT_PROTAGONIST_INTERNAL_R" with
    "[We]" (A),
    "[ourselves]" (B),
    "[our] former self" (C).