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.
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.
If hero survives a killing blow via saving-grace, report that to
livelog but hide it from player's own #chronicle.
Only reveal whether saving-grace was used up during end-of-game
disclosure. Omit that during enlightenment unless running in
explore mode (or wizard mode).
Sanity check failure generated by running the fuzzer, reported
by mkuoppal. The check discovered that the hero's current hit
points were greater than the maximum.
Comments by elunna pointed out where the problem most likely was,
and this attempts to fix the situation, but without a test case
I can't be sure that the fix works.
Both cases being fixed are for formerly fatal incidents (random
chance that poison is fatal, monster touch of death spell) being
'softened' to heavy HP damage (including reduction of maxHP).
The earlier commit I made (045d608) was done without having seen
the relevant comments. It didn't fix anything but did attempt
to make finding the problem(s) easier. It wasn't much help.
Fixes#1252
I don't always want to abort() on an impossible() when debug_fuzzing,
especially if the first impossible() encountered isn't related to the
bug I'm in the midst of trying to hunt down.
I often have breakpoints on impossible() anyway, and I'd like a simple
way to avoid the panic() call during a lengthy debug session.
Make iflags.debug_fuzzer an xint8 instead of a boolean.
Call abort() only if iflags.debug_fuzzer is set to 1.
That allows setting iflags.debug_fuzzer to 2 in order to bypass the
abort call, and make use of other breakpoints that have been set
to narrow down a particular issue.
Issue a livelog/#chronicle message if saving-grace saves the hero.
Right now it's classified as conduct for livelog filtering, because
I didn't want to implement a new category (needs update of global.h
and also the template 'sysconf') and conduct felt like the best fit
of the existing classifications.
Report whether saving-grace is available or already used, among
the attributes of magical enlightenment or end-of-game disclosure.
And move the fixes entry for it from the fixes section to the new
features section of fixes3-7-0.txt.
It seems likely that someone will want to turn not using saving-
grace into a tracked conduct. That seems like overkill to me, not
to mention inflating the N for "N conduct games".
I've been investigating issue #1252 (while the fuzzer was running,
sanity_check complained that hero's current health was greater
than maximum health) off and on for three months and haven't found
the cause.
I've checked all the places that lower maximum HP that I've managed
to find, but not spent much time looking for places that raise
current HP.
These changes might provide some more information. They don't rely
on sanity_check being enabled.
Issue #1252 is still open.
I recently realized that I've been editing sources in a terminal
window that was widened in order to fit curses borders for testing
something or other. That has resulted in some new wide lines in the
source. There were lots of old ones too.
This updates some source files to try to achieve the goal of 78
characters or less. As in the past, I've been inconsistent about
lines with 79 characters. Lines with 80 or more have been wrapped
or shortened (usually by trimming an end of line comment or removing
redundant parantheses, sometimes just by reducing the indentation
of the continuation portion of an already wrapped line).
I eliminated one instance of warning manipulation for non-constant
format string, and simplified stone_luck() where Ken had a silly
comment about the function argument's name.
Since wand of secret door detection now gives feedback even when it
fails to find anything, always discover it.
Some of the other zapnodir() wands had suspect discoveries.
Another byproduct of testing boulder pushing. If you kick a closed
door while polymorphed into a giant, always succeed in breaking the
door instead of maybe getting the Wham! or Thwack! failure result.
Noticed when testing boulder pushing into/out of shops yesterday:
a shopkeeper can "mutter incantations" and fracture a boulder in the
shop, transforming it to rocks. If hero owed shk for the boulder
(happens when it has been further inside the shop and then gets pushed
to the shop's free spot), it would disappear from the shop's bill and
hero would then owe for the resulting rocks (which cost more than the
boulder!). That seemed confusing, especially since neither Iu nor Ix
would show the rocks (which are on the floor rather than in invent;
the $ command reported the amount owed, but not what the item was).
When such fracturing happens move the boulder from the unpaid section
of the shop bill to the used-up section before creating the rocks,
which are no longer interesting.
