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.
My last fix from the Dec'04 report sent by <email deleted>. Many of its remaining observations/complaints are
about things which aren't bugs. This implements the suggestion that
doppelgangers should take on humanoid form, although it doesn't take away
the 1/7 chance for pick_nasty() and it can still fall back to arbitrary
shapes when it doesn't pick a humanoid within 5 tries. This also allows
doppelgangers to take on the shape of the various quest guardian monsters
[mostly the quest leaders' attendants, although there is at least one
extra foe (ninja)]. It excludes the quest guardian for the player's own
role, and I don't think there are any cases where it can yield unexpected
quest guardian behavior.
This also allows specifying monster class (via description or letter)
when #monpolycontrol asks for type of monster to give to a polymorphing/
shapechanging monster.
One of the complaints included in the Dec'04 report from <email deleted> was that spell of charm monster doesn't give
any feedback. This makes that spell, and scroll of taming, always give a
message. And the scroll will become discovered if a visible or sensed
monster gets converted from hostile or peaceful to tame, or from hostile
to peaceful.
Scroll of taming/spell of charm monster didn't hit steed when hero
is mounted; now it does. I don't know whether that matters though. You
can saddle a non-tame monster, but you can't ride one even in wizard mode.
However, I'm not sure whether a tame steed you're already riding can
become untame, let alone if it can do so without throwing you. If latter
is possible then re-taming while still mounted has now become feasible.
Another item from the Dec'04 report sent in by <email deleted>. When prompted for a type of monster to polymorph
into, giving a monster class description like "dog or other canine" (or
single letter like 'd'), triggered "I've never heard of such monsters".
Instead of adjusting the message, this chooses a member from the class.
I put this into the fixes file as a new feature.
<email deleted> reported a long list
of inconsistencies and suggestions. This attempts to address the ones
about werecritters and vampires.
> Polymorphed player does not get werecreature changes. (intentional?)
> Player in were form does not turn into werehuman form, ever. (Previous
> bugged behavior was that player turned into a plain human)
> Player afflicted with a were cannot polymorph into werecreature or
> werehuman form.
The first guess is right; being polymorphed blocks lycanthropy state
changes. The second is not a bug either; hero is either a <werecritter>
when in beast form or a <role> when in human form, never human werecritter
monster. The last one feels more like a bug though; it happened because
all lycanthrope monster entries are marked NOPOLY. This patch extends
an earlier post-3.4.3 change to allow player with polymorph control to
explicitly specify werecritter when in role form or human werecritter when
in beast form to toggle shape. It also allows closely related monsters
to toggle from role to beast (ie, "giant rat" yields wererat).
> Vampire or Werecreature changing form may change sex.
Now the three semi-controlled changes--becoming a dragon due to armor,
toggling were form, and vampire into various critters--are prevented from
having the 10% chance of sex change kick in. For monsters, lycanthropy
didn't apply (sex never toggles) and vampire shifting is now covered but
turning into a dragon due to scales/mail remains susceptible to sex change.
Also, post-3.4.3 code made polymorphing into a vampire enable the
#monster command but neglected to tell the player.
Reported two months ago by <email deleted>,
having a water elemental become trapped in a bear trap seems pretty
strange. Fixed by marking water elementals as M1_UNSOLID (like air and
fire elementals), which has a side-effect of making them immune to webs
as well. Tweaked some unused digging code which checks unsolid(), added
unsolid() to the types allowed to bar through iron bars, and brought the
check for whether a monster is willing to enter a bear trap location up
to date. That code also needed an update to reflect the change made to
anti-magic traps last year. Lastly, there was another report which
suggested that being hit by a bear trap should dish out some damage
(along with a suggestion that wand of opening should work to escape such
traps, which has already been done). This makes bear trap do 2d4 damage
(on entry, not when trying to pull out after becoming stuck).
Back in <email deleted> complained
that randomly generated giants in Sokoban would drop boulders when killed,
interfering with the puzzle solution. He suggested that giants either
be disallowed or be generated without inventory in that dungeon branch.
This doesn't go that far; it just rejects giants on the first pass during
random monster selection, making them much less likely to appear there
but still allowing them if giant is chosen two times in a row. (Existing
boulders aren't an issue here; giants can't pick them up in Sokoban.)
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.
Back in <email deleted> in #U1216
suggested that statues of stone golems which are hit by stone-to-flesh
spell should leave flesh golem corpses instead of meatballs. But they
should actually have revived as flesh golems. Stone-to-flesh revival of
golem statues and golem figurines didn't work as intended because golems
other than flesh or leather were considered to be vegan/vegatarian, which
caused them to produce meat rather than living monsters. Also, S-to-F of
a leather golem statue worked as intended and created a flesh golem, but
S-to-F of a leather golem firugine created a leather golem out of stone
object. This fixes it so that any type of golem statue or golem figurine
revives as a flesh golem.
Two other bugs noticed and fixed: (1) S-to-F cast on self while a
figurine of a non-veggy monster was "worn" in one of the three weapon
slots triggered an "extract_nobj: object lost" panic similar to several
similar cases which were recently fixed (that was 3.4.3; for development
code, it gave "obfree: deleting worn obj" warning instead). (2) S-to-F
activating a shop-owned figurine didn't charge for it.
Back in Nov'04, <Someone> pointed out that even with only 5%
chance for dropping a horn upon the death of a unicorn which has been
revived from corpse, it's still possible to produce a nearly unlimited
number of them for polypile fodder. This bumps the chance for a horn up
to 50%, but flags the horn as coming from a revived corpse and makes such
horns be treated by polymoprh as if they're non-magic (which practically
guarantees that they'll poly into mundane tools instead of magic ones).
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.
Reported last August by <email deleted>: the code
that decided whether hero poly'd into a pudding would be split when being
hit by an iron weapon always reduced damage by u.uac if armor class is
negative, whereas the normal amount is -rnd(-u.uac). So player pudding
with good armor always got maximum reduction. Probably had little actual
effect on game play; puddings can't wear armor so would need to be using
rings and/or spell of protection and/or have eaten rings of protection
while in some previous metallivoric form in order to get good enough AC
for this to matter.
From a bug report, kicking unpaid
food in a shop at a tameable monster resulting in taming the monster
without charging for the used-up food. This forces kicked objects that
are owned by shops to be put on the shop bill and flagged as unpaid, which
is normally reserved for carried items but makes kicked ones behave like
thrown ones. (If they land inside the shop without breaking, they're
removed from the bill.) So kicking food to make a pet now results in the
item being moved from the shop's unpaid bill to its used-up bill, same as
for thrown food. Although the latter kept billing consistent, it lacked
shop billing feedback; this fixes that too.
Wielding a bow while kicking arrows gave a shooting bonus. Also,
From a bug report: applying a
polearm to hit at range never caused a pudding to split because the attack
gets treated as throwing. Likewise, confuse monster effect (hands glowing
red) didn't kick in for applied polearms.
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).
<email deleted> reported back on 8/31/06 that elven weapons were not
affected when he poked a fire elemental with them. This is true, but
moreover, there was no code to have passive fire to affect attackers.
Now erode_obj() supports all the same damage types as rust_dmg(), and added
the connecting code to allow passive fire attacks do something.
There probably should be macros for the damage types used by rust_dmg
and erode_obj, and possibly these functions should be combined, but they
are slightly different and dealing with that requires more thought.
Make polymorphing or changing alignment perform a touch check (as is
done when catching lycanthropy) on wielded weapon(s) to see whether the
hero can still use them in his new form. Part [2 of 2] will update
retouch_equipment() to check all items in use rather than just weapon(s).
(A comment or two in part 1 already refers to expected behavior of part 2.)
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).
From a bug report, trying
to invoke a wielded artifact after changing alignment resulted in "the
<artifact> evades your grasp" but it remained wielded, contradicting the
message. This adjusts the message in touch_artifact() if the object is
already in inventory, and adds retouch_object() to handle cases where
failing to be able to touch ought to force unwearing/unwielding.
From a bug report, applying a stetoscope to
a mimic which was hiding would report that mimic's stats but not bring it
out of hiding, unlike the behavior for other types of hiding monsters.
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.
Part of the final score is doubled for ascension. Some players use
helm of opposite alignment in order to offer and ascend at the first astral
altar they reach. This limits the score doubling to ascending with your
original alignment intact, penalizing (for the subset of players who care
about score) alignment manipulation. Converting to a second alignment and
then using a helm of opposite alignment to switch back and offer to hero's
original deity yields a smaller bonus (one-and-a-half instead of doubling).
Offering to either of the other deities (either via permanent conversion
or temporarily switching via helm or both) gets no score bonus.
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.
Suggested by <email deleted>. The level compiler allows
MESSAGE directives to provide text given upon initial entry to particular
levels. Modify the code that delivers them to support quest pager text
substitution. It could also be tweaked to support deliver-by-popup-window
in addition to deliver-by-pline, but I didn't go that far.
He also suggested revising the message for the Plane of Air, but it
seems ok to me. Instead, I've changed the message for the Astral Plane to
announce that it holds "the High Temple of <your deity>" rather than the
quite lame "the High Temples of the aligned gods".
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.
There's newsgroup discussion about a mind flayer sucking the brains
of a ghost, plus speculation that the fix for C343-121 has already taken
care of it. I agree with them that ghost's brains are too insubstantial
to be hit by brainsuck damage from mind flayers' tentacles. C343-121 is
vague enough to cover this; the corresponding fixes entry was more specific
and is augmented here.
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.
Update the brief explore mode section (it hasn't been a conditional
feature for quite some time, there's an extra way to access it now, and
new game started with -X is different from switching via the 'X' command)
in the Guidebook, and add a short debug mode subsection there.
Reported to the beta-testers list by <Someone> last April:
restoring a normal game save file in explore mode let you keep the file,
then after exploring and quitting without saving, you could restore it
again in normal mode and take advantage of whatever information you'd
gained. This makes nethack -X (or playmode:explore) defer the switch to
explore mode when used while restoring a normal mode save file. It now
performs a normal restore (with save file deletion) and then acts as if
the user had given the 'X' command interactively, requiring confirmation
to actually switch into explore mode.
[see cvs log for src/options.c for some additional info]
Relief for the command-line impaired. Allow player to request
explore or wizard mode via run-time config file or NETHACKOPTIONS.
Validation is left to xxxmain() and has been updated for Unix, VMS, and
ports which share pcmain. Mac and Be appear to allow any user to access
wizard mode, and may not need any modification, although they'll continue
to have the old buglet of running with both wizard and discover flags set
if player uses `nethack -X -D'. This may or may not work as-is for the
Qt interface depending upon whether it goes through one of the xxxmain()'s
mentioned above [someone needs to make sure that it doesn't allow Qt on
Unix to bypass the (username == WIZARD_NAME) test when user requests
wizard mode].
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).
From a bug report: when riding,
#jump command and jumping spell didn't check whether steed is able to move.
This makes #jump command, either magic boots or knight's innate ability,
fail if the steed can't move. Spell still succeeds; its magic overrides
steed's immobility. Fix is trunk only since it relies on a function that
isn't in the branch.
Also, tweak hero movement to avoid an extra function call per move
when not riding.
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.
