Avoids any need for MONITOR_HEAP hackery. Link src/alloc.o and
util/panic.o into util/makedefs.
When replacing the realloc() call in fgetline(), I noticed that
fgetline() would miss the last line of an input file if it lacked a
terminating newline. This was hard to test because OSX seems to be
supplying one when it is missing (VMS would do that too). I had to
modify epitaph (my test bed) to take off the final character, run
'makedefs -s' under debugger control and strip away final newline
that stdio added back, build new nhdat and move it into place, then
run nethack and execute #wizrumorcheck all multiple times before
the fix and once more after it. Much effort for little gain...
Plus some of the recent reformatting: indent labels one space,
replace tabs with spaces, shorten or split wide lines.
I tried building with MONITOR_HEAP defined for the first time in a
while. It wasn't pretty.
date.c was calling libc's strdup() instead of our dupstr() so alloc.c
wasn't tracking those allocations when/if MONITOR_HEAP is enabled.
Then it called free() which is actually a call to nhfree() in that
situation. If the file of allocations and releases was subsequently
fed to heaputil, it would complain about freeing pointers that hadn't
been allocated.
Worse, makedefs and tilemap wouldn't link. For MONITOR_HEAP,
makedefs was undefining free() in order to avoid nhfree() but it now
links with date.o so got nhfree() calls anyway. And it wouldn't link
because that routine isn't available without alloc.o. tilemap
doesn't link with date.o but it does call malloc() and free() and it
wasn't undefining free(), so looked for nhfree() when linking and got
the same no-such-routine failure.
Simplify a glob handling bit in a recent shrink_glob change used when
catching for lost time upon returning to a level.
Revise a clumsily worded fixes entry.
Fix a comment typo in makedefs that's been there for a bunch of years
now. It's been within the diff context for several recent patches
and I still hadn't noticed it until just now.
Solve the uneven distribution situation that has been present for
picking random rumors for a long time and for random engravings,
epitaphs, and hallucinatory monster names since 3.6.0. This relies
on the previous partial solution where short lines have been padded
to a longer length. When that length is N and random seek lands in
a long line of length L, retry if the position is in the first L-N
characters. Put differently, it if takes more than N characters to
reach the next newline, reject that random seek and try again. This
effectively makes long lines behave as if they had the same length
of N as the short lines have been padded to and when all lines are
the same length, all entries have the same chance to be chosen.
While testing 'the("Capitalized Hallucinatory Monster")' I noticed that
some hallucinatory monsters showed up more often than others. When
the random engravings, epitaphs, and bogus monsters were converted from
hard-coded arrays to data files accessed by random seek (3.6.0), they
became subject to the same distribution irregularites that rumors suffer
from. The chance that an entry will be chosen depends upon the chance
that a random seek will hit somewhere in the line which precedes it, so
entries that follow long lines are more likely to be chosen and entries
that follow short lines are less likely. We improved that for rumors
by having makedefs pad the shortest lines. Distribution still isn't
uniform but is much better than it was (and could be further improved
with a longer padding length at the cost of making data files bigger so
possibly slower to access; both overall size and access speed mattered
back when floppy discs were supported but are probably irrelevant now).
Start doing the same thing for the newer files: pad the shortest lines
to increase the chance that seek will find them. The tradeoff is that
the data files become bigger. Rumors, engravings, and epitaphs lines
are all at least 60 characters now; bogus monsters are at least 20.
These are the data file sizes I see (in bytes: old, new; padding for
rumors was already in use so its size hasn't changed):
bogusmon 4449 7211
engrave 1326 2894
epitaph 14159 24075
rumors 49173 49173
The only place that padding is noticeable in-game is #wizrumorcheck.
whitelist the valid cases showing up
If an earlier version of clang is showing more cases (particularly
if they don't make sense), the re-enabling of the warning in
sys/unix/hints/include/compiler.2020 can be made clang-version
specific instead. I had no way to test earlier versions.
makedefs.c:1560:5: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation]
" ",
^
makedefs.c:1559:5: note: place parentheses around the string literal to silence warning
"currently available will not suffice for proving that P != NP or "
^
1 warning generated.
This evolves and hopefully eases the game-build requirements by
removing game-compile dependencies on any header files generated
by the makedefs utility, including:
date.h dependency and its inclusion is removed and comparable functionality
is produced at runtime via new file src/date.c.
pm.h dependency and its inclusion is removed and comparable functionality is
produced by moving the monster definitions from monst.c into new header
file called monsters.h and altering them slightly. The former pm.h header
file #define PM_ values are now replaced with appropriate emitted enum
entries during the compiler preprocessing.
onames.h dependency and its inclusion is removed and comparable functionality
is produced by moving the object definitions from objects.c into new header
file called objects.h and altering them slightly. The former onames.h header
file #define values are now replaced with appropriate emitted enum entries
during the compiler preprocessing.
artilist.h has been slightly altered, and the former onames.h artifact-related
header file #define ART_ values are now replaced with appropriate emitted enum
entries during the compiler preprocessing.
makedefs can still produce date.h (makedefs -v), pm.h (makedefs -p), and
onames.h (makedefs -o) for reference purposes. They won't be used during
the compiler.
The other uses for makedefs remain. They are used to prepare external
file content that the game utilizes, not prerequisite code for the
compile:
makedefs -d (database)
makedefs -r (rumors)
makedefs -h (oracles)
makedefs -s (epitaphs, engravings, bogusmons)
date.c
Pull the code for date/time stamping from mdlib.c into date.c.
Set date.o to be dependent on source files, header files, and .o files
so that date.o is rebuilt from date.c when any of those changes, thus
ensuring an accurate date/time stamp. It also includes git sha
functionality formerly done by makedefs writing #define directives
into include/date.h. For unix it passes the git info on
the compile line for date.c (via sys/unix/hints/linux.2020, macOS.2020)
nethack --dumpenums (optional, but on by default)
Allow developer to obtain some internal enum values from NetHack
without having to resort to an external utility such as
makedefs.
Uncomment #define NODUMPENUMS in config.h to disable this.
The updates to sys/windows/Makefile.gcc have not been tested yet.
There were multiple symbol-related lists that had to be kept
in sync in various places.
Consolidate some of that into a single new file
defsym.h
with a set of morphing macros that can be custom-called from
the various places that use the sym info without maintaining
multiple occurrences. Most maintenance can be done there.
Rename monsym.h to sym.h since it looks after some
symbols not related to monsters now too.
The defsym.h header file is included in multiple places to
produce different code depending on its use and the controlling
macro definitions in place prior to including it.
Its purpose is to have a definitive source for
pchar, objclass and mon symbol maintenance.
The controlling macros used to morph the resulting code are
used in these places:
- in include/sym.h for enums of some S_ symbol values
(define PCHAR_ENUM, MONSYMS_ENUM prior to #include defsym.h)
- in include/objclass.h for enums of some S_ symbol values
(define OBJCLASS_ENUM prior to #include defsym.h)
- in src/symbols.c for parsing S_ entries in config files
(define PCHAR_PARSE, MONSYMS_PARSE, OBJCLASS_PARSE prior
to #include defsym.h)
- in src/drawing.c for initializing some data structures/arrays
(define PCHAR_DRAWING, MONSYMS_DRAWING, OBJCLASS_DRAWING prior
to #include defsym.h)
- in win/share/tilemap.c for processing a tile file
(define PCHAR_TILES prior to #include defsym.h).
rename sys/winnt to sys/windows
move vs (visual studio) folder out of win/win32 and into sys/windows
rename include/ntconf.h to include/windconf.h
rename winnt.c to windsys.c
place visual studio projects into individual subfolders.
This will hopefully resolve GitHub issue #484 as well.
Whitelist all the verified existing triggers:
makedefs.c: In function ‘name_file’
attrib.c: one compiler balks at a ? b : c for fmtstring
cmd.c: In function ‘extcmd_via_menu’
cmd.c: In function ‘wiz_levltyp_legend’
do.c: In function ‘goto_level’
do_name.c: In function ‘coord_desc’
dungeon.c: In function ‘overview_stats’
eat.c: one compiler balks at a ? b : c for fmtstring
end.c: one compiler balks at a ? b : c for fmtstring
engrave.c: In function ‘engr_stats’
hack:c one compiler balks at a ? b : c for fmtstring
hacklib.c: one compiler balks at a ? b : c for fmtstring
insight.c: one compiler balks at a ? b : c for fmtstring
invent.c: In function ‘let_to_name’
light.c: In function ‘light_stats’
mhitm.c: In function ‘missmm’
options.c: In function ‘handler_symset’
options.c: In function ‘basic_menu_colors’
options.c: In function ‘optfn_o_autopickup_exceptions’
options.c: In function ‘optfn_o_menu_colors’
options.c: In function ‘optfn_o_message_types’
options.c: In function ‘optfn_o_status_cond’
options.c: In function ‘optfn_o_status_hilites’
options.c: In function ‘doset’
options.c: In function ‘doset_add_menu’
options.c: In function ‘show_menu_controls’
options.c: In function ‘handle_add_list_remove’
pager.c: In function ‘do_supplemental_info’
pager.c: In function ‘dohelp’
region.c: In function ‘region_stats’
rumors.c: sscanf usage
sounds.c: In function ‘domonnoise’
spell.c: In function ‘dospellmenu’
timeout.c: In function ‘timer_stats’
topten.c: In function ‘outentry’, fscanf, sscanf, fprintf usage
windows.c: In function ‘genl_status_update’
zap.c: one compiler balks at a ? b : c for fmtstring
win/curses/cursstat.c: In function ‘curses_status_update’
win/tty/wintty.c: In function ‘tty_status_update’
win/win32/mswproc.c: In function ‘mswin_status_update’
Microsoft and other non-GNU compilers don't recognize gcc tricks
like /*NOTREACHED*/ to suppress individual warnings. clang recognizes most
of them because it tries to be gcc-compatible. Because of that, a lot of
potentially useful warnings have had to be completely suppressed in the
past in all source files when using the non-gcc compatible compilers.
Now that the code is C99, take advantage of a way to suppress warnings for
individual functions, a big step up from suppressing the warnings
altogether.
Unfortunately, it does require a bit of ugliness caused by the
insertion of some macros in a few spots, but I'm not aware of
a cleaner alternative that still allows warnings to be enabled
in general, while suppressing a warning for known white-listed
instances.
Prior to the warning-tiggering function, place whichever one of
the following is needed to suppress the warning being encountered:
DISABLE_WARNING_UNREACHABLE_CODE
DISABLE_WARNING_CONDEXPR_IS_CONSTANT
After the warning-triggering function, place this:
RESTORE_WARNINGS
Under the hood, the compiler-appropriate warning-disabling
mechanics involve the use of C99 _Pragma, which can be used
in macros.
For unrecognized or inappropriate compilers, or if
DISABLE_WARNING_PRAGMAS is defined, the macros expand
to nothing.
Update makdefs source and its man page.
Remove all mentions of the vision table files from:
o .gitattributes
o .gitignore
o Files
o Cross-compiling
Add a brief note in the fixes file.
add MALE, FEMALE, and gender-neutral names for individual monster species
to the mons array. The gender-neutral name (NEUTRAL) is mandatory, the
MALE and FEMALE versions are not.
replace code uses of the mname field of permonst with one of the three
potentially-available gender-specific names.
consolidate some separate mons entries that differed only by species into a
single mons entry (caveman, cavewoman and priest,priestess etc.)
consolidate several "* lord" and "* queen/* king" monst entries into
their single species, and allow both genders on some where it makes some
sense (there is probably more work and cleanup to come out of this at some
point, and the chosen gender-neutral name variations are not cast in stone
if someone has better suggestions).
related function or macro additions:
pmname(pm, gender) to get the gender variation of the permonst name. It
guards against monsters that haven't got anything except NEUTRAL naming
and falls back to the NEUTRAL version if FEMALE and MALE versions are
missing.
Ugender to obtain the current hero gender.
Mgender(mtmp) to obtain the gender of a monster
While the code can safely refer directly to pmnames[NEUTRAL] safely in the
code because it always exists, the other two (pmnames[MALE] and
pmnames[FEMALE] may not exist so use:
pmname(ptr, gidx)
where -ptr is a permonst *
-gidx is an index into the pmnames array field of the
permonst struct
pmname() checks for a valid index and checks for null-pointers for
pmnames[MALE] and pmnames[FEMALE], and will fall back to pmnames[NEUTRAL] if
the pointer requested if the requested variation is unavailable, or if the
gidx is out-of-range.
Allow code to specify makemon flags to request female or male (via MM_MALE
and MM_FEMALE flags respectively)to makedefs, since the species alone doesn't
distinguish male/female anymore. Specifying MM_MALE or MM_FEMALE won't
override the pm M2_MALE and M2_FEMALE flags on a mons[] entry.
male and female tiles have been added to win/share/monsters.txt.
The majority are duplicated placeholders except for those that were
separate mons entries before. Perhaps someone will contribute artwork in the
future to make the male and female variations visually distinguishable.
tilemapping via has the MALE tile indexes in the glyph2tile[]
array produced at build time. If a window port has information that the
FEMALE tile is required, it just has to increment the index returned
from the glyph2tile[] array by 1.
statues already preserved gender of the monster through STATUE_FEMALE
and STATUE_MALE, so ensure that pmnames takes that into consideration.
I expect some refinement will be required after broad play-testing puts it to
the test.
consolidate caveman,cavewoman and priest,priestess monst.c entries etc
This commit will require a bump of editlevel in patchlevel.h because it alters
the index numbers of the monsters due to the consolidation of some. Those
index numbers are saved in some other structures, even though the mons[] array
itself is not part of the savefile.
Window Port Interface Change
Also add a parameter to print_glyph to convey additional information beyond
the glyph to the window ports. Every single window port was calling back to
mapglyph for the information anyway, so just included it in the interface and
produce the information right in the display core.
The mapglyph() function uses will be eliminated, although there are still some
in the code yet to be dealt with.
win32, tty, x11, Qt, msdos window ports have all had adjustments done to
utilize the new parameter instead of calling mapglyph, but some of those
window ports have not been thoroughly tested since the changes.
Interface change additional info:
print_glyph(window, x, y, glyph, bkglyph, *glyphmod)
-- Print the glyph at (x,y) on the given window. Glyphs are
integers at the interface, mapped to whatever the window-
port wants (symbol, font, color, attributes, ...there's
a 1-1 map between glyphs and distinct things on the map).
-- bkglyph is a background glyph for potential use by some
graphical or tiled environments to allow the depiction
to fall against a background consistent with the grid
around x,y. If bkglyph is NO_GLYPH, then the parameter
should be ignored (do nothing with it).
-- glyphmod provides extended information about the glyph
that window ports can use to enhance the display in
various ways.
unsigned int glyphmod[NUM_GLYPHMOD]
where:
glyphmod[GM_TTYCHAR] is the text characters associated
with the original NetHack display.
glyphmod[GM_FLAGS] are the special flags that denote
additional information that window
ports can use.
glyphmod[GM_COLOR] is the text character
color associated with the original
NetHack display.
Support for including the glyphmod info in the display glyph buffer
alongside the glyph itself was added and is the default operation.
That can be turned off by defining UNBUFFERED_GLYPHMOD at compile time.
With UNBUFFERED_GLYPHMOD operation, a call will be placed to map_glyphmod()
immediately prior to every print_glyph() call.
In file included from makedefs.c:213:0:
../src/mdlib.c: In function ‘runtime_info_init’:
../src/mdlib.c:808:12: warning: variable ‘timeresult’ set but not used [-Wunused-but-set-variable]
time_t timeresult;
^~~~~~~~~~
makedefs.c: In function ‘do_date’:
makedefs.c:1140:16: warning: unused variable ‘ind’ [-Wunused-variable]
const char ind[] = " ";
^~~
makedefs.c:1139:9: warning: unused variable ‘steps’ [-Wunused-variable]
int steps = 0;
^~~~~
makedefs.c: In function ‘do_monstr’:
makedefs.c:1934:12: warning: variable ‘j’ set but not used [-Wunused-but-set-variable]
int i, j;
^
roll parts of pr385 into source tree
This does not take the PR as is.
Unlike the PR, this streamlines and minimizes the integration somewhat:
- use hints/include mechanism instead of creating alternative
Makefile.dat, Makefile.src, Makefile.top, Makefile.utl in sys/lib;
those would have been a maintenance nightmare.
- don't have alternative mkmkfile.sh and setup.sh in sys/lib.
- sys/lib/libnethackmain.c differed from sys/unix/unixmain.c by
very little, so just place a small bit of conditional code at the
top of sys/unix/unixmain.c instead.
- changed the conditional code bits from __EMSCRIPTEN__ to
CROSS_TO_WASM.
- You should be able to build the wasm result by:
cd sys/unix ; sh setup.sh hints/linux.2020 ; cd ../..
make fetch-lua (<-one time)
make WANT_LIBNH all
- You should be able to build LIBNBH by:
cd sys/unix ; sh setup.sh hints/linux.2020 ; cd ../..
make fetch-lua (<-one time)
make CROSS_TO_WASM=1 all
As it is currently coded, winshim.c requires C99.
Update the cross-compiling doc at the top.
Remove sys/msdos/Makefile1.cross, sys/msdos/Makefile2.cross, and
sys/msdos/msdos-cross-compile.sh as they are no longer required.
Remove occurrences of CROSSCOMPILE_HOST as the host-side of a
cross-compile can be determined from:
defined(CROSSCOMPILE) && !defined(CROSSCOMPILE_TARGET)
without the additional macro.
As reported in https://github.com/NetHack/NetHack/issues/391
if make was invoked with -j, makedefs instances could end up running in
parallel and could trample on each other's grep.tmp tempory files.
Default to using mkstemp(); allow a port runtime library implementation
that lacks mkstemp() to define HAS_NO_MKSTEMP to revert to the old behaviour.
Provide a work-alike mkstemp() implementation for windows Visual Studio build
in mdlib.c so there is no requirement to define HAS_NO_MKSTEMP there.
Fixes#391
I tried wishing for "splashes of venom" but was told that no such
thing exists even though "splashs of venom" and "2 splash of venom"
both work to produce "2 splashes of venom". After the spurious
failure, retrying with EDIT_GETLIN enabled showed that "splashes"
had been singularized to "splashe" so fix that.
"2 splashes of venom" IDed to "2 uncursed blinding venoms" because
the base name omits "splash of" prefix. And due to that, explicitly
wishing for "splash of {acid,blinding} venom" didn't work either.
Change the names to include the prefix, and add a hack to makedefs
to keep generating the old macro names without the prefix. (Wishing
for "{acid,blinding} venom" still works due to post-3.6.6 changes
to " of " matching.)
Fixes#369.
Fixes#370.
The default entries inserted by makedefs -s (starting in 3.6.6,
to guard against having an empty data file which led to divide by
zero crash when nethack picked a random entry) lacked a terminating
newline so the first entry from the file (for the usual case when
that data file wasn't empty) got implicitly concatenated to it.
If the first entry got chosen during play, the initial portion
corresponding to the default entry was decrypted properly but the
concatenated portion corresponding to file's first line didn't.
So gibberish was appended to default engraving or epitaph or bogus
monster; also, the input file's first line would never appear.
The newline fix in makedefs is different from pull request #370
but accomplishes the same thing.
The bulk of the patch is an enhancement to #wizrumorcheck to show
first (default inserted by makedefs), second (first in input file)
and last engravings, epitaphs, and bogusmons in addition to rumors.
The command name has become a little misleading but the limited
functionality doesn't call for separate commands.
A check into github issue 364 confirmed that
ba6edbe5dc
had incorrectly updated the bwrite sizeof entry for sysflags.
The SYSFLAGS and MFLOPPY code is all in the outdated part of the tree, so just
remove it rather than re-correct it.
Closes#364Closes#207
Have 'makedefs -m' output default mons[].difficulty values in the
stub 'monstr.c' that still gets generated for that option. It
would be better to allow specifying which monsters are of interest
but I didn't want to get bogged down by interface issues.
I needed it for mons[PM_ELF].difficulty after changing that monster's
level, so it still has a purpose. Code is from 3.4.3, reformatted
manually.
recover had deviated somewhat from NetHack in its
file expectations:
1) A couple of 3.7 fields needed to be accommodated.
2) hard-coded file size values had deviated.
The file sizes are now in an added header file named "filesize.h",
which is included at the bottom of config.h.
There will likely be another commit to write the filename size ahead
of the file name so that the precise number of characters can be read,
but since that will break existing saves, it can go in along with another
save-breaking commit.
This commit doesn't not alter savefiles written by nethack so does not
require an editlevel bump. It does alter the read-in expectation in
recover to match the game and this get recover working again.
