Reading the Definition file gives some clues on this subject, but also reading the manual of The Adventure System. Reading the README file of the asfdcurs interpreter adds some more.
A game consists of a header of 14 values each apparently 16 bit
A game has 16 (maybe more) binary flags, and 8 (maybe more counters). A few
later games seem to have 2 (maybe more) values to store location numbers in
temporarily - eg Yoho spell in Claymorgue.
You have the possibility with Adams’ interpreter to get the Time value, but not with ScottFree.
Exchanges the content of counter with that of alternate counter num (0-7 [8 contains TIME]).
Robert Schneck mentions in his README file of asfdcurs a possible bug of ScottFree with Get.
And other things. Make some tests and you will find some…
Okay, cool. (ISTR that one of those Unknowns is the checksum, which modern interpreters don’t care about, but it is a Thing.)
Actual functionality gaps are more interesting and good to know about, illustrate places where Cox and co. didn’t 100% support the union of SA game features, and certainly worth fixing with the very available source code.
The difference between the two families of terps is that the
“modern” ones loops through all the “actions” and if there is a match with the VERB and NOUN it evaluates the conditions (all after the “when”-part. If all things match then the action is executed and the parser returns and waits for user input. If there is no exact match then the AUTOGET/DROP routine is called before returning to the prompt.
The ADVENTUR/CMD on the other hand only match the VERB and NOUN. If they match AUTOGET/DROP is not called. The instructions, of course, are only executed if the conditions also match.
This will produce this behaviour for the printed code.
Is it a bug and in wich version? I don’t know? The old terp acts strange when you try to “get fox” when you have the box and the new terp acts strange when you are allowed to “get bat” without the hat.
I would recommend not to trust the AUTOGET/DROP when you are overriding it and to write all actions you want to handle and let undefined actions default to “I can’t do that…yet!”. I also think this is the way Scott Adams wrote his games.
Example from Adventureland:
action GET MUD when here mud and carried bites1
print "BOY that really hit the spot!"
action GET MUD when here mud and carried bites
print "BOY that really hit the spot!"
action GET MUD when here mud
It’s in the documentation of The Adventure System and it’s quite obvious:
If a verb-noun match was found in at least one action entry, but the conditions were not true in any of the matched actions, then the message “I can’t do that…yet” is displayed after all of the action entries have been checked.
This is the first player input action. If the player types in LIGHT MATCH then this action is considered. If even one of the conditions of this action are not met, then ADVENTURE continues searching the actions for another LIGHT MATCH. If it finds another, it considers that one also, and so on until it finds a true one. If no other LIGHT MATCH is found then the message “I can’t do that . . . yet!” is printed and the player is asked to respond again.
When player input actions are being evaluated, the action entries are scanned in numeric order. When the verb and noun of an action entry match the player’s input, the conditions are evaluated. If all of the conditions were true, then the commands of this entry are performed. When a “true” match is made, no further player input actions are evaluated on this pass. However, if a match is made and all of the conditions were not true, then the scanning procedure continues until either a “true” match is made or all of the actions are evaluated. If a match was found but the conditions were not true, then the message “I can’t do that . . . yet!” is displayed. If no match was found, then the message “I must be stupid but I don’t understand what you mean” is display.
A new constant that determines how AutoGet/Drop should be handled
;"Sets if AutoGet/Drop should be handled as defined in 'The Adventure System' manual or handled as in ScottFree
THE ADVENTURE SYSTEM
If a verb-noun match was found in at least one action entry, but the conditions were not true in any of the
matched actions, then the message 'I can’t do that…yet' is displayed after all of the action entries have
AutoGet/Drop is only called if there is no verb-noun match found.
Does the same as above but tries to do an AutoGet/Drop before the message 'I can’t do that…yet'."
<CONSTANT AUTOGET-AS-SCOTTFREE <>>
The relevant part in the code that handles this is then in the routine RUN-ACTIONS and reads like this:
This means that the default behaviour for games built with scott2zil is to handle AutoGet/Drop as defined in “The Adventure System” manual. But this behaviour can be changed by setting the constant AUTOGET-AS-SCOTTFREE to true before compiling.
The code in scott2zil is based on PerlScott and follows it pretty closely so if @pdxiv want to do something similiar in PerlScott you probably can find the corresponding code part to change easily.
Another mystery, that I stumbled over again while trying to make a ScottKit compiler, is if an “autogetable” object needs to have an entry present in the noun table. In The ADVENTURE Data Base Format Allan Moluf mentions that:
The name does not have to be a noun in the vocabulary for this pick up or drop to work.
ScottFree doesn’t agree with this, and the following game file refuses to let me pick up an object, because it’s name isn’t present as a noun in the vocabulary table:
ScottKit automatically adds the noun for every “autogetable” object to the noun table. Since ScottKit’s interpreter is based on ScottFree which requires this, it makes sense. Every game out there works fine in ScottFree, which implies that this behavior is “as designed”. At the same time, the number of nouns is a limited resource, and it would be nice to be able to save space in this table.