mirror of
https://github.com/ganelson/inform.git
synced 2024-07-08 18:14:21 +03:00
810 lines
46 KiB
HTML
810 lines
46 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>S/nt</title>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<meta http-equiv="Content-Language" content="en-gb">
|
|
<link href="inweb.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
</head>
|
|
<body>
|
|
|
|
<!--Weave of 'S/ot2' generated by 7-->
|
|
<ul class="crumbs"><li><a href="../webs.html">★</a></li><li><a href="index.html">standard_rules Template Library</a></li><li><b>OrderOfPlay Template</b></li></ul><p class="purpose">The sequence of events in play: the Main routine which runs the startup rulebook, the turn sequence rulebook and the shutdown rulebook; and most of the I6 definitions of primitive rules in those rulebooks.</p>
|
|
|
|
<ul class="toc"><li><a href="#SP1">§1. Main</a></li><li><a href="#SP2">§2. Virtual Machine Startup Rule</a></li><li><a href="#SP3">§3. Initial Situation</a></li><li><a href="#SP4">§4. Initialise Memory Rule</a></li><li><a href="#SP5">§5. Position Player In Model World Rule</a></li><li><a href="#SP6">§6. Parse Command Rule</a></li><li><a href="#SP7">§7. Treat Parser Results</a></li><li><a href="#SP8">§8. Generate Action Rule</a></li><li><a href="#SP9">§9. Generate Multiple Actions</a></li><li><a href="#SP10">§10. Timed Events Rule</a></li><li><a href="#SP11">§11. Setting Timed Events</a></li><li><a href="#SP12">§12. Setting Time Of Day</a></li><li><a href="#SP13">§13. Advance Time Rule</a></li><li><a href="#SP14">§14. Note Object Acquisitions Rule</a></li><li><a href="#SP15">§15. Resurrect Player If Asked Rule</a></li><li><a href="#SP16">§16. Ask The Final Question Rule</a></li><li><a href="#SP17">§17. Read The Final Answer Rule</a></li><li><a href="#SP18">§18. Immediately Restart VM Rule</a></li><li><a href="#SP19">§19. Immediately Restore Saved Game Rule</a></li><li><a href="#SP20">§20. Immediately Quit Rule</a></li><li><a href="#SP21">§21. Immediately Undo Rule</a></li><li><a href="#SP22">§22. Print Obituary Headline Rule</a></li><li><a href="#SP23">§23. Print Final Score Rule</a></li><li><a href="#SP24">§24. Display Final Status Line Rule</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. Main. </b>This is where every I6 story file begins execution: it can end either by
|
|
returning, or by a <code class="display"><span class="extract">quit</span></code> statement or equivalent opcode. (In I7 this does
|
|
indeed happen when the quitting the game action is carried out, or when QUIT
|
|
is typed as a reply to the final question; it's only if the user has altered
|
|
the shutdown rulebook that we might ever actually return from <code class="display"><span class="extract">Main</span></code>.)
|
|
The return value from <code class="display"><span class="extract">Main</span></code> is not meaningful.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">EarlyInTurnSequence</span></code> flag is used to enforce the requirement that the
|
|
"parse command rule" and "generate action rule" do nothing unless the
|
|
turn sequence rulebook is being followed directly from <code class="display"><span class="extract">Main</span></code>, an anomaly
|
|
explained in the Standard Rules.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Global EarlyInTurnSequence;</span>
|
|
<span class="plain">Global IterationsOfTurnSequence;</span>
|
|
|
|
<span class="plain">[ Main;</span>
|
|
<span class="plain">#ifdef TARGET_ZCODE; max_z_object = #largest_object - 255; #endif;</span>
|
|
<span class="plain">ClearRTP();</span>
|
|
<span class="plain">FollowRulebook(STARTUP_RB);</span>
|
|
<span class="plain">#ifdef DEBUG; InternalTestCases(); #endif;</span>
|
|
<span class="plain">while (true) {</span>
|
|
<span class="plain">while (deadflag == false) {</span>
|
|
<span class="plain">EarlyInTurnSequence = true;</span>
|
|
<span class="plain">action = ##Wait; meta = false; noun = nothing; second = nothing;</span>
|
|
<span class="plain">actor = player;</span>
|
|
<span class="plain">FollowRulebook(TURN_SEQUENCE_RB);</span>
|
|
<span class="plain">IterationsOfTurnSequence++;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">if (FollowRulebook(SHUTDOWN_RB) == false) return;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. Virtual Machine Startup Rule. </b>We delegate to the appropriate VM-specific section of code for the real work.
|
|
The printing of three blank lines at the start of play is traditional: on early
|
|
Z-machine interpreters such as InfoTaskForce and Zip it was a necessity because
|
|
of the way they buffered output. On modern windowed ones it still helps to
|
|
space the opening text better.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ VIRTUAL_MACHINE_STARTUP_R;</span>
|
|
<span class="plain">CarryOutActivity(STARTING_VIRTUAL_MACHINE_ACT);</span>
|
|
<span class="plain">VM_Initialise();</span>
|
|
<span class="plain">print "^^^";</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. Initial Situation. </b>The array <code class="display"><span class="extract">InitialSituation</span></code> is compiled by NI and contains:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><ul class="items"><li>(0) The object number for the player, which is usually <code class="display"><span class="extract">selfobj</span></code>.
|
|
</li><li>(1) The object in or on which the player begins, if he does. (This will
|
|
always be an enterable container or supporter, or <code class="display"><span class="extract">nothing</span></code>.)
|
|
</li><li>(2) The room in which the player begins, which is usually the first
|
|
room created in the source text.
|
|
</li><li>(3) The initial time of day, which is usually 9 AM.
|
|
</li></ul>
|
|
</li></ul>
|
|
<p class="inwebparagraph">The start object and start room are meaningful only if the player's object
|
|
is compiled outside of the object tree (as can happen if the source text
|
|
reads, say, "Mrs Bridges is a woman. The player is Mrs Bridges."): in
|
|
other circumstances they are often correct, but this must not be relied on.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP4"></a><b>§4. Initialise Memory Rule. </b>This rule amalgamates some minimal initialisations which all need to happen
|
|
before we can risk using some of the more exotic I7 kinds:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) The language definition might call for initialisation, although the
|
|
default language of play (English) does not.
|
|
</li></ul>
|
|
<ul class="items"><li>(b) A handful of variables are filled in. <code class="display"><span class="extract">I7_LOOKMODE</span></code> is a constant
|
|
created by the use options "use full-length room descriptions" or
|
|
"use abbreviated room descriptions", but otherwise not existing. It is
|
|
particularly important that <code class="display"><span class="extract">player</span></code> have the correct value, as the
|
|
process of initialising the memory heap uses the player as the presumed
|
|
actor when creating memory representations of literal stored actions
|
|
where no actor was specified; this is why <code class="display"><span class="extract">player</span></code> is initialised here
|
|
and not in the "position player in model world rule" below. The other
|
|
interesting point here is that we explicitly set <code class="display"><span class="extract">location</span></code> and
|
|
<code class="display"><span class="extract">real_location</span></code> to <code class="display"><span class="extract">nothing</span></code>, which is certainly incorrect, even though
|
|
we know better. We do this so that the "update chronological records rule"
|
|
cannot see where the player is: see the Standard Rules for an explanation
|
|
of why this is, albeit perhaps dubiously, a good thing.
|
|
</li></ul>
|
|
<ul class="items"><li>(c) We start the machinery needed to check that property accesses are
|
|
valid during play.
|
|
</li></ul>
|
|
<ul class="items"><li>(d) And we initialise the memory allocation heap, and expand the literal
|
|
constants, as hinted above: these are called "block constants" since
|
|
they occupy blocks of memory.
|
|
</li></ul>
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">not_yet_in_play</span></code> flag, which is cleared when the first command is
|
|
about to be read from the keyboard, suppresses the standard status line
|
|
text: thus, if there is some long text to read before the player finds out
|
|
where he is, the surprise will not be spoiled.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ INITIALISE_MEMORY_R;</span>
|
|
<span class="plain">#ifdef TARGET_GLULX; VM_PreInitialise(); #Endif;</span>
|
|
<span class="plain">#Ifdef LanguageInitialise; LanguageInitialise(); #Endif;</span>
|
|
|
|
<span class="plain">not_yet_in_play = true;</span>
|
|
<span class="plain">lookmode = TEMPLATE_CONFIGURATION_LOOKMODE;</span>
|
|
<span class="plain">player = InitialSituation-->PLAYER_OBJECT_INIS;</span>
|
|
<span class="plain">the_time = InitialSituation-->START_TIME_INIS;</span>
|
|
<span class="plain">real_location = nothing;</span>
|
|
<span class="plain">location = nothing;</span>
|
|
|
|
<span class="plain">CreatePropertyOffsets();</span>
|
|
<span class="plain">HeapInitialise(); ! Create a completely unused memory allocation heap</span>
|
|
<span class="plain">StackFramingInitialise(); ! Create an empty stack</span>
|
|
<span class="plain">CreateDynamicRelations(); ! Create relation structures on the heap</span>
|
|
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. Position Player In Model World Rule. </b>This seems as good a place as any to write down the invariant we attempt
|
|
to maintain for the player's position variables:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) The <code class="display"><span class="extract">player</span></code> variable is the object through which the player plays,
|
|
which is always a person: its value is always set by starting from <code class="display"><span class="extract">selfobj</span></code>
|
|
and then making a sequence of 0 or more <code class="display"><span class="extract">ChangePlayer(new_value)</span></code> calls.
|
|
(This enables us to make sure it has the correct property values for
|
|
printed name and so forth.)
|
|
</li></ul>
|
|
<ul class="items"><li>(2) The <code class="display"><span class="extract">location</span></code> is always either the current room, a valid I7 room, or
|
|
<code class="display"><span class="extract">thedark</span></code>, which is not a valid I7 object but is distinguishable both from
|
|
all I7 objects and from <code class="display"><span class="extract">nothing</span></code>. The <code class="display"><span class="extract">real_location</span></code> is always the current
|
|
room, which is always a valid I7 room. <code class="display"><span class="extract">location</span></code> equals <code class="display"><span class="extract">thedark</span></code> if and
|
|
only if the player does not have light to see by; the routine
|
|
<code class="display"><span class="extract">SilentlyConsiderLight</span></code> updates this without printing any messages to
|
|
announce the fall or lifting of darkness (hence "silently").
|
|
</li></ul>
|
|
<ul class="items"><li>(3) The <code class="display"><span class="extract">player</span></code> object is always in the subtree of <code class="display"><span class="extract">real_location</span></code>, and
|
|
is always in a chain O_1 < O_2 < ... < O_n where O_1 is the player,
|
|
O_n is <code class="display"><span class="extract">real_location</span></code>, n>= 2 and O_2, ..., O_{n-1} are all either
|
|
enterable containers, enterable supporters, or component parts of such.
|
|
The routine <code class="display"><span class="extract">LocationOf</span></code>, applied to the player object, always agrees with
|
|
<code class="display"><span class="extract">real_location</span></code>.
|
|
</li></ul>
|
|
<ul class="items"><li>(4) "Floating" objects, such as backdrops and two-sided doors, are in
|
|
theory present in more than one room at once. In practice they can only be
|
|
in a single position in the I6 object tree at any one time. The rule is that
|
|
if they are theoretically present in the <code class="display"><span class="extract">real_location</span></code>, then they are
|
|
actually present in the subtree of <code class="display"><span class="extract">real_location</span></code>. The routine
|
|
<code class="display"><span class="extract">MoveFloatingObjects</span></code> updates this, and must be called whenever the player
|
|
moves from one room to another.
|
|
</li></ul>
|
|
<ul class="items"><li>(5) Any objects carried by the player have the I6 <code class="display"><span class="extract">moved</span></code> attribute set.
|
|
The <code class="display"><span class="extract">SACK_OBJECT</span></code> variable is always set to the object of kind "player's
|
|
holdall" which the player has most recently been carrying, or had as
|
|
a component part of himself. The "note object acquisitions" rule updates
|
|
this.
|
|
</li></ul>
|
|
<p class="inwebparagraph">These invariants are usually all false before the following rule is executed;
|
|
they are all true once it has completed. In addition, because the global
|
|
action variables usually hold details of the action most recently carried
|
|
out, we initialise these as if the most recent action had been the player
|
|
waiting. (Nobody ought to use these variables at this point, but in case
|
|
they do use them by accident in a "when play begins" rule, we want Inform
|
|
to behave predictably and without type-unsafe values entering code.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ POSITION_PLAYER_IN_MODEL_R player_to_be;</span>
|
|
|
|
<span class="plain">player = selfobj;</span>
|
|
<span class="plain">player_to_be = InitialSituation-->PLAYER_OBJECT_INIS;</span>
|
|
|
|
<span class="plain">location = LocationOf(player_to_be);</span>
|
|
<span class="plain">if (location == 0) {</span>
|
|
<span class="plain">location = InitialSituation-->START_ROOM_INIS;</span>
|
|
<span class="plain">if (InitialSituation-->START_OBJECT_INIS)</span>
|
|
<span class="plain">move player_to_be to InitialSituation-->START_OBJECT_INIS;</span>
|
|
<span class="plain">else move player_to_be to location;</span>
|
|
<span class="plain">}</span>
|
|
|
|
<span class="plain">if (player_to_be ~= player) { remove selfobj; ChangePlayer(player_to_be); }</span>
|
|
<span class="plain">else { real_location = location; SilentlyConsiderLight(); }</span>
|
|
|
|
<span class="plain">NOTE_OBJECT_ACQUISITIONS_R(); MoveFloatingObjects();</span>
|
|
|
|
<span class="plain">actor = player; act_requester = nothing; actors_location = real_location; action = ##Wait;</span>
|
|
|
|
<span class="plain">InitialSituation-->DONE_INIS = true;</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP6"></a><b>§6. Parse Command Rule. </b>This section contains only two primitive rules from the turn sequence
|
|
rulebook, the matched pair of the "parse command rule" and the
|
|
"generate action rule"; the others are found in the sections on Light
|
|
and Time.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">We use almost identically the same parser as that in the I6 library, since
|
|
it is a well-proven and understood algorithm. The I6 parser returns some of
|
|
its results in a supplied array (here <code class="display"><span class="extract">parser_results</span></code>, though the I6
|
|
library used to call this <code class="display"><span class="extract">inputobjs</span></code>), but others are in global variables:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) The <code class="display"><span class="extract">parser_results</span></code> array holds four words, used as indexed by the
|
|
constants below.
|
|
</li></ul>
|
|
<ul class="items"><ul class="items"><li>(a) The action can be a valid I6 action number, or an I6 "fake
|
|
action", a concept not used overtly in I7. Most valid I6 actions
|
|
correspond exactly to I7 actions, but in principle it is possible to
|
|
define (say) extra debugging commands entirely at the I6 level.
|
|
</li></ul>
|
|
</li></ul>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><ul class="items"><li>(b) The count <code class="display"><span class="extract">NO_INPS_PRES</span></code> is always 0, 1 or 2, and then that many
|
|
of the next two words are meaningful.
|
|
</li></ul>
|
|
</li></ul>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><ul class="items"><li>(c) Each of the "inp" values is either 0, meaning "put the
|
|
multiple object list here"; or 1, meaning "not an object but a
|
|
value"; or a valid I6 object. (We use the scoping rules to ensure
|
|
that any I6 object visible to the parser is also a valid I7 object, so
|
|
— unlike with actions — we need not distinguish between the two.)
|
|
</li></ul>
|
|
</li></ul>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(2) The global variable <code class="display"><span class="extract">actor</span></code> is set to the person asked to carry out
|
|
the command, or is the same as <code class="display"><span class="extract">player</span></code> if nobody was mentioned. Thus it
|
|
will be the object for Floyd in the command FLOYD, GET PERMIT, but will be
|
|
just <code class="display"><span class="extract">player</span></code> in the command EAST.
|
|
</li></ul>
|
|
<ul class="items"><li>(3) The global variables <code class="display"><span class="extract">special_number1</span></code> and, if necessary, <code class="display"><span class="extract">special_number2</span></code>
|
|
hold values corresponding to the first and second of the "inps" to be
|
|
returned as 1. Thus, if one of the "inps" is a value and the other is
|
|
an object, then <code class="display"><span class="extract">special_number1</span></code> is that value; only if both are values
|
|
rather than objects will <code class="display"><span class="extract">special_number2</span></code> be used. There is no indication
|
|
of the kind of these values: I6 is typeless.
|
|
</li></ul>
|
|
<ul class="items"><li>(4) At most one of the "inps" is permitted to be 1, referring to a multiple
|
|
object list. (And a multiple value list is forbidden.) If this happens, the
|
|
list of objects is stored in an I6 table array (i.e., with the 0th word
|
|
being the number of subsequent words) called <code class="display"><span class="extract">multiple_object</span></code>, and the
|
|
parser will have set the <code class="display"><span class="extract">toomany_flag</span></code> if an overflow occurred — that is,
|
|
if the list was truncated because it originally called for more than 63
|
|
objects.
|
|
</li></ul>
|
|
<ul class="items"><li>(5) The global variable <code class="display"><span class="extract">meta</span></code> is set if the action is one marked as such
|
|
in the I6 grammar. A confusion in the design of I6 is that being out of world,
|
|
as we would say in I7 terms, is associated not with an action as such but
|
|
with the command verb triggering it. (This in practice caused no trouble
|
|
since we never used, say, the word SAVE for both saving the game and saving,
|
|
I don't know, box top coupons.) The state of <code class="display"><span class="extract">meta</span></code> returned by the I6
|
|
parser does not quite correspond to I7's "out of world" concept, so we
|
|
will alter it in a few cases.
|
|
</li></ul>
|
|
<p class="inwebparagraph">Some of these conventions are a little odd-looking now: why not simply
|
|
have a larger results array, rather than this pile of occasionally
|
|
used variables? The reasons are purely historical: the I6 parser
|
|
developed gradually over about a decade.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Constant ACTION_PRES = 0;</span>
|
|
<span class="plain">Constant NO_INPS_PRES = 1;</span>
|
|
<span class="plain">Constant INP1_PRES = 2;</span>
|
|
<span class="plain">Constant INP2_PRES = 3; ! Parser.i6t code assumes this is INP1_PRES + 1</span>
|
|
|
|
<span class="plain">[ PARSE_COMMAND_R;</span>
|
|
<span class="plain">if (EarlyInTurnSequence == false) rfalse; ! Prevent use outside top level</span>
|
|
<span class="plain">not_yet_in_play = false;</span>
|
|
|
|
<span class="plain">Parser__parse();</span>
|
|
<span class="plain">TreatParserResults();</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP7"></a><b>§7. Treat Parser Results. </b>We don't quite use the results exactly as they are returned by the parser:
|
|
we make modifications in a few special cases.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) <code class="display"><span class="extract">##MistakeAction</span></code> is a valid I6 action, but not an I7 one. It is used to
|
|
implement "Understand ... as a mistake", which provides a short-cut way
|
|
for I7 source text to specify responses to mistaken guesses at the syntax
|
|
expected for commands. It can therefore result from a whole variety of
|
|
different commands, some of which might be flagged <code class="display"><span class="extract">meta</span></code>, others not.
|
|
We forcibly set the <code class="display"><span class="extract">meta</span></code> flag: a mistake in guessing the command always
|
|
happens out of world.
|
|
</li></ul>
|
|
<ul class="items"><li>(2) A command in the form PERSON, TELL ME ABOUT SOMETHING is altered to
|
|
the action resulting from ASK PERSON ABOUT SOMETHING, so that <code class="display"><span class="extract">##Tell</span></code>
|
|
is converted to <code class="display"><span class="extract">##Ask</span></code> in these cases.
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ TreatParserResults;</span>
|
|
<span class="plain">if (parser_results-->ACTION_PRES == ##MistakeAction) meta = true;</span>
|
|
|
|
<span class="plain">if (parser_results-->ACTION_PRES == ##Tell &&</span>
|
|
<span class="plain">parser_results-->INP1_PRES == player && actor ~= player) {</span>
|
|
<span class="plain">parser_results-->ACTION_PRES = ##Ask;</span>
|
|
<span class="plain">parser_results-->INP1_PRES = actor; actor = player;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP8"></a><b>§8. Generate Action Rule. </b>For what are, again, historical reasons to do with the development of I6,
|
|
the current action is recorded in a slate of global variables:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) <code class="display"><span class="extract">actor</span></code> is as above; <code class="display"><span class="extract">action</span></code> is the I6 action number or fake action
|
|
number, though in I7 usage no fake actions should ever reach this point.
|
|
</li></ul>
|
|
<ul class="items"><li>(2) <code class="display"><span class="extract">act_requester</span></code> is the person requesting that the actor should perform
|
|
the action, or <code class="display"><span class="extract">nothing</span></code> if the action is the actor's own choice. In the
|
|
command FLOYD, MOP FLOOR, the <code class="display"><span class="extract">act_requester</span></code> is the player and the actor
|
|
is Floyd; but when an action arises from a try phrase in I7, such as
|
|
"try Floyd mopping the floor", <code class="display"><span class="extract">act_requester</span></code> is <code class="display"><span class="extract">nothing</span></code> because
|
|
it is Floyd's own decision to do this. (The computer, of course, represents
|
|
the will-power of all characters other than the player.)
|
|
</li></ul>
|
|
<ul class="items"><li>(3) <code class="display"><span class="extract">inp1</span></code> and <code class="display"><span class="extract">inp2</span></code> are global variables whose contents mean the same
|
|
as those of <code class="display"><span class="extract">parser_results-->INP1_PRES</span></code> and <code class="display"><span class="extract">parser_results-->INP2_PRES</span></code>.
|
|
(This is not duplication, because actions also arise from "try" rather
|
|
than the parser.)
|
|
</li></ul>
|
|
<ul class="items"><li>(4) The variable <code class="display"><span class="extract">multiflag</span></code> is set during the processing of a multiple
|
|
object list, and clear otherwise. (It is used for instance by the Standard
|
|
Rules to give more concise reports of some successful actions.) Note that
|
|
it remains set during any knock-on actions caused by actions in the multiple
|
|
object list: the following rule is the only place where <code class="display"><span class="extract">multiflag</span></code> is
|
|
set or cleared.
|
|
</li></ul>
|
|
<ul class="items"><li>(5) <code class="display"><span class="extract">noun</span></code> and <code class="display"><span class="extract">second</span></code> are global variables which are equal to <code class="display"><span class="extract">inp1</span></code> and
|
|
<code class="display"><span class="extract">inp2</span></code> when the latter hold valid object numbers, and are equal to <code class="display"><span class="extract">nothing</span></code>
|
|
otherwise. (This is not duplication either, because it provides us with
|
|
type-safe access to objects: there is no KOV which can safely represent
|
|
<code class="display"><span class="extract">inp1</span></code> and <code class="display"><span class="extract">inp2</span></code>, but <code class="display"><span class="extract">noun</span></code> and <code class="display"><span class="extract">second</span></code> are valid for the I7 kind of
|
|
value "object".)
|
|
</li></ul>
|
|
<p class="inwebparagraph">In the following rule, we create this set of variables for the action or
|
|
multiple action(s) suggested by the parser: each action is sent on to
|
|
<code class="display"><span class="extract">BeginAction</span></code> for processing. Once done, we reset the above variables
|
|
in what might seem an odd way: we allow straightforward actions by the
|
|
player to remain in the variables, but convert requests to other people
|
|
to the neutral "waiting" action carried out by the player (which is the
|
|
zero value for actions). Now, in a better world, we would always erase
|
|
the action like this, because an action once completed ought to be forgotten.
|
|
The value of <code class="display"><span class="extract">noun</span></code> ought to be visible only during the action's processing.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">But in practice many I7 users write "every turn" rules which are predicated
|
|
on what the turn's main action was: say, "Every turn when going: ..."
|
|
The every turn stage is not until later in the turn sequence, so such rules
|
|
can only work if we keep the main parser-generated action of the turn in
|
|
the action variables when we finish up here: so that's what we do.
|
|
(Note that <code class="display"><span class="extract">BeginAction</span></code> preserves the values of the action variables,
|
|
storing copies on the stack, so whatever may have happened during processing,
|
|
we finish this routine with the same action variable values that we set at
|
|
the beginning.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Finally, note that an out of world action stops the turn sequence early, at
|
|
the end of action generation: this is what prevents the time of day advancing,
|
|
every turn rules from firing, and so forth — see the Standard Rules.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ GENERATE_ACTION_R i;</span>
|
|
<span class="plain">if (EarlyInTurnSequence == false) rfalse; ! Prevent use outside top level</span>
|
|
<span class="plain">EarlyInTurnSequence = false;</span>
|
|
|
|
<span class="plain">action = parser_results-->ACTION_PRES;</span>
|
|
<span class="plain">act_requester = nothing; if (actor ~= player) act_requester = player;</span>
|
|
|
|
<span class="plain">inp1 = 0; inp2 = 0; multiflag = false;</span>
|
|
<span class="plain">if (parser_results-->NO_INPS_PRES >= 1) {</span>
|
|
<span class="plain">inp1 = parser_results-->INP1_PRES; if (inp1 == 0) multiflag = true;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">if (parser_results-->NO_INPS_PRES >= 2) {</span>
|
|
<span class="plain">inp2 = parser_results-->INP2_PRES; if (inp2 == 0) multiflag = true;</span>
|
|
<span class="plain">}</span>
|
|
|
|
<span class="plain">if (inp1 == 1) noun = nothing; else noun = inp1;</span>
|
|
<span class="plain">if (inp2 == 1) second = nothing; else second = inp2;</span>
|
|
|
|
<span class="plain">if (multiflag) {</span>
|
|
<span class="plain">if (multiple_object-->0 == 0) {</span>
|
|
<span class="plain">if (actor == player) { GENERATE_ACTION_RM('B'); new_line; }</span>
|
|
<span class="plain">return;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">if (toomany_flag) {</span>
|
|
<span class="plain">toomany_flag = false;</span>
|
|
<span class="plain">if (actor == player) { GENERATE_ACTION_RM('A'); }</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">i = multiple_object-->0;</span>
|
|
<span class="plain">FollowRulebook(MULTIPLE_ACTION_PROCESSING_RB);</span>
|
|
<span class="plain">if ((multiple_object-->0 == 1) && (i > 1)) {</span>
|
|
<span class="plain">multiflag = false;</span>
|
|
<span class="plain">if (inp1 == 0) noun = multiple_object-->1;</span>
|
|
<span class="plain">if ((inp2 == 0) && (parser_results-->NO_INPS_PRES >= 2))</span>
|
|
<span class="plain">second = multiple_object-->1;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">if (multiple_object-->0 == 0) rfalse;</span>
|
|
<span class="plain">}</span>
|
|
|
|
<span class="plain">if (multiflag) {</span>
|
|
<span class="plain">GenerateMultipleActions();</span>
|
|
<span class="plain">multiflag = false;</span>
|
|
<span class="plain">} else BeginAction(action, noun, second);</span>
|
|
|
|
<span class="plain">if ((actor ~= player) || (act_requester)) action = ##Wait;</span>
|
|
<span class="plain">actor = player; act_requester = 0;</span>
|
|
|
|
<span class="plain">if (meta) { RulebookSucceeds(); rtrue; }</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP9"></a><b>§9. Generate Multiple Actions. </b>So this routine is used to issue the individual actions necessary when
|
|
a multiple object list has been supplied as either the noun or second noun
|
|
part of an action generated by the parser. Note that we stop processing
|
|
the list in the event of the game ending, or of the <code class="display"><span class="extract">location</span></code> variable
|
|
changing its value, which can happen either through movement of the player,
|
|
or through passage from darkness to light or vice versa.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">We use <code class="display"><span class="extract">RunParagraphOn</span></code> to omit skipped lines as paragraph breaks between
|
|
the results from any item in the list: this is both more condensed on screen
|
|
in ordinary lists, and might allow the user to play tricks such as gathering
|
|
up reports from a list and delivering them later in some processed way.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ GenerateMultipleActions initial_location k item;</span>
|
|
<span class="plain">initial_location = location;</span>
|
|
<span class="plain">for (k=1: k<=multiple_object-->0: k++) {</span>
|
|
<span class="plain">item = multiple_object-->k;</span>
|
|
<span class="plain">RunParagraphOn();</span>
|
|
<span class="plain">if (inp1 == 0) { inp1 = item; BeginAction(action, item, second, item); inp1 = 0; }</span>
|
|
<span class="plain">else { inp2 = item; BeginAction(action, noun, item, item); inp2 = 0; }</span>
|
|
<span class="plain">if (deadflag) return;</span>
|
|
<span class="plain">if (location ~= initial_location) {</span>
|
|
<span class="plain">if (player == actor) { ACTION_PROCESSING_INTERNAL_RM('J'); new_line; }</span>
|
|
<span class="plain">return;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP10"></a><b>§10. Timed Events Rule. </b>A timed event is a rule stored in the <code class="display"><span class="extract">TimedEventsTable</span></code>, an I6 table array:
|
|
zero entries in this table are ignored, and the sequence is significant
|
|
only if more than one event goes off at the same moment, in which case
|
|
earlier entries go off first. Each rule in the table has a corresponding
|
|
timer value in <code class="display"><span class="extract">TimedEventTimesTable</span></code>. If this is negative, it represents
|
|
a number of turns to go before the event happens — or properly speaking, the
|
|
number of times the timed events rule is invoked. Otherwise the timer value
|
|
must be a valid time of day at which the event happens (note that valid times
|
|
are all non-negative integers). We allow a bracket of 30 minutes after the
|
|
event time proper; this is designed to cope with situations in which the
|
|
user sets some timed events, then advances the clock by hand (or uses a
|
|
long step time, say in which each turn equates to 20 minutes).
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Because an event is struck out of the table just before it is fired, it
|
|
will not continue to go off the rest of the half-hour. Moreover, because
|
|
the striking out happens before rather than after the rule fires, a
|
|
rule can re-time itself to go off again later, somewhat like the snooze
|
|
feature on an alarm clock, without the risk of it going off again
|
|
immediately in the same use of the timed events rule: there is guaranteed
|
|
to be a blank slot in the timer array at or before the current position
|
|
because we have just blanked one.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ TIMED_EVENTS_R i d event_timer fire rule;</span>
|
|
<span class="plain">for (i=1: i<=(TimedEventsTable-->0): i++)</span>
|
|
<span class="plain">if ((rule=TimedEventsTable-->i) ~= 0) {</span>
|
|
<span class="plain">event_timer = TimedEventTimesTable-->i; fire = false;</span>
|
|
<span class="plain">if (event_timer<0) {</span>
|
|
<span class="plain">(TimedEventTimesTable-->i)++;</span>
|
|
<span class="plain">if (TimedEventTimesTable-->i == 0) fire = true;</span>
|
|
<span class="plain">} else {</span>
|
|
<span class="plain">d = (the_time - event_timer + TWENTY_FOUR_HOURS) % TWENTY_FOUR_HOURS;</span>
|
|
<span class="plain">if ((d >= 0) && (d < 30)) fire = true;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">if (fire) {</span>
|
|
<span class="plain">TimedEventsTable-->i = 0;</span>
|
|
<span class="plain">FollowRulebook(rule);</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP11"></a><b>§11. Setting Timed Events. </b>This is the corresponding routine which adds events to the timer tables, and
|
|
is used to define phrases like "the cuckoo clock explodes in 7 turns from
|
|
now" or "the cuckoo clock explodes at 4 PM". Here the <code class="display"><span class="extract">rule</span></code> would be
|
|
"cuckoo clock explodes", and the <code class="display"><span class="extract">event_time</span></code> would either be 4 PM with
|
|
<code class="display"><span class="extract">absolute_time</span></code> set, or simply 7 with <code class="display"><span class="extract">absolute_time</span></code> clear.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Note that the same event can occur only once in the timer tables: a new
|
|
setting for its firing overwrites an old one. (This ensures that the table
|
|
does not slowly balloon in size if the user has not been careful to ensure
|
|
that events always fire.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ SetTimedEvent rule event_time absolute_time i b;</span>
|
|
<span class="plain">for (i=1: i<=(TimedEventsTable-->0): i++) {</span>
|
|
<span class="plain">if (rule == TimedEventsTable-->i) { b=i; break; }</span>
|
|
<span class="plain">if ((b==0) && (TimedEventsTable-->i == 0)) b=i;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">if (b==0) return RunTimeProblem(RTP_TOOMANYEVENTS);</span>
|
|
<span class="plain">TimedEventsTable-->b = rule;</span>
|
|
<span class="plain">if (absolute_time) TimedEventTimesTable-->b = event_time;</span>
|
|
<span class="plain">else TimedEventTimesTable-->b = -event_time;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP12"></a><b>§12. Setting Time Of Day. </b>This is the old I6 library routine <code class="display"><span class="extract">SetTime</span></code>, which is no longer used in I7
|
|
at present; but might be, some day.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Global time_step;</span>
|
|
|
|
<span class="plain">[ SetTime t s;</span>
|
|
<span class="plain">the_time = t; time_rate = s; time_step = 0;</span>
|
|
<span class="plain">if (s < 0) time_step = 0-s;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP13"></a><b>§13. Advance Time Rule. </b>This rule advances the two measures of the passing of time: the number of
|
|
<code class="display"><span class="extract">turns</span></code> of play, and <code class="display"><span class="extract">the_time</span></code> of day.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ ADVANCE_TIME_R;</span>
|
|
<span class="plain">turns++;</span>
|
|
<span class="plain">if (the_time ~= NULL) {</span>
|
|
<span class="plain">if (time_rate >= 0) the_time = the_time+time_rate;</span>
|
|
<span class="plain">else {</span>
|
|
<span class="plain">time_step--;</span>
|
|
<span class="plain">if (time_step == 0) {</span>
|
|
<span class="plain">the_time++;</span>
|
|
<span class="plain">time_step = -time_rate;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">the_time = the_time % TWENTY_FOUR_HOURS;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP14"></a><b>§14. Note Object Acquisitions Rule. </b>See the Standard Rules for comment on this.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ NOTE_OBJECT_ACQUISITIONS_R obj;</span>
|
|
<span class="plain">objectloop (obj in player) give obj moved;</span>
|
|
<span class="plain">objectloop (obj has concealed)</span>
|
|
<span class="plain">if (IndirectlyContains(player, obj)) give obj ~concealed;</span>
|
|
<span class="plain">#Ifdef RUCKSACK_CLASS;</span>
|
|
<span class="plain">objectloop (obj in player)</span>
|
|
<span class="plain">if (obj ofclass RUCKSACK_CLASS)</span>
|
|
<span class="plain">SACK_OBJECT = obj;</span>
|
|
<span class="plain">objectloop (obj ofclass RUCKSACK_CLASS && obj provides component_parent</span>
|
|
<span class="plain">&& obj.component_parent == player)</span>
|
|
<span class="plain">SACK_OBJECT = obj;</span>
|
|
<span class="plain">#Endif;</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP15"></a><b>§15. Resurrect Player If Asked Rule. </b>If a rule in the "when play ends" rulebook set <code class="display"><span class="extract">resurrect_please</span></code>, by executing
|
|
the "resume the game" phrase, then this is where we notice that: making
|
|
the shutdown rulebook succeed then tells <code class="display"><span class="extract">Main</span></code> to fall back into the turn
|
|
sequence.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ RESURRECT_PLAYER_IF_ASKED_R;</span>
|
|
<span class="plain">if (resurrect_please) {</span>
|
|
<span class="plain">RulebookSucceeds(); resurrect_please = false;</span>
|
|
<span class="plain">deadflag = 0; story_complete = false; rtrue;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP16"></a><b>§16. Ask The Final Question Rule. </b>And so we come to the bittersweet end: we ask the final question endlessly,
|
|
until the player gives a reply which takes drastic enough action to destroy
|
|
the current execution context in the VM, for instance by typing QUIT, RESTART,
|
|
UNDO or RESTORE. The question and answer are all managed by the activity,
|
|
which is defined in I7 source text in the Standard Rules.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ ASK_FINAL_QUESTION_R;</span>
|
|
<span class="plain">print "^";</span>
|
|
<span class="plain">while (true) {</span>
|
|
<span class="plain">CarryOutActivity(DEALING_WITH_FINAL_QUESTION_ACT);</span>
|
|
<span class="plain">DivideParagraphPoint();</span>
|
|
<span class="plain">if (resurrect_please) rtrue;</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP17"></a><b>§17. Read The Final Answer Rule. </b>This erases the current command, so is a technique we couldn't use during
|
|
actual play, but here commands are but a distant memory. So we can use the
|
|
same buffers for the final question as for game commands.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ READ_FINAL_ANSWER_R;</span>
|
|
<span class="plain">DrawStatusLine();</span>
|
|
<span class="plain">KeyboardPrimitive(buffer, parse);</span>
|
|
<span class="plain">players_command = 100 + WordCount();</span>
|
|
<span class="plain">num_words = WordCount();</span>
|
|
<span class="plain">wn = 1;</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP18"></a><b>§18. Immediately Restart VM Rule. </b>Now for four rules acting on typical responses to the final question.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ IMMEDIATELY_RESTART_VM_R; @restart; ];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP19"></a><b>§19. Immediately Restore Saved Game Rule. </b>It is almost certainly unnecessary to set <code class="display"><span class="extract">actor</span></code> to <code class="display"><span class="extract">player</span></code> here, but
|
|
we do so just in case, because <code class="display"><span class="extract">RESTORE_THE_GAME_R</span></code> is protected against
|
|
doing anything when it thinks it might have been called erroneously through
|
|
a command like "DAPHNE, RESTORE". (Out of world actions should never
|
|
be carried out that way, but again, it's a precaution.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ IMMEDIATELY_RESTORE_SAVED_R; actor = player; RESTORE_THE_GAME_R(); ];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP20"></a><b>§20. Immediately Quit Rule. </b></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ IMMEDIATELY_QUIT_R; @quit; ];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP21"></a><b>§21. Immediately Undo Rule. </b></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ IMMEDIATELY_UNDO_R; Perform_Undo(); ];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP22"></a><b>§22. Print Obituary Headline Rule. </b>Finally, definitions of three primitive rules for the "printing the player's
|
|
obituary" activity.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ PRINT_OBITUARY_HEADLINE_R;</span>
|
|
<span class="plain">print "^^ ";</span>
|
|
<span class="plain">VM_Style(ALERT_VMSTY);</span>
|
|
<span class="plain">print "***";</span>
|
|
<span class="plain">if (deadflag == 1) PRINT_OBITUARY_HEADLINE_RM('A');</span>
|
|
<span class="plain">if (deadflag == 2) PRINT_OBITUARY_HEADLINE_RM('B');</span>
|
|
<span class="plain">if (deadflag == 3) PRINT_OBITUARY_HEADLINE_RM('C');</span>
|
|
<span class="plain">if (deadflag ~= 0 or 1 or 2 or 3) {</span>
|
|
<span class="plain">print " ";</span>
|
|
<span class="plain">TEXT_TY_Say(deadflag);</span>
|
|
<span class="plain">print " ";</span>
|
|
<span class="plain">}</span>
|
|
<span class="plain">print "***";</span>
|
|
<span class="plain">VM_Style(NORMAL_VMSTY);</span>
|
|
<span class="plain">print "^^^";</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP23"></a><b>§23. Print Final Score Rule. </b></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ PRINT_FINAL_SCORE_R;</span>
|
|
<span class="plain">if (TEMPLATE_CONFIGURATION_BITMAP & USE_SCORING_TCBIT) ANNOUNCE_SCORE_R();</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP24"></a><b>§24. Display Final Status Line Rule. </b></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">[ DISPLAY_FINAL_STATUS_LINE_R;</span>
|
|
<span class="plain">sline1 = score; sline2 = turns;</span>
|
|
<span class="plain">rfalse;</span>
|
|
<span class="plain">];</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<hr class="tocbar">
|
|
<ul class="toc"><li><a href="S-nt.html">Back to 'Number Template'</a></li><li><a href="S-ot3.html">Continue with 'OutOfWorld Template'</a></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
</body>
|
|
</html>
|
|
|