There is also a limit for the value of the conditions: condition + 20 * value. The documentation says 1600, but with 1680 we stay in an unsigned 16 bits value: 19 (condition max) + 20 * 1680 = 65520
1 Like
Exactly. But… That limit applies to actions using nouns.
Does autoget still work if an item’s noun has the index 152, for example? Perhaps it isn’t actually a problem for most all/most/any terps? If so, simply placing all “non-action” item nouns at the end of the list may give us a bit more space to work with.
Edit: I tried this scenario with Scottfree and Perlscott and both seem to be able to handle this well. I did this by generating a game file with hundreds of of random items with random nouns, and then trying to pick up the last one. I guess it needs testing on more terps, but I’m hopeful.
Mmmm. I know we’re talking about a slightly different situation here but I recall from the “the message limit is 99 except when it sometimes isn’t” discussion, these best-case test scenarios don’t necessarily reflect what happens when a real game really crosses those barriers.
This is certainly a related thing. It’s limited by both the data format and the terp implementation. This is one of the reasons why I decided to make my own compiler for ScottKit files. I plan to address the data format part of this so that it will automatically try to achieve the “sometimes more than 99 messages” scenario in a couple of different ways, or at least give a helpful error message when it fails 
The equation is good, I checked with all of Scott Adams’ games.
1 Like
You cannot exceed the limit of 100 messages because the equation of actions is: 150 * action1 + action2 and the message 99 is set to 149. If you go beyond this, you can no longer decode the actions correctly.
It is possible, under some circumstances, to squeeze in more than 99 messages (depending on the terp). See more in this thread from a couple of months ago.
The trick is (as explained by @pdxiv):
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
Indeed, displaying a message greater than 99 also works with Scott Adams’ interpreter: advent.d1.zip (314 Bytes)
2 Likes
Cool! Thanks for testing that. I’m hoping that the Scott Adams terp will support up to ~218 messages or something like that (if the data type is signed 16 bit integer).
In my highly subjective opinion, the way this should be implemented when ScottKit code is compiled, is by rearranging the entries in the messages list, so that text messages triggered in “even commands” end up at the start of the messages list in the data file. If this doesn’t work, it should try to move the “print text” command to the next command slot, if available.
2 Likes
Another strange discrepancy. This time PerlScott and ScottKit seem to be right, and ADVENTUR/CMD seems to be wrong! Consider this ScottKit code:
start cave
treasury cave
maxload 1
lighttime 90
occur when !flag 1
print "Testing AGETx and BYx->x"
set_flag 1
room cave "cave"
exit east chamber
room chamber "chamber"
exit west cave
item bell "*bell*"
called "bell"
item key "key"
called "key"
action boom when carried bell
superget key
print "Boom!"
action boom when carried key
superget bell
print "Boom!"
action fetch:
put_with key bell
print "Brought key to bell."
action score: score
action inventory: inventory
action look: look
verbgroup boom
verbgroup fetch
The “maxload 1” statement is supposed to limit the player’s carrying capacity to just a single object — and that is indeed what happens when you compile the code and play the game in ScottKit or PerlScott, but if you convert the compiled code to .DAT format (attached) and play it in ADVENTUR/CMD or ADV/CMD, then you’ll find that you can pick up both objects, as long as you pick up the key first!:
But if you drop both objects and then pick up the bell first, you now won’t be able to get the key (because the terp suddenly decides to enforce the inventory-limit)!
Anyone know what’s going on? Have I got the ScottKit code wrong somehow?
ADVENT.D1.zip (411 Bytes)
Seems like something is wrong in ADVENTUR/CMD. Not a lot of room for interpretation of “is the inventory limit 1, or isn’t it?”
Do you get the same results if they are both mundane items?
Do you get the same results if they are both treasures?
Do you get the same results if the treasure is the second item defined instead of the first?
It is indeed weird. I wondered if it wasn’t the fact that the bell is a treasure, but no.
Code
<automatics>
%100
? -BIT 1
"Testing AGETx and BYx->x"
SETZ 1
</automatics>
<inputs>
>BOO ANY
? HAS BEL
AGETX KEY
"Boom!"
>BOO ANY
? HAS KEY
AGETX BEL
"Boom!"
>FET ANY
BYX->X KEY BEL
"Brought key to bell."
>SCO ANY
SCORE
>INV ANY
INV
>LOO ANY
DSPRM
</inputs>
<rooms>
room_0:
""
room_1:
e room_2
"cave"
room_2:It is indeed weird. I wondered if it wasn't the fact that the bell is a treasure, but no.
w room_1
"chamber"
</rooms>
<objects>
BEL:
at room_2
"*bell*"
'BEL'
KEY:
at room_2
"key"
'KEY'
</objects>
No, everything is fine. You should not type GET but BOOM (BOO).
Edit : This does not explain why it works in one case and not the other!
The problem is that if you use ADVENTUR/CMD to play the test game in my previous post, ADVENTUR/CMD will allow you to GET two objects (GET KEY, GET BELL) when you should only be allowed to GET and carry one object.
(The BOOM command doesn’t really have anything to do with this issue. I had added BOOM to test the superget keyword (which is ScottKit’s equivalent to AGETx in ADVEDIT). And then, while testing superget, I stumbled upon this issue where ADVENTUR/CMD sometimes seems to ignore the maxload limit when doing a regular GET.)
Your Header is wrong; I changed the number of objects from 1 to 2 and it works now.
The Adventure System manual, which you linked to above, says this about the “objects” header entry:
The highest numbered object in this particular adventure. The objects are numbered starting at zero, so the number of objects is one plus this number.
(I’m talking about the second number in the header. The first number in the header is the number of bytes needed to store strings; the next number is the number I’m referring to here.)
Yes, but the documentation does not refer to version 8.5 of the Adams interpreter, but to an earlier version. If I leave 1, it works with the internal Advedit interpreter; if I put 2, it works with the Adams interpreter. But since the lamp object is the 10th object maybe the value in the Header should be at least 9.
It is quite possible that Scott Adams wanted, version after version, to break the compatibility with The Adventure System.
1 Like
Interesting! I haven’t tried that yet. I’ve never actually used Advedit.
EDIT: Can you please upload or link to the latest version of the Adams interpreter?
Possible (and we could ask him) but I think this is a case where the simplest explanation is the best one. The Adams-y world was winging it and the goal was to add features and tweak functionality that would work when it shipped, then move on to the next thing. It wasn’t an Infocom-esque setting where an early design goal was to establish a consistent, scalable, shared platform.
I tried with Scott Adams’ interpreter versions 8.2 and 8.4, but it doesn’t change anything. It only works properly if you increase the number of objects.