When cloning a monster, clear the clone trapped and hiding states.
When splitting a monster (eg. a black pudding), the clone could
be placed on a trap, so do mintrap.
When removing a monster from the map, clear the trapped state.
Preserve temporary fake object's previous dknown value by storing it
as a flag value within the m_ap_type field of the posing monster, and
recalling it when it is needed.
This is intended to help eliminate observable differences in price display
between real objects and mimics posing as objects.
98% of this is just switching the code to utilize macro M_AP_TYPE(mon)
everywhere to ensure that the flag bits are stripped off when needed.
Noticed while trying to find the reason for the wildmiss impossible(),
you could be teleported and then drop dead at the destination. A QM's
AD_TLPT hit also does 1d4 physical damage which gets applied after the
teleport. Getting "You die." seemed pretty strange, particularly after
picking the destination with telport control. This makes sure that the
damage will never be fatal when teleport is attempted.
Cleaver's ability to hit up to three adjacent targets could kill a
long worm and then try to cut it in two. When this was first reported
I was unable to reproduce it, but this time I've managed to do so.
But not reliably, so it's hard to claim that it's now fixed. However,
the new report's explanation of why it happens and suggested fix was a
big help. I had been trying to hit three tail segments, but you need
to attack a segment next to the head, then have Cleaver hit and kill
the head first (50:50 chance depending upon whether current swing is
clockwise or counter). Worm cutting would be looking at the location
of the targetted segment but there won't be any monster there when the
head dies. (Cleaver's attack itself already copes the situation where
its 2nd and/or 3rd potential targets aren't there any more by the time
it's ready to try to hit them.)
This is based on the multiple-RNGs code fron NetHack4, but using
only the parts relevant to the display RNG (and with substantial
changes, both because of post-3.4.3 changes, and because Nethack4's
display code is based on Slash'EM's rather than NetHack's).
I did much of this quite some time ago, as prequisite for a different
bug report about monsters vs shades, then set it aside. It ended up
being more complicated than I anticipated.
When deciding whether various non-weapon attacks might hit a shade,
hmonas() was not checking for blessed or silver armor that should have
been applicable. It did check boots when kicking, but not gloves or
rings (when no gloves) when touching, or outermost of cloak/suit/shirt
when hugging, or helmet when head-butting. (The last one is actually
moot because nothing with a head-butt attack is able to wear a helm.)
The problem was more general than just whether attacks might hit and
hurt shades. Various undead and/or demons are also affected by blessed
and/or silver attack but weren't for non-weapon attacks by poly'd hero.
At least two unrelated bugs are fixed: a rope golem's AT_HUGS attack
gives feedback about choking but was fully effective against monsters
which fail the can_be_strangled() test. And it was possible to hug a
long worm's tail, rendering the entire worm immobile.
The report also suggested that all artifacts be able to hit shades for
full effect, but by the time shades are encountered everyone has an
artifact so that would nullify a shade's most interesting ability.
TODO: monster against hero and monster against other monster need to
have similar changes.
Extracted from a larger patch: the only way to get silver damage
bonus from attacking with a shield of reflection (polished silver
shield) is to throw it or to wield it. Give different feedback when
hitting something while wielding a shield (or an iron ball; it seemed
appropriate despite having nothing to due with wanting to dish out
silver damage).
Regular two-weapon requires that both weapons actually be weapons or
at least weapon-tools. Simulation of that while polymorphed allowed
any one-handed object as the primary weapon.
This fixes the weapon related aspects of #H7980: having an alternate
weapon be used in cases where it shouldn't when polymorphed into a
monster form with multiple weapon attacks. The most egregious was
using an off-hand artifact, but it would also use off-hand two-handed
weapon, off-hand silver weapon when in silver-hating form, or any
reasonable off-hand weapon when wearing a shield. That last is iffy
whether or not to allow, since you'll still get the extra attacks
whether it switches to secondary weapon or stays with the primary.
I've made it re-use the primary since two-weapon mode doesn't allow
a shield. The other oddity was being able to use the secondary
weapon on the second swing even if the first swing was weaponless.
I went with ingoring the secondary weapon if there's no primary one
or if the primary is two-handed.
Report included "cursed secondary doesn't weld" but that has nothing
to do with polymorph attacking. I've changed that to drop the weapon
if you attack with it when it's cursed, similar to what happens when
secondary weapon becomes cursed while two-weaponing.
It also included "marilith's attacks beyond the second don't use any
weapon and can hit cockatrices without touching them". A marilith has
two weapon attacks and then four claw attacks. Claw attacks only use
the weapon if it hasn't been used yet, so marilith hits with primary,
secondary (or primary a second time if no secondary), claw, claw,
claw, claw and that's the intended behavior. It is able to hit
cockatrices if wielding anything at all, same as a monster with just
a single attack. Since it is impossible to wield six weapons or three
pairs of gloves, that has to be intended behavior too. Playability
trumps realism even if it is silly to hit without a 3rd through 6th
weapon and be safe from touching the target due to the 1st weapon or
one pair of gloves. [Situation is different from having no control
over unsafely biting something after making a safe weapon or claw
attack; perhaps a better solution would be to refrain from using the
four claw attacks when attacking something that is fatal to touch.]
Reported 14 months ago, a monster reading a scroll of earth which
dropped a boulder that killed another monster in an adjacent pit
was giving credit/blame to the hero and could also trigger a panic.
If the monster was killed, the pit would be filled and deleted via
m_detach and then when flooreffects tried to delete the same trap,
it accessed freed memory and deltrap could panic.
When SEDUCE is disabled, instead of swapping attacks in mons[] once,
do it on the fly in getmattk() whenever needed. That allows mons[]
to become readonly, although this doesn't declare it 'const' because
doing so will require a zillion 'struct permonst *' updates to match.
This seemed trickier than it should be, but that turned out to be
because the old behavior was broken. Setting SEDUCE=0 in sysconf or
user's own configuration file resulted in all succubus and incubus
attacks being described as monster smiles engagingly or seductively
rather than hitting (while dishing out physical damage). I didn't
try rebuilding 3.4.3 to see whether this was already broken before
being migrated to SYSCF.
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).
