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. 
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.
2 Likes
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
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?
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.
1 Like
That’s a bit of digital archeology
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.
2 Likes
Best of luck to you then. I’ll be one of the first to play the game when it comes out.
1 Like
Something’s been bugging me about how tidy this is and it didn’t sit right and I think it’s finally hit me.
Your test isn’t simulating a real-world situation because your second print statements are reusing strings, which means ScottKit can reuse the messages. If you replace the first few lines with unique messages in the second print statement:
occur
print "1"
print "a"
occur
print "2"
print "b"
occur
print "3"
print "c"
occur
print "4"
print "d"
occur
print "5"
print "e"
then run, you’ll find you get various broken messages.
I grant that there might still be potential to break the barrier, but in ScottKit-land it’s very clear right now that using more than one print message per line will get you in trouble past 99 unique messages, and when coding non-trivial conditions there are places where the compiler gets confused and seemingly demands additional print statements.
But the fact that ScottKit and Scottfree can both at least handle displaying those 380+ top-slot messages is a good sign.
I’m trying to wrap my head around this but is it correct that:
Print "A"
print "B"
Print "C"
Use 3 messages, but
print "A\nB\nC"
Only uses one message. If so, what is the drawback with using the second method?
(In rotten_v3, jcompton uses the first example on line 372-, but the second example on other places)
Your interpretation of those scenarios is correct: top example counts as three messages, bottom example is just one. Also, messages can be reused:
action talk ghost when here ghost and at platform
print "If thou didst ever thy dear father love--
Revenge his foul and most unnatural murder
Send Claudius to HELL
And bring me the *treasures* of my ENEMIES!" # all of this is message 1
pause
print "A ghostly voice cries SWEAAAAAARRRRR!" # message 2
set_flag 2
put ghost purgatory
put ophelia manor
occur 2% when flag 2
print "A ghostly voice cries SWEAAAAAARRRRR!" # also message 2
Now, that’s a situation where I am deliberately splitting up the messages, both so I can do the little pause bit and because although I never re-use that message a third time, it saves a few bytes by not having that text appear twice in two different messages.
Unfortunately there’s a limitation in ScottKit where it struggles to automatically split up certain complex condition and action lists using continue , so in several cases I am forced to do this:
action give script when here players and flag 5 and present script
print "We can play the MURDER OF GONZAGO!"
print "They exit to the throne room"
print "The play is ABOUT to begin!" # ugh, 3 messages, I would prefer just 1!
put players throneroom
put script throneroom
This is the most awful case, what should be just one print statement (and hence one message) had to be split into three because with fewer, things like this happen:
/Library/Ruby/Gems/2.3.0/gems/scottkit-1.6.0/lib/scottkit/compile.rb:463:in block in generate_code': condition has 7 conditions (RuntimeError)
For whatever reason, ScottKit can work its way around these problems if you give it more print statements.
I’m losing 8-9 messages in Ghost King to the problem and am hopeful that it’s an easy fix for Mike if he has a minute to replicate it with my filed issue.