Reported in Dec'04 by <email deleted>, an
unpoly'd hero or a hero poly'd into monster form which lacks a kick
attack both get bonus from rings of increase damage when kicking, but
a hero poly'd into monster form which has a kick attack did not.
Back port the trunk fix that prevents stone-to-flesh on self when
wielding a figurine from leaving stale worn object pointer and eventually
triggering a panic or crash. Branch only except for fixes34.4 update.
From a bug report, walk_path() was
favoring orthogonal steps at beginning of the path and diagonal ones at
end, when intermixing diagonal and orthoganal produced a more accurate
representation of the real path. Only mattered for long distance jumps
3x2 or 3x1 steps away; hurtling always moves in a straight line and short
(2x1 knight) jumps aren't affected by the patch supplied with the report.
From the newsgroup: player chatted with leader and was ejected for
not being high enough level, then when he came back later there was no
leader to be found, but there was a polymorph trap on quest home level.
This makes quest leaders and nemesis be aware of all trap types--rather
than just having leaders be aware of magic portals--so they'll be able to
avoid polymorph traps. It also makes chatting with a polymorphed leader
work as long as the new form is able to speak (use same criteria as with
poly'd shopkeepers: can't be in a form that's limited to animal sounds).
I had intended to put the Hate_silver patch into the branch as well
as the trunk, but hit too much nonmatching context. When switching it to
be trunk only, I neglected to put the fixes entry into the proper file.
Monster werecritters are vulnerable to silver when in human form as
well as when in beast form, but hero inflicted with lycanthropy was only
vulnerable while in beast form. Add pseudo-property Hate_silver to handle
that correctly. Also, add silver vulnerability to enlightenment feedback.
Lastly, hero vulnerable to silver had Con abused if hit by silver missile
but not when hit hand-to-hand; add an exercise() call to the latter.
Many (most?) non-weapon artifacts show up in inventory and messages
as "the <foo> of <bar>" even when their underlying object type hasn't been
discovered yet. For types which don't use the `known' bit, obj->known is
forced to 1; obj_is_pname() checked that but not the oc_name_known flag
for the type. So you'd see things like "the Heart of Ahriman" instead of
"a luckstone named <the H of A>" or "a gray stone named <the H of A>" even
though it hadn't been identified yet, unintentionally hiding the artifact's
object type from the player.
While testing the figurine timer patch, I observed
The goblin wields a crude dagger.
You see a goblin drop out of your pack!
Rather than try to get the sequencing right, just prevent monsters made
by figurine activation or by the create familiar spell start without any
inventory. This will have a side effect of making wishes for a blessed
figurine of an archon be less powerful, because the subsequent pet A won't
come equipped with a shield of reflection and an artifact--or at least
rustproof--long sword anymore.
From a bug report: having a lit
candle or potion of oil be wielded or "worn" as alternate weapon or quiver
at the time it finished burning up would leave a stale worn object pointer
which could trigger a panic or crash. Need to call useup() instead of
obj_extract_self()+obfree() for objects in inventory, similar to the way
hatching eggs are handled.
From a bug report: attempting to apply
a towel which is currently "worn" in the weapon, alternate weapon, or
quiver slot fails with "you cannot use it while you're wearing it". The
message sounds odd when the towel is wielded, and there's no reason why
you shouldn't be able to use it when it's in any of those weapon slots.
Compare it with current blindfold rather than checking its owornmask.
<email deleted>, escaping from being stuck
by lava via jumping--or simply walking--got you out of the lava while being
at the same location. You could then stay there for as long as you liked
without falling back in. This makes a lava and water check on turns where
time passes but hero hasn't moved, performing a subset of spoteffects().
I think the water case only matters when using wizard mode to wish for a
pool or moat, which gets created at hero's feet without making him fall in
(unlike wishing for lava, where hero does immediately fall in).
Guard against buffer overflows when reading in score entries, in case
`record' has become corrupted or been maliciously modified. This addresses
the part of "#Q101: Security bug in nethack 3.4.3" that we have control
over. A Gentoo bug tracking discussion pointed out to us by <email deleted>, describes how that particular Linux
distribution makes users be members of the games group, allowing them to
modify files in nethack's playground directory when it has been set up in
the usual ``setgid games'' manner, thus making score processing in that
environment be vulnerable to buffer overrun exploits.
There was a report recently about "<pet> is still eating" coming out
on the console at end of game for player using X11 or Qt. That happened
because the end-of-game pet handling takes place after the message window
has been closed. It won't happen with the dev code any more because eating
no longer prevents pets from accompanying on final ascent or escape. But
a pet carrying the Amulet should still fail to tag along and yield similar
result. However, levl_follower() was changed (probably by me...) to have
pets not attempt to follow when they carried the Amulet, rendering code
in keepdogs()--which reported them as being confused--unreachable. This
reverts levl_follower() to have Amulet-carrying monsters other than the
Wizard try to accompany the hero during level changes (and keepdogs still
prevents them from succeeding). It also reorganizes keepdogs() a bit,
giving trapped followers an extra chance to escape from their trap and
preventing those who fail that chance from tagging along (previously,
non-pets ignored being trapped).
After doing that, I got tty to behave similarly to the X11/Qt report:
a message behaved strangely. In my case, it was delivered between a pair
of clearings of the screen and only visible by using terminal emulator's
scrolling buffer. I think there's a wait_synch() missing somewhere, but
haven't tried to figure out where. Instead, this makes the end-of-game
call to keepdogs() take place sooner, while pline() still works normally.
Dying at a shop doorway, or at the free spot one step in, while not
owing the shopkeeper anything would yield "<shk> gratefully inherites all
your possessions" but leave those possesions where the next hero could
just pick them up for free. Move them all the way inside the shop, as
happens when the hero dies while owing the shk. Also, if hero has gold
left after shopkeeper takes any payment owed, force it to go into shk's
inventory instead of having it end up in the pile of other stuff.
finish_paybill() duplicated much of drop_upon_death(), but not the
two-weapon hack to avoid curse() causing hero's secondary weapon to be
dropped while in the midst of removing it from inventory (but unlike the
old 3.4.1 panic for that, this one just triggered a warning about nonzero
worn mask). It also lacked the named fruit fixup, whatever that does.
Make finish_paybill() call drop_upon_death() instead of copying it.
Noticed while looking at the dipping code: #dip at a pool location
gives the chance to dip into the pool, and dipping a potion of acid into
such causes the acid to explode, causing damage and posibly killing the
hero. Use-up handling was being done after the dip had finished, so the
potion would remain in final inventory during disclosure and end up in
the resulting bones file if there was one.
From a bug report: zapping wand
of speed monster (or slow monster) at an immobile monster would give the
usual '<mon> is moving faster" (or slower) message even though the monster
couldn't move at all. This fixes that for monsters who can never move
and also for monsters who are temporarily paralyzed or asleep, although I
wonder whether speed change magic ought to also snap the latter out of it.
You can't begin or resume locking or unlocking a chest on the floor
while swallowed by a monster, but you could lock or unlock an adjacent
door in that situation.
From a bug report: you could end up
standing on water/lava if you survived being on an open drawbridge while
it was destroyed. This fixes the bridge destruction case; opening and
closing are handled differently and I left them alone.
Trunk and branch, noticed while working on an interface enhancement:
you could use #force to break the lock of a chest that's on the floor
while you're engulfed, also while levitating or mounted w/o riding skill.
Trunk only: refine an earlier fix that bills for breaking the lock
of a shop-owned chest. The item which the hero is forced to buy showed
up in the bill as unlockable, which is accurate after the fact but didn't
reflect the shop's item. Fix by billing for chest before altering it.
Simplify <Someone>'s patch (the part for the secondary weapon wasn't and
still isn't needed since dual-wielding can only occur when both primary
and alternate weapon slots contain weapons or weapon-tools, but we might
as well keep it). There was at least one other case where wielded in-use
leash could be removed from inventory without becoming unleashed first:
a bullwhip-wielding monster could snatch it away.
That lead to some other whip issues: monsters who select disarming
via bullwhip as miscellaneous strategy had 80% chance of not using it on
any given turn, but had no chance to select another misc strategy on such
turns--they always resorted to ordinary nonMUSE behavior and usually just
attacked. The adjacency check missed diagonal locations, also would aim
the disarm attempt accurately even when displacement or invisibility made
the hero's precise location unknown. [I took the easy way out here and
only let them try to disarm when they know the hero's location. It's
tempting to aim at the guessed location and sometimes accidentally disarm
a nearby monster, but disarming is an action which targets a particular
weapon rather than just a location.] Lastly, disarming always targetted
hero's primary weapon, never a dual-wielder's secondary one.
From a bug report, if you polymorph into
something, like a killer bee, that causes you to drop your weapon, but the
weapon is a wielded, in-use leash, the leash would be dropped but retain
it's in-use state. However, the leash was tied to you, so it seems it
should remain attached, just unwielded, just as it would if it hadn't been
wielded. I've changed the behavior to do this. I wonder whether one
should be able to wield an in-use leash.
From a bug report: gelatinous cubes
could engulf Rider corpses, allowing g.cube and cargo to be teleported
away without triggering corpse revival, or to be hit with theft attack by
poly'd hero to get the corpse into inventory so it could then be put into
a container in order to prevent revival (or to be destroyed via bag of
holding explosion or cursed access).
Noticed while checking out the report that you can #jump when riding
a sleeping steed: hero's sleep resistance or magical breathing prevented
sleeping gas traps from hitting steed. "You are enveloped in a cloud of
gas" but your steed is untouched? That didn't make sense.
From a bug report, applying a bullwhip
towards a monster to try to steal its weapon would report that a cursed
cockatrice corpse was welded to the monster's hands even though corpses
wielded by the player never become welded. Code for monsters deciding
what to wield knew that corpses don't weld; everywhere else seems to
assume that they only wield weldable weapons. Add a routine to check
whether a wielded item is welded, similar to what's done for the hero. I
fixed a couple of other spots besides use_whip() but didn't hunt all over.
From a bug report, putting an object with
really long specific and type names into a container with really long
specific and type names caused the program to crash. pline() overflowed
the buffer it formatted into, and even though it was able to send that
for output and trigger a --More-- prompt, eventually a segfault occurred.
Give vpline and vraw_printf a much bigger working buffer, then truncate
the formatted text to BUFSZ - 1 characters so that we don't just push the
long line trouble into the separate interfaces.
From a bug report: if you try to tin a
Rider's corpse and revival fails, you still get the gimicky message about
War not preserving his enemies. Give the suggested alternate message in
that case: The corpse evades your grasp. I hope that we can do better
than that, but I'm too burned out to think of anything.
From a bug report: a shapechanger
which becomes a mimic would always stay as 'm' rather than take on object
or furniture shape. Same applied to monsters which hide in other ways.
The code did that deliberately, but I don't think that it's actually
necessary so this lets them mimic/hide when they're in the right shape.
If they change form to non-mimic/hider while concealed, concealment ends.
It would be fun to have shapechangers-as-mimics actually change their
mimicked shapes periodically, but this doesn't do that. They'd probably
change to non-mimic quicker than they'd mimic something else so it's not
worth the effort.
From a bug report, but
just received: if you choked while eating a cockatrice egg and survived,
the turn-to-stone sequence wouldn't be initiated. For such eggs, turning
to stone starts when the food is finished rather than when it's started,
and fpostfx() wasn't called for food that triggered choking so the egg
went away without actually being finished. Fortune cookies, lumps of
royal jelly, and a few other things suffered from the same situation.
From a bug report, hitting a rust monster with a
fireproof--but not identified as fireproof--weapon caused the rknown bit
to become set, identifying the item as fireproof. That would also happen
for a monster's anything-proof weapon if it hit a rust monster, whether
you could see it happen or not. The code involved is convoluted; I hope
this fix is correct.
From a bug report: you could vomit when polymorphed into a rat but real life
rats can't/don't vomit. The latter was confirmed by <Someone> and <Someone>.
While testing a fix for this, I discovered a couple of other problems.
Healing magic which cured sickness failed to heal Vomiting (potion or
spell; unicorn horn deals with them separately). Enlightenment failed to
report Vomiting (it's not shown on the status line). Most significant was
that vomiting_dialogue() called vomit() twice (also make_confused() and
make_stunned() three times for every once intended). It was dividing the
remaining turns by 3 and then using that value to decide what to do, but
only message display took into account that the same divided value would
occur on 3 consecutive turns (or just 2 for the final countdown to 0,
because dialog routine gets called before timed-property decrement).
From a bug report, but just received:
you can't affix candles to the candelabrum while underwater, because the
underwater check (can't light candles while underwater) is made too soon.
If you somehow managed to get a lit lamp, candle, or candelabrum while
underwater, you wouldn't be able to extinguish it for same reason. The
bug report included a URL for a fix, but I didn't look at that. This
changes use_candle() to rely on use_lamp() for underwater handling, and
changes use_lamp() and use_candelabrum() to check for extinguishing
before making the underwater check.
From a bug report. (Michael forwarded a newsgroup posting about it back
then, but I had trouble reproducing it and didn't figure it out until
trying again now.) If hangup occurred while entering the quest, the magic
portal could be rendered inactive for the hero but still work for monsters.
That's because the hangup save stored the old value of u.uz0 before
goto_level set it to the new u.uz, and a magic portal won't operate when
u.uz0 differs from u.uz (to prevent a pair of portals from getting stuck
sending the hero back and forth). The problem could also occur going from
the quest back to the dungeon, or either direction for Ft.Ludios, but the
--More-- prompt when the quest entry text is being displayed makes hangup
during level change most likely to occur during initial quest entry.
This is just a bandaid, and the SAFERHANGUP config wouldn't be hit
by this situation.
#Q85: Bug: wrest a wand in one turn through engraving
From a bug report: engraving with an empty wand while not levitating, then using
ESC to abort when asked for the text to write, let you attempt to wrest
the last charge without using up a turn. Between the time this report was
sent and received, someone else reported similar issue with levitation,
where no prompting occurs. The fix for it also fixed the original problem.
Somewhat inadvertently though, since you can now no longer write in the
dust with a empty wand. I'm going to leave it this way; all that's needed
is some feedback about failing to engrave.
From a bug report: if you
attempted to engrave with an empty wand while levitating, it wouldn't use
a turn unless you successfully wrested an extra charge out of the wand.
So you could always get such charge in a single elapsed turn of game time
if you didn't care about zapping in any particular direction; extremely
useful for wishing.
Noticed when checking this: when you did wrest the extra charge,
the engraving code accessed freed memory for the wand after it had been
used up.
Lastly, wands producing certain effects always become discovered,
even when you don't yet know what they look like. (This part of the patch
is trunk-only since it utilizes the routine which fixes similar case for
zapping.)
From a bug report: if you
were at one of the map edges and kicked away from map center while blind,
you'd get impossible("show_glyph: bad pos ..."). That was due to calling
feel_location() for the out of bounds location, which occurred after the
kick code had made use of invalid data so other problems might occur too.
Now you kick "nothing" as if it was something (hence possibly wounding
your leg, taking some damage, potentially dying). I didn't want to try to
classify the surrounding terrain as rock or air or whatever, and the thing
being kicked only shows up if the kick is fatal.
From the newsgroup: if polymorphed into a metallivore, you could eat
artifacts that you couldn't touch with your hands. Now you can't eat ones
which evade your grasp, and you take some damage from other touchy items
on--actually, prior to--the first bite. (Those still "taste delicious" if
you survive; I'm not sure whether this ought to be changed.)
From the newsgroup: slash'em lychanthrope character could throw
while in wolf form. That came straight from nethack; any animal capable
of manipulating an object--possibly with its mouth--could throw things.
Now hands are required. This doesn't require free hands, although it
probably should; it's kind of tough to imagine making a competent throw
while your hands are stuck to a cursed two-handed weapon.
From a bug report: shopkeeper
wouldn't move to block his doorway if there was a grave at that location.
Nothing supernatural; shopkeeper and temple priest movement was too
specific about what sort of terrain might be present and didn't know that
room floor might be replaced by a grave.
A recent change to force gold in inventory (during multi-item Drop or
applying/looting containers) to have '$' for its inventory letter for the
!GOLDOBJ configuration has revealed a bug which 3.4.3 has for the GOLDOBJ
configuration. Specifying a count followed by '$' to use a subset of
carried gold didn't work under tty; the $ was treated as a group accelator
and overrode the count, so full stack was always used. (The code a few
lines above this which counts the occurrences of group accelators already
includes this same fix: ignore an item's group accelator when it matches
the selector.)
I wouldn't be surprised if other interfaces are subject to the same
problem; since I can't test those I'm not attempting to fix them blindly.
Someone in the newsgroup claims to have reported this in mid-October,
but he uses a fake address in news and maybe he did so with his mail too,
resulting it not being delivered. Anyway, arming a land mine on the Plane
of Air, then setting it off, produced a pit in the air. This fixes that
directly, in case someone manages to do it again, and it also prevents
land mines and bear traps from being armed in midair in the first place.
Ditto for Plane of Water; water/pool locations were already covered (can't
arm there), and the bubbles ought to be treated similarly to Plane of Air.
When testing this, I managed to get a crash while restoring a saved
game. I had worn a blindfold and armed a land mine on the water level
(with just the no-pit part of the patch in place), then saved. When
restoring, I got a crash in restore_waterlevel() at one or the other of
these lines (traceback pointed at the first, but it has to have actually
been the second; an access violation from an address derived by applying
a small offset to a null pointer):
ebubbles = b;
b->next = (struct bubble *)0;
After that, I couldn't reproduce it with a wished-for trap and couldn't
stay in one place long enough again to successfully arm a trap object.
So there may be a nasty bug still present, perhaps now hidden by no longer
being able to create a new trap on that level.
Reading the comments in the previous patch, I realized that keeping
the old behavior for monsters who are shooting multiple missiles was
leaving an obscure but potentially serious bug. I haven't attempted to
trigger it but 3.4.3 is bound to be vulnerable.
From the newsgroup: ``Something is engraved here on the water.''
An engraving written on a lowered drawbridge would be transfered to the
underlying terrain when the bridge was raised. The coverse was also true;
if you plugged the moat and then engraved on the ground, that engraving
would remain visible--and touchable if blind--when the bridge was lowered
to cover its spot. Rather than try to handle two different engravings at
the same coordinates (with one of those two changing locations when the
bridge is raised or lowered), this just wipes out any engraving at both
span and portcullis locations whenever the bridge state changes, like is
done for traps.
Typing a response at the "Who are you?" prompt didn't allow digits in
the character's name under Unix and VMS; something like "arc15" came out
as "arc__". This allows them to be used anywhere except for the first
character. "arc15" now works; "15arc" ends up as "_5arc" so that there
still won't be a leading digit abutting the uid value when they're joined
to form the save file name.
Also from the newsgroup (2nd from "Three bugfixes for Xorns" [I got
the subject wrong on the previous spell of protection patch]): when
phazing through walls or rock you could engrave as if it was ordinary
floor. Again I didn't use the user's patch; it left closed doors, raised
drawbridge, and iron bars as locations where engraving was still feasible
and said "you can't write in solid rock" even if you were inside a tree.
[The 3rd of "3 xorn fixes" was for misleading feedback when attempting to
engrave while underwater; we've already fixed that one.]
There was a suggestion that you should be able to engrave within solid
rock if you use a wand of digging, and that seems like a pretty good idea,
but the check for location comes before the check for writing instrument so
would be tricky to implement.
