When a monster is drawn on the map, remove any "remembered, unseen
monster" glyph being shown at the same spot. Clairvoyance shows
all monsters in vicinty, then ones which can't be seen are replaced
with the 'I' glyph (which is on the object layer or the display,
not the monster layer show is subject to different update behavior).
But subsequent monster refresh didn't get rid of it when a sensed
monster was displayed over it. (3.6.1 included a similar fix for
warned-of monsters.)
Also during clairvoyance, don't draw an 'I' at a spot that will
immediately be refreshed with a monster because 'I' clobbers any
remembered object at the same location.
This fixes the issue brought up at https://www.reddit.com/r/nethack/comments/dv3pae/curses_and_the_numberpad/?st=k3hgply6&sh=dbc2bf7d .
I don't know why the "regular" (tty) method doesn't seem to work for him,
but I'm going to chalk it up to a PDCurses oddity. What I do know, however,
is that the alternate method I added a year ago or maybe longer, that allows
numpad usage even with number_pad:0 (to retain the default keybindings in case
an user is used to them, while keeping number pad behaviour making sense,
similar to NetHack4+friends) was only partially implemented, for some reason.
This adds the rest of the keys, meaning that this means of key interpretation
should be more realible. KEY_A2/B1/B3/C2 are not standard keys in the Curses
documentation, and is thus behind an ifdef -- but PDCurses, amongst other
implementations, makes use of them.
As a side effect, Home/End/PgUp/PgDn are now interpreted as diagonal movement,
since some terminals interpret number_pad keys that way. I do not consider this
a problem since they went unused in normal gameplay anyway (This does not
interfere with menus or similar).
A reddit thread about an unaligned altar in an aligned temple was
a tipoff that mimics posing as altars didn't have any particular
alignment. The look-at code was misusing an operloaded field of the
underlying terrain. Pick an alignment at random when taking on the
appearance of an altar, store it in the mimic's mon->mextra->mcorpsenm
field, and have look-at use that.
Also, dropping a ring of polymorph into a sink can transform it, and
one possible outcome is an altar. In this case, the alignment is
part of the location's topology, but code setting that up was using
Align2amask(rn2(foo)). That's a macro which evaluates its argument
more than once. The first evaluation was effectively a no-op. If
the second evaluation picked lawful then the result was lawful as
intended. But if the second picked non-lawful and the third picked
lawful, the result would end up as none-of-the-above (a value of 3
when it needs to be a single-bit mask of 1, 2, or 4).
This is similar to the helm of opposite alignment case fixed some
time ago. Deferring the setting of foo->known until an item is fully
worn (because it used to get set earlier but gave away information if
the wear operation was interrupted) didn't take into account that foo
might end up Null in various circumstances. So Boots_on() needs to
validate uarmf before setting uarmf->known in case putting on boots
of levitation while on a sink caused them to come right back off.
I put similar validation into all foo_on() just in case (as far as
I'm aware, only Boots_on() and Helmet_on() actually need that).
I think the previous expression would allow moving (via swapping
places) from a pool to solid rock or closed door which was not what
was intended (but moot since there aren't any pools on the Astral
level). This revised expression does what is intended: can only
swap to a pool location if already located in/over (the Riders fly?
they should probably be non-breathing) another pool.
Don't let Riders swap places with something (fog or ooze, perhaps)
located at a closed door spot because if it gets killed there, there
won't be any corpse and it will stop auto-reviving.
Just avoid moving to spots where mondied() won't place a corpse
instead of worrying about whether a bargethrough creature (if there
ever are any besides the Riders) might be able to survive at the
destination (so ignore pass-walls, door-opening, swimming, &c).
Noticed while testing something: hero drank a potion of see invisible
and nearby invisible monster could now be seen--in theory--but I was
asked what to call the potion while the updated map was buffered. So
I didn't see the invisible monster until after naming the potion.
pline() flushes buffered map updates, but getlin() doesn't. I didn't
change that, but I've made docall() do so since the updated map may
make a difference in what the player can tell about whatever is being
'called'.
Fix the issue where a hallucinatory monster name which begins with
a slash is having that stripped off as if it was a gendor and/or
personal-name flag.
The main issue was pronouns ignoring hallucination and this doesn't
attempt to address that.
Also, add new hallucinatory name "leathery-winged avian" which has
been lurking for a while.
Provide a little more information when dumplog is unavailable.
While testing various permutations, I encountered a couple of
problems with conditionally declared variables.
The Windows data file path has to be constructed because
Windows defines VERSION_IN_DLB_FILENAME.
Keep the personal configuration file details as the last
information displayed.
Have the --showpaths feedback mention whether dlb is in use or not,
and show the container file name(s) when it is. Users of prebuilt
binaries or who build with a hints file instead of picking and
choosing things in config.h might not know, and vms (if it ever
catches up with --showpaths) uses a different container name from
everybody else ("nh-data.dlb" instead of "nhdat").
All Is_*_level tests during early startup would test as true until
dungeon_topology was initialized in a new game or restored from
a save file. That could result in some unexpected code paths being
taken.
The mapglyph() change made a variable obsolete but it got left in
(idx = SYM_PET_OVERRIDE...). Take it out and fix up the formatting
for the block of code that had it.
remove_region() calls newsym() when removing gas clouds, but when
newsym() checked whether it was updating a gas cloud location it
always got a false 'yes' because the region hadn't been removed yet.
Fixing this didn't seem to make any observable difference so it must
be followed fairly rapidly by a full vision recalc.
Don't show the gas cloud glyph at locations where monsters can be
sensed (telepathy, warning, extended detection). It will work
better when/if vision of gas cloud locations gets fixed. (Such
clouds behave as the hero can see into them, so warning doesn't
have any unseen monsters to show unless they're unseen for some
reason other than the gas cloud.)
Region processing does a lot of looping--when there are actually
regions present--and calls functions in those loops which do more
looping of their own. This moves some of the simpler tests so that
they get done sooner and can avoid some of those function calls.
I was hoping that it would speed up the turn cycle on the Plane of
Fire where the spontaneous irregularly shaped fumaroles are composed
of a lot of small regions but I don't think there's any noticeable
difference.
In process of doing that, I discovered a bug (no doubt copy+paste
which escaped an intended update) with monster handling. The check
for whether a monster is entering a region depends upon whether the
hero is in that same region rather than whether the monster is
already inside. So a monster can enter a region--or have a moving
one enclose it--with impunity if the hero is already in that region.
Once the hero moves out of it, the monster will finally enter it.
'orient' is the name of an enum defined in wincurs.h so don't use it
as a variable name in cursstat.c. My compiler didn't complain using
'-Wshadow' but apparently some other one does.
Make the same change in the dead code located in the second half of
that file, plus a couple of formatting tweaks.
