errors when converting with scoot2zip with SAC

Testing the scott2zip perl script and with my own scott adams storyfile compiled from SAC (Scott Adam Compiler) perl script compiler written by Mike Taylor. It came out in errors. But converting an original Adventureland storyfile came out perfect when converted to inform 5.5 source code. But when use the decompiler from SAC (SAD) to convert it to the original source, and then recompiled Adventureland, and then tried conversion to inform source, the same errors came out. Mayhaps I should inspect the script to the successfully converted inform 5.5 sources so I can see if there are consistencies of important headers and functions of the source and just program from scratch for inform 5.5 using said source file as a framework and release a z5 file. Is that a good idea guys?

What errors?

I’ve tried using Scott2Zip and I get strange output. For example, when I try to compile Adventureland, I get this output:

Scalar value @exit_name[$i] better written as $exit_name[$i] at scott2zip line 388. Illegal hexadecimal digit '-' ignored at scott2zip line 949. ADV01.DAT (TRS-80 format) Use of uninitialized value $_ in substitution (s///) at scott2zip line 206, <DATA> line 882. Use of uninitialized value $_ in substr at scott2zip line 207, <DATA> line 882. Use of uninitialized value $_ in substitution (s///) at scott2zip line 206, <DATA> line 882. Use of uninitialized value $_ in substr at scott2zip line 207, <DATA> line 882. Use of uninitialized value $_ in substitution (s///) at scott2zip line 206, <DATA> line 882. Use of uninitialized value $_ in substr at scott2zip line 207, <DATA> line 882. Use of uninitialized value $_ in substitution (s///) at scott2zip line 206, <DATA> line 882. Use of uninitialized value $_ in substr at scott2zip line 207, <DATA> line 882. Use of uninitialized value $_ in substitution (s///) at scott2zip line 206, <DATA> line 882. Use of uninitialized value $_ in substr at scott2zip line 207, <DATA> line 882.
When I try to compile the resulting source in with Inform

Whoops. Anyways, when I try to compile the source, I get weird output about stack overflow and strange hex numbers.

I think there’s some weird condition that SAC along with SAD does to directly alter the first line that is only numbers that reads out on Scott Adams style DAT storyfile, both proprietary and 3rd party. By reading and comparing the first line that is only number, it reads totally different from an original DAT file with any Adventure International game (ie Pirates Island, Adventureland) that is “disassembled” from SAD to SAC readable code. The file format for the DAT storyfile is pure text and straight forward especially with the ScottFree standards interpreter standards on how it reads it out, but I think there are some irregularities in the recoding of any of the SAC made DAT files due that the read out will always come in error with the Scott2Zip script despite the fact that it is even runnable in ScottFree.

my best bet is if you want to make a Scott Adams style game (I wouldn’t due that you have enough space for ram and also storage as is to make a full prose and take advantage of the full on Infocom compatible parser and then some with Inform 5) you cannot use SAC compiled game (at least until Mike Taylor makes an update to it, and that is unlikely due that the last update nearly if not over 5 years old) but study a INF source file from the scott2zip perl conversion script from at least 2 or 3 different of Scott Adams’ games (as study and research, of course you know you can do that long as you just do that, or play it the damn thing, but of course that goes without saying) then compile from Inform 5 (due that it uses function calls that only it uses and is now in obsolescence, cause Inform 6 and 7) etc. But why do that, when you can just use ScottFree out of the box from your personal SAC source? Unless you want to convert to keep your code assembled in zcode I wouldn’t go through the heart ache of wanting to do that because I have the ease of the source of SAC which is still playable through ScottFree… If only if there was ScottFree javascript terp that can read DAT files even from SAC and is truly, ScottFree legit.

Yes, I had the same problem. Have you already found the solution?

Scott2zip is really old Perl, from 1995. Perl 5 didn’t come out until 1997. Perl 5 is mostly backwards-compatible with Perl 4 but I think here, we have some places it’s not.

Simple changes in how variables are handled are why you get “Scalar value @exit_name[$i] better written as $exit_name[$i] at scott2zip line 388.” but that’s only a warning.

The “Illegal hexadecimal digit” is because 0x0 needs to be 0x00 in the ‘tr’ statement (and the following ‘-’ is getting captured as a number and failing). It’s part of a filter to replace non-printable ASCII chars with spaces to keep Inform from having to chew on characters that won’t fit into the legal chars for 5-bit-char compressed Z-machine strings.

The “uninitialized value” is because some of the room descriptions in “Adventureland” have a ‘-’ in them (“Throne-room” among others) and that’s bunging up some of the code that reads in a TRS-80-format file which results in some room descriptions being undef (conceptually like a null-string in C).

I have a fixed version of scott2zip that I need to get into the IF Archive. I did it because there are platforms that do not have a C compiler but do have a Z-machine (COSMAC Elf/1802, for one), so Scott Free is not a solution there. Yes, it’s possible to write a game engine in assembler for those platforms but that’s another project entirely.

1 Like