If you ask for help when wishing, don't leave "help" in the buffer
for EDIT_GETLIN to use as default answer on next retry. It does still
leave anything rejected as unknown so that the player has a change to
review the spelling and conceivably add and/or remove from the end
witout having to retype everything.
Throwing or kicking a lit lamp, lit candle, or lit potion of oil
wasn't giving off any light as it travelled to its destination.
Now it does, and dungeon features, objects, or monsters that are
temporarily seen as it moves from square to square till appear on
the map. In the monster case, they go away as soon as the light
moves beyond range, but when it finishes moving the "remembered,
unseen monster" glyph will be drawn at their location. I think that
part has some room for improvement, but mapping temporarily seen
terrain features is the primary impetus for this change.
Also, any message delivery while the "lit missile" travelled still
showed its light around the hero. Noticeable for lamps or stacks
of sufficient candles if hero has no other light source.
This cannibalizes the monst->mburied bit for temporarily seeing a
monster. It has been present but unused for ages. I needed to
replace a couple of vision macros to make sure they didn't examine
it any more so that overloading for transient lighting doesn't
introduce any vision oddities. For version $NEXT, monst->mtemplit
can be given its own bit. It is only set during bhit() execution
and cleared by the time that returns, so has no effect on save files.
If a corpse with a revive timer included obj->oextra->omonst for
remembering the original monster (I think all corpses do these days)
and makemon() failed to create a new monster when the timer expired,
the copy of the original wasn't freed. makemon() will fail if there
is no room for the monster.
Carried containers could have their contents-known state and/or
lock-known state changed without persistent inventory window being
updated to show the new information.
This also changes the behavior when player has hero zap self with
wand of locking or wizard lock spell. If it doesn't trigger a
holding trap then the effect will hit inventory, similar to how
opening/knock operates (releasing hero from holding trap or hiting
inventory when that doesn't happen).
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.
Report forwarded from spam filter so not included in bugzilla list.
Make corpse revival feedback be more consistent. Some of the healer-
specific flavor is still there.
This is branched from Alex's hallu-rng-stability branch,
with two build corrections (detect.c, zap.c), and merged
with the isaac64 branch that we have ready to go.
Alex's dual rng is supported by setting up the array
of multiple isaac64 contexts.
I stuck with Alex's approach of passing the rng function
name around as the parameter (rng or rn2_on_display_rng)
for the new additional parameter needed for
set_random(), init_random(), reseed_random(),
and init_isaac64().
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).
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.
