Reported seven years ago, when ice melts underneath a monster, it
hovers there until its next move, then falls in and drowns. Dunk it
immediately, and give hero credit/blame if it happens during the
hero's turn (so presumably the melting was caused by the hero).
Also, let monster with teleport capability who gets dunked teleport
away from the water before getting wet, the way hero does.
Fixes#169
Monsters should not be afraid of stepping on the vibrating square
since it's only a trap for display purposes. [Perhaps they should
deliberately avoid it if the hero hasn't seen it yet, but I didn't
implement that.]
"You see a strange vibration beneath <mon's> <parts>." was strange
when <parts> was a wolf's "rear paws" or horse's "rear hooves"--was
the vibration magically skipping the front ones? And it sounded
naughty when it was a snake's "rear regions". If the creature has no
limbs or is floating or flying, just say "beneath <mon>"; otherwise,
if the part is "rear <something>", omit "rear ".
The message was weird in another way. Caller removes the monster
from it's old location and places it on the new one, calls newsym()
for the old location to show lack of monster, but then calls mintrap()
before newsym() for monster's new location (the trap's location). If
pline messages cause buffered map output to be flushed, the monster
will be missing during the time the messages are delivered. I fixed
that for vibrating square [seetrap()->newsym() before pline() rather
than after] but it should probably be fixed in the caller instead.
A change I included with the vault guard fix was triggering fuzzer
panics about dead monsters on the fmons list. I'm not quite sure why;
I couldn't reproduce it interactively. [Perhaps caused by hero killing
a monster and then getting another move before monsters get their turn,
but trying to do that still didn't trip the dead monster sanity check.]
Suppress that check so that the fuzzer can run amok.
Also, a waiting-to-exit vault guard could move extra times, uselessly
since ''hero hasn't left temporary corridor yet'' is why he's waiting,
if there were any monsters fast enough to get extra moves before the
hero's next turn.
"Placing monster over another?" warning was triggered for vault guard
by an earlier change which made m_detach() stop removing monsters at
<0,*> from level.monsters[][]. So one guard would replace another at
<0,0> for however many guards were created, and memory for all but
the last one would be lost.
This involved a lot of flailing about and the patch includes various
things would could have been discarded. One or two extended monster
sanity checks are included, plus a couple of debugpline()'s for
tracking guard movement.
Stinking cloud placed near water or poison gas breathed across it
would affect and potentially kill underwater monsters. Most swimmers
are on the surface and should be affected, but eels and other fish
shouldn't be.
This also changes minliquid() to not treat flying and levitating as
ways to survive water when on the Plane of Water.
I think goodpos() needs to be taught about that Plane (where many ways
of existing at a water location don't apply). This doesn't do that.
During level change, when a monster from mydogs (monsters accompaying
hero, usually pets) couldn't be placed because the level was full, it
was set to migrate to that level (in order to get another chance to
arrive if hero left and returned). The code sequence
mon_arrive()-> mnexto()-> m_into_limbo()-> migrate_to_level()-> relmon()
tried to remove the monster from the map, but it wasn't necessarily on
the map (depending upon whether it couldn't arrive at all, or arrived
at the hero's spot and couldn't be moved out of the hero's way). The
EXTRA_SANITY_CHECKS for remove_monster() issued impossible "no monster
to remove". relmon() now checks whether monster is already off the map.
While investigating that, I discovered that pets set to re-migrate
to the same level to try again on hero's next visit didn't work at all.
migrating_mons gets processed after mydogs so moving something from
the latter to the former after arrival failure just resulted in
immediate second failure when the more general list was handled during
the hero's current arrival. And failure to arrive from migrating_mons
would kill the monster instead of scheduling another attempt.
The sanest fix for that turned out to be to have all monsters who
can't arrive be put back on the migrating_mons list to try again upon
hero's next visit. Pets still fail twice but are no longer discarded
during the second time, and now do arrive when hero leaves and comes
back provided he or she has opened up some space before leaving. If
there's still no space on the next visit, monsters who can't arrive
then are scheduled to try again on the visit after that.
Recent fix for invalid corpses becomes moot. Monsters aren't killed
during arrival failure so there are no resulting corpses to deal with.
Migrating monster attempting to arrive on a level which is already
full of monsters gets killed off. It was leaving a corpse without
regard for whether it was a type of of monster which should never
leave corpses.
I'd prefer that it be put back on the migrating_mons list rather
than be killed off, but this just suppresses impossible corpses.
Sometimes we free the monster data, but the monster is not on the
map - usually this happens if the map is full of monsters and a new one
is migrated on the level.
Make m_detach check the monster x coordinate, so it knows not to touch the map
if the monster isn't on it.
Don't "feel like a hypocrite" when on Elberth and attacking a monster
which isn't scared by Elbereth (exception: peaceful creatures aren't
scared but attacking them in such situation is hypocritical anyway).
This means that players can use Elbereth to scare away some creatures
while continuing to fight others. Elbereth won't be automatically
erased, but weapon attacks will scuff the engraving; wand zaps don't.
Reduce the -5 alignment penalty when alignment is 5 or less. Reduced
amount is -(1..5), so -3 average.
Remove trailing spaces, and remove tabs from the files that had
trailing spaces.
Also, rndorcname() was using a random value to terminate a loop
and was recalculating a new one each iteration.
Iron bars can be destroyed in some circumstances (hit by yellow
dragon breath or thrown potion of acid, being eaten by rust monser
or black pudding, or by poly'd hero in those forms) and should act
like walls for diggable/non-diggable purposes. But they aren't
walls, so the non-diggable flag was not being set for them by the
special level loader. Even once that was changed, they weren't
being handled consistently. Some places checked for non-diggable
directly (zap_over_floor of acid breath, potion of acid hitting bars)
and started working as intended, others used may_dig() to check
non-diggable (poly'd hero attempting to eat iron bars) but it doesn't
handle iron bars, and still others didn't check at all (bars-eating
monster who moved onto bars location in expectation of eating those
next).
The report was "doesn't kill even if unchanging", but it does cause
rehumanize() when not Unchanging, the same thing that happens when
you die due to loss of hit points. But losing the activating word(s)
and then having Unchanging retain the clay golem shape does seem
wrong, so make losing the word(s) while being unable to revert to
normal form be fatal.
Poly'd hero (without Unchanging) reverts to normal when cancelled,
so make monsters behave that way. Previously, only werecritters in
beast form were forced to human form. This changes cancellation to
make shapechangers and hiding mimics take on normal form too.
Cancelled shapechangers now behave as if the hero has the
Protection_from_shape_changes attribute and will be unable to change
their shape (after having been forced into normal form). Getting
polymorphed in any fashion uncancels them prior to giving new shape.
[There may be some newcham() situations that should be disallowed
when cancelled rather proceeding and consequently uncancelling.]
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.
Wizard mode sanity checking gave spurious "mon not on map" warnings
for steed when hero is mounted. Steed is in the fmon list but not
expected to be present on the map.
If we do it the other way round, then mimics will forget what
they're mimicking without a seemimic() call, meaning that the
line-of-sight calculations can get confused if the mimic was
mimicking something opaque.
The special level loader would allow the level description to specify
an alternate monster appearance for any type of monster, and if one
was specified for a mimic then that mimic would be polymorphed into
the appearance instead of masquerading as it. This changes it to
only use an appearance for mimics, the Wizard, vampires, and general
shapeshifters (chameleons, doppelgangers, sandestins). The mimic
case doesn't work as expected: map display shows the symbol for the
specified shape but farlook describes it as a mimic. The Wizard case
hasn't been tested. The chameleon and vampshifter cases seem to work.
It also allowed shapechangers (including vampires) to be given an
object or furniture appearance. I didn't try things out to find out
what what their behavior would be if/when that happened.
I'm not sure whether the farlook issue for mimics-as-monsters is with
the pager code or the monster name formatting code. (Possibly the
mimic just needs to be flagged has 'hidden' as well has having an
alternate appearance.) I'm not going to worry about it since none of
our special levels attempt to give mimics a monster shape. Mimicking
a monster is a feature for clones of the Wizard, not for mimics,
although it might be nice if the latter worked correctly someday.
This change was coded by FIQ, who suggested it by email.
The main change here is related to monster anti-oscillation code.
When a monster believes it's stuck in an AI loop, it looks for an
alternative strategy. That applies to pets too. However, if the
pet is currently near the player, we can typically assume that it's
there because it wants to be there, and an oscillation is not
because it's stuck but because it's already in the best possible
place. This commit causes pets to be "allowed" to stay near the
player, rather than running the wrong way down a corridor because
it's the only way to do something different than what they're
currently doing.
If the pet is far from the player, we use the old behaviour unless
the pet is leashed or the player tried to call it with a whistle
or the like, in order to avoid the risk of a genuine AI loop trying
to get back to the player. (Whistling happens rarely enough that it
won't cause AI loops of its own - the player isn't going to whistle
every turn - and it makes flavour sense that a pet might interpret
it as "you're going in the wrong direction!".)
[Subject was actually "possible bug with shape-shifted vampires".]
The observation was that a pet vampire which took on fog cloud form
would just stay a fog cloud, rendering it nearly useless as a pet.
Fog clouds are too weak to attack dangerous monsters so are rarely
subject to damage from counter-attacks, so they wouldn't even get
killed to revert to vampire form.
Make a vampire in fog cloud form--hostile or tame--sometimes change
to bat form if not in view or out of missile range (the same criteria
used by vampires to change into alternate shape to begin with). Bats
are slightly more useful as pets and definitely more prone to revert
to vampire. The potential transformation from bat to cloud isn't
done randomly; that already occurs when encountering closed doors.
From the newsgroup, remarking on an usual cause of death seen at NAO.
Surviving a gas spore's explosion (via hit points, not from life-saving)
left "gas spore's explosion" as stale killer.name. Being killed by
opening a drawbridge (but not by closing or breaking one) only assigned
killer.name if it didn't already have a value, so the stale reason got
used: crushed to death by a gas spore's explosion.
This fixes it two ways: clear the stale value after surviving the
explosion, and assign a specific reason when opening the drawbridge.
This also removes stale reason for death set up by various drawbridge
activity. For the usual case, the hero only survives by life-saving
which does its own clearing of killer.name. But there might have been
cases where it was being set for the hero when operating on a monster,
so no life-saving involved. The drawbridge code is not the easiest
code to navigate....
Report was for a blinded horse which ate a carrot but remained blind.
This fixes that, and also lets blinded carnivorous pets eat carrots.
Gelatinous cubes now handle carrots too, but since they lack eyses
there won't be any noticeable effect for them.
Report was about "Pet vampire" but the relevant aspect was that the
vampire had been assigned a name, not that it was tame:
You observe a Hilda where a Hilda was.
Investigating this has uncovered two other bugs, one potentially
serious. m_monnam() overrides hallucination but seems to be getting
used to some situations where hallucination should be honored (several
instances). Dynamically constructed format strings are including
monster or object names in the format (rather than the usual use as
arguments), so player assigned names containing percent signs could
cause havoc (a few instances). This fixes some of the former and one
of the latter, but doesn't deal with various other cases revealed by
grep.
Simlify the earlier revision for "the seemingly dead creature suddenly
transforms and turns into a vampire". x_monnam() already handles "the"
the way we want here: it's suppressed when the monster has a name
assigned and the "seemingly dead" phrase is omitted.
Fix a couple of weird messages issued when a shape-shifted vampire
is "killed" and reverts to regular vampire form instead of dying.
First weird one was when vampire has been given a name, as reported.
Second was noticed while fixing that: when cause of death destroys
the creature so thoroughly that there'd be no corpse, the alternate
phrasing for noncorporeal or amorphous form should be used.
old:
The Dracula suddenly transforms and rises as Dracula!
The vampire bat is disintegrated. The seemingly dead vampire bat
suddenly transforms and rises as a vampire!
new:
Dracula suddenly transforms and rises as a vampire!
The vampire bat is disintegrated. The seemingly dead vampire bat
suddenly reconstitutes and rises as a vampire!
Some discussion in the newsgroup about nearby peaceful monsters becoming
hostile if they observed the hero attacking a peaceful monster made me
look at the code and I spotted a couple of problems. An auto array was
being initialized in an inner block--some pre-ANSI compilers couldn't
handle that. Worse, it was inside a loop and may or may not have
resulted in unnecessary setup each iteration. Make it static. Oddly,
the array had the same name as a function but `gcc -Wshadow' either
didn't notice or didn't care.
A more significant problem was that mon->mpeaceful was being set to 0
without checking whether mon->mtame was set, potentially resulting in
humanoid pets being both tame and hostile at the same time. This change
prevents that but doesn't do anything interesting about pets who observe
attacks against peacefuls. (I also wonder why chaotic peacefuls now get
upset by seeing other peacefuls be attacked; it seems out of character.)
There was also a check for non-humanoid peacefuls seeing another of the
same species be attacked, but it was checking for an exact match without
regard for littler or bigger incarnations of the same species. I've
added the latter.
This also reformats a couple of block comments.
Back when dead green slime left a corpse, gelatinous cubes wouldn't
eat that, but they would eat globs of green slime without being
affected. Add the missing glob check so g.cubes will engulf globs
of green slime instead of eating those.
This fixes melee kiting more comprehensively (it now doesn't work
against slower monsters either), and prevents you doing things like
opening up a gap when running from an imp (you couldn't do that in
3.4.3).
If you attack a monster under Elbereth protection, and it wasn't
scuffed by the attack itself, then it'll be automatically removed
with an alignment penalty. It no longer fades from scaring monsters;
only from being abused to attack monsters while protected.
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.
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.
From November, 2014, player thought eating a scroll labeled YUM YUM
while polymorphed ought to give a special message.
While implementing it, I noticed that if a g.cube managed to get on
to a spot containing a scroll of scare monster, it would eat that
along with everything else.
You kill poor goblin.
"poor" implies a pet; pet has a name; "the" is omitted for named
creature; hallucination suppresses name, so "the" needs to be
reinstated.
You kill the poor goblin.
