Blessed scroll of fire allows to choose the explosion location like
scroll of stinking cloud does. This should make it somewhat useful
in the early game.
From the newsgroup, remarking on an usual cause of death seen at NAO.
Surviving a gas spore's explosion (via hit points, not from life-saving)
left "gas spore's explosion" as stale killer.name. Being killed by
opening a drawbridge (but not by closing or breaking one) only assigned
killer.name if it didn't already have a value, so the stale reason got
used: crushed to death by a gas spore's explosion.
This fixes it two ways: clear the stale value after surviving the
explosion, and assign a specific reason when opening the drawbridge.
This also removes stale reason for death set up by various drawbridge
activity. For the usual case, the hero only survives by life-saving
which does its own clearing of killer.name. But there might have been
cases where it was being set for the hero when operating on a monster,
so no life-saving involved. The drawbridge code is not the easiest
code to navigate....
The BONES_POOLS implementation added an extra dot to the bones file
name (only when enabled) which would be a problem on some filesystems.
This changes the name from "bonD0.15.3" to "bon3D0.15" which avoids
the second dot and also fits within 8.3 characters. To enforce that,
the maximum value for BONES_POOLS is now 10 (yielding single-digit pool
numbers 0 through 9).
BONES_POOLS==1 will omit the pool number (that's not a change, just a
reminder), yielding "bonD0.15" and so on. Right now, BONES_POOLS==0
is equivalent to BONES_POOLS=1, but it could be changed someday to
mean that bones files shouldn't be used if we decide to support that.
The pool number as a suffix was being included in content validation,
so it wasn't possible to move "bonD0.15.3" to pool 2 by renaming it to
"bonD0.15.2". I'm not sure whether that was intentional, but it seems
overly draconian. "bon3D0.15" can be renamed to "bon2D0.15" and then
be loaded by a game assigned to pool 2. Also, pre-pool bones can be
retained by renaming to any valid pool and should still work.
The three letter filecode for quest bones has made the bonesid be
broken since 3.3.0 introduced it (the three letter code, not bones-id).
"QArc.2" for level 2 of the Archeologist quest was being written into
the bones file as "rc.2", but worked as intended because validation
when loading bones had the same mistake. This fixes it to use "QArc.2"
when saving and accept either "QArc.2" or "rc.2" when loading, so 3.6.0
bones files (and existing to-be-3.6.1 bones) will continue to work.
Reduce the chance of a player playing on a public server encountering
their own bones, by implementing separate bones pools. The pool a player
belongs to is determined at game start, and only bones in that pool
are used. The sysconf BONES_POOLS allows the sysadmin to define how
many pools there are.
Drinking any potion full healing or extra healing or non-cursed potion
of healing cures blindness in addition to restoring lost hit points.
Now breathing vapor from any potion of full healing or non-cursed
potion of extra healing or blessed potion of healing will also do so.
Report was for a blinded horse which ate a carrot but remained blind.
This fixes that, and also lets blinded carnivorous pets eat carrots.
Gelatinous cubes now handle carrots too, but since they lack eyses
there won't be any noticeable effect for them.
Fix the SELF_RECOVER part of files.c which was actually in slightly
worse shape than previously fixed recover.c itself.
I think the HOLD_LOCKFILE_OPEN edition of nhclose() is the only
remaining file descriptor leak from the original #H5778 report.
The revised code compiles when SELF_RECOVER is defined, but I didn't
actually force a recovery to fully test it.
This patch includes a couple of reformatting and/or reorganization
bits in addition to the fd leak fix.
Reported directly to devteam: if applying a grappling hook towards
a target past some water ended up pulling the hero toward the target,
hero would drown without any chance of crawling out of the water.
It used hurtle() to move, and hurtle assumed levitation so didn't
check for entering pools of water except on the Plane of Water.
Overriding clang-format was justified, but the result was too wide.
Make the lines less that 80 characters.
Also, WC_PERM_INVENT and WC_PLAYER_SELECTION had comments cloned from
the preceding line.
Previously the "fast-moving" when getting a target location
was always by 8 units. If this option is on, fast-moving
will instead skip the same map glyphs. This should be much more
useful for blind players.
Reported directly to devteam, so no #H number. Conditional code in
amii_get_ext_cmd() included an unmatched '{', which would break
compilation (at least if EXTMENU was enabled) and also resulted in
the remainder of winami.c being mis-formatted (the functions there
were treated as being inside a block rather than at file level).
This is completely untested.
There's some code suppressed via '#if 0' with a comment "fix for PL2".
We haven't used the patch-level nomenclature since version 3.0!
Files modified:
include/extern.h
src/pline.c, priest.c, potion.c, mkobj.c
A bunch of calls to pline() in pline.c started triggering warnings
either as-is or possibly after the changes to tradstdc.h. Fixing
them in place would include intrusive VA_PASSx() like in lev_main.c.
Moving them to other files is much simpler (and they didn't
particularly belong in pline.c in the first place, although I didn't
actually find any better place for them....).
The probing/stethoscope feedback went to priest.c, where there's a
comment stating that it should move to wherever englightenment ends
up once that is moved out of its completely inappropriate current
home in cmd.c. (Holdover from when ^X was wizard-mode only but even
the other wizard mode commands don't really belong with the command
processing code.)
Files modified:
include/tradstdc.h, sp_lev.h, system.h
util/lev_main.c
Silence a bunch of warnings generated by recent gcc which weren't there
with whatever version I had when 3.6.0 was being readied for release.
For lev_main, there were two basic types: not enough arguments in calls
to lc_pline, lc_warning, and lc_error (since we weren't passing dummy
arguments as is done for add_opvars), and conversion from 'int' or
narrower to 'char *' (from -Wint-to-pointer-cast, which either wasn't
there yet in the older gcc, or wasn't included in -Wall back then).
[Note that for any configuration decrepit enough to actually need
USE_OLDARGS, such conversions will either work fine or else nethack
simply won't be viable.]
src/pline.c generates a bunch of warnings (for USE_OLDARGS). The fix
for that will be (2 of 2).
To test, instead of mucking about with CFLAGS or sys/unix/hints, I've
been temporarily adding unconditional
|#undef USE_STDARG
|#undef USE_VARARGS
|#define USE_OLDARGS
to the end of config1.h and then doing my normal build--which is why
-Wall (or possibly -W) is drawing -Wint-to-pointer-cast warnings.
Compound option whatis_filter, filters the eligible map locations
when getting a cursor location for targeting. Accepts 'n' (none),
'v' (map locations in view), or 'a' (map locations in the same area,
eg. room or corridor).
Reported directly to devteam, so no #H number. If SIMULATE_CURSOR
isn't defined, there would be no switch statement to attach the
subsequent cases to.
The suggested fix is obviously correct, but untested....
win/share/tileset.c seems only to be used by the MSDOS port, but it
compiles cleanly on OSX after these changes.
A file pointer was passed to fclose() twice, second time potentially
causing problems. There were cases of potentially null pointers
being passed to free() too. That should be safe these days, but it's
something we've tried to hard to avoid and would probably trigger
complaints from our own MONITOR_HEAP code if that ever got applied
here.
Change lev_comp's add_opvars() to be like pline(), where there's a
single visible opening brace and a second one hidden in VA_DECL2
that introduces a nested block, plus a single visible closing brace
with a hidden one in VA_END() to close the nested block. This
addresses the erroneous report (sent directly to devteam, so no #H
number, subject "missing '{' in util/lev_main.c:634") that the code
for !USE_STDARG/!USE_VARARGS in add_opvars() wouldn't compile.
Also, fix the part of "#H5778: file descriptor leaks" dealing with
util/recover.c -- an open file not being closed after various errors.
I didn't take responsibility for this entry in the bugzilla list
since the report includes similar problems in other code that's not
addressed here.
And a blast from the past: some reformatting fixups in recover.c.
The most interesting bit is for a block of dead code....
Alex mentioned that loops over mons[] were starting at [0], which
should be [LOW_PM] instead. I only found two, and the mvitals[] one
was benign. The special level one might have been too, depending
upon spec_lev's thoroughness--I didn't attempt to check.
Once upon a time there was a possibility of moving 'playermon' from
a separate variable to mons[0], so LOW_PM became the index of the
first valid monster. Instead, 'playermon' went away altogether.
LOW_PM (and NON_PM) could go away too, but I don't see how reverting
to hardcoded 0 and -1 would be an improvement. We have enough
problems as it is with "giant ant" turning up in unexpected places
because someone used 0 instead of NON_PM to mean "none of the above".
This started out as just an attempt to remove some duplicated code,
but mutated. Move health recovery into a separate routine to
streamline moveloop().
Intentional changes:
1) when poly'd hero is at max u.mh (hit points as a monster), do
not recover lost u.uhp (hit points when in normal form). That
was caused by a missing !Upolyd check in the long if..elseif..
elseif..endif logic. If we want to make it deliberate, I think
some u.uhp recovery in rehumanize() would be the way to go.
2) regeneration for poly'd hero in sea monster form (ring worn on
left or right pectoral fin) now counteracts the loss of hit
points for turns spent out of water. [Do eels even have fins?]
3) poly'd hero with moderate or worse encumbrance and lacking
regeneration wouldn't recover any health. Now he/she will do so
if not moving [on the magic (moves%20 == 0) turn when u.mh
recovery takes place].
If there are any other changes in behavior, they're unintentional.
Having selectable base indexes for the monster list doesn't seem
likely to be needed in the future any more, now that the code for
the monster list is stable. Additionally, the functionality in
question has bitrotted heavily (e.g. many "loops over all
permonsts" start at a hardcoded 0, which wouldn't work with a
1-indexed monster list). As a result, removing the relevant code
in makedefs makes it clearer what can and can't be assumed about
the code, reducing the risk of bugs in the future.
Thanks to FIQ for mentioning that this could be an issue.
by Excalibur. Noticed on Reddit by Alex, the attempt to fix being
blasted twice by wielded artifact weapon when changing alignment
ended up preventing wielding other role's quest weapons. At the
moment I can't even see how it prevented the double-blast....
This backs out that change and fixes the double-blasting correctly.
When uwep and uswapwep are tested in advance of the rest of invent,
mark them as already processed before entering the loop that checks
all not-yet-processed inventory.
Reported nearly four years ago for 3.4.3, original subject was
\#H3013: NetHack grammar bug when taking unpaid fruit from chest
Player used OPTIONS=fruit:Quorn and the capitalized value confuses
the() into thinking it's a proper name which shouldn't be preceded
by an article, resulting in "Quorn will cost you N zorkmids" when
removing it from a chest in a shop, followed by "X - a Quorn (unpaid)"
as it went into inventory. It is a product name, but when used as a
fruit it shouldn't be treated as a proper name. (Quorn is a meat
substitute rather than anything related to fruit.) Teach the() about
named-fruits, so that we'll get "The Quorn will cost you N zorkmids."
Unfortunately, it means that someone who names their fruit after a
proper name used by the program, for example Mjollnir, can probably
induce other poorly worded messages (about the item rather than the
named-fruit). the() is used all over the place and all it has to work
with is text, not the object whose formatted name produced that text.
I looked through a bunch of old cvs log messages last night, and
spotted one I wrote (in objnam.c) a dozen years ago where I suggested
forcing named-fruit values into lower case as they're being set up.
I don't remember that, but if we'd done it, this bug would have been
avoided.
The object name formatting routines operate using a pool of buffers to
hold intermediate and/or final result. Some routines consume multiple
intermediate buffers, so use releaseobj() to try to reuse just one in
order to avoid churning through too many and maybe clobbering live
data. It worked as intended for routines that use nextobuf() directly
but wouldn't haved worked right for xname(), also doname() and other
xname() callers. This fixes that.
There have never been any reports of garbled messages which could be
traced to clobbering of formatted object names, so this fix is mostly
academic.
