I6 Template Layer

Requirements Bitmap.

As noted above, the AD_REQUIREMENTS field is a bitmap of flags for various possible action requirements:

Try Action.

This is method (ii) in the summary above.

I6 Angle Brackets.

This is method (iii) in the summary above. The routine here has slightly odd conventions and a curious name which would take too long to explain: neither can be changed without amending the veneer code within the I6 compiler.

Conversion.

This is method (iv) in the summary above.

Implicit Take.

This is method (vi) in the summary above.

Look After Going.

This is method (vii) in the summary above.

Fundamentally, room descriptions arise through looking actions, but they are also printed after successful going actions, with a special form of paragraph break (see Printing.i6t for an explanation of this). Room descriptions through looking are always given in full, unless we have SUPERBRIEF mode set.

Abbreviated Room Description.

This is used when we want a room description with the same abbreviation conventions as after a going action, and we don't quite want a looking action fully to take place. We nevertheless want to be sure that the action variables for looking exist, and in particular, we want to set the "room-describing action" variable to the action which was prevailing when the room description was called for. We also set "abbreviated form allowed" to "true": when the ordinary looking action is running, this is "false".

The actual description occurs during LookSub, which is the specific action processing stage for the "looking" action: thus, we use the check, carry out, after and report rules as if we were "looking", but are unaffected by before or instead rules.

Uniquely, this pseudo-action does not use BeginAction: it works only through the specific action processing rules, not the main action-processing ones, though that is not easy to see from the code below because it is hidden in the call to LookSub. The -Sub suffix is an I6 usage identifying this as the routine to go along with the action ##Look, and so it is, but it looks nothing like the LookSub of the old I6 library. NI compiles -Sub routines like so:

(with whatever rulebook numbers are appropriate). GenericVerbSub then runs through the specific action processing stage.

Begin Action.

We now begin the second half of the segment: the machinery which handles all actions.

The significance of 4096 here is that this is how I6 distinguishes genuine actions – numbered upwards in order of creation – from what I6 calls "fake actions" – numbered upwards from 4096. Fake actions are hardly used at all in I7, and certainly shouldn't get here, but it's possible nonetheless using I6 angled-brackets, so... In other respects all we do is to save details of whatever current action is happening onto the stack, and then call ActionPrimitive.

Action Primitive.

This is somewhat different from the I6 library counterpart which gives it its name, but the idea is the same. It has no arguments at all: everything it needs to know is now stored in global variables. The routine looks long, but really contains little: it's all just book-keeping, printing debugging information if ACTIONS is in force, etc., with all of the actual work delegated to the action processing rulebook.

We use a rather sneaky device to handle out-of-world actions, those for which the meta flag is set: we make it look to the system as if the "action processing rulebook" is being followed, so that all its variables are created and placed in scope, but at the crucial moment we descend to the specific action processing rules directly instead of processing the main rulebook. This is what short-circuits out of world actions and protects them from before and instead rules: see the Standard Rules for more discussion of this.

Internal Rule.

Provided only as a hook on which to hang responses.

Type Safety.

Some basic action requirements have to be met before we can go any further: if they aren't, then it isn't type-safe even to run the action processing rulebook.

(i) For an out of world action, we set the meta flag. Otherwise: (ii) If either the noun or second noun is a topic, then this is an action arising from parsing (such actions do not arise through the "try" phrase, unless by stored actions in which case this has all happened before and doesn't need to be done again) – the parser places details of which words make up the topic in the I6 global variables consult_words and consult_from. We convert them to a valid I7 snippet value. (iii) If either the first or second noun is supposed to be an object but seems here to be a value, or vice versa, we stop with a parser error. (This should be fairly difficult to provoke: NI's type-checking will make it difficult to arrange without I6 subterfuges.) (iv) If either the first or second noun is supposed to be an object and required to exist, yet is missing, we use the "supplying a missing noun" or "supplying a missing second noun" activities to fill the void.

We return true if type safety is violated, false if all is well.

Basic Visibility Rule.

This is one of the I6 primitive rules in the action processing rulebook: see the account in the Standard Rules for details.

Note that this rule only blocks the player from acting in darkness: this is because light is only reckoned from the player's perspective in any case, so that it would be unfair to apply the rule to any other person.

Basic Accessibility Rule.

This is one of the I6 primitive rules in the action processing rulebook: see the account in the Standard Rules for details.

Carrying Requirements Rule.

This is one of the I6 primitive rules in the action processing rulebook: see the account in the Standard Rules for details.

Standard Implicit Taking Rule.

Requested Actions Require Persuasion Rule.

This is one of the I6 primitive rules in the action processing rulebook: see the account in the Standard Rules for details.

Carry Out Requested Actions Rule.

This is one of the I6 primitive rules in the action processing rulebook: see the account in the Standard Rules for details.

Generic Verb Subroutine.

In I6, actions are carried out by routines with names like TakeSub, consisting of -Sub tacked on to the action name Take. Sub stands for "subroutine": this is all a convention going back to Inform 1, which was in 1993 practically an assembler. In the I6 code generated by I7, every -Sub routine corresponding to an I7 action consists only of a call to GenericVerbSub which specifies the three rulebooks it owns: its check, carry out and report rulebooks.

Work Out Details Of Specific Action Rule.

This is one of the I6 primitive rules in the specific action processing rulebook, and it's basically a trick to allow information known to the GenericVerbSub routine to be passed down as rulebook variables for the specific action-processing rules – in effect allowing us to pass not one but five parameters to the rulebook: the out-of-world and silence flags, plus the three specific rulebooks needed to process the action.

Actions Bitmap.

This is a fairly large bitmap recording which actions have succeeded thus far on which nouns. It was to some extent an early attempt at implementing a past-tense system; I'm not at all sure it was successful, since it is hindered by certain restrictions – it only records action/noun combinations, for instance, and the notion of "success" is a vexed one for actions anyway. There is a clearly defined meaning, but it doesn't always correspond to what the user might expect, which is unfortunate.

Printing Actions.

This is really for debugging purposes, but also provides us with a way to print a stored action, for instance, or to print an action name value. (For instance, printing an action name might result in "taking"; printing a whole action might produce "Henry taking the grapefruit".)