<!--Weave of 'Chronology Template' generated by 7-->
<ulclass="crumbs"><li><ahref="../index.html">Home</a></li><li><ahref="../extensions.html">Kits</a></li><li><ahref="index.html">WorldModelKit</a></li><li><b>Chronology Template</b></li></ul><pclass="purpose">To record information now which will be needed later, when a condition phrased in the perfect tense is tested.</p>
<ulclass="toc"><li><ahref="S-chr.html#SP1">§1. Scheme I</a></li><li><ahref="S-chr.html#SP2">§2. Present and Past</a></li><li><ahref="S-chr.html#SP3">§3. Chronology Point</a></li><li><ahref="S-chr.html#SP4">§4. Update Chronological Records Rule</a></li><li><ahref="S-chr.html#SP5">§5. Test Single Past State</a></li><li><ahref="S-chr.html#SP6">§6. Scheme II</a></li><li><ahref="S-chr.html#SP7">§7. Past Action Routines</a></li><li><ahref="S-chr.html#SP8">§8. Track Actions</a></li><li><ahref="S-chr.html#SP9">§9. Storage</a></li></ul><hrclass="tocbar">
<pclass="inwebparagraph">It's a somewhat ambiguous matter of context in English when the reference time
is for past tenses. If somebody comes out into the sunshine and says, "But
it was raining," when does he mean? We would reasonably guess earlier that
day, and probably only an hour or two ago, but that's a contextual judgement
made on the basis of our own experience of how rapidly weather changes.
The context for Inform source text is always that of actions, so our
convention is that the reference time for past tenses is the point just
before the current action began. Such key moments — when things are just
about to happen — are called "chronology points". There is a CP just
before each action begins; there is a CP in the startup process; and there
is a CP at the end of each turn, for good measure. CPs happen when somebody
calls <codeclass="display"><spanclass="extract">ChronologyPoint()</span></code>. The action machinery does this directly, while
the startup CP and the CP at end of turn happen in the course of the
update chronological records rule (below).
</p>
<pclass="inwebparagraph"><aid="SP3"></a><b>§3. Chronology Point. </b>This is when the time of reference for past tenses is now: so it is where the
past becomes the present. Soon, exciting things will happen, and the present
will go on developing, while the past will remain as it was; until things
calm down again and we come to another chronology point.
<pclass="inwebparagraph"><aid="SP4"></a><b>§4. Update Chronological Records Rule. </b>It might seem odd that a routine to, supposedly, update something would only
call another routine called <codeclass="display"><spanclass="extract">TestSinglePastState</span></code>: but in this setting, any
test updates the state, because it changes the number of times something has
<pclass="inwebparagraph"><aid="SP5"></a><b>§5. Test Single Past State. </b><codeclass="display"><spanclass="extract">TestSinglePastState</span></code> is called with four arguments:
</p>
<ulclass="items"><li>(a) <codeclass="display"><spanclass="extract">past_flag</span></code> is true if we want to test a condition like "if the well was
dry" or "if the well had been dry", which concern only the state as it was
at the last chronology point — in other words, the <codeclass="display"><spanclass="extract">past_chronological_record</span></code>,
which we must not change; whereas <codeclass="display"><spanclass="extract">past_flag</span></code> is false if we want to test
a present tense like "if the well is dry" or "if the well has been dry",
because then we deal with the <codeclass="display"><spanclass="extract">present_chronological_record</span></code> which must be
kept continuously updated.
</li><li>(b) <codeclass="display"><spanclass="extract">pt</span></code> is the PT number for the condition.
</li><li>(c) <codeclass="display"><spanclass="extract">turn_end</span></code> is true if we are making the test at the end of a turn, as
part of the update chronological records rule, and false otherwise. (For these
purposes the start of play is a turn end since the UCRR runs then, too.)
</li><li>(d) <codeclass="display"><spanclass="extract">wanted</span></code> describes what information the function should return, as
detailed in its code below.
</li></ul>
<pclass="inwebparagraph"><aid="SP6"></a><b>§6. Scheme II. </b>Actions discussed in the past tense — "if we have taken the ball" or,
more subtly, "Instead of waiting for the third turn" (which also refers
<pclass="inwebparagraph">It might reasonably be asked why we don't simply use all of the clever
machinery above: why have an entirely different system here? One reason is
that actions are events and not continuous states of being. "The well is
dry" could be true for any extent of time, but "taking the ball" either
happens at a given moment or doesn't: it is not continuously true. We are
therefore in the business of counting events, not measuring durations.
Another reason is that the point of reference for past tenses is different.
It makes no sense to say "if we were looking" because that would mean at
a time just before the current action, when actions were probably not
happening at all; while "if we had looked" and "if we have looked"
would almost always be identical in meaning for the same reason. So we need
a much simpler system with just one possible past tense; we don't need to
keep two different states; and we use the extra storage to enable us to
count the number of times, and the number of turns, to at least 31767
instead of stopping at 127. (We also generate more legible code to test
past tense actions.)
</p>
<pclass="inwebparagraph"><aid="SP7"></a><b>§7. Past Action Routines. </b>Actions can be quite complicated to test even in the present, and this is
frame; so each past tense action has its own testing routine, with a name
like <codeclass="display"><spanclass="extract">PAPR_41</span></code>, which returns true or false depending on whether the action
is going on now. The word array <codeclass="display"><spanclass="extract">PastActionsI6Routines</span></code> then contains a
null-terminated list of these routines.
</p>
<pclass="inwebparagraph"><aid="SP8"></a><b>§8. Track Actions. </b>The routine <codeclass="display"><spanclass="extract">TrackActions</span></code> then updates the two arrays, and is the
equivalent for past tense actions of <codeclass="display"><spanclass="extract">ChronologyPoint</span></code>. It's called
twice for each in-world action: <codeclass="display"><spanclass="extract">TrackActions(false)</span></code> just as a new
action is about to begin, and then <codeclass="display"><spanclass="extract">TrackActions(true)</span></code> just after it
has finished — note in particular that if action B happens in the
middle of action A, for instance because of a try phrase, then the
<codeclass="display"><spanclass="extract">TrackActions(true)</span></code> call for B happens when A is back as the current
action. In fact, that's the point: because it tells us that B was not
the main action for the turn, but only a phase which has now passed
again.
</p>
<pclass="inwebparagraph">For each of the action patterns we track, we need to count the number of
succeeded), and also the number of consecutive turns on which it has been
"the" action. The count of the number of tries is unambiguous and easy to
keep: it is incremented at the start-of-action call only, and only if the
action matches. But the consecutive turn count is more problematic. The
user wants to think of actions and turns as synonymous, and to write
conditions like "Before going for the third turn", and we want to play
along because that's a natural phrasing: but actions and turns are not
synonymous at all. The rules are therefore:
</p>
<pclass="inwebparagraph"></p>
<ulclass="items"><li>(1) At the start-of-action call, provided the action is not a silent one,
the consecutive turns count is either incremented or zeroed, depending on
whether the action matches. Silent actions are ignored because they are
almost always knock-on actions tried in the course of other actions, and
are certainly not the "main" action of the turn. But the count can be
incremented only once in the course of each turn, so that "Instead of
taking something for the third turn: ..." cannot happen on the very first
turn because TAKE ALL causes three or more take actions.
</li><li>(2) At the readjustment call, provided the action is not a silent one,
the consecutive turns count is zeroed if the action does not match.
</li></ul>
<pclass="inwebparagraph">Why do we zero the count in rule (2)? Well, suppose that the player types
OPEN BOX, so that the opening action takes place, and that it causes a
further (non-silent) action, say examining the lid: and suppose that the
action pattern we track the turn count for is "examining something".
Then the following calls take place:
</p>
<pclass="inwebparagraph"></p>
<ulclass="items"><li>(a) <codeclass="display"><spanclass="extract">TrackActions(false)</span></code> while the action is "opening the box".
Turn count zeroed by rule (1).
</li><li>(b) <codeclass="display"><spanclass="extract">TrackActions(false)</span></code> while the action is "examining the lid".
Turn count incremented by rule (1).
</li><li>(c) <codeclass="display"><spanclass="extract">TrackActions(true)</span></code> while the action is "opening the box".
Turn count zeroed by rule (2).
</li><li>(d) <codeclass="display"><spanclass="extract">TrackActions(true)</span></code> while the action is "opening the box".
Turn count zeroed by rule (2).
</li></ul>
<pclass="inwebparagraph">Thus rule (2) prevents us from counting this turn as the first of a sequence
of turns in which examining something was the action, because it wasn't the
main action of the turn.
</p>
<pclass="inwebparagraph">A further complication is that we need to record the qualification, or not,
even of silent actions, because testing rules like
</p>
<blockquote>
<p>Instead of taking the top hat less than three times...</p>
</blockquote>
<pclass="inwebparagraph">works by checking that (a) we are currently taking the top hat, and (b) have
done so fewer than three times before. (b) uses the turn count described
above; but (a) cannot simply look to see if that count is positive, since
the action might be happening silently and thus not have contributed to the
count; so we also record a flag to hold whether the action seems to be
happening in this turn, silent or not.
</p>
<pclass="inwebparagraph">And a still further complication is that out-of-world actions should never
affect counts of turns for in-world actions. Thus,
</p>
<blockquote>
<p>Every turn jumping for three turns: say "A demon appears!"</p>
</blockquote>
<pclass="inwebparagraph">must not have the count to three broken by the player typing SAVE, which
causes an out-of-world action but doesn't use a turn. The simplest way to
deal with that would be to make <codeclass="display"><spanclass="extract">TrackActions</span></code> do nothing when <codeclass="display"><spanclass="extract">oow</span></code>
is set, but then we would get rules like this wrong:
</p>
<blockquote>
<p>Check requesting the pronoun meanings for the first time: ...</p>
<ulclass="toc"><li><ahref="S-tst.html">Back to 'Tests Template'</a></li><li><ahref="S-str.html">Continue with 'StoredAction Template'</a></li></ul><hrclass="tocbar">