Scott Adams interpreter discrepancies

Somewhere around game 7 or 8 in the fairly widely circulated collection of classic Scott Adams games, you start to see code like the following when you decompile the .dat file:

action LOOK PILE when here Pile and !moved battery
	put battery Booth
	print "O.K."
	print "I see"
	print something

That example is from a ScottKit decompilation of adv14b.dat, Buckaroo Banzai. Those text strings are displayed one string per line by ScottKit, ScottFree, PerlScott and ADVENTUR/CMD: i.e. each individual print statement prints its string and then breaks the line, so you get something like this:

O.K.
I see
something

Here’s ADVENTUR/CMD:

I haven’t checked the disk-images of any of the original releases of Buckaroo, but I can’t really believe that that’s how the programmers intended the messages to appear on screen. I presume they intended all three messages to appear on a single line – or at least the last two – like this?:

I see something

It’s intended. It’s a way to stretch the strict message limit.

Remember, although yes it has been discovered that there are ways to perform profane incantations to get beyond 99 messages, none of the official SA or offshoot commercial games did that. Breaking up and reusing strings like this was a way to repurpose some of those 99.

The question is: who wanted it? The authors of the game or those who converted the game to “ScottFree” format.
Buckaroo Banzai has been converted to ScottFree format from the ZX Spectrum version, and this one does not split these sentences.

A typical example that saves a bit of storage space:

	>LOOK BATT
	? AVL OBJ_19 && -BIT 31
	"I see"
	"there's no"
	"water in the battery."

	>LOOK BATT
	? AVL OBJ_19 && BIT 31
	"I see"
	"water in the battery."

I tried, without success, to replace CR (0D) by LF (0A) between two chains of carateres in the hope that this would concatenate them.
(In the database, LF is used in a string for linefeed, and CR for data separation.)

There may be an additional instruction to display messages by concatenating them.

Yes, here’s a screenshot of the Spectrum version from archive.org:

1 Like

I have a hard time blaming this on the terps. Every PRINT-statement are unique entries in the DAT-file. How would the terp know when to print a LF and not to print it?

Is it possible that the different versions use different DAT-files (the widely circulated ones have been modified or are from another source)?

Could it be for effect? On slower HW I could see it be like a small pause between the different PRINT-statements.

EDIT: I can’t test it now but later this evening I could have a look how it is done in C64 (I think I have old original games, somewhere).

I’d hope that no one was “blaming” anyone or anything! I’m just making observations.

I don’t know for sure but I suspect that some or all of the terps that were created for games 9 and later (and possibly also for games 7 and 8 — I can’t remember) were modified to treat consecutive print commands differently than the earlier terps.

The later games seem to concatenate the output of consecutive prints onto a single line, whereas the earlier games seem to print one string per line.

I don’t mean blaming as in finding someone guilty! maybe I should have put it inside quotes, like “blaming”.

Your observation seems correct in so far as “The Count” (adv #5). This is from the ScottKit decompile:

action GO OVE when present Oven and counter_gt 0
	print "Sorry I can't do that"
	print "There's A tremendous Amount of HEAT & SUNLIGHT coming out."

And this is from the one C64-version:


(LF between “…can’t do that” and “There’s A tremendous…”)

1 Like

What is that? Is it the output from a later version of ADVEDIT? Where can I download it from?

This is Adventure 13.

PerlScott:
image

C64:

This is definitely “something”. I don’t know how to identify this. In scott2zil there’s no problem, it is just a new option when you compile the file. Other terps could maybe use a switch?

1 Like

I use my own decompiler that I used to do game solutions in SAGA format for CASA.

1 Like

Interesting! Could this be an Adventure Soft-specific terp feature, present in the platforms they dealt with?

As a slightly off-topic question, I’m nearly done with the ScottKit compiler I’m working on. Should I add an option to merge messages to emulate the “multiple messages on one line” behavior?

I think your compiler should behave in more or less the same way as ScottKit, but with some changes to reflect the discussion in this thread (e.g. the way light timers are handled), if you think that would be a good idea.

But your interpreter should probably have an option (a commandline flag?) to emulate “Buckaroo mode”, where multiple consecutive print commands within a matched action should concatenate their strings onto a single line. (Additionally you might want to be sneaky and somehow autodetect those classic games that need the string-concatenation behaviour and switch it on automatically for those games…?!)

Just my opinion. Feel free to ignore it!

2 Likes

Just for the record, I thought I’d mention that there’s another discrepancy in the way the terps behave: this time PerlScott and ADVENTUR/CMD seem to be correct, and ScottKit seems to be wrong. I’ve written up the apparent bug at the ScottKit Github repo:

https://github.com/MikeTaylor/scottkit/issues/42

What about ScottFree?

It’s very tempting to simply render the text and room description when the control is returned to the player in a terp, to minimize the number of calls. I was actually planning to do it this way for the web version of PerlScott/tensodoct. Good thing this was brought up.

There’s a related “strange” scenario in The Count (if i remember correctly). During “sleep”, the player is moved to an invalid room number for a short amount of time. I assume this is used to empty the room description “window” for dramatic effect, but if the terp doesn’t take this into consideration, it might end up not happening, or giving an error message.

1 Like

ScottFree behaves in the same way as PerlScott and ADVENTUR/CMD: it displays the hintroom description briefly before swapping back to the bedroom. The .DAT file is attached (the checksum is incorrect, strictly speaking, but fine as far as ScottFree is concerned).

testarr.dat.zip (450 Bytes)

1 Like

Yet another discrepancy in the behaviours of various Scott Adams interpreters.

There’s a problem in the way that some terps handle a player-command that contains a noun that hasn’t been explicitly declared in the game data.

This time, only ScottFree exhibits the desired “correct” behaviour, while PerlScott, ScottKit, and the versions of ADVENTUR/CMD and ADV/CMD that I referred to earlier in this thread all behave “incorrectly” when they play the following example (also attached), which is an adapted extract from a ScottKit-decompilation of the TRS-80-format datafile (adv05.dat) of The Count:

start workroom 

room workroom "workroom"

item file "Large tempered nail file"
	called FIL
	
item bolt "Lockable slide bolt"

item lock "Broken slide lock"
	nowhere

verbgroup CUT BRE FIL TRI
noungroup FIL NAI

action CUT:
	print "Tell me with what? Like: `WITH FIST`"

action WIT FIL when present file and here bolt
	swap bolt lock
	look2
	print OK

action WIT FIL when !present file
	print "Sorry I can't do that"
	print "I've a hunch I've been robbed!"
	comment "NO FILE"

ScottFree allows the player to enter the command BREAK BOLT, even though no such noun as BOLT (or BOL) has been declared. That behaviour accords with the solution to The Count that can be found at CASA, and with this walkthrough video of a TRS-80 version of the game [see update below], both of which specify the command BREAK BOLT.

ScottFree matches the command BREAK BOLT with the “action CUT” handler. (In this example, BRE(AK) is a synonym for CUT.) In fact, ScottFree will activate that handler whenever the player’s command consists of the verb BREAK followed by any word at all (even a gibberish one!).

But in the ScottKit terp, and in PerlScott, and in my found versions of ADVENTUR/CMD and ADV/CMD, the only way to break the bolt is to type the word BREAK on its own – i.e. you have to type the verb without a noun (which isn’t exactly intuitive!):

nounlessness test.dat.zip (478 Bytes)

1 Like

That’s a good find! So, in other words (if I understand this correctly), using the “ANY” noun fails, because all terps except ScottFree attempt to locate the noun in the vocabulary before actually executing actions using an “ANY” noun.

From your investigation, it sounds like this behavior is “canonical”, but I prefer the ScottFree behavior here too. I can’t think of any disadvantages to the ScottFree behavior, so I’ll look at altering the behavior in PerlScott (and related things) accordingly.

1 Like

To be honest, I’ve never been 100% sure what the “ANY” noun is or how it works!

Yes. But note that ScottFree isn’t quite an outlier: the apparently official TRS-80 version of The Count in that Youtube video I linked to in my previous post seems to behave in the same way as ScottFree in this case. (And I believe that at least one other official release of the game does too (the BBC Micro release).)

EDIT, December 2021: I’ve found a TRS-80 version of the game The Count which allows you to say BREAK BOLT, like ScottFree. It can be found online in “quickload” format (whatever that is!), as a file named sa05115b.cmd:

Here’s the intro screen, identifying the game version (1.15) and the interpreter version (8.2) – but exactly which interpreter (ADV/CMD…? ADVENTUR/CMD…?) I don’t know!:

EDIT2, December 2021: I’ve just confirmed that BREAK BOLT also works in v.1.16 of The Count running in v8.5 of ADVENTUR/CMD (the “official” TRS-80 Scott Adams terp):



1 Like