For those that don’t know, scott2zip.perl is a Perl script that can be used to convert a TRS-80 (ASCII) or TI-99/4A (binary) Scott Adams format file to Inform 5 source code. Neat trick, huh?
I recently had need to use this only to find that [a] it produced Inform 5 source code that would not compile in Inform 6, [b] when this source code was patched, it produced run-time errors in the complied z-code file, [c] it deleted any room descriptions that had a hyphen in the description.
I had to download an Inform 5.5 compiler and delete the hyphens in the dat file to get it all to work. Once this was done, it worked fine, but I don’t know what other gotchas I’m likely to strike in other games.
So has anyone updated this script so that it is compatible with Inform 6?
I’ll give that one a go-over.
This is an opportunity to review the gameloop of Scott Adams format games again. The authors of the interpreters and tools for this format didn’t seem to have all the documentation that we have updated today.
I spent a bit of time on it, and it sounds like you actually got further than I did. I still don’t know enough Inform 5/6 to really make any meaningful contributions. Perhaps rewriting it from scratch is a better option to get away from the obsolete versions of languages (the Perl code is for Perl 4, if I remember correctly!).
I played around with the SA-format earlier this summer when I wrote scott2zil. If you find something of value in there you are free to use it anyway you like…
scott2zip misinterprets the CONT instruction. It jumps to a label that does not exist (clabel_1):
? IN ROOM_1
? IN ROOM_1
? IN ROOM_1
[ TestSub matches;
if (location ~= room_1) jump label_0;
print "message 1 ";
if (location ~= room_1) jump clabel_0;
print "message 2 ";
if (location ~= room_1) jump clabel_1;
print "message 3 ";
if (matches ~= 0) print (string) CantDoYet;
print (string) DontUnderstand;
If there is a CONT statement in a .cont block, which is useless but not illegal, it bugs too.
I’ve just started fiddling with this and have struck two problems.
There’s a line that appears twice in the converted code that says:
print object new_sorted->i;
new_sorted is a byte array that holds an object number.
print object prints the text for that object - once for the visible objects in a room and once for the objects in the player’s inventory. The Inform 6 compiler spits the dummy when it encounters this line and produces the error:
Error: Expected comma but found new_sorted
What’s the Inform 6 equivalent of this line? Remember that we are not using the Inform 6 library.
The conversion process produces a lot of labels. The last of these looks something like this:
Note that there is nothing after the label. The Inform 5 compiler accepts this, but the Inform 6 compiler chucks a hissy fit. Any idea how to get around this? Ideally, you don’t want it to produce the label in the first place. Look for the lines that say:
print ' ' x $indent, ".label_", $label++, ";\n";
A ‘nop’ instruction after the ‘.label_’ or ‘rtrue’ instead of the ‘jump’, maybe.
The I6 syntax is
print (object) new_sorted->i;
@nop instruction will work, but of course then you’re wasting bytes. If you can tweak the script to not generate unused labels, that would be best.
Oh, silly me. If you end a function with
…it will compile exactly the same as if you omit those lines. (Because a top-level function returns true by default, the compiler inserts the rtrue if you don’t supply it.) So you can use that to work around this without wasting space.