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.
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.
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.)
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).
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.
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.
Add some new routines for dealing with fruit. I had hoped they would
let the existing fruit handling be simplified quite a bit, but the
improvement wasn't great. However, they're also groundwork for fixing
an old bug.
A couple of days ago when verifying the report about being forced to
pay for a second tin when eating one from a stack on a shop's floor,
wishing for 'tins' (rather than 'tins of foo meat') was repeatedly
producing tin wands instead. The name "tin" and the wand description
"tin" in objects[] were being given 50:50 chance for either one by
the 3.6.1 wishing code. Wishing for "tins of spinach" also gave me
a tin wand on the first attempt. Handle 'tin(s)' more explicitly.
This also does some reformatting.
Add support for filtering by unpaid status for container-in and
container-out actions. When taking out of a container, it works as
expected if you're carrying the container while in a shop, but won't
find any unpaid items if the container is on the floor. That's
because they're only flagged as unpaid while in the hero's inventory.
(And when it doesn't find any unpaid items it won't list 'unpaid' as
a category of item to manipulate, so while that might be suboptimal
for taking items out of shop containers, it shouldn't be a problem.
Typically all the contents are shop-owned anyway, so using unpaid as
a filter wouldn't gain any advantage over just taking stuff out.)
Remove the assumption of property index values from the list of
property names. Move the properties that can't have timed values
in normal play to after those which can. (Mainly only matters for
the #wizintrinsic command.)
Bug fix: #wizintrinsic variable 'any' wasn't initialized properly
if 'a_int' is smaller than a long or a pointer. The separator line
I've added was ending up as a menu choice.
Reported directly to devteam, eating 1 of 2 tins of spinach from a
shop's floor forced the hero to buy both. (1 was gone, the other was
intact and now owned by the hero rather than the shop. Tins of other
contents behaved similarly.) The bug is easy to fix but not so easy
to explain: eating split one from the stack but passed the remaining
stack to useupf(obj,1) which also split one off and treated that as
used up. The second one was billed as used up and the first one was
added to the bill--as being subjected to a costly modification made by
the hero--and kept intact, now marked no-charge with hero obligated to
pay for it.
Eating 1 of N tins, for N greater than 2, billed for two, one gone and
the other now in a separate stack and marked no-charge. The remaining
N-2 stayed as normal shop goods in their original stack.
The fix is communicate the splitobj() for costly modification up-call
so that the use_up_tin code operates on the one which was split off
the stack rather than on the remainder of the original stack.
Reinstate the deprecated 'bouldersym' option for the 'O' command
instead of just showing the set-at-start-of-play value. I leave
boulder with the default value except when attempting to solve
Sokoban, and it's a pain to have to save, edit config file or
reset NEHTACKOPTIONS, then restore in order to change the boulder
symbol, then do that all over again once leaving Sokoban.
If using the default symbols, a custom symbol set which just sets
boulder will work, but with {DEC|IBM}graphics that's no help
because the unspecified symbols revert to their default values.
Extend the wizard mode #timeout command: show timeouts for all 67
intrinsics rather than just a handful. Most won't appear because
they don't have any way to receive a timed value. Except for...
Extend the wizard mode #wizintrinsic command: allow setting a
brief (30 turn) timeout for any/every intrinsic, not just for
deafness. It ought to prompt for duration, but that's more effort
than I'm willing to expend. This might turn up lots of quirks that
the code isn't prepared to handle (like setting life-saving to
non-zero will break the assumption that it comes from worn amulet).
Perhaps some will warrant fixing, others just a shrug.
There are still some timed events that aren't listed by #timeout:
remaining duration to stay polymorphed in current form, number of
turns until it's safe to pray, luck decay, number of turns until
next attribute exercise/abuse check, probably others that I'm
overlooking.
Bug fix: while testing, I observed
Your limbs have turned to stone.
You have turned to stone.
You can hear again.
You are a statue.
when deafness and petrification were timing out at the same time.
This modifies the stoning and sliming countdowns to extend deafness
duration a little if it's about to time out at the tail end of the
stoning or sliming sequence, so that "you can hear again" won't
happen until after life-saving. There are probably other variations
of simultaneous or near simultaneous timeout that interact oddly.
The different menustyle settings have been offering different degrees
of support for BUCX filtering:
Full : multi-drop, container-in, container-out
Trad, Combo: multi-drop
Partial : none (to be expected; it explicitly jumps past class
filtering, where BUCX gets handled, to a menu of all objects)
This adds pickup, container-in, container-out, multi-unwear/unwield,
and object-ID for Trad and Combo, and multi-unwear/unwield for Full.
(Full behaves like Partial for pickup--not sure why--and for object-ID,
bypassing filters to go straight to a menu of all applicable items.)
There are probably several new bugs--this stuff is very convoluted....
Report #5426 was classified as not-a-bug, but the underlying issue
can be improved.
For item selection where BUCX (bless/curse state) filtering is
supported (mostly for menustyle:Full, but there are a few actions
where Traditional and Combination handle BUCX too), 3.4.3 took the
union of object class and bless/curse state (so ?!B gave all scrolls
and all potions and every blessed item from other classes) but 3.6.0
changed that to the intersection (so ?!B gives blessed scrolls and
blessed potions, period). Since gold is inherently not blessed or
cursed it has been getting excluded during intersection handling
when that includes BUCX filtering. Report #5426 was from a player
who was used to choosing $X when putting newly acquired loot into a
container asking to have the old behavior reinstated.
The ideal fix would be to support both union ($ | X) and intersection
(?! & B), but implementation would be bug prone and the interface,
especially when done for menus, would be cumbersome. Instead, this
adds new boolean option, goldX, to allow the player to decide whether
gold is classified as uncursed--even though it is never described as
such--or unknown. The new-loot-into-container issued can be solved
either via $abcX, where abc lists all classes that have any X items
(when gold is included as one of the classes, its BUCX state is now
ignored for the current selection), or by setting the goldX option
and then just picking X for the types of items to put into the
container (or drop or whatever other action supports BUCX filtering).
The situations where menustyle:Full allows BUCX filtering during
object class specification and styles Traditional and Combination
don't should to be fixed (by extending BUCX support to Traditional
and Combination rather than removing it from Full, obviously).
From end of last December: turning into a "new man" or "new woman"
used the right gender if the hero was polymorphed at the time, but
always used "new man" if it happened when trying/failing to polymorph
while in original form.
I think this finally quashes the "cursed without otmp" issue.
Various ways of destroying wielded weapon used setnotworn() rather
than unwield(), so the previous change to have unwield() clear the
pending W_WEP bit from takeoff.mask wasn't sufficient to prevent
'A' moving on from another item (blindfold--it's the only thing
processed before primary weapon) to weapon which wasn't there any
more. Also, if weapon was already set in takeoff.what to be
processed on the next move, clearing W_WEP from takeoff.mask wasn't
sufficient either.
Move the previous unwield() 'fix' to setworn() and setnotworn() and
extend it to include cancel_don() if the item being replaced or
removed is in progress or scheduled for next. (Most of the time,
remove_worn_item() has already done that before setworn() or
setnotworn() is called.)
This adds new utility routine strNsubst(), a more versatile version
of the existing strsubst(), that can replace the Nth occurrence of
a substring rather than just the first, and replaces all occurrences
if N is 0.
When working on vampire shape-shifting messages a few days ago I
noticed that a constructed pline/sprintf format was vulnerable to
the player giving the vampire a name with '%' in it and included
a fix for that. This fixes two other instances of the same
vulnerability: a monster with reflection triggering a floating
eye's gaze and the hero using a silver weapon against a silver-
hating monster.
I didn't do a lot of experimenting with the failure, just assigned
the name "foo%s" to the floating eye or the weapon. The resulting
feedback for the relevant messages was garbled due to parameters
being substituted in the wrong place. When that caused there to be
too few arguments to satisfy the format, the final message included
"null" for the missing one rather than triggering a crash while
trying to format something arbitrary from the stack.
I don't think these bugs provided sufficient user control to be
vulnerable to stack manipulation that does something naughty.
I found the dynamic format strings by searching for "%%". There
may be others scattered around the code which don't have that as
an indicator....
m_monnam() overrides hallucination, which is appropriate in some
situations but not others. This fixes one instance where it was
being misused: discovering a hidden monster when another monster
attacks it was calling either m_monnam() or a_monnam(); one ignores
hallucination and the other doesn't, so accurate or inaccurate
monster type depended on the condition tested.
Figurine activation and egg hatching are using m_monnam(), which
seems suspect, but I left them as is.
The do_wear.c part just eliminates some redundant code but shouldn't
produce any change in behavior.
The steal.c part should fix problems with 'A' when outer items are
taken off during theft in order to steal an inner item, where the
outer item is next to be removed (call to cancel_don() wasn't being
made). The wield.c part matches the X_off() behavior and is needed
to handle a weapon item that's slated for removal but isn't next (so
wouldn't pass the donning()/doffing() test to trigger cancel_don()).
If this seems a lot like trial and error, it is....
Extend the 'A' blindfold fix from three weeks ago to cover weapons
too. This might fix the problem being caught via curse(NULL) when
using 'A' to remove multiple items. The blindfold bug was straight-
forward since it was requiring two turns but not checking for loss
of blindfold when interrupted by theft. Weapon/alt-weapon/quiver
each only need one turn so I'm not sure what's really happening to
trigger problems for them.
Noticed while composing a reply to the #H5547 report about named
vampire shape-shift message. The message when a vampire (possibly
in vampire bat form) turned into a fog cloud in order to pass under
a closed door was using a stale cached mon->data value when choosing
the verb. So normal fog cloud or vampire already in fog cloud shape
would "flow" under the door, but newly shifted fog cloud would "ooze"
under the door. I saw this while testing the previous patch but its
significance didn't register at the time.
Report was about "Pet vampire" but the relevant aspect was that the
vampire had been assigned a name, not that it was tame:
You observe a Hilda where a Hilda was.
Investigating this has uncovered two other bugs, one potentially
serious. m_monnam() overrides hallucination but seems to be getting
used to some situations where hallucination should be honored (several
instances). Dynamically constructed format strings are including
monster or object names in the format (rather than the usual use as
arguments), so player assigned names containing percent signs could
cause havoc (a few instances). This fixes some of the former and one
of the latter, but doesn't deal with various other cases revealed by
grep.
Update a comment prompted by '#H5459 - explosions and steeds'.
Also a couple of formatting changes.
This doesn't attempt to address the reported issue: hero's and
steed's resistances are intermingled when exploding at the hero's
coordinates and influence the effect on both. Inherited from the
behavior for an engulfed hero, and might not necessarily be a bug.
This started out as a fix for '#H5460 - minor monster detection bug'
but that report turned out to be wrong. It claimed that pets weren't
highlighted as pets if the only way to observe them was via extended
monster detection, but the code (both 3.6.0 and current) indicates
otherwise. Detected monster highlighting is bypassed for pets.
Reorganize the code slightly to emphasize that this is intentional:
tameness trumps remote detection when choosing which highlight method.
For tty, if hilite_pet and use_inverse are both enabled or both
disabled, you can't see the difference anyway. At least I can't....
That report also wanted the use_inverse option to be changed (I guess
it's overloaded for multiple things) so I haven't marked #H5460 as
closed.
