ScottKit producing misplaced/out-of-order strings

I’ve filed to @MikeTaylor at the ScottKit issue tracker but am hoping the broader Scott Adams base might have some ideas.

I’m running into situations with my ScottKit-based game in development where, under limited but repeatable circumstances, print strings are appearing out-of-sequence and with a substituted string, typically one from much higher up in the source file. I can’t find documentation that says there’s a hard-and-fast limit on print-able strings in a SA-format game, and the first time I ran into it (and coded around it), a maneuver to save strings was causing the problem. It’s now showed up in a different spot where I’m not trying anything particularly tricksy, so I’m at a loss to explain or fix it.

Any ideas? A fuller summary is on the Github tracker but the basic behavior is that

action read book when carried book and !exists script
	print "Words words words"
	print "Paper you used as a bookmark FALLS out!"
	put_with script book

actually produces

Tell me what to do ? read book
Paper you used as a bookmark FALLS out! #this is in the wrong order
You are PRINCE HAMLET # this is an early string

and

action read script when carried script
	print "Play script: The MURDER of GONZAGO!"
	print "about fratricide & other TERRIBLE acts"
	print "CLAUDIUS is also guilty of!"

produces

Tell me what to do ? read script
about fratricide & other TERRIBLE acts
What are you going to DO about it? # this is another early line
CLAUDIUS is also guilty of!
Tell me what to do ? 

Behavior is identical in scottfree and in the scottkit built-in interpreter.

…ooh, wait a sec, is there a limit of 99 printable messages in the SA format?

From the definitions text:

1-51	Print message 1-51. Some drivers add a space some add a newline.
        It does not seem to be possible to print message 0

102+ Print message 52-99

I was thinking “well, this problem showed up before I had 127 strings, so it’s probably not a 7-bit limit!” but…

There is indeed. In my experience it’s the harshest and most relevant limitation of the format.

It’s a shame, too, because there are also some blocks of unused opcodes which could have been dedicated to more messages.

1 Like

It’s kinda casually mentioned in the Scottfree spec, but if I may be so bold as to recommend to @pdxiv @MikeTaylor and anybody else with Adamsland dev tools: that’s a really really useful warning to throw your users as they build projects. (When I hadn’t quite convinced myself of the truth of the limitation I fired up Adventshark and rapid-click asked it to create >99 messages. It was happy to do so.)

Also, re:

That doesn’t seem right—doesn’t message 0 not exist? (Or, alternately, it’s always the empty string, which can be printed by opcode 0 (NOP)?) But I haven’t worked with this format for a long while so I might be misremembering.

Sorry I was slow to get to this! Yes, it seems the analysis here is correct. I will follow up on the GitHub issue, and at least make sure, as you suggest, that the compiler rejects files that have too many messages. (And I agree this is a particularly wretched limitation.)

1 Like

It is an objectively ridiculous limitation which obviously gets in the way of what the tastemakers of the past quarter-century would consider “serious IF.”

As a crutch to shrug off any complaints about limitations or lack of detail, however, it’s fantastic. :slight_smile:

It also encourages some fun workarounds using displayable text that isn’t subject to the 99 message limit, like item descriptions. I initially had an occur 40% message in the Royal Bedroom something about “a couch for luxury & damned incest”, but I realized that replacing it with an object named “couch for luxury & damned incest” was basically just as good from an atmosphere standpoint, and freed up one of those precious messages.

1 Like

I haven’t read the whole conversation very closely, but it isn’t quite true that there’s a 99 message limitation. The .dat file format limits the number of messages to 99, on half of the commands in an action/occurence. For the other half, it goes up to ~400 possible messages.

As for whether or not interpreters are able to pick up this subtle detail, is anybody’s guess.

I’m having trouble parsing what you mean by those halves, can you rephrase?

Are there any SA games in the wild which successfully run at >99 messages on any interpreter? The OG Adams and Howarth games all seem to adhere to that limit.

ScottFree and ScottKit both disliked my >99 message build of this game. Maybe that’s because of this “half” thing you’re talking about that I don’t know what it is, but I don’t know what one would do about that, either.

So, each action/occurrence in ScottKit consists of up to 4 possible “commands”, which may be “print” or “inventory” or something else. If your print command is command #1 or #3, it should allow you to use many more messages.

If you can find a copy of the SA game “r” by therealeasterbunny, I believe that it utilizes this “trick” to squeeze ~170 messages into the adventure.

The reason for this, is that in the .dat file format, the 4 commands are encoded as 2 numbers, like this: (150*command 1 + command 2), (150*command 3 + command 4) . This effectively means that command #2 and command #4 are limited to 150, 100 of which are available for use for printing messages. Not a very good explanation, perhaps.

My opinion on the matter, is that ScottKit probably should allow more messages when using commands 1 or 3, and scream bloody murder if you try to use too many messages with commands 2 or 4 :slight_smile:

2 Likes
print "WHOA IF TRUE"

Very interesting. I’m probably content for S.A.L.A.D. #1 GHOST KING to stick with the 99 limit unless I am somehow persuaded to beef up the storyline with additional quest/puzzle elements.

Makes me wonder why, if it was that simple, guys like Howarth (who seemed, um, maybe a little more willing to write narrative than Adams) adhered to the 99 limit instead of just building their actions using the #1/#3 rule as you suggest.

The historical basis for why this wasn’t “exploited” more in the early eighties, possibly had to do with the limited memory of the 8 bit machines that they were often targeting. RAM would run out before storage space in the game data files did.

Also worth noting that this limitation also applies to verbs and nouns. you can have much fewer nouns than verbs (i think).

So I did some experiments with ScottFree and ScottKit, and came to the conclusion that ScottKit handles more than 500 “odd” messages. ScottFree doesn’t handle that much, but it seems to go up to 386 “odd” messages without weirdness appearing.

Interesting, can you share the .sao/.dat?

SCK: https://pastebin.com/y83hdfCK
SAO/DAT: https://pastebin.com/740ms5M7

1 Like

Very cool. Would be great to find out what the original TRS-80 interpreter does with this, but I haven’t found a handy tool to do that kind of surgery.

That’s a bit of digital archeology :slight_smile:
If we go back to the seventies, the first iterations of the engine were written in TRS-80 Level II Basic. The max capacity would match whatever was possible with the Basic datatypes. Integers were signed 16 bit (-32768 to 32767), so if an integer data type was used, at maximum there would be something like 218 messages. If floating point data type was used… ¯\_(ツ)_/¯

If your game becomes two large for the Scott Adams Format, I suggest you migrate to either Adventuron or DAAD. Adventuron itself can be exported to DAAD, but I suggest using DAAD directly since you can write your game without requiring internet access.

Oh, I’m totally committed to embracing the limitations of the SA format because the entire premise is “what if Scott Adams had written a Hamlet game 40 years ago?” but yes, those are sensible steps for a graduate if that were the goal. :slight_smile:

1 Like

Best of luck to you then. I’ll be one of the first to play the game when it comes out.

1 Like