Thanks, I’m still not 100% sure that I understand this so I’ll need to ponder on this a bit before I decide if this is something that I should correct in PerlScott/tensodoct, or possibly add as an optional feature. 
I wonder if this behavior is game breaking, with any of the existing titles out there.
So the plain-language explanation is “the player should only be allowed to take the bat when they are already carrying the hat?”
If that is the case, I don’t agree that your example represents a problem that needs interpreter-side fixing. It needs “don’t write the code that way. Block the take.”
This is the output from ScottFree:
As far as I can see it is consistent with ScottKit and PerlScott. I think changing the behaviour from ScottFree could potentially be gamebreaking for some existing games out there. I’m asuming ScottFree currently is the most widely used terp for SA games.
Yes. Unfortunately, the behaviour of ScottFree, ScottKit, and PerlScott might encourage authors to write code similar to my fox/box example, which won’t work as intended in the “official” ADVENTUR/CMD interpreter (nor in other terps, possibly).
So ScottFree, ScottKit and PerlScott seem to diverge from the behaviour of ADVENTUR/CMD on what is quite an important piece of core functionality. Which seems a shame.
I disagree and I think a big part of the disconnect here is coming from the way the Scott Adams system developed.
As we’ve seen and discussed, the format was a moving target and the games were initially coded in BASIC with enough “driver” or “interpreter” code to get done whatever the next game needed to get done. (And, noble as it was, Pirate Adventure’s code release was both buggy and behind the curve.)
Later, third parties like Howarth and Hansen expanded and extended on the format.
Later still, tools like ScottFree came along with the intention (which has largely succeeded) of supporting the union of all of the things those games were trying to do. And despite being coded in C, ScottFree is demonstrably lightweight enough that there have been at least two successful 8-bit ports of it (C64, TRS-80).
Unless ScottFree is doing something achingly awful, it should be considered the gold standard in interpreter behavior, not the just-enough-to-get-the-job-done behavior of a Scott Adams binary that was only ever meant to support the Adams-authored games.
I’m with @jcompton on that ScottFree is the “gold standard” for SA terps. On the other side am I open to implement a switch/option i scott2zil that could compile “ADVENTUR/CMD compliant” for users that would like that (as suggested by @pdxiv).
I strongly disagree with that. Obviously, the developer of ScottFree did not have some of the information that is available today.
I don’t understand the logic of Scott Adams’ interpretation in this case:
>Get Fox
Can't get fox when !carried box
>Get Box
OK
>Get Fox
I can't do that...yet!
He should take the object instead of displaying “I can’t do that…yet!”
Do you think this is a bug in the interpreter?
…name two?
In this case, it is up to you to display “OK”.
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.
Definition file:
A game consists of a header of 14 values each apparently 16 bit
Header:
0 Unknown
12 Unknown
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.
Etc.
You have the possibility with Adams’ interpreter to get the Time value, but not with ScottFree.
EXm,CT num:
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
destroy2 bites1
get mud
print OK
print "BOY that really hit the spot!"
action GET MUD when here mud and carried bites
destroy2 bites
get mud
print OK
print "BOY that really hit the spot!"
action GET MUD when here mud
get mud
print OK
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.
Is consistent with:
Or am I thinking wrong on this?
It was just to confirm, through documentation, what you were saying.
I see, thanks.
(In the first quote you seems to suggest that the terp should allow the user to ‘get fox’ the second time, but I understand it as it follows the rules set out in your second quote.)
That’s a valuable find. I can’t find this in the Adventure Editor manual that i converted to MarkDown (LuaScott/doc/Adventure_Editor_Manual_(1981).md at master · pdxiv/LuaScott · GitHub). Is there a different version of this document, or is this a completely different document (or did I just mess up my conversion somehow)?
You have this in your document:
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.
which says, as I read it, about the same thing.
There is also this quote:
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.