Bugs in the block initialization & elsewhere; some which were inherited from the Fortran version.

[LydiaMarieWilliamson]

I'm retranslating the Fortran version to C99, and have also updated my branch of your archive to C99, while progressively bringing them into convergence with each other and the Fortran original (which is also undergoing update to Fortran 2018). The process has uncovered several bugs in both the Fortran original and the 1991 C translation.

In particular, there are several inconsistencies in the initializations done in blkdata.f (which corresponds to your parse.h with INIT defined). There are mismatches in the following places: ∙ (1RS, 29560): Mismatched value (it should be 30400); 29560 corresponds to 2RRS. ∙ (3RPAP, 256656): Mismatched value (it should be 25656). ∙ (1RO, 0): Mismatched value (it should be 24000). ∙ (1RY, 4000): Mismatched value (it should be 40000). ∙ (3RMIN, 21175): Mismatched value (it should be 21174).

The first two of these inconsistencies were corrected by the 1991 translation to C, and are not present in the C version. The ‟1RS” in (1RS, 29560) was already changed to ‟2RRS”. This involved words starting in ‟HOURS⋯”, but did not affect them, since the mistake was in the comment, not the code. The 256656 in (3RPAP, 256656) was already changed to 25656, is for words beginning in ‟PAPER⋯” and affects the code.

The remaining inconsistencies, which affect words that start in ‟INTO⋯”, ‟CLAY⋯”, ‟CRIMIN⋯”, respectively, have all been inherited by the translations of Zork into C and are present in your copy, as well. For now, they've been kept intact in our copy, but will soon be corrected.

The ability to see this was obscured by the fact that the 1991 C translation mangled the layout of the initializations, relative to the layout listed in the comments, and failed to keep the comments aligned with the code. A translation project should not be considered complete until the comments are also translated and realigned; and the 1991 translation left this unfinished. This is one of the reasons why.

In most of the *.c files, the function header comment for the first function definition was misplaced at the top of the file, separated from the function it is in reference to, and should be moved down back next to the function.

In gdt.c, at one point, a file output has eqo misaligned as eqo[j + k * 200 - 201] at 200, when it should be aligned as eqo[j + k * 220 - 221] at 220. This was a error made in the 1991 C translation. The error will mangle the display of the object table during debug mode.

Also, in gdt.c, after L35500 should be printf("Old= %c New= ", cevent_1.cflag[j - 1] ? 'T' : 'F'); to match the Fortran original. This omission was an error, as can be seen by the fact that the "fflush(stdout);" statement was left intact ... with nothing left to flush. This affects the display of clock interrupt events during debug mode.

[john-peterson]

I saw that you split out the text index to readable form but the game text itself is still illegible to me

This is a problem because i want to remove the sentence breaks from the game text so it can be played on a phone primarily or any terminal that is not exactly 70 columns

notice and cringe at the out of place break in the opening message

./Zork
Welcome to Dungeon. This version created 2021-10-31.
You are in an open field west of a big white house with a boarded <-- BREAK
front door.
There is a small mailbox here.
>

the text printer likewise prints breaks everywhere

gdt
dt
4
The parser tries to be clever about what to do in the case of
        actions which require objects that are not explicitly specified.

it seems to break at 70 columns so it will look right only on that column width. anything else will look strange. a phone has around 40 colums

echo "You are in an open field west of a big white house with a boarded"|wc
      1      15      66
echo "You are in an open field west of a big white house with a boarded front"|wc
      1      16      72
tput cols
44
termux-info
Android version:
12
Kernel build information:
Linux localhost 5.4.147-qgki-g3eeb1d6e489b #1 SMP PREEMPT Thu Jul 28 11:17:53 UTC 2022 aarch64 Android
Device manufacturer:
HMD Global
Device model:
Nokia G60 5G

have you seen if it tries to determine column width during runtime?

or are the line feeds hard coded into the text file?

in that case how do i change the text. or read it to begin with? do you have a command for reading the text

head -c 30 dtext.dat
=��a��ՠ�
        ��Q

the emulator does not suffer from this. maybe the text can be copied from that data file if its free of line breaks

http://www.infocom-if.org/downloads/zork1.zip
frotz DATA/ZORK1.DAT

ZORK I: The Great Underground Empire
Copyright (c) 1981, 1982, 1983 Infocom, Inc.
All rights reserved.
ZORK is a registered trademark of Infocom,
Inc.
Revision 88 / Serial number 840726

West of House
You are standing in an open field west of a
white house, with a boarded front door. <-- COMPLETE SENTENCE 
There is a small mailbox here.

>

it talks about rows

grep -wr rows
Makefile:## The Dungeon/Zork program provides a ‟more” facility which tries to figure out how many rows the terminal has.
Makefile:## more option 3: assume all terminals have 24 rows
local.c://      MORE_TERMCAP    Use termcap routines to get rows of terminal
local.c://      MORE_TERMINFO   Use terminfo routines to get rows of terminal
local.c://      MORE_AMOS       Use AMOS monitor calls to get rows of terminal
local.c:// Initialize the more waiting facility (determine how many rows the terminal has).

but not about columns

a@e:~/zork$ grep -wr columns
a@e:~/zork$ 

which makes me think the sentence breaks are in the data file

[LydiaMarieWilliamson]

On Tue, 2023-09-05 at 15:48 -0700, John Sebastian Peterson wrote:

I saw that you split out the text index to readable form but the game text itself is still illegible to me This is a problem because i want to remove the sentence breaks from the game text so it can be played on a phone primarily or any terminal that is not exactly 70 columns notice and cringe at the out of place break in the opening message Please excuse the delay in my reply. I've been preoccupied and I've now found a little time to examine your letter in some detail.

The changes made, related to the database file, are logged in History.txt in the period 2021-10-06 to 2021-10-21 and 2021-11-11; the most important being adding in a compiler and decompiler for the database file.

Although their compilation and decompilation are not under the umbrella of the Makefile's automation, the programs used to generate the files are in the distribution. They are in the C directory, as "writeit.c" for producing a data file and "readit.c" for generating a more legible view of the file that can be used to verify and examine its contents. There is also a Fortran version of the decompiler, "readit.f", in the Fortran directory. For consistency, the two versions of the software use the same file and format.

You should try to recompiling the data file with your suggested changes.

For reference, in writeit.c:

./Zork Welcome to Dungeon. This version created 2021-10-31. You are in an open field west of a big white house with a boarded <-- BREAK front door. There is a small mailbox here.

The break is in message listed in writeit.c as 1015. The continuation line is the following one that is labeled 0, as are all the continuation lines. The simplest fix would be to eliminate the text in the continuation and append it directly to 1015's text

A large number of change, on the other hand, will be more labor intensive. There are 1660 messages listed in writeit.c, laid out over 2811 lines. Maintenance will not be friendly to automation, because of constraints in layout. An example of this is messages 1609,  1610 and 1613. Messages 3, 4, 875, 1098 and 1099 are also somewhat constrained in layout, as is, as well as a few others further below.

The line breaks are embedded in the "writeit.c" file and largely match those inherited from the original sources.

To make this work with the more restrictive sizes of a cell phone - unless you're able to use landscape - might make it necessary to remake the layout of the message list in its entirety. Of course, that's been done in a much more expansive way in other - later - version of Zork, which was to change to a GUI-based interface. Remaking the game on a GUI-building platform, like SDL or QT, has been considered. I have projects on GitHub and locally that are SDL-based and QT-based. But it would be a large overhaul.