Generally, fish should lay their eggs in the water and
not on land, but the game was only allowing the opposite.
Eels are catadromous and lay their eggs in the Sargasso Sea,
not in the dungeon.
Something else noticed while testing #H8271: toggling perm_invent on
with 'O' didn't show anything (at least with curses) until some later
action caused it to be updated. Make updating persistent inventory be
included with full redraw and set the need_redraw flag when toggling
perm_invent.
Realized while fixing #H8271: if persistent inventory got an update
while wearing or taking off was in progress (not within user's control
since hero is busy) the item in question was flagged as "(being worn)"
even though it wouldn't be worn if putting on got interrupted. Update
doname() to show "(being donned)" or "(being doffed)" instead of
"(being worn)" when corresponding operation is in progress. (During
testing, I was able to observe "being doffed" but never managed to see
"being donned".)
A relatively recent change moved 'obj->known = 1' when wearing armor
from before setworn(), which issues an update_inventory() call, to
afterwards. There wasn't any particular update then, so observing
the enchantment of armor by wearing it wasn't being reflected in the
persistent inventory window if that was enabled.
Take another crack at describing yesterday's do-again fix. Having
'autoquiver' enabled wasn't necessary to encounter the problem.
Also, 'in_doagain' is an int rather than a boolean.
It's possible to get a rolling boulder trap which doesn't have any
boulder. That isn't invalid, but if/when it happens on a shallow
level it shouldn't be covered by the corpse of a fake adventurer
since such a trap won't kill anyone.
One-line fix is much shorter than attempting to describe the problem.
^A could misuse previous input if 'f'<direction> needed to fill the
quiver and there was nothing suitable, so that the sequence became
'f'<what to throw>. If previous <direction> was an inventory letter
that was occupied, and the item it that slot wasn't already worn in
some other slot, it would be put in quiver slot. Then player would
be asked for direction rather than immediately throwing it since the
what-to-throw prompt had just used up the last of the ^A queue.
Miscellaneous formatting included....
The fuzzer likes to set options randomly; the combination of
DECgraphics symbol set (on a display capable of rendering it) plus
eight_bit_tty produces a bizarre map display. Make DECgraphics
override eight_bit_tty rather than the other way around.
Leather jacket doesn't take multiple turns to wear, so wearing it
wasn't calling Armor_on() and recently moved 'uarm->known = 1' didn't
get executed. Not reported yet but had the same issue: fedora and
dented pot wouldn't call Helmet_on().
Closing nethack's window sets 'program_state.stopprint' to inhibit
disclosure interaction, but shopkeeper claiming hero's stuff or vault
guard claiming hero's gold didn't honor that and just issued normal
pline messages. For win32, they got delivered in a popup even though
nethack's window had gone away.
Make those two end-of-game situations honor 'program_state.stopprint'.
[Fix not tested on win32...]
about the armor. Wearing armor sets obj->known, making its enchantment
be shown when it gets formatted, because the AC value on the status line
lets the player deduce what that is. It was being set at the beginning
of the wear operation. If the armor got stolen before it became fully
worn, the enchantment was still shown. Defer that until the end of the
operation. An attentive player can still deduce the enchantment if the
item is stolen (because its protection starts immediately) but the hero
won't learn that enchantment unless the donning completes.
This might be suboptimal but it isn't qualitatively different from
watching a pet walk/not-walk over items whose bless/curse state isn't
known or dropping unidentified items in a shop to check their price.
The player can deduce something that the hero doesn't know yet.
Support <delete> (aka <rubout>) during getline(). It doesn't actually
honor the current erase_char value set up for the terminal, just
treats DEL the same as ^H. (The previous lack of support had nothing
to do with terminfo specifying ^H; the handling is hard-coded.)
tty treats escape while there's already some input as kill_char (erase
the input but get more from scratch) and returns ESC if there isn't.
curses was doing the first half but not the second, so not providing
any way to communicate "cancel" back to the core. Fix is simple.
Other getline() bug fixes:
1] there was a wprintw("%*something") which was passing the value from
strlen (type 'size_t') to the "%*" argument (type 'int'). That's
always wrong (size_t is guaranteed to be unsigned) and could be severe
(if size_t is different width than int--as on current OSX systems--
depending upon the internals of argument passing).
2] strncpy() only supplies a terminating '\0' if the input is shorter
than the number of characters specified.
A lot of reformatting is warranted but I only did the getline routine
(manually, so might have missed stuff).
There was no provision for malloc() potentially returning Null and it
wasn't integrated with nethack's MONITOR_HEAP. 'heaputil' shows that
the curses interface is leaking like a sieve. If some things are
actually being allocated separately and then freed from within curses,
those need to be thoroughly documented and maybe switched back to
malloc().
The curses interface already has a hack to keep 'Count: 12', 'Count:
123' intermediate multi-digit counts out of its message recall history
for ^P, but it was flushing real messages when getpos()'s 'autodescribe'
reported what the cursor moved over. Overload the count hack to support
putstr(WIN_MESSAGE, ATR_NOHISTORY, text)
(which is what custompline(SUPPRESS_HISTORY, ...) eventually calls).
The conditional logic for when to create the 'count_window' was pretty
convoluted. This simplification has the same semantics but I don't
have PDCURSES to actually verify that.
Noticed while investigating the issue with DECgraphics characters in
msg_window:full/combination/reverse output for tty which got fixed
by the previous commit. There was a discrepancy in DUMPLOG because
the pager code bypasses pline() in order to use putmixed(). tty
puts strings from the latter into ^P recall history (although they'll
only render correctly if nothing after the first character needs
special handling), but nothing was putting that same info into
DUMPLOG. This fix is pretty clumsy but eliminates the discrepancy.
Noticed while testing the history suppression: if you have DECgraphics
enabled and look at a graphics character on the map, the topline shows
x description of x
where 'x' is displayed as it appears on the map (line drawing char).
^P for msg_window:single knows about that and reproduces the effect if
you recall such a line. But msg_window:full/combination/reverse didn't
know about that and dumped it as-is into text output, ending up with a
strange 8-bit character for 'x' instead of the line drawing one.
I think other rendering schemes will be unaffected by this. It's just
duplicating what is done for msg_window:single.
Fixes#101
If you tell the vault guard your name, drop carried gold, wait one
turn, then pick up the gold again, the guard will move a step away
during the wait. If you teleport away, the guard will seal vault
walls and then park himself on the one-square (so far) temporary
corridor adjacent to the vault wall. Periodically he'll say "Move
along!" and the hero will hear it, regardless of location on the
level. Unless you dig a corridor to rescue him, or one or more of
the vault's walls get breached again, he will never move.
The report emphasized that you could use this to steal the vault's
gold, but it relies on being able to teleport beyond the gaurd's
reach and if you can do that, you might as well do so before the
guard comes. The stranded guard, and him saying "Move along!" when
no longer leading hero out of the vault, are more significant bugs.
Bonus fix: if the game ends and the guard seals up the vault while
the hero is in a spot that gets fixed up (vault wall or temporary
corridor) don't give the "You are encased in the rock" message if
game end was due to death rather than quit.
When ^I was changed to allow picking more than one item to make
its temporary identification become persistent, group accelators got
left out. So to pick all potions, you needed to select them letter
by letter (or via '.' to select everything, then deselect non-potions
letter by letter). Now you can use '!' to select all potions.
Make healing magic which cures blindness also cure deafness. So,
drinking non-cursed potion of healing or any extra healing or full
healing; breathing fumes from blessed potion of healing or non-cursed
potion of extra healing or any potion of full healing; prayer reward
to cure blindness as a minor trouble. (Doesn't affect unicorn horns
which already treat deafness and blindness as two distinct troubles
that are eligible to be cured.)
More of a missing feature than a bug fix, so I listed it in the new
features section of the fixes file.
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.
