Lock context wasn't being cleared if it was for a container and that
container got destroyed. Case discovered was forcelock() ->
breakchestlock() -> delobj() (sometimes the container is destroyed
rather than just breaking its lock) followed by #wizmakemap (replace
current level) and maybe_reset_pick() trying to check whether
xlock.box was being carried. But being interrupted, destroying the
container or dropping it down a hole to ship it to another level, then
attempting to resume picking the lock would also find a stale pointer.
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.
Having an artifact wish be refused uses zeroobj and code which
followed was attempting to update its weight, triggering a segfault
now that zeroobj is 'const'.
User-contributed fix; bypassed the contact form so no #Hnnnn number.
On the Gnome King's Wine Cellar version of Mines' End, a couple of
wall stubs in the lower far right were diggable, unlike all other
walls on the level. One single-spot wall stub was leftmost of three
undiggable spots, wall+floor+stone. The floor spot wasn't noticeably
different from normal (not sure whether digging a pit was prohibited)
but the stone one was.
new domove_core() assessment results
potentially smudge engravings
Proceed to wipe engraving after domove_core() now, but only under
all of the following conditions:
- you can reach the floor
- preceding domove_core() move attempt was marked as
having succeeded in domove_core()
- there is actually an engraving there to impact at
your original spot, or your new spot, or both
I did much of this quite some time ago, as prequisite for a different
bug report about monsters vs shades, then set it aside. It ended up
being more complicated than I anticipated.
When deciding whether various non-weapon attacks might hit a shade,
hmonas() was not checking for blessed or silver armor that should have
been applicable. It did check boots when kicking, but not gloves or
rings (when no gloves) when touching, or outermost of cloak/suit/shirt
when hugging, or helmet when head-butting. (The last one is actually
moot because nothing with a head-butt attack is able to wear a helm.)
The problem was more general than just whether attacks might hit and
hurt shades. Various undead and/or demons are also affected by blessed
and/or silver attack but weren't for non-weapon attacks by poly'd hero.
At least two unrelated bugs are fixed: a rope golem's AT_HUGS attack
gives feedback about choking but was fully effective against monsters
which fail the can_be_strangled() test. And it was possible to hug a
long worm's tail, rendering the entire worm immobile.
The report also suggested that all artifacts be able to hit shades for
full effect, but by the time shades are encountered everyone has an
artifact so that would nullify a shade's most interesting ability.
TODO: monster against hero and monster against other monster need to
have similar changes.
Items on floor in the free spot one step inside a shop's doorway were
showing shop sell prices. Treat items on that spot as if they were
flagged no_charge as on the floor of other shop squares.
Report stated that sometimes they showed a 'for sale' price and
sometimes they didn't, but I didn't see any cases where they didn't.
This fixes the weapon related aspects of #H7980: having an alternate
weapon be used in cases where it shouldn't when polymorphed into a
monster form with multiple weapon attacks. The most egregious was
using an off-hand artifact, but it would also use off-hand two-handed
weapon, off-hand silver weapon when in silver-hating form, or any
reasonable off-hand weapon when wearing a shield. That last is iffy
whether or not to allow, since you'll still get the extra attacks
whether it switches to secondary weapon or stays with the primary.
I've made it re-use the primary since two-weapon mode doesn't allow
a shield. The other oddity was being able to use the secondary
weapon on the second swing even if the first swing was weaponless.
I went with ingoring the secondary weapon if there's no primary one
or if the primary is two-handed.
Report included "cursed secondary doesn't weld" but that has nothing
to do with polymorph attacking. I've changed that to drop the weapon
if you attack with it when it's cursed, similar to what happens when
secondary weapon becomes cursed while two-weaponing.
It also included "marilith's attacks beyond the second don't use any
weapon and can hit cockatrices without touching them". A marilith has
two weapon attacks and then four claw attacks. Claw attacks only use
the weapon if it hasn't been used yet, so marilith hits with primary,
secondary (or primary a second time if no secondary), claw, claw,
claw, claw and that's the intended behavior. It is able to hit
cockatrices if wielding anything at all, same as a monster with just
a single attack. Since it is impossible to wield six weapons or three
pairs of gloves, that has to be intended behavior too. Playability
trumps realism even if it is silly to hit without a 3rd through 6th
weapon and be safe from touching the target due to the 1st weapon or
one pair of gloves. [Situation is different from having no control
over unsafely biting something after making a safe weapon or claw
attack; perhaps a better solution would be to refrain from using the
four claw attacks when attacking something that is fatal to touch.]
Reported 14 months ago, a monster reading a scroll of earth which
dropped a boulder that killed another monster in an adjacent pit
was giving credit/blame to the hero and could also trigger a panic.
If the monster was killed, the pit would be filled and deleted via
m_detach and then when flooreffects tried to delete the same trap,
it accessed freed memory and deltrap could panic.
when level teleporting or digging. Level teleporting while levitation
was blocked due to being inside solid rock didn't notice that it should
be unblocked until you moved from whatever type of terrain you landed
on (room, for instance) to some other type (such as corridor). Digging
down to make a pit or hole while inside solid rock converts that spot
to floor so should also check whether to unblock levitation/flying, and
not fall if unblocking occurs.
Redo the Ft.Ludios entry hack to suppress the lit walls on the left
and top rather than to light the upper-right corner. Only noticeable
if carrying a lit candle. Usually, that is. This simpler hack could
be detected visually from the treasure room side of the walls involved
but normally won't be.
The entry chamber for the Fort Ludios level would be completely lit
except for one corner wall if you arrived carrying a lit candle. The
unlit spot turns out to be correct, it is beyond candle radius, but
spots further away than that were showing up lit. That's due to them
bordering a lit region on the opposite side and lit regions seem to
be bigger than their specified dimensions.
I tried to make the lit walls be unlit but it wasn't working. (Making
the lit region be smaller would probably work but might have unintended
consequences when populating the zoo room. I didn't try that.) This
makes the unlit corner show up if light hits the spot next to it, so
that it behaves like the other lit walls surrounding that entry area.
I haven't marked the bug report closed because I don't think this is
the proper way to fix this.
When SEDUCE is disabled, instead of swapping attacks in mons[] once,
do it on the fly in getmattk() whenever needed. That allows mons[]
to become readonly, although this doesn't declare it 'const' because
doing so will require a zillion 'struct permonst *' updates to match.
This seemed trickier than it should be, but that turned out to be
because the old behavior was broken. Setting SEDUCE=0 in sysconf or
user's own configuration file resulted in all succubus and incubus
attacks being described as monster smiles engagingly or seductively
rather than hitting (while dishing out physical damage). I didn't
try rebuilding 3.4.3 to see whether this was already broken before
being migrated to SYSCF.
More shop price determination fallout. After the most recent change
to get_cost_of_shop_item(), using ':' inside an engulfer carrying at
least one item while inside a shop would try to follow the item's
obj->ocontainer back-link and crash when that led to the engulfing
monster rather than to a container.
The recent attempt to have looking inside a container show shop
prices had multiple problems. Worst one was showing shop prices as
if the hero would be buying for items already owned by the hero.
Item handling inside containers on shop floor was inconsistent: if
shop was selling those items, they would include a price, but if not
selling--either already owned by hero or shopkeeper didn't care about
them--they were only marked "no charge" if hero owned the container.
This is definitely better but I won't be surprised if other obscure
issues crop up. Gold inside containers on shop floor is always owned
by the shop (credit is issued if it was owned by the hero) but is not
described as such.
Fix fuzzer feedback. The new wizard mode ^T menu had an early return
which bypassed destroy_nhwindow(), leaving the menu around. Fuzzer
eventually got "No window slots!" panic from tty. Make sure that the
menu window is torn down fully before returning.
Also, make the normal wizard mode teleportation chioce be preselected
so that not picking anything doesn't lead to an early return any more.
ESC still does though.
Fixes#172
Casting teleport-away via ^T used different requirements for energy,
strength, and hunger than casting it via 'Z'. The strength and hunger
requirements were more stringent, the energy one more lenient. When
it rejected a cast attempt due to any of those, it used up the move,
but 'Z' didn't.
When testing my fix, I wanted an easier way than a debugger to control
how ^T interacts with wizard mode, so finally got around to a first
cut at being able to invoke it via wizard mode but not override those
energy/strength/hunger requirements. It uses the 'm' prefix to ask
for a menu. 'm^T' gives four options about how to teleport. (There
are other permutations which aren't handled.)
Also noticed while testing: ^T wouldn't attempt to cast teleport-away
if you didn't know the corresponding spellbook. 'Z' will attempt that
because it is possible to forget a book and still know its spell.
Some object classes (such as armor and weapons) are split into
"subclasses" when sortloot applies an ordering (for armor, all helms,
then all gloves, then all boots, and so on). Give gem class subsets.
Simple (1) valueable gem, (2) worthless glass, (3) gray stone, (4) rock
would give away information; instead, factor in discovery state and use
(1) unseen gems and glass ("gem")
(2) seen but undiscovered gems and glass ("blue gem"),
(3) discovered gems ("sapphire"),
(4) discovered glass ("worthless pieced of blue glass"),
(5) unseen gray stones and rocks ("stone"),
(6) seen but undiscovered gray stones ("gray stone"),
(7) discovered gray stones ("touchstone"),
(8) seen rocks ("rock").
If everything happens to be identified, the simpler ordering happens
(via 3, 4, 7, and 8) because the other subsets will be empty.
Similar to ^G of 'I' triggering impossible "mkclass found no class 35
monsters", using a leading substring of "long worm tail" (other than
"l" and "long worm") would trigger impossible "mkclass found no class
59 monsters and kill the fuzzer when it escalates impossible to panic.
Tighten up the substring matching.
^G of '~' wasn't affected; it deliberately creates a long worm rather
than the tail of one. But it was possible to ask for "long worm tail"
as a specific monster type and then override the switch to long worm
when prompted about whether to force the originally specified critter.
I've added a check to prevent that opportunity to override even though
a tail without a head seemed to be harmless.
The 'O' handling for bouldersym was updating the display value for
boulder even if the value had been rejected, and if it still had the
default of '\0', the map would end up with <NUL> characters. (When
examined via '//' or ';', those matched dummy monster class #0 and
led to the impossible "Alphabet soup: 'an("")'" that was suppressed
yesterday.)
Attempting to set bouldersym to ^@ or \0 would also be rejected as
duplicating a monster symbol. That is now accepted and used to reset
the boulder symbol to default. However, other control characters are
also accepted--not due to this patch, they already are, and from a
config file in addition to via 'O'--so bouldersym can still disrupt
the map. But that's no different from putting control characters
into a symbol set or setting them from config file via S_foo:^C.
A recently added impossible to check for an(Null) and an("") was
triggered by the fuzzer: Alphabet soup: 'an("")'. I reproduced it a
couple of times and tracked it do_screen_description(for '/' command)
matching the symbol from mapglyph to monster class #0, a placeholder
with symbol value '\0'. So mapglyph() returned a symbol of '\0', but
not necessary from showsyms[0 + SYM_OFF_M].
The pager lookup code's monster loop shouldn't have been attempting
to match against class #0, and since this fix I haven't been able to
reproduce the situation again. But I also didn't trigger it with a
bunch of temporary checks in mapglyph() so don't know what is really
going on under the hood.
