/usr/share/doc/frotz/BUGS is in frotz 2.44-0.1+b1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 | =============
Color mode ||
=============
It seems that it's up to the curses library to decide if a program may
or may not use color. For example, ncurses on NetBSD refuses to allow
Frotz to run in color mode, even when color mode is forced. Frotz and
the program it's running think color is being emitted, but ncurses won't
allow it. On the other hand, NetBSD's standard curses library (1.6 and
later) will let colors be seen.
=======================================
Ctrl-Space causing Bogus ZC_TIME_OUT ||
=======================================
Under ncurses, getch() will return OK (defined to 0 ) when Ctrl-@ or
Ctrl-Space is pressed. 0 is also the ZSCII character code for
ZC_TIME_OUT. This causes a fatal error "Call to non-routine", after
which Frotz aborts. This doesn't happen with all games nor is the
crashing consistent. Sometimes repeated tests on a single game will
yield some crashes and some non-crashes. When linked with ncurses, we
must make sure that unix_read_char() does not return a bogus
ZC_TIME_OUT. This returning of 0 appears to be abnormal behavior
peculiar to ncurses, so an #ifdef is used to enable the fix only if
ncurses is being used. Alembic's fix didn't have this
#ifdef and so it broke NetBSD's newly-updated curses library.
=======================
Bug-testing Programs ||
=======================
Unix Frotz now comes with crashme, TerpEtude, gntests, strictz, and
Unicode Test. These are intended to excercise the interpreter and
verify that it is functioning according to spec. You will find these
programs in the src/test/ directory.
==================
Screen Resizing ||
==================
There are some significant problems involved in getting screen resizes (as
in resizing an xterm) to work correctly at least with Frotz's
implementation of the Z-Machine and probably the Z-Machine standard
itself. For this reason, I have not implemented screen resizing for
Frotz. I know that some zcode interpreters are able to deal with resizes
somewhat gracefully, but I haven't seen one yet that will handle some
weirder situations. Infocom's "Border Zone" and "Beyond Zork are
especially troublesome for doing resizes. Nitfol seems to have the best
handling of screen resizes. Since it uses the Glk library, I'm inclined
to think the Glk library is at least partially responsible. If you have
any other ideas on how to cleanly resize screens, I'd like to hear them.
The Z-Machine seems to assume that when the screen dimensions are set,
they will never change over the course of the game, even across saves and
restores. For some reason, saves include screen dimensions and I've yet
to discover how to override the Z-Machine from setting its dimensions to
the saved ones instead of how the current screen really is. When the
Z-Machine was first defined by Infocom, this made sense since terminal
screens rarely, if ever, changed their dimensions and few people were
assumed to trade saves across platforms.
=====================
Arrow Key Handling ||
=====================
Not really a bug, but an idiosyncracy. In "Journey", sometimes you can't
use the right-arrow key to move from the "party commands" menu to the
"individual commands" menu. IMHO, this is a bit sloppy, but it isn't
Frotz's fault. Instead, use the spacebar to jump from menu to menu.
I mistakenly attributed this to an unknown bug. That'll teach
me to do bugtesting when I'm about to nod off to sleep.
===================
Other Known Bugs ||
===================
Sound flag is not being set properly.
|