Mimic-as-slime_mold needs to keep track of the fruit index the same
way that mimic-as-corpse keeps track of corpse's monster type. The
mimic description was changing (for '/' and ';' feedback) whenever
the player assiged a new fruit name.
That wasn't noticeable when applying a stethoscope because
mimic-as-slime_mold always yielded "that fruit is really a mimic".
Change it to report the fruit's type instead of generic "fruit".
A couple of early returns could result in temporary windows getting
left around instead of being released for re-use, which in turn might
lead to a panic due to lack of available window slots. The first
one is accompanied by an 'impossible' warning which no one has ever
reported and the second one could only happen if data file 'keyhelp'
was missing, so panic due to either of these is hypothetical as far
as released versions go. Somebody making modifications could run
afoul of either of them though.
query_category() - switch from early return to 'goto' so that the
temporary window used for a menu will always be destroyed;
whatdoes_help() - defer creating the display window until after the
data file has been successfully opened so that early return won't
need any window cleanup.
would describe it as trapped if you could see its location, but if
the trap was unseen that trap would remain unseen, at least in some
circumstances. Mark the trap as seen.
When using '/' or ';' and picking--not just viewing the autodescribe
feedback for--a space or '#' on the map, the game would produce
That can be many things (stone)
or
That can be many things (corridor)
unlike the usual
- the interior of a monster or a wall or an open door (wall)
when the symbol matched more than 4 things. I first changed it to
append the full sentence's missing period, but ultimately switched to
# can be many things (corridor)
so that the symbol that "many things" refers to isn't hidden. This
works better for ^P where player isn't looking at the symbol anymore.
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.
Showing the price of a shop object when examining it with '/' or ';'
didn't include a price if it was actually a mimic. This makes fake
objects have prices when appropriate, but it is only a partial fix
because moving away from a mimic causes nethack to forget the fake
object's dknown flag for most types of objects.
That could be solved by adding an mobj field to mon->mextra, which
will break save compatibility, or by adding a whole extra set of
object glyphs for object-with-dknown-set. The latter could probably
be done without breaking backwards save compatibility (new program
using old files) but it seems like more effort that it'd be worth and
it would break forwards save compatibility (old program attempting to
use new files--something we've never claimed to support).
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.
When farlooking at a leash glyph on a map, the fake object should never
have leashmon set. This happened when a mimic was on the same spot
and was mimicing a corpse or statue, due to leashmon and corpsenm
using the same field.
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).
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.
get_cost_of_item() was giving different information from shop #chat
when dealing with containers owned by hero containing objects owned
by the shop. And when it was legitimately reporting a price of 0,
doname_with_price() wasn't reporting 'no charge' for items inside a
shop that were owned by hero or that shopkeeper didn't care about.
Extend the shop price reveal to far-look, but only when hero and item
being examined are inside the same shop.
When testing the change to the Eyes of the Overworld wording and asking
for information about inventory item
k - a pair of lenses named The Eyes of the Overworld
I got "I don't have any information on those things". Not because that
item wasn't identified, but because the lookup was for "pair of lenses"
(finding nothing) and then for "The Eyes of the Overworld" (and not
finding it due to "The" which is stripped from the first attempt but
wasn't from the second nor present in the data.base key).
Another item from static analysis. If an internal error ever caused
the "bad do_look buffer" warning from checkfile(), open file 'data'
would not be closed. (The bug in checkfile()'s caller which prompted
that check was fixed long go.)
An alternate fix would be to move the input buffer check to before
the file is opened, but verifying the file first seems worthwhile.
Under some circumstances, when all the marauding orcs belonging to the
horde operating within the gnomish mines had been provided with their
spoils and placed appropriately, there could still be some pillaged stuff
left-over on the migrating obj chain. Orcs created by regular monster
generation elsewhere would then be susceptable to receiving that stuff
until it was used up. That part is fine, except that the orcs were then
being named as part of the same horde operating within the mines. Now
they will no longer be named as part of the Gnomish Mines horde.
Mythos: There's a good chance that these particular orcs received the
stolen goods from the Gnomish Mines horde.
PatR