The rationale is that since the player character resists conflict,
fake players should too.
[I'm not sure that I buy that. Player character is always the one
*causing* conflict and it doesn't affect self. But this is simple
as long as no other resistance checks are against attack-by-ring.]
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.
struct rm.flags in overloaded for a bunch of rm.typ -dependent things
(doormask, altarmask, throne/fountain/sink looted, a few others) and
wasn't being reset for various cases where rm.typ gets changed.
I've changed a lot, some no doubt unnecessarily, and probably missed
plenty. This compiles but has not been thoroughly tested.
Make the sequence:
be zapped by lightning,
have worn ring of levitation be destroyed,
fall onto fire trap
work better. The fire trap handling will mark everything in inventory
as already processed; anything vulnerable to lightning past the destroyed
ring would not be checked. So delay destroying such a ring until after
all of inventory has been subjected to lightning.
Inventory traversal can be disrupted when items being traversed are
able to change inventory. I've lost track of how many times this
sort of thing has been discovered.
Report claimed that boiled potion of polymorph caused transformation
which resulted in dropped weapon and dropped or destroyed worn armor.
That was evidently a guess; potionbreathe() for that potion only
abuses constitution. The traceback showed 'you_were()' was involved.
Boiled potion of unholy water triggers human-to-beast transformation
of hero inflicted with lycanthropy, yielding similar situation.
I didn't notice anything unusual when reproducing this but inventory
was definitely vulnerable. My 'one line' fixes entries are steadily
getting to be more verbose; I may have to go back to 'fix bug'. :-}
If hero was carrying Schroedinger's Box at end of game, disclosing
inventory converted it into an ordinary box. That interferred with
subsequent disclosure when writing DUMPLOG, which saw an empty box
if inventory had been shown or the special box with newly-determined
contents if not. I tried a couple of ways to fix it and decided
that redoing it was better in the long run.
Schroedinger's box is still flagged with box->spe = 1, but instead
of having that affect the box's weight, now there is always a cat
corpse in the box. When opened, that will already be in place for
a dead cat or be discarded for a live one, but the weight will be
standard for container+contents and when box->cknown is set it will
always be "containing 1 item" (which might turn out to be a monster).
Some temporary code fixes up old save/bones files to stay compatible.
TODO: food detection used to skip Schroedinger's Box; now it will
always find a corpse, so some fixup like the ridiculous probing code
is needed.
Make being trapped in/on/over floor block Levitation and Flying, the
way that being inside solid rock already does, and the way levitating
blocks flight.
Blocked levitation still provides enhanced carrying capacity since
magic is attempting to make the hero's body be bouyant. I think that
that is appropriate but am not completely convinced.
One thing that almost certainly needs fixing is digging a hole when
trapped in the floor or tethered to a buried iron ball, where the
first part of digactualhole() releases the hero from being trapped.
If being released re-enables blocked levitation, the further stages
of digging might not make sense in some circumstances.
I recently realized that being held by a grabbing monster is similar
to being trapped so should also interfere with levitation and flying.
Nothing here attempts to address that.
Save files change, but in a compatible fashion unless trapped at the
time of saving. If someone saves while trapped prior to this patch,
then applies it and restores, the game will behave as if the patch
wasn't in place--until escape from trap is achieved. (Not verified.)
A polymoprh zap which creates a long worm can hit and transform the
same monster again depending upon tail segment placement. Similar
behavior occurs if monpolycontrol is set in wizard mode and player
chooses 'long worm' for what to transform an existing one into (in
which case polymorph fails and zap might hit that same worm again
in another segment, prompting player to choose its new shape again).
Simplest fix would be to make tail segments be immune to polymorph,
but that would prevent players from deliberately attacking the tail
(for polymorph attacks only). Next simplest would be to make long
worms M2_NOPOLY so that polymorph can't create them, then just live
with multiple promptings when monpolycontrol is set. This fix
tracks whether a long worm has just been created via polymorph (or
explicitly retained its shape via monpolycontrol) and makes further
hits on same creature on same zap have no effect. It does so by
setting mon->mextra->mcorpsenm to PM_LONG_WORM when a long worm is
result of polymorph, and setting context.bypasses to get end-of-zap
cleanup. (It doesn't bother discarding mon->mextra if reset of
mcorpsenm leaves mextra empty.)
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#111
Casting stone-to-flesh at a random statue animates it as a monster
(created via direct call to makemon()) at an adjacent or nearby spot
if there is already a monster at the statue's spot, but doing so on
a statue of a petrified monster (create attempt via montraits() which
called makemon() without the ADJACENTOK flag) turned it into a corpse
instead. Pass an extra argument to montraits() so that it behaves
the same normal statue animation for stone-to-flesh without changing
how it behaves when reviving corpses for undead-turning.
Fixes#109
Spells of healing and extra healing cast at monsters were handling
monster blindness differently from other forms of healing. (Potions
also work differently when drunk by monsters but I haven't changed
that since it seems to be intentional.)
Hero:
potion of healing cures blindness if blessed; spell of healing
cast at skilled or better now behaves likewise;
potion of extra healing cures blindness if not cursed; spell of
extra healing is inherently not cursed and already behaved
likewise;
potion of full healing always cures blindness even if cursed.
Monsters quaffing potions:
plain healing cures blindness if not cursed;
extra healing and full healing always cure blindess.
Hero casting healing spell at monster:
plain healing behaves like the hero plain healing case: cures
blindness as if blessed when cast at skilled or expert level;
this is a change in hehavior--it used to cure timed blindness
even if unskilled and not cure 'permanent' blindness at all;
extra healing cast by hero is inherently not cursed so always
cures blindness.
The earlier change for 'fix github issue #106' could result in a
polymorphed weapon being worn in multiple weapon/alt-weapon/quiver
slots. Reorganize the relevant code more thoroughly this time.
Fixes#106
If dipping a worn amulet into a potion of polymorph turns it into an
amulet of change, the game panics while trying to use up that amulet
when the new one hasn't replaced the old one in inventory yet. Simply
reordering the relevant code isn't sufficient to fix things: once it
is in inventory and can be successfully used up, later code would end
up deferencing a stale pointer because it was unaware of the deletion.
Instead of replacing the check for DRAWBRIDGE_UP with one for
DRAWBRIDGE_DOWN, the correct fix is to check for both because
replacing either one with water breaks the two-square dbridge.
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'.
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.
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.
Requested by one of the beta testers 13 months ago... when a visible
monster becomes invisible and vanishes, mark its map location with
the remembered, unseen monster glyph. (When the player zaps a
monster with a wand of make invisible, that only happens if the wand
type is known. I'm not sure that's right but didn't alter it....)
The request suggested also doing it for a monster who disappears by
teleporting away, but I haven't attempted to implement that.
This is the Pet ranged attack -patch by Darshan Shaligram,
with the spellcaster parts removed to keep it simpler.
Pets will now throw, spit and breathe at other monsters.
When a stack of N corpses is hit by wand or spell of undead turning,
1 revives and N-1 remain corpses. If owned by a shop, a fee for
using up all N corpses was charged and if carried at the time, the
extra N-1 became owned by the player but if on the floor, they
remained owned by the shop. Feedback was schitzophrenic as to
whether the whole stack was involved:
One of the <foo> corpses glows irridescently.
You owe <shk> X zormids for them.
Split the stack so that revival explicitly operates on only 1 corpse.
It's done after the revival side of things has already succeeded or
given up, so the split will never need to be undone.
Zapping wand of undead turning at self while inside a shop and
carrying a corpse caused the shopkeeper to claim a use-up fee for
the corpse regardless of whether it was owned by the shop.
Not mentioned in the report: casting stone-to-flesh as self while
carrying a figurine or statue behaved similarly.
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.
Reported directly to devteam, zapping wand of undead turning at a
shopkeeper's corpse would cause a crash. 'Traits' to fully recreate
the shk were attached to the corpse, but the temporary monster
created on the map intended to be relaced by the shk didn't have any
eshk struct, and the sequence replmon() -> replshk() -> inhishop()
attempted to access mtmp->mextra->eshk when trying to reattach the
shk to his/her shop. No other mextra structs involve pointer fixups,
so pets, priests, vault guards don't need extra handling.
I tested four cases. #1 and #3 had no shop bill at the time; I'm not
sure about #2. These all worked.
1) shk killed inside shop, resurrected there;
2) killed outside shop on the shop level, resurrected there;
3) killed inside his shop, corpse carried to different level before
being resurrected;
4) killed and resurrected on different level from shop after hero
stole something (teleported out of shop with unpaid item)--shk
left shop to chase hero and followed him/her up some stairs.
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.
'Your <single-potion> boils and explodes.'
'One of your <stack-of-potions> boils and explodes.'
'Some of your <stack-of-potions> boil and explode.'
'All of your <stack-of-potions> boil and explode.'
The last variation had an extra space in the message prefix....
In addition to removing the excess space, this adds
'Both of your <stack-of-potions> boil and explode.'
to be used for the (All == 2) case.
The bug and fix also apply to stacks of potions 'freezing and
shattering' and to stacks of scrolls 'catching fire and burning'.
Force the menu for the look-here command when 'here' is the inside
of an engulfer to be PICK_NONE. That way '>' won't exit the menu
by choosing the extra inventory item "> - hero".
Rescuing an old revision from bit rot: If one of fog clouds or
vampire bats has been genocided and you try to polymorph a vampire
disguised as the other, it won't change form because the shape it's
currently in is the only candidate shape left for vampshifting.
This makes shapechangers who fail to take on a new shape when
polymorphed try again, specifying original form on the second try.
It's unlikely to affect chameleons, but disguised vampires will
sometimes become undisguised instead of seeming to be immune from
polymorph.
There have been two or three reports on getting feedback about
amulets rusting. Object formatting doesn't display erosion for
them, so being told about damage then not seeing that damage
feels like a bug. Even if damage was displayed, it has no effect
on them so would still feel somewhat strange. It does display
erosion for wands and rings, which is strange too.
This limits erosion damage--and its feedback--to items which are
actually impacted by erosion: armor, weapons and weapon-tools;
also heavy iron balls and iron chains since they've traditionally
shown rust even though it has little effect.
A side-effect of this change is that flammable items (other than
armor and weapons) which don't burn up immediately will no longer
become burnt, then very burnt, thorougly burnt, and finally be
destroyed. Since the player couldn't see or possibly repair the
erosion state, it seemed incomplete. It could be reinstated by
making other flammable items be subject to erosion and displayed
as such by xname() & co.
Wishing now avoids applying erosion and erosion-proofing to items
that aren't affected by it, regardless of material. It also now
allows wishing for "rusty rustproof <iron-object>" which used to
suppress "rusty" in that combination and triggered a couple of
old bug reports.
Heavy iron balls and iron chains can have rust repaired and can
be made rustproof by wielding, then reading enchant weapon while
confused, as if they were weapons.
Pt 1 was about the wrong message delivered when a high priest
rejects being given a name by the player, and was fixed weeks ago.
Pt 2 is about zaps on the Elemental Plane of Air which reach the
edge of the map not having their temporary display effect removed
after "the <zap> vanishes in the aether". There was a 'goto' in
use which bypassed the tmp_at(DISP_END) call. I guess Dijkstra
earns an "I told you so" here.
When using a stethoscope or wand of probing on a long worm, report
the number of segments it has in the feedback given.
Some of the extra bhitpos and/or notonhead assigments may not be
necessary. They were added when I was trying to figure out the
question of why probing of a tail segment revealed a long worm's
inventory even though the code explicitly prevents that. (Answer:
it didn't; I had misinterpreted bz 12 to think that that was what
was being reported. You need to use wand of probing--or "insigtful"
Magicbane hit--on the head in order to see its inventory or be told
"not carrying anything".)
When destroy_item() or destroy_mitem() burned up a glob of green slime,
they had the message index and damage amount reversed. This could give
a nonsense message ("the glob of green slime freezes and shatters") or
go out of array bounds and wreak havoc. Even if the message index had
been correct, fatal damage would have produced an incorrect cause of
death since it would have used a potion or scroll string.
Now globs will boil and explode like potions, and damage will be
proportional to the size (weight) of the glob, which seems to be the
original intent.
