This is better placement for making the original
engraving vanish when told that it vanishes;
helps to ensure that it isn't showing for any
next steps.
also, a warning bit
During a restore from a savefiles is not the only
time that levels are processed by getlev() in NetHack.
They are read back in as the hero moves up and down
between levels and dungeons.
The previous fix checked for program_state.beyond_savefile_load,
but once set, that remains static through level changes.
It would be better to check the status of the level
being read, because those operations do placements as well.
Add the following:
struct levelstatus level_status;
level_status.making - in the midst of makelevel processing
level_status.loading - in the midst of loading a level via getlev()
level_status.ready - the level is fully ready
(all 3 of the above status settings are mutually exclusive)
level_status.shkready - the level processing is far enough
along to allow shop keeper tests and actions
This also relocates the find_lev_obj() call in getlev() down several
lines, so that it falls after any set_residency() calls, so that it
has a better chance of carrying out what it was intending to do with
the shop_keeper() checks made by its subfunctions.
In SELECTSAVE implementations, out of date savefiles in the
tree were triggering error messages to the user during the
building of the pick list. The file with the error never
ended up on the pick list, or got removed, so the error was
perpetual on every SELECTSAVE startup.
This passes the UTD_QUIETLY flag down the the small set of
callers involved, so that when it was received by uptodate(),
it went about its verification work quietly.
The terminfo entries from the standard ncurses distribution have
peculiar settings for entries supporting 24 bit colors. The direct
entries mix indexed and RGB values into an incompatible mess.
This commit adds a simple workaround for the tty port. Colors are
initialised as if only 8 ANSI colors are available. This does not
affect color customisation from the symsets.
The curses port is affected as well. But I am not yet comfortable to
refactor a large part of the code for an absolute edge case.
- cmap_offset was calculated on every compose_glyph_name() call;
calculate it once with a static function.
- Drop parse_id's G_ auto-populate: an unbracketed lookup allocated
the index with no matching free. Linear-scan instead when absent.
- compose_glyph_name: require bufsz >= BUFSZ, build names with
bounded Snprintf instead of Strcpy/Strcat, drop the dead memchr.
- parse_id's permonst scan used i <= pm_count, reading one past the
SYM_MON block (S_nothing) and matching it as a monster; use <.
- Drop a stale NO_GLYPH empty-bucket comment from the open-addressed
table.
The directories and permissions portion of the linux.500 and macOS.500
hints files and their included files has been consolidated to
dirs-perms.500.
The builder can edit that one file now, to identify
the folders that will be utilised as part of the build.
Alternatively, you can set those folders and permissions in a
make.perms file in the top of the NetHack folder tree and
they should take precedence over the ones in dirs-perms.500
because dirs-perms.500 uses '?=' variable assignment, which
means "set the value of the variable if no value has been set."
* NOTE: BUILD CHANGE *
This also makes WANT_SOURCE_INSTALL=1 the default over
WANT_SHARED_INSTALL=1, if neither is explicitly set.
The new default is the safer and less-impacting default,
but it will change where things get installed over earlier
Makefile builds. You can be explicit with WANT_SHARED_INSTALL=1
in your make command to get that..
These are the differences between the two:
make WANT_SHARED_INSTALL=1 Place the results of the install/update portion
of the build into a shared area on a multiuser
system.
make WANT_SOURCE_INSTALL=1 Place the results of the install/update portion
of the build into a subfolder of the source
tree, rather than in a system-wide shared area.
Also note that the macOS hints file behaves slightly differntly depending
on whether WANT_SOURCE_INSTALL=1 was set versus letting it be the default.
That's not new, it behaved that way before.
Be able to carry out uplifts during minor release
lifetimes.
Document a way to be able to uplift struct content
without incrementing EDITLEVEL and breaking existing savefiles.
Use the mechanics outlined to uplift the contents instead, where
it is feasible to do so. The uplift is currently one-way only. An
uplifted savefile cannot be used with an earlier build of NetHack
, one built with a lower SAVEFILE_REVISION_LEVEL, than the one which
wrote the savefile.
The final byte (byte 79) of the 80 critical bytes in the savefile,
of which 10 are reserved for future expansion and not currently
used, will now be used for holding the savefile revision level
(SAVEFILE_REVISION_LEVEL in include/patchlevel.h) at the time
the savefile was written.
That leaves 9 of the bytes available for future use.
The previous rotate-1-xor put consecutive characters' bits in
adjacent positions, so short similar names like fox/bat or
jaguar/lichen collided -- 164 colliding buckets across the 9577
named glyphs. Rotate-5 spreads each character across a 5-bit
window: zero true collisions, one m68k ROL.L, no multiplication.
The 16 remaining same-hash buckets are name duplicates from a
separate compose_glyph_name bug, addressed by its own fix.
parse_id's glyph_is_object branch only emitted the "piletop_" prefix
when glyph_is_normal_piletop_obj(glyph) was true. Piletop-generic
objects (the GLYPH_OBJ_PILETOP_OFF + 1 .. + LAST_GENERIC range) hit
glyph_is_piletop_generic_obj() instead and got no prefix, so they
produced the same canonical name as their non-piletop generic
counterparts.
For example glyph 3449 (GLYPH_OBJ_OFF + GENERIC_STRANGE) and glyph
7993 (GLYPH_OBJ_PILETOP_OFF + GENERIC_STRANGE) both yielded
"G_generic_strange". 14 such pairs exist; the piletop variant is
unreachable by name from nethackrc, and the runtime hashtable's
"assume no id occurs twice" populate loop silently dropped them.
Emit "piletop_" for both piletop predicates so each glyph gets a
distinct canonical name. --dumpglyphnames now shows the 14
"G_piletop_generic_*" entries (and the count goes from 9577 to 9591;
the existing off-by-one in glyph_is_normal_piletop_obj still hides
slot GLYPH_OBJ_PILETOP_OFF + FIRST_OBJECT - 1, which is addressed by
its own fix).
The open-addressed glyphname_hashtable stored each canonical
"G_xxx" name as a dupstr'd string in its bucket: ~9577 small heap
allocations and ~290 KB of resident name strings, on top of ~256 KB
of 32768-bucket scaffolding kept at <50% load for probe performance.
On classic Mac OS the populate cost (quadratic small-allocation in a
fragmented Memory Manager heap) dominated startup time -- many
seconds on an SE/30 -- and ~800 KB resident is meaningful on the
small machines the port targets.
Switch to a sorted (hash, glyph) index sized exactly to the number
of named glyphs:
struct glyphname_hashtable_entry_t {
uint32 hash;
int glyphnum;
};
populate_glyphname_hashtable() allocates one block of MAX_GLYPH
entries (no per-name strings), fills it via compose_glyph_name() +
glyph_hash(), and qsort()s ascending by hash. Lookup binary-searches
the hash column, then walks any equal-hash neighbours verifying each
candidate by reconstructing its canonical name and strcmpi'ing it
back -- collisions are rare with 9577 uniformly-distributed 32-bit
hashes.
Other changes that fall out:
* Extract compose_glyph_name() from parse_id's bulk-iteration switch
so it is the single source of truth for "glyph number -> canonical
name". Called by find_glyph_in_hashtable for collision
verification, by populate_glyphname_hashtable, by the
--dumpglyphnames path, and by wizcustom_glyphnames.
* empty_glyphname_hashtable() reduces to free(ptr); no per-entry
strings to release.
* Drop find_glyphname_in_hashtable_by_glyphnum (no longer used --
wizcustom_glyphnames iterates compose_glyph_name directly).
* Drop the res_fill_hashtable parse_id mode; populate iterates
directly.
Memory drops from ~800 KB to ~75 KB. One allocation instead of
~9578. Lookup goes from O(1) to O(log N) but N ~ 9577 means ~14
comparisons per probe -- well under what the upstream cache ever
cost in practice.
Function names (populate_glyphname_hashtable, etc.) are kept for
extern.h compatibility; the data structure is now a sorted index,
"hashtable" in the names is historical.
--dumpglyphnames output is byte-identical.
glyph_is_normal_object includes its boundary slot
GLYPH_OBJ_OFF + FIRST_OBJECT - 1 via >=, but its piletop sibling
glyph_is_normal_piletop_obj used > and excluded the matching
GLYPH_OBJ_PILETOP_OFF + FIRST_OBJECT - 1 slot. That leaves
exactly one glyph (the would-be G_piletop_generic_venom) matching
neither the piletop-generic nor the piletop-normal predicate, so
parse_id never builds a name for it and --dumpglyphnames emits a
blank line for the slot.
Change > to >= so the two ranges are inclusive on the same side.
--dumpglyphnames now produces (8009) G_piletop_generic_venom.
Pasi Kallinen