Things won't build for ports that first
define SYSCF.
This moves assure_syscf_file() from unixmain.c
to files.c and adjusts extern.h to get it
out from under #ifdef UNIX.
The call to assure_syscf_file() in options.c was
only #ifdef SYSCF, SYSCF_FILE and not UNIX,
so new ports #defining SYSCF would get an erro.
assure_syscf_file() will be utilized by mswin
when SYSCF is defined.
There is a lot of code affected by this, and Pat Rankin correctly
observes that it would be better to store roguelike as a level flag
rather than just using Is_rogue_level. A note for the future.
gcc reports "comparison between signed and unsigned". One header file
uses unsigned long for tty flags, another uses [signed] short. 'unsigned'
seems like the best compromise, but this might accidentally introduce lint
for some other configuration.
Remove date.h and patchlevel.h from win/tty/wintty.c, win/X11/winX.c,
and sys/share/pcmain.c (caveat: the latter two are untested) so that they
don't get recompiled every time any other source file changes and triggers
creation of a new date.h. Only version.c needs to be recompiled in that
situation. Also, Makefile.src was missing a reference to botl.h.
Tested on the unix port; I've updated as many other ports as I can figure
out but they're not tested. See window.doc for info on the changed banner
lines. Also adds the ability to override the generic "Unix" port - used now to get
"MacOSX" into the version line instead of "Unix" (so we don't scare people who don't
know what's going on).
This is all tiny stuff - allow overriding WIDENED_PROTOTYPES from the hints
file, missing NO_SIGNAL conditionals, remove a GCC-ism, conditional indentation,
void return in a non-void function.
PORTS: Please make sure I've done the right thing for/to your code.
This patch adds a new winproc that lets the window port approve or cancel
the suspend request - this should take care of the Mac Qt lockup issue.
In addition, Unix suspend is restricted to accounts that can use the shell
if SYSCF is defined.
A few other fixes:
- bug: text window does not scroll left on left arrow
- pcmain.c: fix warning: _fileno() returns void* in Windows CE SDK
3.5.0 only:
- files.c: compile error: don't include <signal.h> if NO_SIGNAL is defined. WinMo does not support POSIX signals
- version.c: compile error: append_port_id() is undeclared
- link error: mktime() is unsupported -> define it in celib.c
-<Someone>
cvs admin -ko sys/share/*_*.c to suppress $Date$ and $Revision$ expansion,
reverting to the text checked a few days ago.
cvs commit -f sys/share/*_*.c to trigger this mail; you'll need cvs update
to get the actual text.
It always struck me as odd that x_maze_max and y_maze_max were
initialized in main(). They're only needed when making new levels, so
don't have to come before saved game restoration. They could easily have
gone into init_dungeon() (although they make well predate that), or even
mklev() (reinitializing them for each new level wouldn't have been a big
deal). That's all moot, though, since it's trivial to initialize them at
compile time.
[See cvs log for src/role.c for a much longer description.]
When picking role, race, and so forth, new menu entries allow you to
pick any of the other items before the one currently being handled. After
picking all four of race, role, gender, and alignment (or if you answered
'y' to "shall I pick for you?"), there is a followup prompt to confirm the
choices. It's a menu which also provides a chance to rename the character.
This has only been implemented in win/tty's player_selection(), with
some support code in the core that might be useful to other interfaces.
And so far, the chance to rename is only presented as a menu choice if
you've given an answer to "who are you?" prompt earlier during startup.
Also, ports that use pcmain.c aren't able to perform hero renaming yet.
More warning bits that never got committed.
More appropriate compiler flags for warning checks (macosx only for the moment).
The changes in dgn*[lc] just rename line_number to nh_line_number to avoid a
clash, so no need to regenerate the lex output.
infrastructure for "system options" - things currently specified at build
time that should be changeable at install time or run time but not really
under user control
generalize contact info so it can be localized and it doesn't have to be
an email address
move recently introduced WIZARDS into sysopt
drop bogus OPTIONS=wizards possibility
new function build_english_list() to comma-ize and add 'or' from a whitespace separated list: A. A or B. A, B, or C.
syscf file now handles: WIZARDS SUPPORT RECOVER
SUPPORT specifies local support information
RECOVER will eventually supply port-specific and/or localized info on how
to run recover (or get it run for you).
Note: in sys/msdos I changed sys.o (generated from pcsys.c) to pcsys.o
Note: sys/msdos/Makefile.GCC has 2 rules for sys.o (now pcsys.o)
From a bug report.
Pointer subtraction yields a result of type ptrdiff_t which can be
bigger than type long, potentially resulting in warnings about value
truncation--in these cases, when assigning to a long.
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].
Clean up the preprocessing associated with the
loadable symbol stuff.
Base it on new LOADSYMSETS, rather than on the
previously existing ASCIIGRAPH preprocessor define.
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".
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.
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.
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.
o Add support for zlib compression via ZLIB_COMP in config.h (ZLIB_COMP
and COMPRESS are mutually exclusive).
o rlecomp and zerocomp are run time options available if RLECOMP and
ZEROCOMP are defined, but not turned on by default if either COMPRESS
or ZLIB_COMP are defined.
o Add information to the save file about internal compression options
used when writing the save file, particularly rlecomp and zerocomp
support.
o Automatically adjust rlecomp and zerocomp (if support compiled in)
when reading in an existing savefile that was saved with those options
turned on. Still allows writing out of savefile in preferred format.
o In order to support zlib and not conflict with compress and uncompress
routines there, the NetHack internal functions were changed to
nh_uncompress and nh_compress as done in the zlib contribution received
in 1999 from <Someone>.
I tagged the sources NETHACK_3_5_0_PREZLIB prior to applying these
changes.
