If anyone wants to take a stab at this, I’ve uploaded some text documents to Github. They are mostly extracted from the file SPL52.DAT in the MS DOS version of Questprobe featuring Spider-Man. Everything is very messy and preliminary, however, so it is probably incomprehensible to everybody else.
Here follows an attempt to describe the problem:
This is an action in the non-plus ScottFree / TRS-80 version, decompiled with ScottKit:
action LOOK SHAF when at Shaft (6) and !exists Gem2 (4)
print "I see"
print "mostly empty tool niches."
(The terminology is pretty confusing, as different tools use “actions” to mean different things, but here an “action” is the entire structure, verb + noun + conditions + commands.)
And here is the corresponding action in the Saga Plus version. Everything to the right of the pure numbers is my added comments:
49
11 LOOK
19 SHAFT
203
195
193
0
196
128
142
3 "I see"
26 "mostly empty tool niches."
The first byte (49) is one mystery I haven’t been able to figure out. Every action starts with a single byte before the verb and noun, and I think it might tell the interpreter where one action ends and the next one starts, and possibly also where the conditions end and the commands start, but it is nothing straightforward like the number of bytes or commands.
The last two lines, 3 and 26, are commands that simply print the messages with the corresponding indices, just like in the ScottFree format.
The biggest mystery, however, is the seven bytes between the noun (19, SHAFT) and the first printed message (3, “I see”.) Somehow they encode the conditions “if player is in room 6 (Shaft) and object 4 (Gem2) is uncreated”, but there is nothing in there that looks like a 6 or a 4.
In the TRS-80 format, the condition player in room has value 4 and uncreated has value 14, so you might expect something like 4 6 14 4 (in room 6, uncreated 4) but there is nothing like that. Of course, the TRS-80 format has its own crazy encoding of these values (condition + 20 * argument) so something similar might be going on here.
Here is another example:
action LOOK SKY when at Skyscraper (17) and !exists cloud (28)
print "I see"
print something!
drop cloud
look2
And the corresponding Saga Plus action:
54
11 LOOK
25 SKY
203
195
193
2
36
131
142
3 "I see"
34 "something!"
85 PRINTOBJ
28 "strange cloud"
53 DROP
28 "strange cloud"
76 LOOK
This has the same conditions as the previous action we looked at, but different arguments. Note that here, the first three condition bytes (203, 195, 193) and the last (142) are the same as in the previous action, while the other three (2, 36, 131) are not.
This might indicate that 203, 195, 193 encode the conditions "player in room " and “uncreated”, while the next three (2, 36, 131) encode the two arguments (17 and 28), and that 142 marks the end of conditions.
