A pet with the hides-under attribute could hide under cursed objects
if it first moved reluctantly to their location. Also, the messages
seem contradictory:
| The cobra slithers reluctantly over a scroll labeled DUAM XNAHT.
| You see your cobra slither under a scroll labeled DUAM XNAHT.
First over, then under, but that was actually accurate; the monster
moved, then after it was on the pile it hid underneath.
Change hideunder() to not let pets hide under an object if it is
cursed or any object in its pile is cursed. Initially I was just
going to check the top item and the item directly beneath it, but
reluctance to move there extends to the whole pile so I made hiding
do so too.
Change the first message to move reluctantly "onto" an object since
"over" suggests that it has continued past the item, unless it is
actually flying or levitating so truly "over" the pile.
Crash triggered by fuzzer.
The Null value for not-hungry between "Satiated" and "Hungry" in the
array of possible hunger states caused a crash if C++ regex handling
was being used. With posixregex, it would pass benignly for tty but
crash for curses. I didn't check any other interface.
display.h -- bring an unused macro up to date
detect.c -- always call newsym() when searching or secret door
detection finds a trap rather than just when not blind
glyphs.c -- some formatting
pager.c -- lookat() behaves very strangely when single-stepping
in the debugger (gdb); this didn't help
Issue reported by ars3niy: an arrow trap covered by more than
one stack of arrows was described by farlook as "unexplored area".
Later simplified to any object pile with plain arrows on top; the
trap turned out to be irrelevant aside from producing a pile of
arrow stacks.
This problem turns out to be due to an off by 1 error introduced
into the xxx_is_piletop() macros when generic objects were added in
mid-January of last year, and plain arrow is the first real object
so suffered from the bug. Misclassifying the glyph at a specific
location also confused the #terrain command but it's the same bug.
Knowing what was wrong (map glyph was UNEXPLORED when it should
have been ARROW) wasn't sufficient to figure out the problem.
Without the simplified way of reproducing the problem, I would
never have managed to use 'git bisect' to find the offending commit
because that would have been too time consuming.
Fixes#1289
A poison gas breath attack that hits a wall would leave a 1x1 gas
cloud region at that wall spot.
Not always noticeable due to other spots along the zap path leaving
regions that blocked vision.
Changes to setuhpmax() a couple of days ago to deal with sanity_check
for "current hero health as monster better than maximum" ended up
triggering sanity_check about "current hero health better than maximum"
when gaining experience level(s) while polymorphed.
If the force_invmenu option is On for choosing an inventory item
and the set of likely candidates is only a subset of full inventory,
then "* (list everything)" is an extra menu choice. If the player
picks that, the menu is reissued showing entire inventory (with the
extra "* (list everyhing)" choice omitted this time).
When that happens, add "? (list likely candidates)" instead, so that
the menu can be toggled back to how it initially was.
If the menu allows choosing anything in inventory (the 'd' command,
for instance), it will already show full inventory and neither '*'
nor '?' gets included as helper choices.
Issue reported by ars3niy: non-fireproof water walking boots are
supposed to be destroyed if worn on lava, but a post-3.6 change
made that only happen if the hero died and left bones.
The boots remained intact if hero was fire resistant or survived
6d6 damage. Staying intact should only happen if they're fireproof.
This seems to work but each time lava_effects() gets modified it
becomes more fragile. Having deleted objects stick around doesn't
help with this problem, which is to keep an item which is being
stolen--and whose loss causes the hero to drop into lava--from
being burned up before being transferred to the thief's inventory.
Fixes#1291
timeout.c:550:1: warning: no previous prototype for ‘region_dialogue’ [-Wmissing-prototypes]
550 | region_dialogue(void)
| ^~~~~~~~~~~~~~~
../win/curses/curswins.c: In function ‘curses_destroy_win’:
../win/curses/curswins.c:202:33: warning: variable ‘dummyht’ set but not used [-Wunused-but-set-variable]
202 | int mapwidth = 0, winwidth, dummyht;
| ^~~~~~~
When hero is poly'd into a gremlin, using #monster at a fountain
location will clone a gremlin pet. Do the same at a pool location
(might not match the movie but if not, most likely because the
situation never came up). Also, do the same for #sit at either
fountain or pool.
Like stuck-in-wall, there might not be any place to move the hero
in order to escape a poison gas cloud. That could result in "fix
all troubles" becoming stuck in a loop. 3.6.something fixed the
stuck-in-wall case by temporarily conferring Passes_walls. Fix the
in-poison-region case by temporarily conferring Magical_breathing.
Not adequately tested...
I don't think that this fixes "#K4252: NH 3.7 Prayer Bug" where the
game hung during a couple out of scores of prayers. I didn't see
any other fix-trouble cases that seemed likely to remain unfixed
and end up with repair attempts retrying.
Prayer result of fix very low HP. Tricky because when poly'd,
prayer operates on both u.mhmax and regular u.uhpmax but setuhpmax()
only operates on one of the two depending on Upolyd.
being greater than u.mhmax
I think this will fix the situation where current HP as a monster
was greater than maximum HP as a monster, triggering a sanity_check
failure. No promises though.
[poisoned() needs some missing Upolyd handling.]
Starting as a pauper and executing #conduct during play reported
"you have gone without possessions", which wasn't accurate unless
your inventory remained empty from start until the time #conduct was
examined. That isn't tracked. I don't think it needs to be since
staying possessionless from start to finish is not a viable goal
unless you're on a suicide mission.
Change #conduct feedback for pauper to "you are without possessions"
if inventory is currently empty and "you started without possessions"
when it isn't.
Also, report pauper before nudist (which is enabled implicitly when
starting without any equipment). The other way around struct me as
being a bit strange, although if nudist was specified in addition
to pauper it probably makes sense.
The recently revised priestname(), which is also used for angels
since they share the " of <deity>" suffix, included a test for
'!strncmp(,"Angel ",6)', assuming it was looking at the beginning
of "Angel of <deity>". But the " of <deity>" part doesn't get
appended until later, so the test should be '!strcmp(,"Angel")'
without the trailing space.
Noticed by code inspection; I don't have a test case. Like priests,
Angels are almost always referred to as "_the_ Angel of <deity>" so
the bad "Angel " check normally wouldn't get reached.
Also, fix an unrelated indentation bit in fixes3-7-0.txt.
|You hear an priestess of Issek incant PHOL ENDE WODAN.
using "an" instead of "a" wasn't because the deity name started
with a vowel, it was because the wrong argument was being passed to
just_an() and just_an("") always yields "an" (actually "an ").
I eventually gave up trying to reproduce the message but am fairly
sure that this fixes it.
Issue reported by g-branden-robinson: vertical status panel ended
up with an extra closing paren on the energy line, and sometimes
popups left some text and/or border to the right of the map.
I haven't been able to reproduce the energy anomaly. It is possible
that it is dependent on the version of curses.
This fixes the leftover popup traces that the base window catches
(and hangs onto) when there is extra space to the right of the map.
Erasing a popup prior to deleting it suffices to make base window
forget it.
I have a more elaborate fix that covers the space to the right of
the map, when there is some, with an extra window and erases that
window when refreshing the map. It works but adds a bunch of code
that we can get by without.
Issue #1285 is still open.
I remembered some more of the light source problem that led to the
panic() call that was fixed earlier today, but I'm not sure how
accurate this new comment is. If it is accurate, the changes of
impossible() to panic() that the fix included won't necessarily
catch the old, apparently one-off, problem it describes.
Reported directly to devteam: restoring a save file which was
made while the hero was polymorphed into a light emitting monster
would trigger a panic.
This was caused by an attempt to deal with corrupted save data,
which in turn was caused by attempting to use impossible() in a
situation where the game can't reliably continue. If bad light
source data was ignored during restore, it would cause trouble
during next save.
Remove the check which was erroneously detecting invalid data
and also change two impossible() calls to panic().
Caught by 'sanity_check': hides-under monster hiding under nothing
after the glob it was under coalesced with an adjacent one. Tricky
to test because dropped, thrown, or kicked globs will always merge
with the one being hidden under. Needed to kill the type of monster
that drops the type of glob since it gets created on the floor so
is eligible to draw in the existing one.
If you used 'm #dip' to skip being asked about dipping into a
fountain, sink, or pool and go directly to being prompted for which
potion to dip something into, formatting for the thing being dipped
was skipped. If 'verbose' was On, an uninitialized buffer was
inserted into "dip [] into?" for use by getobj(). Could cause a
crash (prior to a commit made earlier today) but if it didn't, it
would only be noticable to players who leave 'force_invmenu' Off.
When 'tips' are enabled, the farlook tip displays some text at the
start of getpos(). But it clobbered the initial prompt, leaving
the screen in an ambiguous state (seemingly a normal map display,
but it is actually waiting for player to move the cursor) after
removing the tip's popup window.
Reissue the prompt. farlook's short but misleading prompt of
"Pick an object" is changed to "Pick a monster, object or location".
I would normally include a comma before "or" but omitting it makes
the longer text seem slightly less cluttered.
The other tips are all one-line, delivered via pline(). Prefix
all of their messages with "Tip:" (which the farlook one already
uses) as a hint for using OPTIONS=!tips to shut them off.
This prevents a buffer overflow that was encountered during fuzzing,
but the underlying issue in the caller dodip() is still pending.
That appears to be the result of 'obuf' not being filled with
appropriate content prior to being used at line 2343 in potion.c.
...some of them, at any rate. We shut off (1) warnings provoked by Matt
Bishop's "mn" macro package, and (2) warnings spuriously emitted by
groff 1.23 and previous when "-wall" (or "-ww") is specified.
Also update explanatory comments.
