When makedefs generates dat/options for #version, enhance the
formatting of the 'supported windowing systems' section with more
thorough word fill and also emphasize the actual window system names
so that user can tell what value to give to OPTIONS=window_system:%s
when picking one of them. Before and after
Supported windowing systems:
traditional tty-based graphics,
terminal-based graphics using curses libraries, and X11
with a default of tty.
Supported windowing systems:
"tty" (traditional text with optional line-drawing), "curses"
(terminal-based graphics), and "X11", with a default of "tty".
People have been wondering how to change the tiles on the X11
version, and the old default of NetHack-specific binary tile data
isn't directly editable with image editing tools.
Also show in the #version info if xpm and graphic rip are enabled.
Fix lev_comp's variable argument usage by changing it to make
add_opvars() expect an int rather than a long when given the "i"
indicator, and add "l" for really passing a long. The ints are
conveted to longs when setting up the interpreter. I think I changed
just about all the integer opvars to int, although there is one use
of "l" in lev_main.c just to make sure it works. There could be
arguments that really do need to be 'long'; if so, the add_opvars()
calls for them will have to have its indicator string updated and
possibly add or remove some casts.
There's a lot of reformatting included but it's not consistent about
tab replacement. Some of the changes are due to renaming long-named
'variable_definitions' to 'vardefs' to shorten a bunch of lines.
Updated sys/share/*_yacc.c will be checked in separately. The ones
currently in the repository won't work with patched lev_main.c due to
that renamed variable.
On Windows, if you build without STATUS_HILITES defined,
you'll be greeted by the following barrage of errors when
you start the game.
On Windows, use makedefs to detect that STATUS_HILITES
isn't defined, and comment out the offending lines in
the sample config file.
Errors received before this change:
OPTIONS=statushilites
* Line 197: 'statushilites' is not supported.
OPTIONS=hilite_status:hitpoints/100%/gray&normal
* Line 200: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<100%/green&normal
* Line 201: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<66%/yellow&normal
* Line 202: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<50%/orange&normal
* Line 203: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<33%/red&bold
* Line 204: 'hilite_status' is not supported.
OPTIONS=hilite_status:hitpoints/<15%/red&inverse
* Line 205: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/100%/gray&normal
* Line 208: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<100%/green&normal
* Line 209: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<66%/yellow&normal
* Line 210: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<50%/orange&normal
* Line 211: 'hilite_status' is not supported.
OPTIONS=hilite_status:power/<33%/red&bold
* Line 212: 'hilite_status' is not supported.
OPTIONS=hilite_status:cap/burdened/yellow/stressed/orange/strained/red&bold/ove
rtaxed/red&inverse/overloaded/red&inverse&blink
* Line 215: 'hilite_status' is not supported.
OPTIONS=hilite_status:hunger/satiated/yellow/hungry/orange/weak/red&bold/fainti
ng/red&inverse/fainted/red&inverse&blink
* Line 218: 'hilite_status' is not supported.
Hit <Enter> to continue.
Moved the code page 437 mapping table to winnt.c so that it could be
used in window and console clients.
Added check that fonts support unicode values we use from code page 437.
Use unicode to draw text if font supports it otherwise use ASCII.
mons[].difficulty takes over for monstr[]
Invoking "makedefs -m" gives a deprecation message; it is also included
in the (now mostly empty) monstr.c.
Ports should now remove "makedefs -m" from their build procedures but this
commit does not include that change.
Incorporate some git information into NetHack so that it
is potentially visible to a player. That's useful when
collecting details about the version that they are
running and, if the gitinfo is present, it can tie the
code to a specific git commit in the repository.
This modifies 'makedefs -v' to check for the presence of a data file
called dat/gitinfo.txt and if it is there, parse out its
contents, then write additional lines to include/date.h beyond
what 'makedefs -v' was previously putting in there, similar to
this sample:
#define NETHACK_GIT_SHA "0c84e564c78e2024e562d39539376ce2e21eec8e"
#define NETHACK_GIT_BRANCH "NetHack-3.6.0"
The contents of an appropriate dat/gitinfo.txt are as follows,
and trailing/leading whitespace is not significant:
githash = 0c84e564c78e2024e562d39539376ce2e21eec8e
gitbranch = NetHack-3.6.0
It also adjusts the contents of the 'v' version information to
include the additional git info when available.
Also adds some hooks DEVEL/hooksdir and a perl file to DEVEL
for simplifying and automating the deposit of dat/gitinfo.txt
so that it generally reflects the most current git commit.
DEVEL/gitinfo.pl can be used to build dat/gitinfo.txt at any
time without doing a commit, merge, or checkout.
perl DEVEL/gitinfo.pl
command line --version and -version support
To complement the extra information being provided in the
version by the 'v' command, this also adds support for the
following new command line arguments:
--version
-version Output the NetHack version string then exit.
--version:paste Output the NetHack version string and also copy it to
-version:paste the platform's paste buffer for insertion somewhere,
then exit.
If the paste variation of -version is requested on a platform that
hasn't incorporated any support for the capability, it will deliver
the version info then an error message, prior to exiting.
To support the extended -version:paste variation, a port needs to:
- provide a port-specific routine to perform
the paste buffer copy in a port code file.
- #define RUNTIME_PASTEBUF_SUPPORT in the include/portconf.h header file.
--skeleton--
void port_insert_pastebuf(buf)
char *buf;
{
/* insert code to copy the version info from buf into
platform's paste buffer in a supported way */
}
macosx and Windows have both added support for RUNTIME_PASTEBUF_SUPPORT
Apply user-contributed patch to make do_vision() handle FILE_PREFIX
correctly. It was putting that value into the filename buffer, then
overwriting it with the ordinary filename instead of appending.
Deletion of just-made vis_tab.h when creation of vis_tab.c fails would
have failed too if FILE_PREFIX had been working.
The patch was against 3.4.3 and didn't apply cleanly to current code,
but it is a staightforward fix, although the file deletion case was
buggy (failed to clear "vis_tab.c" from buffer before reconstructing
"vis_tab.h" via appending stuff). FILE_PREFIX seems to be Amiga-only
so I've only tested the usual case where it isn't defined.
I've sometimes seen
, and basic NetHack features.
as the last line of the features section from '#version'. I thought
it was due to the way feature phrases were split into individual words
by makedefs, but it turned out to be due to inserting pattern matching
method at run-time. That dynamic options update had a second problem:
if the final phrase "and basic NetHack features" was split across two
lines, the run-time substitution didn't find it and the pattern matching
entry ended up being left out. This fixes both problems, but if future
dynamic entries become more complex, the phrase-splitting/word-wrapping
being done by makedefs may need to be moved into nethack.
Also, add entries for XLOGFILE and PANICLOG to makedefs' options and
re-order a couple of existing ones alphabetically (a failry hopeless
endeavor).
Files modified:
include/tradstdc.h, sp_lev.h, system.h
util/lev_main.c
Silence a bunch of warnings generated by recent gcc which weren't there
with whatever version I had when 3.6.0 was being readied for release.
For lev_main, there were two basic types: not enough arguments in calls
to lc_pline, lc_warning, and lc_error (since we weren't passing dummy
arguments as is done for add_opvars), and conversion from 'int' or
narrower to 'char *' (from -Wint-to-pointer-cast, which either wasn't
there yet in the older gcc, or wasn't included in -Wall back then).
[Note that for any configuration decrepit enough to actually need
USE_OLDARGS, such conversions will either work fine or else nethack
simply won't be viable.]
src/pline.c generates a bunch of warnings (for USE_OLDARGS). The fix
for that will be (2 of 2).
To test, instead of mucking about with CFLAGS or sys/unix/hints, I've
been temporarily adding unconditional
|#undef USE_STDARG
|#undef USE_VARARGS
|#define USE_OLDARGS
to the end of config1.h and then doing my normal build--which is why
-Wall (or possibly -W) is drawing -Wint-to-pointer-cast warnings.
Change lev_comp's add_opvars() to be like pline(), where there's a
single visible opening brace and a second one hidden in VA_DECL2
that introduces a nested block, plus a single visible closing brace
with a hidden one in VA_END() to close the nested block. This
addresses the erroneous report (sent directly to devteam, so no #H
number, subject "missing '{' in util/lev_main.c:634") that the code
for !USE_STDARG/!USE_VARARGS in add_opvars() wouldn't compile.
Also, fix the part of "#H5778: file descriptor leaks" dealing with
util/recover.c -- an open file not being closed after various errors.
I didn't take responsibility for this entry in the bugzilla list
since the report includes similar problems in other code that's not
addressed here.
And a blast from the past: some reformatting fixups in recover.c.
The most interesting bit is for a block of dead code....
Having selectable base indexes for the monster list doesn't seem
likely to be needed in the future any more, now that the code for
the monster list is stable. Additionally, the functionality in
question has bitrotted heavily (e.g. many "loops over all
permonsts" start at a hardcoded 0, which wouldn't work with a
1-indexed monster list). As a result, removing the relevant code
in makedefs makes it clearer what can and can't be assumed about
the code, reducing the risk of bugs in the future.
Thanks to FIQ for mentioning that this could be an issue.
