Dropping an existing fragile item while levitating will usually
break it. Getting a new wished-for fragile item and dropping it
because of fumbling or overfull inventory never would.
Some callers of hold_another_object() held on to its return value,
others discarded that. That return value was unsafe if the item
was dropped and fell down a hole (or broke [after this change]).
Return Null if we can't be sure of the value, and make sure all
callers are prepared to deal with Null.
Salvage part of an old patch. Swapping places with any long worm,
even a baby one, always failed with "You stop. Foo is in the way!"
This lets you swap places with tame baby long worms, and adult ones
if they have no tail (which won't happen unless there are more than
32 long worms on the current level--even if a long worm appears to
be only a head, there is normally a hidden tail segment at the same
location).
hmon() can destroy the weapon being used, and known_hitum() would
still pass the pointer to the freed object to cutworm(). Remember the
relevant weapon attribute before using and maybe freeing the object,
then pass that attribute instead of the whole weapon. Also pass
'more-likely-to-cut' for axes in addition to blades.
thimonst() behaved similarly, although due to much different code
paths none of the objects that might get to hmon() were then passed to
cutworm(), so it wasn't vulnerable. But pass 'more-likely-to-cut'
for axes instead of for blades when thrown.
The original report complained that gremlins seemed impervious to
Sunsword's light yet a flash from a camera caused them to cry out in pain
despite "The long sword named Sunsword begins to shine brilliantly!"
This commit does two things:
1. A dmg bonus is applied against gremlins using a lit Sunsword.
2. Gremlins will generally avoid the light emitted by Sunsword.
There's a few minor flavor bits thrown in also.
It is understood that this effectively makes Sunsword provide
"gremlin-proofing", but the gremlin myth and Sunsword's characteristic
feature pretty much demand it.
bug 42
Fixes#133
Monsters who lost an amulet of life saving while having their life
saved wouldn't attempt to put on another amulet unless/until they
picked up some object. Likewise if they had a worn item stolen.
(There are probably other events which should re-check worn gear.)
The suggested commit had a life-saved monster re-check equipment
during life-saving which might have led to reports about them
effectively getting extra moves, especially if two-weapon fighting
or zap rebound with sequence of kill/life-save/kill-again allowed
the target to put on a replacement amulet of life-saving prior to
the second kill. It also wasn't amenable to dealing with stolen
equipment. This alternate fix sets a flag to have monster check
its equipment on its next move.
Fix a comment typo. While in there, change the cleave attack to
swing counter-clockwise the very first time instead of setting up
for that but then toggling to the opposite direction before the
actual attack. Also, refactor a bit of common code for choosing
< xdir[], ydir[] > index for next target.
I worked on this a while back but didn't commit it because I couldn't
figure out the dead monster which wouldn't die. Pasi beat me to that.
Clean up the Cleaver code some and make the three-target swing alternate
between counter-clockwise and clockwise to simulate normal right-to-left
swing followed by left-to-right backswing. (Alternation happens on each
swing regardless of whether it is consecutive with the most recent one.
That's suboptimal but easy....) Also, stop three-target attack early if
hero is life-saved after being killed by a passive counter-attack from
the first or second target.
Prevent rogue backstab and two-hander breaking foes' weapons when using
Cleaver hand-to-hand because getting more than one of either of those
bonuses at a time would be excessive. I think allowing those for the
primary target but not for the two adjacent ones would be better, but I
just thought of that and am not going back for another round of revising.
This doesn't incorporate the two pull requests: one to avoid hitting
tame or peaceful adjacent targets unless the primary was also tame or
peaceful, the other to avoid hitting unseen adjacent targets. I'm not
sure if that includes remembered-unseen 'I' on the spot or no monster
shown at all. (There's a third one about updating the map but it isn't
needed for the existing Cleaver code either before or after this patch.)
I'm in favor of the first one and am not sure about the second. My
original concern was that someone could use Cleaver to find/hit three
unknown monsters at a time via 'F' prefix, but forcefight aimed at
thin air doesn't reach the Cleaver code so that can't happen, nor can
attacking two known close monsters at once by targetting an empty spot
between them.
Due to inverted logic, hitting a blue jelly with the Cleaver could cause
a dmonsfree warning - the jelly would die, but then come back to life
via the passive attack. This is a post-3.6.0 bug
Report was for dual-wielding hitting an enchanter and assumed that
a resistant artifact as primary weapon was protecting vulnerable
secondary weapon. Actual reason was simpler.
When in normal form, dual-wielding attacks against creatures which
cause erosion to the weapon which hits them would only inflict the
passive erosion damage to the primary weapon, even if it missed and
secondary hit. Make primary attack always trigger passive counter-
attack--before second swing now, rather than after--even if it misses,
and secondary attack trigger another one if that hits. Both weapons
are now subject to passive erosion (but only when they actually hit);
when secondary weapon hits, hero gets a double dose of counter-attack.
Hero poly'd into a monster with multiple weapon attacks (various
leaders: dwarf lord, orc-captain, and so forth) would try to emulate
dual wielding and first hit with uwep then with uswapwep. But it
would do that even if uswapwep was a bow or stack of darts that the
player had no itention of using for hand-to-hand. Stick with repeat
hits by uwep when uswapwep seems inappropriate.
Splitting a pudding while dual-wielding would only do so when hit by
uwep of appropriate material, never when hit by uswapwep. So silver
saber and longsword could split if longsword was primary but never
split if saber was primary. Check material and splitting separately
for each hit. It's now possible to split twice with one dual-weapon
attack if both weapons hit and both are made of the right material
(iron or 'metal'; among relevant objects the latter is only used for
tsurugi and scapel).
When a monster killed a paper golem with a fire attack, the player was
told that the golem "burns completely" yet it might still leave some
blank scrolls as 'corpse'. The fix for that was one-line, but several
other death-by-fire situations which didn't report "burns completely"
were also leaving scrolls: fireball spell or scroll of fire or other
fire explosions (if any), also wand of fire. Fire trap and poly'd
hero with fire attack were already suppressing 'corpse'.
When hitting a monster with the Cleaver, you swing it in an
arc, possibly hitting the monsters to the left and right of
the targeted monster.
Based on code by Fredrik Ljungdahl
thitu() is mostly used for arrows and darts "thrown" by traps, but
scatter() uses it on items launched by a land mine explosion. Traps
had no need for potion handling, but scattering does. Changing thitu()
to call potionhit() required that more information be passed to the
latter in case killer reason was needed, and thitu()'s callers needed
to be updated since it now might use up its missile (only when that's
a potion, so scatter() is only caller which actually needed to care).
Quite a bit of work--especially the testing--for something which will
never be noticed in actual play. In hindsight, it would have been
much simpler just to make scatter destroy all potions rather than
allow the 1% chance of remaining intact (via obj_resists()), or else
leave any intact ones at the explosion spot instead of launching them.
Reported for nethack.alt.org where impossible events in to-be-3.6.1
trigger a panic instead of just a warning, being polymorphed into a
vampire and draining something to 0 HP (rather than killing it with
the bite attack) didn't properly kill off the victim unless it was
also being drained from level 0 to level -1, resulting in impossible
"dmonsfree: 1 removed doesn't match 0 pending". If the hero got
another move before dead monsters were purged, applying a stethscope
to the victim could trigger an actual crash rather than an impossible
escalated to a panic. Other actions such as attacking again probably
could too.
A followup included a diagnosis and one-line patch. I expanded the
adjacent comment when manually putting the patch into place.
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....
setmangry() and wakeup() were being used for multiple purposes. Add an
extra parameter to track which. This fixes several minor bugs (e.g.
whether monsters with no eyes were angered by (useless) gaze attacks
against them previously depended on the state of a UI option, and
the Minetown guards would be annoyed if you used a cursed scroll of
tame monster on a shopkeeper). It's also a prerequisite for the
Elbereth changes I'm working on.
drain_item() always assumed player was responsible, so called
costly_alteration() to adjust shop price of disenchanted item.
If it was unpaid and the effect was caused by a disenchanter
attack rather than by the hero, the feedback was nonsensical.
This also lets a disenchanter hit worn rings, amulet, or blindfold
if no armor gets targetted. Amulets, blindfolds, and most rings
have no charge to be drained, but several types of rings do.
for digesting a swallowed critter. The "you kill <critter>" message
was left implicit, but if hero gained a level, that made "welcome
to level N+1" look like it was issued out of sequence because it's
immediate and the "you totally digest <critter>" is delayed. Giving
the you-kill-it message explicitly makes things be more verbose but
avoids having the new-level message seem out of order.
and vs digestion. minstapetrify() was previously changed to
explicitly revert a shape-shifted vampire back to vampire form
when it was turned to stone. This does the same for monstone().
It also causes shape-shifted vampires to revert to vampire form
immediately when swallowed, so subsequent death via digestion or
engulfing damage doesn't have to deal with reverting changed shape.
I'm not convinced this is the right fix for either stoning or
being digested. Unlike with ordinary damage, where multiple hits
are usually needed to kill a vampire after it reverts to 'V' form,
here the vampire will be killed by the next successful stoning or
digestion attack in one hit. It ought to least try to flee.
I've hunted for other instances where monster hit points were set
to zero or less without calling the routine that kills off the
monster (see recent mon_unslime() vs zhitm()) and didn't find any
for mhp subtraction. I haven't checked for direct assignment yet.
For a while I thought I'd found several cases where a monster was
intended to be killed but got left with positive hit points, but
it turned out that lifesaved_monster(), of all places, was setting
them to zero. I've moved that to its callers so that it isn't so
well hidden. And changed several ''if ((mon->mhp -= dmg) <= 0)''
into separate subtraction and 'if' just so the mhp manipulation is
a bit more visible.
I think the only actual change here is the message for monster
being killed by lava, where glass golems now melt instead of burn.
Do it properly, using the arguments to xkilled() instead of reversing
the conduct counter after the fact.
The xkilled() flag value of '1' has been reversed. It used to mean
'display message' but now means 'suppress message' since both of the
other flag bits are for suppression. All callers have been updated
to specify either XKILL_GIVEMSG or XKILL_NOMSG so the underlying
number remains transparent.
Hitting a rust monster with a greased weapon would rust the weapon
instead of removing the grease. Likewise for monsters with passive
acid or corrosion damage. passive_obj() was ignoring grease.
When hero with two-handed weapon, or samurai with katana and without
shield, hits a monster which is wielding a weapon, there is a chance
for defender's weapon to be destroyed via shattering. The chance is
reduced--by increasing the chance to resist--if the hero's weapon is
rusty or otherwise eroded. That works as intended. This changes
things to make the chance be increased--by reducing the chance to
resist--if defender's weapon is rusty or otherwise eroded.
Let monsters who have a weapon attack for non-physical damage dish
out physical damage instead of doing the drain life or drain
strength they usually do if they happen to be wielding cockatrice
corpses or a couple of particular aritfacts that do more harm
than just level drain. (Other artifacts are candidates, but I
don't think it's worth checking for them since the monsters
involved have such a small chance of acquiring and wielding them.)
Also switch to physical if monster's ability has been cancelled.
Only barrow wight, Nazgul, and erinys are affected. Yeenoghu and
the Master Assassin have a weapon attack for physical damage and
another one for non-physical damage (not necessarily delivered in
that order). They haven't been changed--only the physical damage
attack has a chance to apply their weapon's special damage.
Another one from 4.5 years ago: the Tsurugi of Muramasa ought to
be able to split puddings in keeping with its special attack effect
of slicing things in two. The suggestion was more extreme: always
split instead of kill. This generalizes the less extreme version;
METAL weapons (scalpel and tsurugi) can now split puddings like IRON
weapons do even though their user faces no risk of having the weapon
become rusty. Sam's quest artifact receives no special treatment.
Bashing puddings with wielded iron-tipped projectiles was splitting
them. This prevents that (and also for metal-tipped ya).
The report that a tame Archon got two "<pet>'s long sword is not
affected" messages thought there was some duplication error when a
flaming sphere exploded, which was incorrect. Since an Archon has
two weapon attacks, getting that message twice just meant that both
attacks hit. However, the player has only 1/6 chance to suffering
passive fire damage to weapon, where monster-on-monster or monster-
on-polyd-hero was inflicting that for every successful hit, so
there was a bug here after all. Give monsters the same 1/6 chance.
Also, add even more verbosity to that message--now that it won't be
delivered so often--to mention what didn't affect the item.
While investigating this, I noticed that hitting a steam vortex
with a flammable weapon was doing fire damage to that weapon. Fire
damage in the steam vortex definition makes some sense in that it
allows fire resistance to give protection, but dishing out actual
fire damage makes no sense and is now prevented for passive counter-
effects.
The automated reformatting put a space in casts of the form
'(type)(expression)', yielding '(type) (expression)', but it didn't
do that for '(typedef)(expression)'. There are lots of instances of
'(boolean)(expression)'; (uchar) and (xchar) also occur. I haven't
noticed other types, but I haven't looked in very many files yet.
Last few && or || followed by end-of-line comments, plus tab replacement
and 'return' parentheses. Not as many of those; some of these files had
already had that done.
Also, tweaked non-cursed scroll of charging read while confused to be a
tiny bit more effective.
To do: find and fix block comments that immediately follow a line with
an end-of-line comment and got misindented to line up with that comment.
End of first pass, but '[&|?:][ \t]*$' doesn't catch trailing operater
followed by end-of-line comment so more needs to be done. As with the
past couple of batches, I've removed redundant parentheses from 'return'
statements but only for files that had continuation fix-ups.
I've also removed tabs from comments in some of the files, but didn't
start until part way through this subset of the sources.
Flesh out wet towels a bit:
1) wielding a wet towel--or a dry one which becomes wet--won't give a
"you begin bashing with your wet towel" message when attacking;
2) if a formerly wet towel dries out completely while wielded, *do* give
"you begin bashing with your towel" on the next attack;
3) successfully hitting with a wet towel no longer always loses wetness;
4) water damage to dry towel always confers at least 1 point of wetness;
5) taking fire damage (via burnarmor() which is used for most types of
fire damage) has a chance to partially or fully dry a wet towel
(regardless of whether it's wielded at the time; applies to monsters
as well as hero; each towel being carried is checked until one is
affected, then any others escape drying.
Not done:
-) attacking with a wielded wet towel perhaps ought to be treated as a
weapon attack using whip skill rather than an augmented arbitrary-
junk-by-weight attack;
-) throwing a wet towel should probably ignore wetness--it's just a wet
piece of cloth when not finishing with a whip snap; right now, it
loses a point of wetness when thrown and usually--#3 above--another
point if it hits...;
-) hitting burning creatures is no different than hitting anything else;
-) likewise for hitting wet creatures.
Dipping a towel into a potion, fountain, or some other water source
makes the towel wet. Hitting with a wet towel deals up to 6 points
of damage, but every hit reduces wetness, as does throwing or applying
the towel. You can also wish for a moist or wet towel.
Instead of making the caller remember to use MON_NOWEP, make
setmnotwielded handle that automatically. This fixes the
"bad monster weapon restore" errors I've been seeing.
Also adds sanity checks for this.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
