Have magic mapping add special rooms to known overview data. Only
affects shops and temples because they're the only rooms tracked.
Most other special rooms revert to normal rooms as soon as they're
entered so there wasn't any point in tracking them. That might no
longer be the case.
Wand of probing zapped at or through a shop door or even at a shop
wall will add the shop annotation to the overview data. That works
differently for normal shops than for subrooms in the twin business
theme rooms. I'm not sure whether any fixing is needed there since
the shop type information gets suppressed as soon as more than one
shop becomes known on a level.
Add the shop type variations used for automatically generated
annotations to the shop structure and get rid of the switch that
has been being used to pick them.
Give a different message from "obj not free" if attempting to delete
an already deleted object. Also, skip sanity checking of in_use/
bypass/nomerge bits for deleted objects instead of clearing them when
going onto the objs_deleted list.
Eating from a stack while inventory is full drops the partly eaten
food. If over lava and it is flammable it gets used up without the
eating code being aware of that. (Dropping into a hole or trap door
shouldn't have the same problem because the dropped object is still
accessible via the migrating objects list.)
Have touchfood() return NULL if the food item gets used up due to
being dropped. By itself, that wasn't enough. Callers needed to be
updated to handle that.
I didn't look at other callers of dropx/dropy/dropz; they might have
similar issues. Perhaps they should return the dropped object or
take a pointer to an obj pointer so that there can be just one check
for obj->where==OBJ_DELETED after dropping, but their callers would
still need to updated to cope with that.
Teach obj_sanity_check() and clear_bypasses() about the new obj list.
It should always be empty when sanity checks are performed. That
might not be the case when obj bypasses are cleared, although failing
to clear bypasses for deleted objects wouldn't make any difference,
so this is mainly cosmetic.
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.
