Some code to stop a monster's zap of a wand of striking short if it
gets destroyed by hitting and destroying a drawbridge is no longer
needed with the new deferred obj deletion.
[PR #1243. Cherry picked with new commit log message. PatR]
Fixes issue where room_discovered was never called for shops
unless #overview was called while inside the shop, fixes#1241.
Issue #1241 reported by mark-mcknight-oncorps.
Triggered by commit e4026d55fb
last December: Lazy evaluation of overview info.
Closes#1243Closes#1241
A monster zapped a wand of striking, hitting a burning potion
of oil, which destroyed items in the same square, and the ray was
checking destroyed item. Similar thing with a ray done by hero.
The code currently stops checking the objects in the location
if a next object in the chain was destroyed - an improvement
would be to gather all the objects into an array and iterate
over that instead of relying on the nexthere pointer.
Pull request from disperse: moving diagonally from an intact doorway
isn't allowed but if there was a known trap at the destination and
parnoid_confirm:trap was set, player would be asked whether to move
onto the trap before not being allowed to move diagonally.
There was similar misbehavior if a trap had been armed or web spun
in a doorway and you tried to move diagonally into that doorway, not
just out of one. The pull request's one-line change fixes that too.
I modified the file manually rather than keep the PR's commit. This
also adds a couple of unrelated reformatting bits.
Closes#1242
Make object deletion work similarly to monster deletion:
it's marked for deletion (by setting the where-field to OBJ_DELETED
and moved to specific deleted-objects chain), but they're actually
freed at the beginning of turn.
This may need some more tweaking, especially in places that iterate
over object chains, but fuzzing did not find any obvious problems.
Fix a case of accessing freed memory: a monster breathed at hero,
destroying some items. The code stored the next item in the chain
(a cloak), but a ring of levitation was destroyed, causing hero to
plop down into lava, destroying the cloak. The item destruction
code then tried to access the destroyed cloak object.
Make the code check the object where-field - which will be different
if the object was marked for deletion. Also removed an extra loop
going through the whole object chain looking for the items to
destroy.
Due to integer rounding, merging two partially eaten food rations
will have wrong weight if we add the old weights together.
Recalculate the weight instead.
quan = 1, weight = 6 (6.675)
quan = 2, weight = 13 (13.35)
A mind flayer blasted a polyed hero on a pool, who reverted back
to human. The hero teleported to safety, but the mind flayer was
still thinking hero was at the old location, and tried to attack there.
I still haven't found any explanation for the report by a hardfought
player recently that going down some stairs with a pair of leashed
pets got one into a confused state where it was flagged as leashed
but the corresponding leash was no longer in use.
This adds some new object and monster sanity checks regarding leashes,
and it changes o_unleash(obj) to clear obj->leashmon even if/when the
monster can't be found.
It also changes behavior for dipping an attached leash into a potion
of polymorph when that happens to yield another leash--now the new
one will end up being pre-attached.
Add a way to request that unpaid_cost() produce the cost for a single
item, which is necessary for the price adjustment made in
bill_dummy_object. Another option would be to simply divide by quan in
bill_dummy_object, but this might be more future-proof in case
unpaid_cost ever involves more than simple multiplication by quan
(e.g. the use of alternate units vs the base price, as are used for
globs).
Fixes#1236
underneath gets boiled away
Pull request by disperse: when a water walking hero zaps a wand of
fire downward and it boils away the water, hero should fall into the
resulting pit.
The PR commit didn't handle monsters (who don't zap wands downward
but could be on/in water that's boiled out from under them). And
while testing it I noticed that the existing code had message
sequencing issues (being enveloped in a cloud of steam before seeing
the water evaporate). This ended up redoing the fix rather than
using the commit.
Fixes#1238
The same routine handles both monster-vs-hero and monster-vs-monster
breath attacks, but the code was considering what the attacker knows
about hero's resistances even when attacking another monster.
Also unconditionally prevent the monster breath attack if the monster
knows about hero reflecting - previously the monster could use the breath
if it were just far enough from hero, even when hero had reflection.
Fix a FIXME added for issue #1233. When engraving, if the writing
implement is a stack of cursed weapons which are welded to the hero's
hand, just write in the dust rather than engrave in the floor, in
order to keep the whole stack welded.
Only applies when the stack is actively welded. Other stacks of
cursed weapons will have one split from the stack to perform the
engraving, otherwise engraving could be used to determine whether a
stack is cursed without the risk of wielding it.
Issue reported by NetSysFire: engraving with a stack of multiple
weapons dulls the whole stack where it ought to only dull one of them.
This was actually trickier than it ought to have been, and will need
a lot more testing. When engraving with a stack, split one off and
use just that one. If inventory is full, it will be dropped (after
writing the first 2 characters and becoming duller). I've avoided
moving it into the overflow slot, otherwise engraving repeatedly with
an arbitrarily large stack could be used to produce an arbitrary
number of overflow items.
Engraving with a weapon of known enchantment us somewhat more verbose
than it used to be.
From the report:
" It would be a great quality of life change if only one item of the
" specified stack was used, as with #forceing open chests.
One person's improved quality of life is another's outrage. Players
who want to dull a stack of +6 daggers down to +5 in order to have
another try of enchanting to +7 are not going to like this....
Closes#1233
Failed #force due to wielding wrong implement didn't phrase things
well if current weapon was a stack.
Plus some reformatting split out from a forthcoming #engrave patch.
Contains some wood nymphs and fountains, and the room walls are trees.
Adds a new lua hook for themeroom generation, "post_level_generate",
which is called last when generating the level.
Give a resistance animation if you #invoke Sunsword while it's
wielded and direct its blinding ray at yourself. Flashing a camera
at a monster who is wielding it will also produce the animation.
about testing whether an unsigned value is >= 0. Since there's no
chance that it might have a value of NON_PM (-1), just comment out
the assertion that was intended to ward off a potential complaint
about that.
Commit fddc966a3e included:
Add S_suit as another alternate for S_armor.
I got fooled by the description "suit or piece of armor" and was
thinking that each of the 7 armor slots had their own symbol that
could be overridden.
There's no need for S_suit when there isn't any S_helm, S_boots, &c.
Even 100 deaths wasn't enough, as the fuzzer was still quitting.
If we're in wizmode, just execute wizmakemap to recreate the level,
getting rid of whatever was blocking hero from teleporting to safety.
Prevent glyph change messages while loading a level file.
Otherwise a monster hiding under an item triggered a vision recalc
before light sources were linked to their sources, leading into
strange errors looking like pointer corruption.
getlev -> hide_monst -> hideunder -> newsym -> show_glyph ->
pline_xy -> vision_recalc -> do_light_sources -> get_obj_location
Add in_getlev program state variable, analogous to in_mklev
When a monster mimicks another monster (traditionally Double Trouble
Wizard, since 3.6.x also pet that eats a mimic corpse), using farlook
or getpos+autodescribe revealed the monster's real identity. Hard to
believe that nobody ever noticed, but it was obvious when a pet dog
quick-mimicked a cat or vice versa.
Add an extra x_monnam() flag to ignore monst->m_ap_type==M_AP_MONSTER
plus monst->mappearance. Only the m_monnam() variation of x_monnam()
includes it (via EXACT_NAME); monnam() and the rest will now describe
an M_AP_MONSTER by its appearance rather than as its true self.
Improve the feedback for an unnamed pet eating a mimic corpse.
|You see a tripe ration where Rover was.
is ok.
|You see a tripe ration where the dog was.
looks somewhat odd. Change that to be
|You see a tripe ration where your dog was.
When a camera flash hit a mimic which was posing as something, the
feedback mentioned the mimic but didn't bring it out of hiding.
Change to make light pass over a mimic impersonating an object but
unhide one impersonating furniture. Ones impersonating some other
monster are woken up but wakeup doesn't force it back to mimic shape.
Trying to get the messages right brought on more code changes than
antipated. I changed one of the arguments to mhidden_description()
so had to change its callers; fortunately there aren't very many.
