THE-FIX

(c) G T Kellett/Kelsoft 1986		FIX 1.6.DOC

THE-FIX like the Patch, is an extension utility for use with The Quill (C series), which adds five extra actions to The Quill system. Unlike the Patch however it operates while the editor is in place and can be installed before or during the creation of an adventure and so can be tested out and modified in just the same way as one that is not. What is more a 'FIXed' adventure remains fully compatible with both the Patch and the Illustrator as well. You cannot though have the use of UDGs as the main block of CODE for THE-FIX occupies that area of memory.

THE-FIX exploits a 'quirk' of the Editor's syntax checker, in that it does not require terminating actions to be the last item of an entry, so by prefixing five particular Quill actions by the normally termination action OK, THE-FIX actions are invoked. THE-FIX actions, giving THE-FIX operational pseudonyms with the actual Quill actions in brackets -T indicates terminating actions, are as follows:

PARSE ( OK INVEN ) T; This interprets or parses in addition to the two usual words, a further two words at a time (if there are any) from a single line of input, and processes them in just the same way as standard input. Repeated use of PARSE will allow more complex sentences to be interpreted. If PARSE can find no KNOWN words (i.e. any remaining words of a line are not in the vocabulary) then the usual 'I didn't understand that....' message results, but since the first two words may have been understood it is recommended that it is amended to take account of this. N.B/ PARSE invocation is suspended during WAIT periods as this would otherwise cause premature termination of a WAIT period.

WAIT n ( OK PARSE n ) T; Where n is the number of extra cycles through TURN flags update & the STATUS table (one pass is made through these in normal operation). The case where n is zero is a special case, if used as an EVENT table action, the action DONE is effectively performed except that the STATUS table is bypassed, this can be used to accept input without the possibility of something occurring in between due to STATUS table actions (although the answer will count as one turn). If used as a STATUS table action, it will terminate the current WAIT period with DONE.

ADD flag# flag# ( OK PLUS flag# value ) & SUB flag# flag# ( OK MINUS flag# value) ; These respectively add to & subtract from the contents of the first specified flag the contents of the second specified flag, due to the method of their operation, not only can the second specified flag be a 'normal' flag, but it can also specific; the location of an object (add 37 to the object# to give the 'flag#'), the players location ('flag#'35), and the last two word-values ('flag#s 33 & 34), the last three flags mentioned won't be of as much use as the first set of 'flag#'s, as the information they derive is given by normal Quill operations. But the former can be used to see if an object is; ATLT, AT or ATLT a location specified by the value in the first flag.

PERFORM word word ( OK BEEP wv1 wv2 ) T; N.B. use as a STATUS table action will cause OK to be performed instead. This action processes the two words as if they had been input by the player. Primarily intended to implement 'forced synonyms' or 'EVENT equivalents', where an action can be expressed by the player in two or more ways, but where it is inconvenient or impossible to make each corresponding word of a word label pair, synonyms within the vocabulary, and would otherwise require multiple entries in the EVENT table under each word pair. It can also be used to implement; loops (with an entry that 'calls' itself & is regulated by a flag used as a loop counter), shared routines (where several entries exit via a commonly used entry), ORed & XORed logic (by several 'condition' entries 'calling' a single 'action entry). NOTE: Use of words with no corresponding entry in the vocabulary will give the 'I/You can't; response. Using valid 'direction words' may invoke Movement table actions instead of EVENT table ones (you may in fact wish this to happen, but be warned).

Using THE-FIX

THE-FIX package consists of five programs, each is loaded with LOAD "" & ENTER, and instructs you as to the method of its operation.
1) PRE-FIX is used to operate The Quill when initialising a new adventure for use with THE-FIX
2) IN-FIX, use this to operate The Quill when loading up an adventure you have already 'FIXed' with PRE-FIX for subsequent sessions. It is also used to 'FIX' and adventure you have already started. To do this load up your database and then use Quill menu option K to load up FIXCODE which you will find following IN-FIX on THE-FIX tape.
3) POST-FIX, this re-instates THE-FIX system into the Illustrators adventure interpreter, It is only necessary to use POST-FIX to operate the Illustrator for sessions in which you intend to save an adventure from, it is not required if you are only working on the graphics.
4) SUF-FIX, is used to operate the Patch with 'FIXed' adventures, because of the changes to the Patch's interpreter it is necessary to load a new version of FIXCODE block, SUF-FIX will request to load SUF-FIXCODE (a copy of which you will find following SUF-FIX).
5) PIC-FIX, this section is optional, it allows you to have full screen pictures in Patched adventures that are Illustrated, in the same manner as for unPatched ones (ie the picture stays on screen until a key is pressed). It also allows you to alter the number of words that the interpreter considers as 'direction words'. These features are available regardless of whether the adventure to be Patched has been 'FIXed' or not. In either case, at the point where the part LAST BIT would be loaded, load PIC-FIX instead, implement either or both features, then proceed as normal. It is also possible to use only the 'alter number of direction words' feature of PIC-FIX with Quilled only, or Quilled & Illustrated adventures. To do this manually load up only the CODE part of the adventure (not forgetting to set RAM_TOP appropriately first), load PIC-FIX (but on no account select the PIC option), alter the number of 'direction words' and when PIC-FIX asks to load LAST BIT, press BREAK instead and manually re-save the CODE (it is not altered from its original length).

OPERATIONAL NOTES

Implementation of THE-FIX makes the operation of the interpreter more complex than it previously was, and may now lead to situations in which a 'latch up' is possible. You are therefore strongly advised to save the database before you select to test any 'FIXed' adventure.
	So far I have found three such situations;
1) unregulated PERFORM or incorrectly regulated PERFORM loops (i.e. infinite loops).
2) 'back referencing' loops where a 'forced synonym' calls an entry that has just called it (i.e. each of the entries regards the other as a cross reference, each calling the other ad infinitum)
3) Invoking a WAIT period while on is already in progress, such that WAIT periods are constantly re-started & never terminated (the exception to this is using WAIT 0 in the STATUS table to prematurely terminate a WAIT period).

Although it is up to the individual user as to exactly how PARSE is to be used. Incautious use may cause hiccups, so here is a suggested method of use. Taking the sentence: KILL (THE) DRAG(ON) WITH 'a weapon'; as an example, then using say flag 26 as a 'special features' flag, the sentence may be dealt with as follows;
	KILL DRAG(ON) LET 26 1 OK INVEN ; this signals a specific special feature, and then looks for the weapon that must be specified
	WITH DAGG(ER) EQ 26 1 ...; these deal with each specific weapon with which we may KILL (THE) DRAG(ON).
	WITH SWOR(D) EQ 26 1 ....'
	WITH etc
	WITH _   EQ 26 1 ...; this deals with any weapon for which a particular response is not required or for any unrecognised weapons.
It is also possible that the player may neglect to specify a weapon, in which case PARSE will fail to find any words & will perform DONE, it is therefore not possible to 'trap' this situation with any of the above or an entry of the form
	EQ 26 1 MESSAGE n DONE
However if you include in all the WITH entries the item CLEAR 26, to signal that the special feature has been successfully deal with, then by placing something like this following into the STATUS table, this situation can be catered for.
	KILL DRAG(ON) EQ 26 1 MESSSAGE n CLEAR 26 DONE
where MESSAGE n says something like 'Specify WITH what you wish to do that', the player then needs to re-enter the sentence, this time specifying a weapon. Alternatively, omitting the item CLEAR 26 from the above, the player need only enter WITH weapon, but will not be allowed to proceed until he does so or flag 26 is reset.
A similar method can be used to deal with longer and more complex sentences, using a flag to indicate the special feature, and even at what stage the interpretation is (ie as each tow words are PARSEd the flag can be updated to show this).

Use of WAIT is quite straight-forward if it is used only as an EVENT table action, the complications start when it is used in the STATUS table, since it is then possible to invoke a WAIT period while one is already in progress. To prevent this from happening it is necessary to indicate that a WAIT period is in progress and then test for this in each entry that invokes a WAIT period. The most useful way to do this is to set a flag equal to the length of the WAIT period (preferably one of the auto decremented ones), it is then possible to set up things to occur at a given point during a WAIT period, and to test when one is in progress by using the condition NOTZERO flag#.

As well as their obvious sues ADD & SUB, as has already been stated, can implement less obvious ones. ADD can be used to copy any byte of the data-buffer to a given flag (you can for instance store the last location visited before making a move with say; CLEAR 20 OK PLUS 20 35 ). It was mentioned above that SUB can be used to make tests on the whereabouts of objects, to do this LET flag to a value one more than the location about which you are testing then SUB flag# object#+37, you can make the following tests ZERO flag# = object ATFT specified location; EQ flag# 1 = object AT specified location; GT flag# 1 = object ATLT specified location.

In a standard Quill to implement ORed & XORed logic it is necessary to have two or more entries (you can OR any number of items but only XOR two), to test for the alternative (or in the case of XOR mutually exclusive) possibilities, each of which had to contain the full complement of actions to be enacted. With THE-FIX you still need to have an entry for each possibility, but these need only contain the test for each and the actions to 'call' a shared 'action routine'.

Although using PERFORM 'calls' can save memory, if you aren't careful it can also waste it. Because there is an overhead of 6 bytes for each entry in the EVENT table, unless the entry that is called is fairly long or is shared by many 'callers' there will be no advantage in using PERFORM. AS an approximate guide if the value of the following equation is 1 or more, then it is worthwhile.
	Bytes save =~ n*(Lc-4) -6
where n is the number of 'callers' & Lc the length of the called routine. (calculated as 1 byte for each condition/action +1 byte for each number that follow a condition or action).

This issue of THE-FIX comes with an adventure database for an adventure giving a demonstration of the features of THE-FIX, in it are reproduced some of the above examples together with many other examples of how to make use of THE-FIX actions. LOAD it up & play through it to see the new actions at work, then take a good look at both the EVENT & STATUS tables to see how each effect has been achieved, paying particular attention how the flags are used to regulate the use of the new actions.

PLEASE GIVE A CREDIT TO THE-FIX IN ANY ADVENTURE IN WHICH YOU USE IT

(Retyped by 8bitAG.com... Note: the grammar and punctuation of the original has been preserved)