Reported directly to devteam rather than via the web contact form:
throwing wielded aklys while swallowed would hit the engulfer and
return to the hero's hand but leave a stale 'thrownobj' pointer if
the monster survived. Under usual circumstances, throwing anything
else or throwing the aklys again when not engulfed would clear that
pointer, putting things back to normal. However, killing any engulfer
with the same weapon would try to add it to engulfer's inventory to
be dropped as it died. If the killing blow was via melee rather than
another throw, the object in question would still be in hero's
inventory instead of free, hence panic.
The initial returning-aklys implementation shared Mjollnir's code
which doesn't have this issue. This reverts from having attached
aklys always returning successfully when thrown while swallowed to
Mjollnir's 99% chance of return and 99% to be caught when it does
come back. (That was already the case if the engulfer was killed by
the throw, where hero wasn't swallowed anymore after the damage was
inflicted.)
causes "dmonsfree: N removed doesn't match N+1 pending" warning. The
sandestin monster definition flags it as MR_STONE, immune to being
turned to stone. If the hero hit it with a cockatrice while it was
shape-changed into something which isn't MR_STONE, it had its mon->mhp
set to 0, so died, and its form (mon->data) was set back to sandestin.
known_hitum() decided that it didn't turn to stone because of MR_STONE
for that form so proceeded to kill it off due to lack of hit points,
causing it to die twice.
I started to change that so that it didn't kill off the critter a
second time, bit it really shouldn't be able to kill it by stoning in
the first place. So sandestin how shares some vampire code to revert
to innate form and not turn to stone when "killed" by stoning. It
only yields the normal visible polymorph message: "the <foo> turns
into a <bar>" without any attempt to explain why. Once in sandestin
form, smacking it with a cockatrice corpse doesn't do anything special
(due to MR_STONE now being unambiguously in effect). It will soon
shape-change to some other form and then become subject to being
forced back to innate shape by stoning again.
For wizard mode 'monpolycontrol', the getlin() answer buffer for the
"Change <monster> @ <x,y> into what kind of monster?" prompt is also
used to format the coordinate portion of that prompt, so when
EDIT_GETLIN is enabled getlin() was inadvertently given "<x,y>" to use
as default response. Clear it after the prompt is formatted instead
of via an initializer. Also, shorten the prompt on the first try:
"Change <monster> @ <x,y> into what?", expanding to the old prompt if
retry is needed.
This also allows specifying 'chameleon' when <monster> is a chameleon,
'doppelganger' when it's a doppelganger, and 'sandestin' when it's one
of those (but not 'doppelganger' when it's a chameleon or sandestin,
and so forth), instead of blanket refusal to accept any non-vampire
shapechanger as the choice.
While testing, I noticed that I could completely fill the Water level
with air elementals.
Hero can't fly or levitate or water walk into/onto water locations
on Water level without drowning/crawling out the water, and monsters
shouldn't have been able to but could, then they were hit by drowning
since minliquid used different criteria than movement. But goodpos(),
used for teleport destination and new monster creation among other
things, consided water locations acceptable on that level for
non-aquadic creatures with Fly/Lev/Wwalk ability.
It explains why so many dragons and other 'nasty' monsters have been
ending up on the vanquished monsters list when hero uses level
teleport to go directly there from level 1. They've either been
getting created in water and then they drown when it's their turn to
move or moving into it to approach the hero and drowning (not sure
whether that case is immediate or on next move). There's no message
since hero doesn't see it, and air elementals didn't drown since thy
don't breathe.
Even though a goodpos failure in mnearto() would return 0 to
the caller and trigger proper overcrowding handling for mtmp,
the 'othermon' would be left with its mx,my set to 0,0 under
that circumstance and then trigger a mon_sanity_check()
failure and accompanying impossible() message a short while
afterwards.
This also includes the addition of some flags that proved useful
for troubleshooting the mystery sanity_check failure and helping
to understand some of the code paths the struct monst data had
been through. They are only used for inspection when issues are
reported or when debugging, they don't presently control the
code flow. Their setting and use is done in an overloaded way
that should not intrude on the existing use of mspare1 for
MIGR_LEFTOVERS. mon->mstate is just a pseudonym for mon->mspare1
and does not alter save file content.
This doesn't solve the <0,0> problem but it does prevent mnexto()
from using uninitialized coordinates if enexto() fails. It also adds
several debugging messages.
enexto() was ignoring map row #0 (unlike column #0, row #0 contains
valid map locations). Fixing that doesn't matter for Plane of Water
though since that row is stone there--that's probably a bug. It was
also repeatedly re-testing the top+1 and bottom rows and left and
right columns after they had already failed to be acceptable. It
still does some of that, but less.
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.
|The seemingly dead vampire bat rises as a vampire.
was overriding hallucination when describing both old and new forms.
In 3.6.0 it only overrode the dying shape (explicitly so, presumeably
because the feature was brand new) and honored hallucination for the
revived shape. The 3.6.1 fix to prevent non-hallucinating: 'The
seemingly dead Foo rises as Foo.' for a named vampire unintentionally
overrode hallucination for the revived shape.
Change it to honor hallucination for both before and after monsters
|The seemingly dead grid bug rises as a microscopic space fleet.
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.
Change in meaning of mnearto()'s return value wasn't progagated to
shkcatch(). Make it an int instead of boolean so that it can
communicate both 'moved successfully' and 'moved but had to move
another monster out of the way to do so'.
mon_arrive() -> m_into_limbo() -> migrate_to_level() -> wormgone()
followed by place_monster() "for relmon". relmon() was changed (last
November, cc5bb44a9a) to not require
the monster be on the map, so just get rid of the place_monster() that
was trying to put the "gone" long worm at <0,0>.
Also, another m_into_limbo() bit: make mdrop_special_objs() check the
location and send any dropped items to random locations if the monster
dropping things isn't on the map, instead of placing them at <0,0>.
Fixes#177
The monst struct has 'mintrinsics' field which attempts to handle
both mon->data->mresists and extrinsics supplied by worn armor, but
polymorph/shape-change was clobbering the extrinsics side of things.
Potentially fixing that by changing newcham() to use set_mon_data(...,1)
instead of (...,0) solved that but exposed two other bugs. Intrinsics
from the old form carried over to the new form along with extrinsics
from worn armor, and update_mon_intrinsics() for armor being destroyed
or dropped only worked as intended if the armor->owornmask was cleared
beforehand--some places were clearing it after, so extrinsics from worn
gear could persist even after that gear was gone.
So, fixing the set_mon_data() call in newcham() was a no go. This
fixes update_mon_intrinsics() and adopts the suggested code from
github pull request #177 to have mon->mintrinsics only handle worn
gear instead of trying to overload innate intrinsics with that. This
is a superset of that; the flag argument to set_mon_data() is gone
and mon->mintrinsics has been renamed mon->mextrinsics. (The routine
update_mon_intrinsics() ought to be renamed too, but I didn't do that.)
Fuzzer feebdack. When turning a monster into a statue, monstone()
builds a linked list of mon->minvent items to put into that statue.
It doesn't use obj_extract_self() to take them off again, leaving
obj->nobj non-Null. Not noticed for the normal case where each item
gets linked into the container's contents, but triggers panic if an
item merges with something already put inside so gets removed.
Suddenly, the dungeon collapses.
dealloc_obj with nobj
[2] 0x01000c4193 panic + 995
[3] 0x0100155427 dealloc_obj + 71
[4] 0x010021d4de obfree + 686
[5] 0x01000f2f92 merged + 834
[6] 0x010015356e add_to_container + 126
[7] 0x01001628ac monstone + 636
I don't know why the petrified monster's mergeable inventory wasn't
already merged while in inventory.
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.
