Last fall when Michael added the symset stuff to supersede the old
handling for IBMgraphics and DECgraphics, Guidebook.tex was changed to
support multi-page tables in the output. But that requires that the
input be processed twice, because it requires feedback stored in
Guidebook.aux and the first pass can't rely on that file being present
or up to date. This updates the Unix, VMS, and OS/2 makefiles to do
two-pass processing. (I didn't see latex usage anywhere else, and the
branch version doesn't include the formatting change which needs this.)
Suggested by <Someone>: in the special level compiler, support
"random" in addition to "open" and "closed" for a drawbridge's inital
state. Drawbridge shares code with door, so the necessary parsing was
already present. This just treats random as valid for drawbridge instead
of explicitly rejecting it, and makes the special level loader process it.
He also suggested that the two drawbridges on the bottom level of
the Valk's quest be changed from open to random, but this patch doesn't
go that far. I think it's a good idea, but since the player can't use a
musicial instrument on those bridges, this has more impact on game play
than it might at first seem. I don't really want to see Valkyries be
required to use magic for occasions where both bridges start out closed.
Reorganize the recent wizard mode control: move set_playmode() from
xxxmain.c to the core, and have it call new authorize_wizard_mode() to do
the port-specific part. If the set_playmode() call during startup doesn't
result in running in wizard mode (either because not allowed or user
didn't request it), it will be called again during restore if the save
file is from a wizard mode game.
For ports which check character name for authorization, players will
have to use `nethack -u whatever -D' (or options for name and playmode) to
restore a wizard mode save file if WIZARD has been changed from "wizard".
plname[] from a wizard mode saved game will always have that value, so if
it's not the right one players will need to get authorized by the startup
code before loading the save file.
Wizard mode or explore mode can be forced on (via -D or -X on the
command line, or now via OPTIONS=playmode:debug|explore) when restoring
a saved game; explore mode handling was confined to restgamestate(), but
wizard mode handling was replicated in every main(). Treat `wizard' the
same as `discover'. Also, prevent a new game started when restore fails
from using the old game's option settings if partial restore attempt got
far enough to load the flags struct. And update bemain.c and macmain.c
to catch up with the others modified by the playmode patch.
[see cvs log for src/options.c for some additional info]
Relief for the command-line impaired. Allow player to request
explore or wizard mode via run-time config file or NETHACKOPTIONS.
Validation is left to xxxmain() and has been updated for Unix, VMS, and
ports which share pcmain. Mac and Be appear to allow any user to access
wizard mode, and may not need any modification, although they'll continue
to have the old buglet of running with both wizard and discover flags set
if player uses `nethack -X -D'. This may or may not work as-is for the
Qt interface depending upon whether it goes through one of the xxxmain()'s
mentioned above [someone needs to make sure that it doesn't allow Qt on
Unix to bypass the (username == WIZARD_NAME) test when user requests
wizard mode].
NOSAVEONHANGUP isn't documented anywhere. I don't see why it should
wipe out recoverable level files just because it doesn't want to build a
save file out of them during the hangup. Leave them intact if checkpoint
is active. If someone really wants to make them always go away, they'll
need to disable INSURANCE as well as enable NOSAVEONHANGUP.
tty's getret() -> xwaitforspace() could get stuck in a loop after
hangup, depending upon the state of terminal shutdown (accepting EOF or
ESC cares about cbreak mode?). Make xwaitforspace() become a no-op during
hangup processing.
vms's call to hangup() from an exit handler took place after the
terminal has been reset (the exit handler for the latter is registered
later so executes sooner). Then exit_nhwindows() resulted in a second tty
reset attempt and settty() -> setctty() encountered an error (which it
reported, triggeting a getret() call). Make the vms code correctly guard
against multiple resets.
[See cvs log for src/cmd.c for more complete description.]
This turns clearlocks() into a no-op during the period when the UNIX
port is asking the user to confirm whether to overwrite an existing game.
Also, this removes the duplication of code and function between hangup()
and end_of_input(), and it simplifies the check for whether hangups are
supported by adding new macro HANGUPHANDLING. (I don't think global.h is
the best place to be defining that but I couldn't figure out where else
it would fit, other than repeating for individual xxxconf.h files.) And
adds a couple more done_hup checks to try to cope with situations where
rhack() is being bypassed. Lastly, having readchar() return EOF was
ignored for non-UNIX configs; now everybody gets ESC instead of letting
EOF be seen further inside the core.
- force time_t to be 32 bits via Makefile. (If struct u gets changed to not
store a time_t field, this can be removed).
- Latest Windows SDK (supporting Vista) causes a warning due to
a prototype in sys/winnt/nttty. Since we don't actually link with that
function and rely on a DLL find procedure at run time, comment out
the prototype. The function is now officially in the SDK in the
windows header files anyway.
Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
[See cvs log for doc/window.doc for more details.]
This patch attempts to add some levels of unicode support
to NetHack.
The master on/off switch for any Unicode support is
defining UNICODE_SUPPORT in config.h. Currently
there is code support for two subsets of unicode support:
UNICODE_DRAWING
If UNICODE_DRAWING is defined, then the data
structures used to house drawing symbols are expanded
to the size of wchar_t, big enough to hold unicode characters.
A typdef called `nhsym' is involved and if UNICODE_DRAWING
is defined, it is wchar_t, otherwise it is uchar.
UNICODE_WIDEWINPORT
If UNICODE_WIDEWINPORT is defined, then the data
structures inside the window port are expanded to the size of
wchar_t, big enough to hold unicode characters. Both map
symbols and text within the window port are expanded, in order
for potential support for displaying multinational characters some
day, but this patch only provides viewing of map symbols.
A typdef called `nhwchar' is involved and if UNICODE_WIDEWINPORT
is defined, it is wchar_t, otherwise it is char.
The only window port with code support for UNICODE_WIDEWINPORT
currently is the TTY port. Don't enable UNICODE_WIDEWINPORT
unless:
- it is a TTY port
- the underlying platform specific routines can
handle the larger data structures.
Don't enable UNICODE_SUPPORT unless:
- your compiler can handle wchar_t.
- your compiler can accept L'a' characters.
- your compiler can accept L"wide" strings.
Note that if your compiler can handle the above, you could
enable the larger data structures (currently if TTY) even if your
platform can't actually display unicode or UTF-8, by messing
with u_putch() in win/tty/wintty.c to only deal regular chars.
That should be the only function that actually pushes wide characters
out to the display.
If you enable UNICODE_SUPPORT, and your platform is capable
you will need to turn on the unicode run-time option to be able to
load unicode character sets from the symbol file, to be able to
push unicode characters to the display. You'll also want to load
a unicode symbol set once the unicode option is toggled on. In
a config file you would do that via these two lines:
OPTIONS=unicode
OPTIONS=symset:Unicode_non_US
The repository was stamped with NETHACK_PRE_UNICODE
prior to applying this patch, and stamped with
NETHACK_POST_UNICODE afterwards. The code differences
between those two tagged versions are this patch.
Add putmixed() to the window port. It allows map symbols to
be included in the string by encoding them in a unique fashion.
This was done because Unicode symbols, for instance, could be
longer than the size of a char.
The encoding of the map symbols in this patch is done by
prefixing a glyph value with \GXXXX, where XXXX is a
random value for the current game. The reason for the random
prefix is to minimize the possibility that a player can trigger
the escape sequence processing within text under their control
(dog names, etc.) the way they could if the sequence was fixed
in the source code. The random prefix remains the same throughout
the lifetime of a game because message window strings are
saved in the save file.
(There was actually a bug present because of the embedded
character even before the recent symbol changes, because if
someone was using a different set of characters between games,
the saved messages would reflect the original characters, rather
than the current. That bug was introduced with the ability to
save messages to the savefile.)
A window port does not have to supply an XXX_putmixed() routine,
it can use genl_putmixed() which uses the old behavior of
embedding the sequence as a character within the string
and calling putstr(). genl_putmixed() takes care of the decoding
of the escape sequence.
This also #ifdef's out code in pager.c for converting a glyph
to a character, and uses mapglyph() to do that instead. Does
anyone see a problem with doing that through mapglyph instead
of repeating similar code within pager.c?
The palette option is supposed to be allowed in the config file
without a value for win32 to trigger a load of a predefined
NetHack palette, but that wasn't working.
This fixes that. To prevent the use of any palette modification
code at all, just leave the palette option out of the config
file entirely.
Clean up the preprocessing associated with the
loadable symbol stuff.
Base it on new LOADSYMSETS, rather than on the
previously existing ASCIIGRAPH preprocessor define.
- reduce the number of symbol tables for each graphics
set {PRIMARY, ROGUESET} from three {map, oc, mon}
tables for each of the display symbols, the loadable symbols,
and the rogue symbols, to one continguous table for
each:
showsyms: the current display symbols
l_syms: the loaded, alterable symbols
r_syms: the rogue symbols
- Modify mapglyph so that the index into the symbolt table is
available as a return value (it was a void function), rather than
just the char converted from the glyph.
- That makes it possible for a window port to use the same
index value to extract from another table (perhaps a unicode
table) for a different set of display symbols. The index
is much more useful than trying to convert the character
into another type of symbol, as some contributed patches
have done.
- It is much easier to load a single alternative flat table to
make substitutions, since the corresponding value just
has to get placed into the same index offset in the
alternative table.
This also fixes a bug I found in botl.c, where you could
go to the rogue level, and the bottom line gold symbol
was not being updated with the new character as it should.
The reason was because the gold value had not changed,
only the field symbol used had changed.
This updates multiple ports to place a (void) cast on
the mapglyph call, now that it returns a value, so this
is going to generate a lot of diff e-mails.
Pat Rankin wrote:
> Symbol set definitions need a description attribute, above and
> beyond allowing comments in the file, for inclusion in the 'O'
> command's menu entries for selecting them.
[...]
> mapglyph.c isn't the proper place to decide whether to define
> ROGUE_COLOR. That may need to become a symbol attribute,
> which we'd then specify on the Epyx rogue set(s).
Implement both of the suggestions above.
This takes the PC config file commented symbol value
recommendations from <Someone> for blind players
and puts them into a symset.
[note to devteam: They look odd. I thought perhaps that
something was code wrong, but I went back to 3.4.3
and uncommented the config file stuff. They look the
same there, still odd, especially corridors.
Does anyone have any of the e-mail from <Someone> that might give an indication of what is supposed
to be seen on the display? I wonder if those config
file options fell out of synch with the code long ago]
- Instead of checking for the Rogue level, check which
graphics are engaged (PRIMARY or ROGUESET) in the
SYMHANDLING() macro.
- track which graphics are active through 'currentgraphics'.
- Instead of symset and roguesymset and symhandling and roguehandling
variables, have symset and symhandling be arrays of two, with the
following indexes:
PRIMARY
ROGUESET
That reduced the amount of repeated code.
(Not to be confused with the 'symset' and 'roguesymset' config file options
both of which still exist)
- the symbol routines were adjusted to pass
the index , rather than 'rogueflag' and coding to roguesymset etc.
Other than fixing bugs that are encountered, this is probably
the last of the symbol stuff, with the exception of
making the symset and roguesymset config file options
accept the keyword value "default".
- tile2x11 would not build because drawing.c now depended on strcmpi which
was (via STRNCMPI not being defined) defined to strncmpi which is
implemented in hacklib.c which needs panic which is defined in... I gave up
on tracking down all the loose ends and changed the strcmpi to strcmp,
which means the handling is case sensitive, but it avoids a bunch of
changes to the way the util/Makefile.
- the symhandling changes introduced a chicken and the egg problem for
ASCIIGRAPH on Unix platforms, which was getting the defn from tcap.h but
that does not get included earlier enough nor often enough. I added a defn
to unixconf.h to mimic ntconf.h, since ASCIIGRAPH is normally defined on Unix.
- options.c included an unused decl for a function named graphics_opts
- Unix Makefile was not installing "symbols". I'm assuming this isn't
supposed to get the DLB treatment.
This is an overhaul to the NetHack drawing mechanism.
- eliminates the need to have separate lists in drawing.c
for the things and their associated explanations by grouping
those thing together on the same inializer in a struct.
- replaces all of these options: IBMgraphics, DECgraphics, MACgraphics,
graphics, monsters, objects, boulder, traps, effects
- drawing.c contains only the set of NetHack standard symbols for
the main game and a set of NetHack standard symbols for the
roguelevel.
- introduces a symbols file that contains named sets of
symbols that can be loaded at run time making it extensible
for situations like multinational code pages like those reported
by <Someone>, without hardcoding additional sets into the game code.
- symbols file uses names for the symbols, so offsets will not break
when new things are introduced into the game, the way the older
config file uchar load routines did.
- symbols file only contains exceptions to the standard NetHack
set, not entire sets so they are much less verbose than all of
the g_FILLER() entries that were previously in drawing.c
- 'symset' and 'roguesymset' config file options for
preselecting a symbol set from the file called 'symbols'
at startup time. The name of the symbols file is not under the
users control, only the symbol set name desired from within the
symbols file is.
- 'symset' config file option loads a desired symbol set for
everything but the rogue level.
- 'roguesymset' config file option loads a desired symbol set
for the rogue level.
- 'SYMBOLS' config file option allows the user to specify replacement
symbols on a per symbol basis. You can specify as many or as few symbols
as you wish. The symbols are identified by a name:value pair, and line
continuation is supported. Multiple symbol assignments can be made on
the same line if each name:value pair is separated by a comma.
For example:
SYMBOLS = S_bars:\xf0, S_tree: \xf1, S_room:\xfa \
S_fountain:\xf4 \
S_boulder:0
- 'symbols' file has the following structure:
start: DECgraphics
Handling: DEC
S_vwall: \xf8 # meta-x, vertical rule
S_hwall: \xf1 # meta-q, horizontal rule
finish
start: IBMgraphics
Handling: IBM
S_vwall: \xb3 # meta-3, vertical rule
S_hwall: \xc4 # meta-D, horizontal rule
finish
- 'symbols' file added to the source tree in the dat directory
- Port Makefiles/scripts will need to be adjusted to move them into
HACKDIR destination
I don't know if this was introduced post 3.4.3 or not, but the
DOS port was doing a chdir at the start, but not doing one
at the finish of the game, so you ended up in the same
directory as the NetHack.exe executable post-game.
It was doing the chdir even if NOCWD_ASSUMPTIONS was
defined.
Incorporate part of <Someone>'s changes to address
the main part of bug W343-3.
One other patch yet to come needs to provide a way
to limit the IBMGraphics symbols to various subsets that are
available on some international versions of Windows. Pat
suggested that we not incorporate that patch as is, so I'll be
working on an overhaul of the {DEC|IBM|MACgraphics mechanism.
* Checks for the presence of the Unicode
APIs. If GetVersion() returns the 31st bit set, NetHack is running on
a 95-based version of Windows. The Unicode APIs are not available
and NetHack will revert to the pre-patch behavior. This fix isn't needed
on 95-based Windows anyway.
* Fixes console output for text strings.
The character is converted according to the user's configured IEM code
page and passed to the Unicode version of WriteConsoleOutputCharacter.
* Fixes console output for map symbols.
The character is converted according to a fixed mapping containing
code page 437 plus the symbols in the space from 00 to 1F. A fixed
table is used so that a player using Lucida Console can get full
IBMgraphics (original set, i.e. level 3) regardless of the code page.
A table is used instead of MultiByteToWideChar so that the space from
00 to 1F will be converted correctly; this is necessary for correct
display of the Rogue level.
If you specified one or more palete options in the config file,
but not all 16, you ended up with black for any you didn't
specify - oops.
This patch ensures that the table has a full complement
of 16 colours by initializing it to the windows default colours
just ahead of the first palette option encountered.
As before, if the config file has no palette option in it,
no calls to change the palette are made at all. If the
undocumented method breaks in a future release of
Windows, then avoiding palette options will work
around the problem.
Allow config file entries to adjust win32 console colours.
The following entries in a config file are examples:
OPTIONS=palette:black-0-0-0
OPTIONS=palette:red-210-0-0
OPTIONS=palette:green-80-200-0
OPTIONS=palette:brown-180-100-0
OPTIONS=palette:blue-0-0-200
OPTIONS=palette:magenta-128-0-128
OPTIONS=palette:cyan-50-180-180
OPTIONS=palette:gray-192-192-192
OPTIONS=palette:dark gray-100-100-100
OPTIONS=palette:orange-255-128-0
OPTIONS=palette:bright green-0-255-0
OPTIONS=palette:yellow-255-255-0
OPTIONS=palette:bright blue-100-100-240
OPTIONS=palette:bright magenta-255-0-255
OPTIONS=palette:bright cyan-0-255-255
OPTIONS=palette:white-255-255-255
This uses an undocumented way to adjust the console
colours in a win32 console application. The method and
code snippet used comes from www.catch22.net by James Brown.
This page:
http://www.catch22.net/about.asp
states the following:
"you do not have to pay anything to use the software, and there are no
licencing terms for any sourcecode that you may download from this site.
This means you can freely use any sourcecode or portions of code in
your applications, whether they be free software or professional, retail
products."
botl.c conversions. All the ports seem to be using genl_status_update(),
rather than a window port specific version, so botl.c was the only place
this had to be adjusted.
Also a uudecode cast for the result of strlen, since it isn't using
config.h
We've been getting numerous complaints from people
about "dungeon failure", often related to attempts
to start NetHack from within various zip utilities
that present a folder-like view.
The dungeon failure was actually misleading. The
real problem was a dlb file open failure, but the
return value of dlb_init() was not being checked
in pcmain.
This moves the dlb_init earlier in the startup,
checks for failure, and provides some feedback
around the common zip utility problem for win32.
The revised newmail() wouldn't compile (Strncpy doesn't exist, `buf'
was an array of pointers rather than of char). Simplify it substantially,
and adjust the one caller (vms) that relied on the old convoluted bit.
Move some internals-related code out of port-specific main so that
it isn't duplicated a bunch of times. One minor side-effect of this
change is that if you auto-pickup something at the very start of a game,
it will happen after any full moon/new moon/Friday 13th message rather
than before. There's a second change for some: the shared main() used
by several of the micro ports had a small difference in game play--if you
saved a game while on an engraving, it would automatically be read when
you resume--that will now occur for everybody [Elbereth weenies rejoice!].
pcmain() was also calling update_inventory() at start of play. That's
unnecessary for new games, where inventory initialization triggers a call
to it for each item added to your pack; but I wasn't sure about restored
games, so everybody gets it there now.
The Mac and BeOS ports evidently haven't been touched it some time;
they still referenced flags.move which got replaced by context.move quite
a while back. The Windows GUI code has a declaration for mswin_moveloop()
which appears to be non-existant, but I left it alone. I assume that the
Qt interface uses the existing main() routines; at least I couldn't find
any start of game code specific to it. vmsmain's revised main() is the
only one which has been tested.
