A vampire in bat form was seen via infravision or possibly telepathy,
then when it changed into fog cloud form the feedback was
|You now detect it where the vampire bat was.
The message substitutes "detect" for "see" when the new form can't
be seen and the monster name formatting yields "it" for that case.
Give a vanish message instead since that is effectively what happens.
The pull request by argrath changes weight_cap() to never return a
value less than 1 because try_lift() divides by that return value
and a 0 would trigger a crash. The code involved is used when
attempting to pull a monster out of a pit via #untrap.
I'm fairly sure that weight_cap() can never produce a value that's
less than 1 already, but have put in a variation of the PR's fix.
I've also implemented a different fix that removes the division
from try_lift(). The original code seems to have gone out of its
way to avoid calculating inv_weight() twice, but doing the latter
(for the once in a hundred games where it might happen) greatly
simplifies things by removing details of carrying capacity.
Fixes#621
Reported by G7Nation; attacking walls and such with a polearm just
gave lackluster "you miss; nobody's there" feedback.
Make applying a polearm at some non-monster locations give feedback
similar to using 'F'orcefight with melee weapons. Was
|You miss; there is no one there to hit.
now
|You uselessly attack the closed door.
Also, extend the supported locations to include dungeon furniture.
Was
|You attack thin air. ('F')
now
|You harmlessly attack the throne. ('F')
|You uselessly attack the throne. ('a')
This doesn't address #613: attempting to hit non-visible locations
with an applied polearm.
Closes#614
Reported by entrez, wielding something fragile (potion of acid
perhaps), and using F to smash it against iron bars called breaktest()
directly, then a second time indirectly through hero_breaks() via
hit_bars(). There is a random chance to resist breaking (99% for
artifacts, 1% for other items) so breaktest() might say that something
will break on the first call and that it will not break on the second
call, or vice versa. That could remove uwep from inventory then leave
it in limbo without destroying it, or destroy uwep without removing it
from inventory first triggering impossible "obfree: deleting worn obj".
Engraving with a weapon which has known enchantment or with a magic
marker which has known charge count that decremented the amount did
so without updating the persistent inventory display. Report was
for curses but applied to every interface that can show perm_invent.
This includes some reformatting (mostly
if {
}
else {
}
to
if {
} else {
}
multiple times; also add some new braces after 'if' or 'else' where
one half already had those and the other didn't). And removal of
some unnecessary 'register' designators.
Plus fix up one sanity check which complained if number of charges
being used was more than a marker had, but then let the engraving
continue and decrement the count by that large amount. If that
impossible situation ever occurred, it would result in a marker
with negative charges.
Noticed when testing the "wall_angle: unknown" fix, if there is a
boulder rather than a door in the breach in a vault's walls at the
spot where the guard arrives, the guard would walk onto it, tell the
hero to drop any gold and follow, then move back. The boulder would
remain in the hero's way and couldn't be pushed because the guard was
in the boulder's way. Have the guard smash any such boulder(s) into
rocks when arriving (with no explanation for how that is accomplished,
just a message about seeing or hearing boulder(s) shatter). Later
when repairing the walls, delete any rocks or boulders at all vault
wall locations (even when no gap-to-wall repair is needed).
Reported directly to devteam by entrez via email:
>
> I noticed some potential issues with (melting) ice:
>
> * Digging down into ice, or setting a land mine on the ice and
> triggering it, doesn't remove the melt_ice timeout, so it can result
> in a sequence like dig down -> pit fills with water -> freeze water
> -> freezing water tries to set melt_ice timeout -> duplicate timeout
> impossible. Or if you don't freeze the water again, melt_ice will
> run on a non-ice surface, which might at least produce strange
> messages.
>
> * Setting a land mine on ice: melting ice doesn't do anything with
> the trap, so there is still a land mine which you can trigger by
> flying over the water (the land mine's trigger is also still
> described as being 'in a pile of soil', despite being underwater at
> this point). Similar thing happens with bear traps.
>
> * Not really related to _melting_ ice, but an exploding land mine
> doesn't reset the typ from ICE to FLOOR (like normal digging does),
> so it will result in a square with a pit that is also an ice square,
> where the ice can melt under the pit and produce a combination
> pit/moat. If you then freeze the moat, the pit reappears on top of
> the ice.
https://github.com/NetHack/NetHack/pull/573 by entrez
Pull request comment states:
"Moving into a position containing a warning symbol with m-<direction> to
'safely' move would still attack as though the 'm' prefix was not
specified. Ensure warning symbols are counted as 'detected' monsters
for this purpose, to avoid falling through to do_attack()."
Closes#573
https://github.com/NetHack/NetHack/pull/592 comment states:
"In commit db68395, most of the instances of xdir and ydir here were
changed to u.dx and u.dy, but not all of them. The remaining ones are
out-of-bounds on xdir and ydir, because i is always set to 12 from an
earlier loop and is no longer involved in handling user input. They
should be u.dx and u.dy like the rest."
triggering an impossible warning about "wall_angle: unknown" due
to the known conflict between door state and wall info which both
overlay the flags field for map locations.
Reported and diagnosed by vultur-cadens: if a shop's wall was dug
open, followed by use of locking magic to plug the gap with a door,
and then unlocking that door, the D_CLOSED door flag was left as
invalid wall_info when shop damage was repaired. Map re-display
complained. Leaving the door locked or opening it after unlocking
did not result in any complaint because the values for those door
states do not conflict with wall angle values.
The problem was reproducible and is now fixed by adding an extra
field to the shop damage structure. A similar change has been
made to the vault guard's 'fake corridor' structure but I have no
test case for that so don't know whether it makes any difference.
At least it doesn't seem to have broken anything.
Existing save and bones files are invalidated by the fixes.
Fixes#606
Describe the new feature of m<dir> making it feasible to move to a
boulder'd spot without pushing. Giving specific information among
vague descriptions is awkward....
While in there, move a handful of sentences to separate lines as per
the 'roff guidelines. I did the same for Guidebook.tex even though
it's not needed there, to try to keep things parallel.
Revise the m<dir>-toward-boulder handling to let a hero who would be
able to squeese into the boulder's spot if it was blocked from being
pushed to do the squeeze without any pushing.
Unlike the previous changes, this might have an impact on play. It
allows squeezing under then stepping past an unblocked boulder that's
in a corridor in order to be able to push it back the other direction
where maybe there's more room to maneuver it out of the way.
Allow a hero polymorphed into a giant to move to a boulder's spot
via m<dir> no-pickup move, instead of having to push it until the
way is blocked by something and then having push failure move hero
to the spot.
Also change m<dir> when not a giant to no longer push the boulder.
No time will elapse when not moving unless hero who didn't know
that there was a boulder there learns that one is. Since no actual
push attempt gets performed, player doesn't learn whether there is
anything beyond the boulder that inhibits it from being pushed.
Reported directly to devteam, player observed that objects on the
floor had their bless/curse state change when reading a blessed
scroll of remove curse while confused. Message feedback mentioned
a silver saber being dropped. I didn't attempt to view the ttyrec
playbacks; what I'm sure happened was that the saber was secondary
weapon for dual wielding and had been uncursed; the confused remove
curse effect cursed it, which in turn caused it to be dropped. The
saber's 'next object' pointer became the [previous] top of the pile
at that spot and further object traversal intended to process the
rest of hero's inventory ended up processing floor objects there
instead.
This bug has been present for over 20 years (since 3.3.0 came out
in late 1999, when dual wielding was introduced and cursing of the
secondary weapon forced it to be dropped since making it become
welded was deemed to be too complicated) and never been reported.
Most likely players keep secondary weapons blessed so the scroll
effect doesn't touch them and simple object traversal sticks with
inventory. Or items at the spot have unknown BUC state so having
them be affected wouldn't be particularly noticeable.
Reported directly to devteam: monster vs monster location swapping
didn't handle single-segment long worms properly. Multi-segment
worms are disallowed but a worm with no visible segments (which
actually has 1 segment at the head's location) are allowed and the
segment wasn't being moved with the core monster and could trigger
warnings if sanity checking is enabled. The next time that the
worm moved, it got itself back in synch.
I couldn't reproduce the warning but mdisplacem() clearly assumed
that a long worm reporting 0 segments didn't have any so wasn't
attempting to handle the hidden one.
for helm of opposite alignment.
Discovered and described by vultur-cadens.
The #adjust command can be used to split an object stack and if the
shop price of the two halves are different, the new stack will have
its obj->o_id modified to make the prices the same. That could be
used to tip off the player as to what the low bits of the next o_id
will be. Since no time passes, no intervening activity such as
random creation of a new monster can take place, so the player could
wish for something that depends on o_id with some degree of control.
Matters mainly for helms of opposite alignment intended to be used
by neutral characters since the player isn't supposed to be able to
control that. (Other items like T-shirt slogan text and candy bar
wrapper text had a similar issue but controlling those wouldn't have
had any tangible difference on play.)
The issue writeup suggested allowing the player to specify a helm's
alignment during a wish. That would defeat the purpose of having
o_id affect the helm's behavior in an arbitrary but repeatable way
so is rejected.
I implemented this fix before seeing a followup comment that suggests
using a more sophisticated decision than 'obj->o_id % N' for the
arbitrary effect. This just increments context.ident for the next
obj->o_id or mon->m_id by 1 or 2 instead of always by 1 and should
be adequate. It also has the side-effect that two consecutive wishes
for helm of opposite alignment won't necessary give one for each of
the two possible 'polarities', even with no intervening activity by
monsters, reinforcing the lack of player control.
Minor bonus fix: it moves the incrementing check for wrap-to-0 into
a single place instead of replicating that half a dozen times. Ones
that should have been there for shop billing and for objects loaded
from bones files were missing.
Fixes#596
by the Riders that only damage the hero, not other monsters.
Noticed and diagnosed by vultur-cadens. Attacks dishing out the
damage type AD_DETH (Death), AD_FAMN (Famine), AD_PEST (Pestilence),
and also AD_DISE (Demogorgon, Juiblex, Scorpius) did 0 damage if
inflicted against monsters. That made Death harmless to other
monsters. The others have additional attacks (in the two Rider's
cases, only if both instances of their special attack hit on the
same move so that the second one is converted into a stun attack)
and could manage to kill other monsters.
The uhitm case can't happen. I suspect that the mhitm case was
originally intentionally omitted as something which won't happen,
but that's just a guess.
Fixes#594
Reported and diagnosed by entrez:
recalc_mapseen() has been looking at all slots in u.urooms[] rather
than stopping at the first \0. Since the whole array doesn't get
zeroed out when the value changes, stale room indices might follow
that first \0 and any rooms those referred to would erroneously get
flagged as having been visited by overview updates. Wouldn't matter
for the level where the stale indices got set, since you'd have to
have been in those rooms for it to happen, but would matter once you
moved on to other levels.
If a bones file is created, any object-liking monster next to
where hero died has a chance of grabbing objects from hero's
inventory.
This comes from xNetHack by copperwater <aosdict@gmail.com>.
The gas will expand from its chosen center point via breadth-first
search instead of hardcoding a diagonal shape. The search is performed
with a randomized list of directions, and has 50% chance of not spreading
to a space it otherwise would have spread to. This has the effect of fuzzing
the cloud edges in open areas, helping the clouds on, for instance,
the Plane of Fire not be big rhombuses.
Also some other code refactoring related to stinking clouds in read.c
This comes from xNetHack by copperwater <aosdict@gmail.com>
Use a slightly more meaningful name for each one rather than
a sequential numerical name.
S_explode1 to S_expl_tl
S_explode2 to S_expl_tc
S_explode3 to S_expl_tr
S_explode4 to S_expl_ml
S_explode5 to S_expl_mc
S_explode6 to S_expl_mr
S_explode7 to S_expl_bl
S_explode8 to S_expl_bc
S_explode9 to S_expl_br
When using a menu to drop or put in items into a container,
allow putting in the item (or items) you picked up previously,
by selecting the 'P' entry from the item class menu
Inspired by the itemcat patch by Stanislav Traykov.
Invalidates saves and bones.
Reported and diagnosed by entrez:
"The <mon> yanks <two-handed weapon> from your corpses!"
It became unwielded and that triggered a perm_invent update and
such updates reformat entire inventory, so if that contains a dozen
or more items it will use all the obuf[] static buffers as least
once. In this case, the bullwhip code had plural of "hand" in one
of those buffers and by the time it delivered the message which
used that, the value had been clobbered.
As the diagnosis mentioned, it can be tricky to reproduce since
either &obuf[0] or &obuf[PREFIX] might be used and if the value
being clobbered didn't overlap, the effect wasn't noticeable.
Instead of fixing the bullwhip message, this changes inventory
display so that it should no longer churn through all the buffers.
It also adds a fixes entry for #K3401, which was already fixed for
3.7 but I hadn't been able to reproduce it for 3.6.x (which I now
blame on the PREFIX trickiness).
Save files from before the 'disambiguate WHACK' patch were not
necessarily compatible with ones after it, leading to potential
restore problems.
Comments in objclass.h (from before the patch) suggested that
inappropriate assumptions were being made about field layout.
This deliberately introduces new incompatibility and increments
EDITLEVEL to caused earlier save and bones files to be thrown
away.
Fixes#587
when fleeing hero who was wearing gold dragon scales/mail and not
wielding any weapon.
When a gremlin was made to flee "artifact light", code originally
intended for Sunsword attempted to format 'uwep' as an artifact. For
gold scales/mail instead of that, it gave a sane but inappropriate
value if wielding something or segfaulted if not wielding anything.
Fixes#589
