version feedback (trunk only)

     Show the 'v' output (full version number plus build date-time) as
the first line of '#version' output (build time configuration settings).
It isn't simple to do that when generating dat/options (there's some
port-specific tweaking going), so do it at run-time by processing that
file one line at a time instead of passing it through a pager routine.

     This also inserts an "About NetHack" entry as the first choice in
the menu for '?', the way that most Windows programs have interactive
help organized.  Picking that gives the same output as using #version.

'make depend' manually updated for Unix and VMS (add dlb.h to version.*).

'makedefs' handling for DEFAULT_WINDOW_SYS (trunk only)

     Change the windowing system section of generated file dat/options
to omit "with a default of <foo>" when it has listed just one enabled
windowing system.

     This also adds checks to make sure DEFAULT_WINDOW_SYS is defined,
at least one xxx_GRAPHICS option is enabled, and that the default matches
[one of] the enabled xxx_GRAPHICS.

fix W343-7 - strange topten output on Windows

     Move the toptenwin option from flags to iflags to keep it out of
save files, thus preventing odd behavior from win32 (nethackW.exe) when
restoring and finishing games started and saved with tty (nethack.exe).
[See cvs log entry for flag.h for more complete explanation.]

fix W343-7 - strange topten output on Windows

     Using the two Windows binaries, starting a game with the tty
interface (nethack.exe) and saving, then restoring and finishing with
the win32 interface (nethackW.exe) would display the topten output as a
series of popup windows displaying one line at a time.  The win32 binary
forces the toptenwin option to 1, but when restoring a saved game that
would get overridden by data from the save file and could end up 0.

     This change keeps the toptenwin option out of save files, like color
and other display-oriented features that might not be applicable when
restoring on something with different capabilities.  Separate binaries
for alternate interfaces aren't quite the same situation, but close enough.
The toptenwin option can still be toggled interactively with 'O', but the
new value will disappear if you save rather than finish.  Setting it once
via config file or environment variable is the preferred way to go if you
want to override the default behavior.

     Both trunk and branch get iflags.toptenwin added.  For the trunk,
flags.toptenwin is simply deleted and patchlevel.h's EDITLEVEL is bumped.
For the branch, flags.toptenwin is renamed and becomes unused, while
EDITLEVEL is left alone.  Leaving a dummy field in the old toptenwin slot
of struct flags preserves save file compatability with 3.4.3.

new command '`' to show discoveries for one class (trunk only)

     Use the grave accent (back tick) character as the keystroke for a
new command which prompts for an object class and then shows a subset of
the discovered objects list covering just the selected class.  Similar
to the 'I' variant of 'i' for viewing inventory, and mainly useful once
the '\' discoveries list has grown long.

#H2441 - Snow White (trunk only)

     <email deleted> suggested that eating a cursed apple
give a Snow White reference.  The apple eaten by Snow White is described
as poisoned, but cursed seems close enough.  Fall asleep for 20..30 turns
if you eat a cursed apple when you lack sleep resistance.

jabberwock hands

     Revert a change from five weeks ago which added M1_NOHANDS to the
jabberwock definition.  The jabberwock illustration from Lewis Carroll's
_Through_the_Looking_Glass_ depicts one with its forelegs held like arms
and the forefeet look like clutching hands.  Enormous hands, but
nethack's one-size-fits-all object model means they can manipulate things
just like anybody else's hands.

PANICTRACE on VMS (trunk only)

     The preliminary implementation of PANICTRACE on VMS had a "Fixme"
that this fixes, and a "TODO" that this makes moot, but the main reason
for this patch is that vmsmisc.c had been changed to call vms_define(),
which resides in vmsunix.c.  Since vmsmisc.obj is linked into progarms
in util/ and vmsunix.obj isn't, enabling PANICTRACE caused linking
problems for those.  This moves the code that wants to call vms_define()
into vmsunix.c (despite the fact that it's not even vaguely related to
Unix emulation), so that it only matters to nethack and doesn't impact
the utility programs anymore.

     This uses a VMS facility called LIB$INITIALIZE to call code before
main() starts.  It's rather messy--at least when written in something
other than assembler or Bliss--and shouldn't be needed for nethack,
but I couldn't figure out how to trap the condition signalled by
lib$signal(SS$_DEBUG) when the debugger isn't available to do so, so I
needed a way to make issuing that signal be conditional upon debugger
availability.  One of the arguments passed to LIB$INITIALIZE-invoked
routines contains information that makes if feasible to deduce whether
the debugger is available.

     Even when PANICTRACE is disabled, that's useful for handling abort
due to panic while in running in wizard mode.

sokoban completion (trunk only)

     Something I've had in mind for a long time and finally gotten around
to implementing:  when you fill in the last pit or hole of a sokoban level,
it's considered to be completed so luck penalties for unsokobanish things
(breaking a boulder, dropping everything and squeezing onto a boulder's
spot, reading a scroll of earth) stop being assessed and most Sokoban-
specific movement restrictions (against pushing boulders diagonally,
squeezing diagonally between boulders, floating over a pit or hole without
falling in, digging of new holes by monsters) are lifted.  Teleporting,
level teleporting, and phasing through walls are still prohibited when in
the sokoban branch of the dungeon.  (Keeping the non-phasing one in place
prevents taking a shortcut to the final prize in order to bypass the
treasure zoo monsters.)

     This adds level.flags.sokoban_rules, defines Sokoban macro to access
it, and replaces most In_sokoban(&u.uz) tests to check it instead.  It
gets set when a sokoban level is pre-mapped at the end of level creation,
and if it is set then whenever a trap is deleted, the flag gets cleared
if there are no more pits or holes present on the level.

probably fix teleport display bug (trunk only)

     This might fix the following buglist entry
|Teleporting while using tiles may place you one tile beyond the edge of
|the display screen, and place the crosshair on empty space.

     Various bits of code, including teleport, are assigning directly to
u.ux,u.uy instead of calling u_on_newpos().  It wouldn't be an issue for
small tiles where the whole map fits on the screen, but it probably is for
bigger ones where clipping is in operation.  Using u_on_newpos() adjusts
the clipped map right away but changing u.ux,u.uy directly won't do so
until control returns to moveloop() and it eventually calls cliparound().
Usually the hero's position only changes by one column and/or row, hence
stays within the clipping margin, but that's not the case for teleport
nor for hurtling (throwing recoil while levitating, &c).

     Perhaps all the places that assign u.ux,uy should call u_on_newpos()
instead?  Most--all?--of them aren't updating u.usteed->mx,my, but I
guess that monster's coordinates don't matter since it isn't placed on
the map.

wishing tweak: detect X vs X detection (trunk only)

     Allow wishing for a "potion of detect objects" to generate a
"potion of object detection", or for a "spellbook of monster detection"
to generate a "spellbook of detect monsters".

     To get a spellbook you'll need to explicitly specify "spellbook"
even when using a name that's unique to books:  asking for "detect food"
will yield a "scroll of food detection" rather than "spellbook of detect
food" because it finds potions and scrolls first.  [That's nothing new
for the case where a spellbook and potion or scroll have the same name,
only new behavior for "detect X" vs "X detection" matches.]

     Wishing for "detect food" used to yield a random food item rather
than a "spellbook of detect food".  That's fixed now, although as
mentioned above it will actually produce a "scroll of food detection".

shopkeeper inheriting hero's possessions (trunk only)

     Fix one of the issues noticed while investigating the report of a
shopkeeper sighing when a hero died without owing anything.  If the death
takes place outside of any shop on a level with multiple shopkeepers, the
first one in the fmon list would be the one who had access to the dying
hero's inventory, even if nothing was owed to that one and something was
owed to another shopkeeper.  Now the one who is owed gets first chance to
take the hero's possessions.

     When dying inside a shop, the keeper of that shop takes control of
the possessions regardless of whether he or anyone else is owed anything.
That hasn't changed, except that if the hero is simutaneoulsy inside
multiple shops (within a wall spot shared by two or more shops) and owes
money to one of them, the one who is owed will take his inventory even if
the other shk is found first.

     This doesn't include any changes to feedback given when the hero dies
in the presence of shopkeepers.

fix #H2428 - cockatrice nests filled with giant ant statues (trunk only)

     From a bug report, if the high scores file
is brand new (empty), statues placed in a cockatrice nest (special room)
end up all being giant ant statues.  Statue creation for that room
suppresses object initialization (to prevent the statues from containing
spellbooks), so statue type is left as 0 by mkobj(), then when 'record'
is empty it never gets overridden with a role value as intended.

     This forces obj->corpsenm to be initialized as NON_PM instead of 0
by default, then overrides that for corpses, statues, and figurines even
when mkobj()'s caller requests that initialization be suppressed.  So if
'record' is empty, there will be a sensible fallback statue type.

     obj->corpsenm is overloaded for leashes ('leashmon', mon->m_id),
potions ('fromsink', fountain quaff hack), spellbooks ('spestudied', the
number of times the book has been read), and loadstones (corpsenm hack to
handle singular vs plural for "you can't let go of that/those" message).
If there are any other hidden corpsenm overloads, they may behave
strangely now that corpsenm is defaulting to -1 instead of 0....

wizard mode wishing for traps (trunk only)

     Change the way wishing for bear traps in wizard mode is handled so
that spelling of "bear trap" vs "beartrap" doesn't affect the result.
Land mine doesn't have a similar spelling variation, so it already had to
be handled differently (if you wanted an armed trap, you needed to append
something--anything--such that it didn't match the object name).  Now
they're consistent with each other.  By default, you'll get an object
regardless of whether you include a space inside the name, and you'll
need to specify a prefix ("trapped") or a suffix ("trap"--actually,
anything other than "object") to get an armed trap placed on the ground.

  "bear trap", "beartrap", "untrapped bear[ ]trap", "bear[ ]trap object"
will yield the disarmed object,

  "trapped bear[ ]trap", "bear[ ]trap trap", "bear[ ]trap<anything else>"
will yield an armed trap.

  "land mine" works the same way, treating the embedded space as optional
even though both object and trap include it.

fix #H2397 - "<Mon> turns to flee" when paralyzed (trunk only)

     From a bug report, a
monster incapable of moving could yield the message "<Mon> turns to flee!"
when hit by an attack which scared it.  I thought that something to fix
this had already been done, but that wasn't the case.  Now it will give
"The immobile <mon> seems to flinch" instead.  I'd rather use
  mon->data->mmove == 0 ? "immobile <mon>" :
    mon->paralyzed ? "paralyzed <mon>" : "sleeping <mon>"
but it presently isn't possible to distinguish between sleep, paralysis,
and being busy doning armor because mon->mfrozen is used for all three.
(I'm not going to worry about the busy case, even though "immobile" sounds
inaccurate for it.)

     Also, stethoscope and probing were suppressing "scared" after giving
"can't move", in order to reduce the chance of wrapping the top line.
This changes it to display both status conditions so that scared state
isn't hidden when the target is paralyzed or asleep (or busy).

escapes() revamp

     Partial rewrite of escapes(), mostly changing its if-then-else
logic so that end-of-string can be checked once instead for each case.
The previous version had a bug if the input string ended with backslash
and one decimal digit (due to being lumped together with the handling
for trailing \X or \O).

fix exploitable security bug in options processing

     From a bug report, the function escapes(),
which is used during options parsing for various options that accept
string values, is given user-controlled input that could end with a
backslash or caret (or two character "\M").  Such a malformed escape
sequence would make it consume the input's end-of-string character and
then keep processing whatever followed.  That meant that it could
generate more data than its output buffer was prepared to hold, making
nethack be vulnerable to stack overflow issues.

     His example that was supposed to clobber the stack didn't trigger
any trouble for me, and I didn't bother trying the second one that can
allegedly cause the Win32 binary to run another program.  But the bug
itself is clearly real.

Sleeping vs Sleepy (trunk only)

     While looking at fixing the mfrozen issue for monsters (there's no
way to tell whether it's been caused by sleep or paralysis, necessitating
that some messages be vague or suppressed when actions impact monsters
who can't move), I noticed a drawbridge bug for the hero.  It was using
the misleadingly named Sleeping intrinsic incorrectly.  When that is
nonzero, the hero is prone to falling asleep at random intervals, not
necessarily asleep right now.  I've always intended to rename it to
something that's not misleading, but hadn't ever gotten around to doing
so, until now:  change the SLEEPING property to SLEEPY and the Sleeping
intrinsic/attribute to Sleepy.

     This may be moot for the drawbridge.  I can't remember any hero ever
jumping to safety instead of being crushed by either the bridge or its
portcullis, and I'm sure sleepiness hasn't been a factor.  So I haven't
included any fixes entry about misusing Sleeping when it meant u.usleep
(or better yet, unconscious(); or even better, Unaware [a post-3.4.3
pseudo-property that tests both unconscious() and fainted() when checking
whether hero is incapacitated]).

mark jabberwocks as M1_NOHANDS

     Jabberwocks are flagged as animals hence won't use items, or else
this would have been obvious long ago.  They weren't flagged as no-hands,
so a hero in their form could wear gloves and/or wield a weapon (or a
cockatrice corpse, whose ineffectiveness when used with a claw attack
which followed a bite attack led to the discovery of this oversight).
I'm not sure what a jabberwock ultimately looks like, but am pretty sure
that it shouldn't have usable hands, particularly ones which are only
usable by a poly'd hero and not by jabberwock monsters.

polyself weapon attack (trunk only)

     From the newsgroup:  hero poly'd into various monster forms would be
incapable of turning a target to stone when wielding a cockatrice corpse.
Monster forms with a claw attack as their very first attack (second for
incubus and sucubus, handled as a special case) would have that be
converted into a weapon attack.  But some monster forms start with bite
attacks and have their claw attacks later; a hero poly'd into such form
wouldn't use his/her wielded weapon.

     This fixes that, but it's actually academic (or about to become so).
The only monster capable of wielding a weapon which would then be ignored
was jabberwock, and I think leaving NOHANDS off the jabberwock definition
is a bug in itself (next patch...).

calculating shop price adjustments (trunk only)

     Fix the second of a couple of minor things I noticed when viewing
that guy's ttyrec about a hidden inventory item which turned out to be
scrolls of scare monster on the used-up items section of his shop bill.

     He had a lot of scroll prices which started as $X00 and were changed
to $Y99 due to integer division roundoff when being hit with a 1/3 price
increase for unID'd items followed by 1/2 price increase for low charisma:
  100  ->  133  ->  199
  200  ->  266  ->  399
Forcing things to round up instead of truncate would help in some cases
but yield $Z01 in others.  Rather than doing that, this accumulates the
adjustment factors and then uses them to make one calculation which gives
a better result:
  100  ->  200
  200  ->  400
Other values and/or other adjustments might not work out so well, but I
don't think they'll ever become prices which look worse than before.
For a single increase of 1/3, 100 still yields 133 but 200 now gives 267
(so ends up differing from the combined price for two 100->133 items).

shop credit feedback (trunk only)

     Fix the first of a couple of minor things I noticed when viewing
that guy's ttyrec about a hidden inventory item which turned out to be
scrolls of scare monster on the used-up items section of his shop bill.

     Be more precise when a shopkeeper gives the hero credit for dropped
gold.  Instead of just displaying
  N zorkmids are added to your credit.
show either
  You have established N zorkmids credit.
when you had no previous credit, or
  N zorkmids added to your credit; total is now X zorkmids.
when adding to existing credit.

packaging fix
Remove debugging output that was ending up inside a plist file.

fix #H2384 - ceiling hiding by poly'd hero (trunk only)

     From a bug report, a hero hiding on the
ceiling while poly'd into a piercer or lurker-above could be moved long
distances when a monster attacked his location, because when the attacker
moves into hero's spot, hero's new location is chosen before the attacker
had released its own spot.  If things are crowded, the nearest open space
can be quite far away, including beyond nonpassable walls.  Fix by taking
attacker off the map before choosing hero's destination, so in crowded
conditions they will likely end up trading places.

     This also prevents eels and sharks from moving onto land when the
hero has hidden on the ceiling next to their pool.  They'll miss without
moving into hero's spot, but the hero will become unhidden so they'll be
able to make ordinary water-to-shore attack on their next turn.

     Lastly, when the attacker is a long worm, the spot chosen for hero
might be filled by its tail by the time hero actually moves.  So double
check and possibly re-select target spot after moving a worm's tail.

fix #2382 - temp Dex loss becomes permanent when dismounting

     From a bug report, if you dismount
from a steed whose legs are wounded, you won't recover the point of
dexterity which was removed when they becme injured.  He noticed the
case where the steed had just died, but it happens for voluntary
dismount too (actually any dismount except one which wounds the hero's
legs in the process:  DISMOUNT_THROWN or DISMOUNT_FELL).

     It seems rather odd that the hero temporarily loses Dex when the
steed becomes injured, but I haven't changed that.

fix shop ownership of saddle dropped by dead pet (trunk only)

     From a bug report, you could obtain
a saddle for free if it was dropped (while worn) by a dying pet inside a
shop.  That's intentional, but it was happening even when the hero was
not in the shop, which doesn't seem right.  Change things to only set it
no_charge if hero is within the same shop (including standing in the
doorway or a temporary wall breach, not just when all the way inside) at
the time of the drop.

fix #H2326: support window resize on linux
From a bug report.  Applied the suggested change to enable window resize
support by default on linux.

vms update (trunk only)

     I hadn't tried the build script vmsbuild.com in a long time....
vmsbuild.com wasn't compiling src/sys.c;
vmsbuild.com and Makefile.src+Makefile.utl had some linking discrepancies;
Makefile.top, Makefile.dat, Makefile.doc - replace old SCCS id/date/rev
  comment with current cvs one (done for .src & .utl a month or so back);
config1.h - running DEC C in VAX C compatability mode to test linking
  yielded a diagnostic about signed in the schar typedef for every file.

Guidebook formatting
Get this in before it gets any staler.

fix #2276 - unlightable candelabrum

     From a bug report, applying unlit Candelabrum
of Invocation when its candles had 1 turn's worth of burning left would
give a message that the candles were burning but not actually light them
if done anywhere other than the invocation location.  Their burn time is
cut it half when not at that spot, and dividing an age of 1 yielded 0,
confusing begin_burn().  They wouldn't light and they couldn't be replaced
since they'd never get used up.

     The problem is real, but the chance of it actually happening in
normal play is just about zero.  This applies his suggested fix of
rounding the halved burn time up instead of down so that it can't yield 0.
It also applies his suggestion that the Candelabrum treat the invocation
spot like any other location once invocation has produced stairs there,
just as the Bell and the Book do.

extra additional paranoia (trunk only)

     When requiring "no" to reject in addition to "yes" to confirm one
of the paranoid_confirmation prompts, only loop a handful of times before
giving up and rejecting (in case there's some hangup-like situation that
isn't hangup enough to switch over to using ESC for further input).
There's no "that's enough tries" feedback; after 6 tries it just stops
asking for a yes or no answer and behaves as if it had gotten no.

Guidbook.mn typo (trunk only)

     nroff didn't care, but groff gives "warning: can't find font i".

additional paranoia (trunk only)

     A couple of extensions to the paranoid_confirmation option:

1) add paranoid_confirmation:Confirm -- setting this means that any
prompt where the other paranoid_confirm flags have been set to require
a yes response instead of y to confirm also require explicit no rather
than arbitrary non-yes to reject.  It will reprompt if you don't answer
"yes" or "no" (unless you use ESC, which is treated the same as "no").

2) add paranoid_confirmation:bones -- control whether the "save bones?"
prompt in wizard mode requires yes instead of just y.  The original user-
developed paranoid_confirm patch required yes unconditionally here, and
I left that out thinking it was undesireable.  But after testing the
"your body rises from the dead as <undead>..." fix a couple of days ago,
where you now get an extra message and consequent --More-- prompt just
before "save bones?", I've changed my mind about its usefulness, provided
that it's settable rather than unconditional.

     Handling paranoid_confirmation:bones outside of wizard mode is a
bit tricky.  Right now, it can still be seen via 'O' if it has been set
in NETHACKOPTIONS, but it won't show up in the menu if you use 'O' to
interactively change the value of paranoid_confirmation.  I'm not sure
whether that's the right way to go; it might be better to let non-wizard
users uselessly toggle it on and off rather than only partially hide it.
Or maybe it should be hidden from the current value even when it's set.
Or decline to set it in first place, despite external option settings.

paranoid_confirmation indentation cleanup
Pat confirms this is the intended behavior.

sort of/kind of support PANICTRACE on VMS (trunk only)

     I don't think this is useful enough to recommend ordinary users
enable it, but it's close enough to being useful that I don't want
to leave it to become subject to bit rot like umpteen other unfinished
patches.  Anyone running in wizard mode who has a panic already gets
pushed into the debugger on VMS, although it doesn't work for what might
be considered the most important configuration (a secure playground, as
opposed to the wide-open one I've always been content to leave mine at).

fix #H2259 - rising from dead message gives away info (trunk only)

     From a bug report, receiving the
message "Your body rises from the dead as an <undead>..." gives away
the fact that bones are being created (and its absence when applicable
undead kills the hero gives away the fact that bones aren't being
created).  Not very interesting for single player installations where
5-10 seconds later the player is going to check the playground for new
files, but matters on multi-user installations where players don't have
access to the directory and sometimes race each other to juicy bones,
such as nethack.alt.org.

     At the end of disclosure, give the message whether bones are being
saved or not (for cases where it would have happened when bones are
created).  Player won't know whether new bones are becoming available.
Also, prevent risen undead-from-hero from being given random monster
inventory, but explicitly give mummy-from-hero a mummy wrapping if the
hero isn't already carrying one.  It will end up being worn; that's
the only armor mummies are allowed to put on.

number_pad formatting fix for Guidebook.tex
Fix the alignment issue Pat noted (this is different than the suggestion I
mailed out - installing latex so I could test it proved it was wrong).

SYSCF for VMS (trunk only)

     Enable SYSCF_FILE for VMS, and simplify option initialization
in the process.  I still need to put a template into the playground
directory during initial install, and the one in sys/unix/ probably
isn't appropriate.

SYSCF/PANICLOG fix (trunk only)

     files.c wouldn't compile if SYSCF was defined and PANICLOG wasn't.
Also, a couple of PANICLOG option sanity checks treated 0 as an error
but then said that the value had to be 0, 1, or 2.  I went with the
message and changed it to treat 0 as ok.  Unfortunately the numeric
value is derived via atoi() so you get 0 from bogus input.  Perhaps it
should use sscanf(string,"%d%c",&number,&dummy)==1 to try harder to make
sure it actually gets a number.

avoid lava recursion

     Noticed while working on the "lava inconsistencies" patch:  it was
possible for lava_effects() to be called recursively, despite a patch
five and half years ago which was supposed to prevent that.  That patch
handled the case where the hero dies and gets life-saved, but it didn't
deal with a hero who survives due to water walking boots and then has
those burned away.  [Not an issue in 3.4.3 because Boots_off() didn't
call spoteffects() for lava then, but it does in post-3.4.3 branch as
well as trunk.  fixes34.4 has an entry about fixing an "object lost"
panic for this but I don't think it's accurate.  I think that the panic
only became possible after the post-3.4.3 "handle lava when removing or
losing water walking boots" fix was introduced.]

fix #H2247 - lava inconsistencies (trunk only)

     From a bug report, if you move into lava, die,
and are life-saved or leave bones, your potions will remain intact,
whereas if you have fire resistance and survive, they'll be subjected to
destroy_item() and usually be destroyed (not always, because stacks of
more than 1 don't always destroy the whole stack).  Also, wooden ring
will be destroyed even if it happens to be ring of fire resistance.
This addresses both of those bugs.

     He also thought that all vulnerable armor should be destroyed rather
than just boots in the case where you have fire resistance and survive,
but I didn't change that.  It is a little odd, but presumeably only your
feet are in lava at first (although later sinking further into lava
doesn't actually burn up any other stuff).

avoid mkclass() infinite loop (trunk only)

     Back on Feb 28, I committed a patch to prevent the special level
loader from generating mail daemons for levels which specified random
demons.  It had a pair of copy+paste mistakes that could result in
mkclass() looping forever.  It was looking at the same monster every
time and if that monster was one which mustn't be generated, it would
just keep repeating.

fix #2142 - skipping levels when climbing with Amulet

     From a bug report,
when climbing out of Gehennom while carrying the Amulet, you could skip
a handful of levels by taking the magic portal into the Wizard's Tower,
dropping the Amulet, zapping it with a wand of teleportation--possibly
more than once--until it lands outside the tower.  Then take the portal
back out of the tower and level teleport--feasible now that you're not
carrying the Amulet any more--back to the tower level and retrieve the
Amulet.  Overall probably not much of a savings unless you're having
really bad luck with the mysterious force sending you back whenever you
try to go up.  The hero and monsters can't teleport from inside the tower
to the outside or vice versa; this gives the same limitation to objects.

altmeta Alt key hack, mainly for unix (trunk only)

     Some time ago we received a patch submission which attempted to
handle the Alt key for terminals or emulators which transmit two char
sequence "ESC c" when Alt+c is pressed, but I can't find it.  I don't
remember the details but recall that it had at least once significant
problem (perhaps just that it was unconditional, although it may have
been implemented in a way which interferred with using ESC to cancel).

     This patch reimplements the desired fix, making the new behavior be
conditional on a boolean option:  altmeta.  That option already exists
for the Amiga port, where it deals with low-level keyboard handling but
essentially affects the same thing:  whether Alt+key can be used as a
shortcut for various extended commands.  This one affects how the core
processes commands, and is only available if ALTMETA is defined at
compile time.  I've defined that for Unix and VMS; other ports don't
seem to need it.  (I'm not sure whether "options" created by makedefs
ought to mention it.  So far, it doesn't since this isn't something
users are expected to tweak.  The setting of the non-Amiga altmeta
option doesn't get saved and restored, so won't affect saved data if
someone does toggle ALTMETA and then rebuild.)

     When [non-Amiga] altmeta is set, nethack's core will give special
handling to ESC, but only during top level command processing.  If ESC
is seen while reading a command, it will be consumed and then the next
character seen will have its meta bit set.  This introduces a potential
problem:  typing ESC as a command will result in waiting for another
character instead of reporting that that isn't a valid command.  Since it
isn't a valid command, this shouldn't be a big deal, but starting a count
intended to prefix your next command and then typing ESC after deciding
to abort that count runs into the same situation:  nethack will wait for
another character to complete the two character sequence expected for
"ESC c".  There's not much that can be done with this, other than have
the Guidebook mention that an extra ESC is needed to cancel the pending
count, because digits followed by ESC could actually be a numeric prefix
for Alt+something rather than an attempt to abort the count.

fix #2253 - shk dismissing kops from other level (trunk only)

     From a bug report, if you rob a shop, let the
angry shopkeeper catch up with you outside his shop, escape to another
level with adjacent shk tagging along, then pacify the shk by paying him
off, he will dismiss kops on the present level and return to his shop
but when you return to his shop level there'll still be kops chasing you
there.  This fix adds an extra flag to the eshk structure so that kops
can be dismissed a second time when the shk migrates back to shop level.
The first dismisal (on the "wrong" level) still takes place in case any
kops are around.  Neither dismissal actually occurs if there happens to
be another angry shk present on the level where dismissal is being done.

vms Meta key hack (trunk only)

     I can't figure out how to make PuTTY use the Alt key to function as
a Meta key and set a character's high bit, so I used this hack to test
the M-5 fix just committed.  This lets me specify a character to be used
to force the next character to have its high bit set, so I can fake the
Meta key with a two character sequence.  (I used the back-tick/accent,
since nethack doesn't do anything special with it.)  Conceivably something
like this should be promoted to the core; this just affects VMS, and only
when vmstty.c is compiled with DEBUG defined.

fix #2251 - M-5 operation with number_pad:2

     From a bug report, using Alt+5 when number_pad mode
is set to MSDOS compatibility (where Alt+5 is supposed to function as the
'G' movement prefix) didn't work correctly.  The code that did M-5 to G
conversion was being executed after the code which should have gotten G's
direction, resulting in strange behavior, probably using stale values for
u.dx and u.dy.  (With current dev code, I evidently had u.dx==0 && u.dy==0
so was getting "You can't get there from here..." which is actually pretty
amusing in the current context.  3.4.3 didn't have that feedback so I'm
not sure what happened in it; possibly just silent refusal to move.)

fix #2236 - bag of holding weight

     From a bug report, the weight of a non-cursed bag
of holding would be off by 1 when the weight of contents was a multiple
of 2 (for uncursed) or of 4 (for blessed), since the round off handling
added 1 when it shouldn't in those cases.  Mainly noticeable when empty;
the extra 1 unit made it be twice as heavy as it should have been.

     Probably never noticed in actual play.  He has implemented a patch
which shows weights as part of an object's formatted description, making
this stand out.  Supposedly the Vulture's Eye interface also added a
patch like that a farily long time ago; I wonder why nobody using it ever
noticed.  (Maybe the weight was suppressed for bags of holding there?)

magic cancellation/Protection revamp (trunk only)

     Optimize yesterday's new code.  When calculating magic cancellation,
avoid calling protects() for hero's inventory; the information it's
providing is already available via u.uprops[PROTECTION].  That part of
the inventory scan is only needed for monsters.

typo/thinko fix (trunk only)

magic cancellation and Protection (trunk only)

     Magic cancellation comes from some types of worn armor and has a
value of 0 through 3.  A non-zero value guards against some forms of
monster magic attacks (most notably, level drain by vampires and wraiths
and lycanthropy from werecritter bites).  This reduces the effectiveness
of mc a moderate amount (the new values happen to be the same as those
adopted by the Spork variant):
 chance to block various touch effects
  mc  old     new
   1  34.67%  30%
   2  67.33%  60%
   3  98%     90%

    This also makes the Protection intrinsic (strictly speaking, extrinsic)
be the only way to attain an mc factor of 3.  Cloak of protection is the
only way to get mc 3 from a single item.  Otherwise you need an mc 2 item
and a ring of protection (or one of the recently modified quest artifacts).

     Cancellation factor for elven and dwarvish mithril coats and for
robes and oilskin cloaks is reduced from 3 to 2; for elven cloak and
cloak of magic resistance from 3 to 1 (play balance; they're valuable
even without magic cancellation); for dwarven and orcish cloaks and
clocks of invisibility and displacement and for cornuthaum (wizard hat)
from 2 to 1.  Plate mail and crystal plate mail stay at 2.  A variety of
suits which were at 0 are increased to 1; leather jacket and dragon
scales/scale mail stay at 0 (the latter for play balance rather than for
the amount of your body that's covered).

     Having extrinsic protection will increase mc by 1 (unless it's
already 3).  That's obtained by wearing a cloak of protection (where the
increase is redundant), a ring (or two) of protection (even if conferring
a negative AC amount), or wearing the Mitre of Holiness or wielding the
Tsurugi of Muramasa.  Having multiple sources doesn't make the benefit
cumulative; it's just +1.

     Intrinsic protection (bought from priest, gained from prayer, gained
from eating rings of protection while polymorphed into metallivore, or
temporary while spell of protection is active) doesn't increase mc from
armor but does provide minimum mc 1 instead of naked 0 (play balance
again; buying it is too easy to let it increase mc 1 or 2 to 2 or 3).
(Extrinsic protection is a superset; its +1 bonus also increases 0 to 1.)

    TODO: add an amulet of protection so player has another option for
extrinsic protection.

Protection groundwork/artifact tweaks (trunk only)

     This is mostly groundwork prior to making the Protection intrinsic
become more meaningful.  The Mitre of Holiness (priest quest artifact)
and the Tsurugi of Muramasa (samurai quest artifact) will now confer
Protection when worn/wielded (though at present that effectively does
nothing).  While in there, this also changes the Eye of the Aethiopica
(wizard quest artifact), the Eyes of the Overworld (monk quest artifact),
and the Sceptre of Might (caveman quest artifact) so that they need to
be worn/wielded rather than just carried in order for them to confer
magic resistance.  That way they're a little less attractive for wishing
by other roles and a little more likely to be actively used by their own
roles (not an issues for the Eyes, I'm sure).  This change actually works
to the player's advantage, since it means that monsters who successfully
steal those items won't instantly obtain magic resistance in the process.

     This adds protects() as a predicate routine to check an item for
conferring Protection.  In order to do that, it renames the existing
protects() routine to defends_when_carried(), because that predicate is
actually a variant of defends() for items which aren't worn or wielded.

yet another test

high level monster spell casting (trunk only)

     Mage-spell casters higher than level 23 and cleric-spell casters
higher than level 13 became less and less likely to cast interesting
spells as level went higher, more and more likely to cast the default
psi-bolt or open wounds.  [Level 21 caster had 4.75% chance to cast
touch of death; level 22, 9%; level 23, 13% chance; then level 24, 12.5%;
level 25, 12%; level 30, 10%; level 50 (demon lords/princes), only 6%.]
This oddity in spell selection meant that the Wizard of Yendor gradually
became less likely to use "double trouble" to clone himself as he got
killed off more times and his next incarnation arrived at higher level.
This fix makes high level casters who pick too-high spell usually retry
until they get a valid one instead of just reverting to the default.
Still slightly biased towards psi-bolt and open wounds, since they're
effective even though a bit boring.

Guidebook update (paranoid_confirmation 3 of 2) (trunk only)

     This started out just documenting the commands where use of the
new paranoid_confirmation option was relevant, but it end up sprawling
to other stuff so I left it out of the paranoid_confirmation patch.
Eventually I changed all the commands with long-ish descriptions to use
a single line summary of the what the command does, with any additional
explanation or examples forced into a separate paragraph instead of
just being appended to the summary.  It increases the number of lines
and probably pages in the document, but I think it makes skimming over
the list of actual commands much easier.

     A couple of unmodified command descriptions are 'f' and 'Q'.  The
only way I could avoid the temptation to discard "quiver sack" was to
leave those alone entirely.

     A couple of others received some spoiler-ish additions, notably
#offer (which doesn't actually give anything away) and #pray (where
someone might assume that the command is useless if their very first
attempt gets rejected).  I also added tips for two-weapon combat (how
to set up to use it, not when or why to use it) that ended up being much
more verbose than planned.

     I don't know whether nroff+tmac.n offers a better way to get a
non-indented paragraph than using a labeled paragraph with an empty
label; .lp "" achieved what I wanted so I used it quite a bit.  I also
wanted the value lists for number_pad and paranoid_confirmation to not
be indented but failed to figure out how to do that properly.  In
Guidebook.mn they're still indented; in Guidebook.tex number_pad fakes
it using fixed-with tt font, paranoid_confirmation approximates it with
a ridiculous indentation hack.  The number_pad result is wrong, but I've
given up.  "~0" lines up with "-1", but "~1" through "~4" line up with
the minus sign instead of with the 1 as if that unbreakable space prefix
wasn't there.

another test (cross your fingers)

another test

another try

another test

yet another test run

back out test - make sure things work

another test

another dummy test

dummy change test

another dummy change test

dummy change for testing (reduce debugging output - I'm done for now)

dummy change for testing

dummy change for testing

dummy change for testing

just mess with zap.c to continue debugging postcommit.pl

yet another compiler warning

another compiler warning

another compiler warning

another compiler warning

another compiler warning

another compiler warning

another compiler warning

another compiler warning

fix one compiler warning (first attempt to probe for cvs email bug)

paranoid_confirmation [expanded user patch] (trunk only; 2 of 2)

[Short writeup; see 'cvs log' of flag.h or options.c for the long one.]

     This is a reworking of user contributed patch known as Paranoid_Quit.

     Add a new compound option, paranoid_confirmation, accepting a space
separated list of values "quit die attack pray Remove"; default is "pray".
paranoid:quit   - yes vs y for "really quit?" and "enter explore mode?"
paranoid:die    - yes vs y for "die?" in explore mode or wizard mode
paranoid:attack - yes vs y for "really attack <peacful monster>?"
paranoid:pray   - y to pray; supersedes prayconfirm boolean; on by default
paranoid:Remove - always issue an inventory prompt for 'R' an 'T', even
  when only one applicable item is currently worn.

paranoid_confirmation [expanded user patch] (trunk only; 1 of 2)

[Long writeup committed with flag.h and options.c only.]

     This is a reworking of a user contributed patch available in Pasi
Kallinen's NetHack Patch Database at http://bilious.homelinux.org under
the name "Paranoid_Quit".  It was created by David Damerell and extended
by several others, and I haven't attempted to preserve attribution.

     Their patch added three new boolean run-time options (this one
doesn't; details below):

paranoid_quit: if true, change the "really quit?" prompt to require an
  answer of yes rather than just y to quit, presumeably for players who
  type faster than they read and think (been there, done that...).  It
  also applies to the "do you want to enter explore mode?" prompt.  The
  changed prompt shows yes and no rather than yn as possible answers.
  After having used it a few times, I find it easily noticeable that
  "yes"<return> is expected instead of just single keystroke 'y', and
  if you mess up somehow you can just reissue the #quit or X command
  with no harm done.  (And the default setting is off; the game still
  issues the original yn prompt.)

paranoid_hit: if true, make a similar change for the "really attack <the
  peaceful monster>?" prompt.  Definitely helpful if you bump into a
  monster while in the midst of using 'y' to move diagonally upper left.
  Note that this just changes the expected/required answer to an existing
  prompt; it doesn't change interaction between the hero and monsters.

paranoid_remove: if true, the 'R' and 'T' commands will prompt the player
  to select an appropriate item from inventory even when there's only one
  applicable item (instead of simply removing or taking off that only
  item).  Helpful if you think you've got more than one thing on and
  intend to take off something other than the last one (which might be a
  ring of levitation keeping you from dropping into lava or a blindfold
  and you're trying to play the whole game blinded).

Their patch also made two other changes which weren't controllable via
options:  when dipping, after picking what to dip, mention it in the
second prompt for what to dip into; and require yes instead of y at the
wizard mode "save bones?" prompt.  We've had the enhanced dipping prompt
for a while, and "unknown" installed a fix-up (which wasn't needed with
their version) for it recently.  I've left our bones prompt alone, the
original yn query.  Anyone who saves bones by accident can remove them,
if not externally they by using wizard mode to revisit the same dungeon
depth, load the bones, and unlink them.

#####
     That's a summary of the contributed patch.  Now for the implemented
one....  Instead of separate booleans, this adds a single compound option
called "paranoid_confirmation" that takes a string argument of space
separated words:  "quit die attack pray Remove".  And it puts the actual
yes vs y querying into a new routine instead of duplicating it at each
affected prompting location.

paranoid_confirm:quit - as above, if true then require yes instead of y
  to answer the "really quit?" and "do you want to enter explore mode?"
  prompts.  Can also be supplied as paranoid_confirm:explore or even
  "quit explore" but that's just redundant; it's a single flag which
  controls prompting for both game-ending or game-altering commands.

paranoid_confirm:die - applicable only for explore and wizard modes but
  visible/settable during option viewing/changing in normal play.  If
  true then require yes instead of y at the "die?" prompt.  This wasn't
  part of their original patch, but should have been since the effect
  of accidental y is just as drastic as unintentionally quitting.

paranoid_confirm:attack - as above, yes vs y for "really attack <the
  peaceful monster?".  Can also be supplied as paranoid_confirm:hit.

paranoid_confirm:pray - supersedes the existing prayconfirm boolean.
  That option is still accepted and honored duing config file processing,
  but option viewing/changing with 'O' only handles the new variant.
  This does not control "yes" vs 'y', but rather whether there's a prompt
  first or prayer simply starts.  When used, the prompt itself is the
  same yn one already being asked with prayconfirm.  Presumably config
  file support for prayconfirm will go away in some future version.
  Unlike the other paranoid settings, this one defaults to 'on' in order
  to match the 3.3.0 through 3.4.3 behavior controlled by prayconfirm,
  whose default was on (but maybe should have been off...).

paranoid_confirm:Remove - as above, causes the 'R' and 'T' commands to
  use a "what do you want to remove?" or "what do you want to takeoff?"
  inventory selection prompt even when only one accessory or piece of
  armor is worn.  Player can pick the inventory letter and remove/takeoff
  the item, use ? or * to see what the candidate item is, or cancel with
  ESC.  Can be supplied as paranoid_confirm:takeoff or "remove takeoff",
  but like with "quit explore", a single flag controls the behavior of
  both 'R' and 'T'.

Option file processing accepts two other settings, paranoid_confirm:none
and paranoid_confirm:all, but those are not available (nor needed) when
using the 'O' command.  "none" is useful because it's the value shown to
the player by 'O' when none of the paranoia flags are set, and it's a
way to turn off paranoid_confirm:pray without turning on any of the other
choices.  "all" probably isn't very useful but was trivial to tack on.

     This is an example of the menu that 'O' puts up after picking option
paranoid_confirmation from the main list.  I've shifted everything left
to reduce whitespace here; it appears on the right side of the screen for
tty menuing.

  Actions requiring extra confirmation:

  q - yes vs y to quit or to enter explore mode
  d - yes vs y to die (explore mode or debug mode)
  a - yes vs y to attack a peaceful monster
  p + y to pray (supersedes old "prayconfirm" option)
  R - always pick from inventory for Remove and Takeoff
  (end)

Currently set paranoia features are marked as preselected and can be
toggled off along with toggling any others on as desired.  I've just
realized that this menu relies on showing entries marked via preselection
rather than explicitly annotating each one as [on] or [off]; that seemed
perfectly natural during testing so I think I'll leave it this way, at
least for the time being.

#dip fix (trunk only)

     A post-3.4.3 dipping change (to make the dipping prompt mention
the item that you've chosen to dip) formats a phrase for its eventual
getobj() call in advance, but then was modifying it inappropriately if
you were on a fountain or pool location.  If you declined to dip into
the fountain or pool, the prompt for carried potion to dip into was
garbled:   "What do you want to Dip <the object> into the fountain??".
instead of "What do you want to dip <the object> into?".  Fix to use
a separate buffer in the case of a fountain or pool prompt so that the
"dip <the object> into" phrase will be intact when calling getobj().

new man/woman (polyself, inevitably...)

     Noticed when testing the [trunk] ^X fix:  polymorphing into human
form (not reverting to original form) reported "you feel like a new man"
when I resumed being a cavewomen.  Like with ^X, it used poly'd hero's
current monster gender instead of the about-to-be-restored role gender.
It's amazing that nobody seems to have ever noticed in all this time.

^X fixes  (trunk only)

     Being a cavewoman polymorphed into a male creature revealed multiple
mistakes in the post-3.4.3 ^X code, including the initial title text.
It was using current gender in several places where it should have been
using the saved value that applies when not polymorphed, leading to
confusion as to whether you'd changed genders if/when current and saved
ones were different.  More noticeable with gender-distinct role names.

dragon scale mail degraded by polymorphing into dragon (trunk only)

     Apparently I lied yesterday when I said that patch was the last
polyself one.  This has been on my agenda for a long time:  when dragon
scale mail merges with your skin during polymorph into the corresponding
dragon, have it revert from mail to scales.  Its enchantment stays the
same when reverting.  So after returning to your original form, using
enchant armor to convert it into scale mail again will eventually risk
its destruction due to over-enchanting.  (Cursed scroll of enchant armor,
spell of drain life, or being hit by a disenchanter can be used to reduce
its enchantment back to a safe-to-enchnat value.  Or cancellation if
you're desperate.  I think those all work on all colors of dragon scales
despite the assorted magical properties that scales confer.)

fix #H2200 - disintegration by divine wrath (trunk only)

     From a bug report, it you're targetted by
divine wratch while swallowed by a shock-resistant engulfer, the
ineffective lightning is followed by a wide-angle disintegration beam
which "fries <the engulfer> to a crisp"; he felt that being fried was
not appropriate for disintegration.  I agree.  (He also failed to notice
that the exact same terminology is used for killing the hero when not
swallowed.)  I wanted to use "disintegrated into a cloud of dust" here,
but if a suit has just been disintegrated you'll have seen "turns to dust
and falls to the floor" for that, so I settled for "into a pile of dust".

one last(?) polyself bit: no control while stunned (trunk only)

     Teleport_control is disabled while the hero is Stunned; do the same
with Polymorph_control.  Also now disabled while unconscious, but that
is academic since random polymorphs and were-critter transformations are
postponed until multi is non-negative.  I included it for completeness.
(Reverting to original form can occur while unconscious, but control is
not a factor in that situation.  Teleporting handles being unconscious
differently but does negate control then.)

     The fixes entry could just as easily have gone into the new features
section as into the bug fixes one.  The teleport control part actually
belongs in fixes34.4 because it is present in the branch, but I didn't
feel like spreading this across two different files (and the current diff
references ``Unaware'' which doesn't exist in the branch so it isn't
trivial to include this patch there).

still more polyself fallout (trunk only)

     Also noticed while testing polyself changes, a few polymorph related
items weren't being listed as reasons for having some polymorph related
intrinsics during wizard mode enlightenment (a post-3.4.3 feature).
There may be other intrinsics conferred by items where you aren't told
about the item being responsible; I didn't look around for them, just
noticed these three:  Unchanging (via amulet), Polymorph (via ring), and
Protection from Shape Changers (also via ring).

more polyself fallout (trunk only)

     When testing the change of "you can't polymorph into that" to
"you can't polymorph into <a monster type>" I noticed that specifying
high priestess told me that I couldn't become a priest (role monster),
but specifying high priest told me that I couldn't become a high priest
(monster as-is).  Aligned priestess and high priestess aren't separate
monsters; the user-specific string to monster name code found the latter
as a rank title rather than as a monster and couldn't find the former
at all.  This adds those two special monst types to the list of variant
spellings and whatnot that are used to augment name to type lookup.
Since they aren't viable candidates for polyself or for genocide I doubt
that any players ever noticed, so I haven't added a fixes entry for this.

polyself changes (trunk only)

     While making the change to prevent random mail daemons, I noticed
that controlled self-polymorph into a critter specified by class (a post-
3.4.3 feature) rather than by name wasn't excluding NOPOLY monsters so I
checked to see if they were being handled correctly.  Accepting NOPOLY
monsters as candidates was intentional but it had a problem (although
many NOPOLY monsters are NOGEN and vice versa, so the problem wouldn't
show up often).  If I specified A and Archon was randonly chosen, I'd
be told "you can't polymorph into that" but if I retried A and it chose
couatl, the polymorph succeeded.  This changes the way the first case
gets handled:  it skips the message and makes another pick from the
specified class, although that consumes the same retry counter as
reprompting so you might still end up with "you can't" if random picks
come out unfavorably too many times (or if you've typed in some bad
choices first and the counter has already been reduced).

     When doing that, I changed the "you can't" message to say what it
is you can't polymorph into, instead of just "that".

     And I've changed controlled polymorph to accept ESC when prompted
for monster type.  When used, either don't polymorph (for wizard mode
#polyself command) or revert to uncontrolled poly (for all other causes
of polyself) instead of just asking again.  Specifying "*" or "random"
will also produce uncontrolled polymorph.

spurious mail daemons (trunk only)

     From the newsgroup:  when the special level loader is creating
random '&' class monsters, it can produce mail daemons.  The thread
reports seeing some on the levels holding the Wizard of Yendor's Tower
and they vanish as soon as it's their turn to move.  I didn't reproduce
it, but create_monster() is overriding the NOGEN flag when it calls
mkclass() so getting mail daemons is feasible.  This fixes that by
treating them similar to the human/elf/orc/giant placeholder monsters
that are excluded from random generation.  More or less.

fix #H2225 - death by poison after life-saving (trunk only)

     From a bug report,
when falling into a spiked pit and being killed and then life-saved, you
could immediately die from fatal poison.  It isn't necessarily a bug and
there are other ways to be killed, life-saved, and re-killed (such as
zaps that bounce off walls or reflecting targets), but it does seem to be
somewhat unfair.  This patch makes life-saving be more effective:  in a
damage-plus-poison situation, if the damage triggers life-saving then the
poison won't deal out any further damage (including its nasty chance for
instant death).  The poison still matters, but it will always target an
attribute stat--which is already one possible random outcome--instead of
maybe doing damage.  [It is actually possible to get damage if stat loss
tries to take hero's strength below 3, but now there's no chance of that
being fatal immediately after savelife() has restored full hit points.]

enlightenment/status feedback about wielded weapons (trunk only)

     I noticed "you were wielding two weapons at once" in end of game
disclosure from a newsgroup ascension post for the Spork variant and
thought we ought to show that too.  Well we already do.  This moves it
from an attribute entry for magical enlightenment to a status entry for
^X display since it's something the hero and the player should already
always know.  In the process I added feedback for being weaponless and
then went further and added some feedback about what weapon is wielded.
This is stuff that could/would be shown on the status line if there were
room, and fits with the post-3.4.3 ^X expansion of cryptic status stuff.

     The "new ^X output" entry in the new features section of fixes35.0
covers this too.

multishot throwing/shooting tweaks (trunk only)

     I've been sitting on this for a long time (29 months?); it got more
elaborate for a while, then got stripped back to something fairly simple.
The original description was once accidentally attached to an unrelated
patch; it was more detailed than this one....

     This makes it harder for non-fighter types to throw or shoot
multishot volleys of missiles, and gives a couple of minor new bonues to
try to get a little more variety than the current situation of everyone
(with possible exception of arrow shooting by rangers) just using stacks
of daggers for ranged attacks.  Since daggers are so plentiful that's
probably just wishful thinking.

mimic-as-door stealing key (trunk only)

     Suggested by <email deleted> a month ago when he
reported that attempting to unlock a door which was actually a mimic
simply told the player that the door was not locked or that there was
no door.  He thought that mimic should take the key/pick/card away from
the hero.  This gives a 50% chance for the unlocking tool to be stolen
and become part of the mimic's inventory; it will be dropped when mimic
is killed.

     The theft routine has groundwork to be able to be used to take the
hero's wielded or thrown weapon when hitting, but the attack code doesn't
call it so that won't happen (and the theft code hasn't been tested under
that circumstance).  I'm not sure whether mimics should be able to grab
weapons, but g.cubes perhaps should, and if puddings could then "pudding
farming" [using a low damage iron weapon to split puddings, yielding tons
of experience, death drops, and #offer fodder when they're killed and
repeatable for as long as at least one pudding is kept healthy enough to
be split again] would become tougher to accomplish.  [The item drop and
corpse aspects have been toned down quite a bit since 3.4.3, but with
sufficient patience it is still possible to abuse.]

stumble_onto_mimic while blind, #untrap vs mimic

     Noticed while testing a forthcoming mimic patch:  when blind, some
actions (open, close, #untrap, applying a key [as of a month ago],
possibly others) taken against a mimic posing as a door would yield
"Wait!  That's a monster!" but leave the map showing the door instead
of replacing it with the unseen monster glyph.  Similarly, using #untrap
towards a known trap location covered by a concealed mimic could yield
"It is in the way." or "It isn't trapped.", depending upon the type of
trap present, and not reveal the mimic.  Same thing happened when not
blind, except the message would refer to "the <size> mimic" rather than
"it".  Now it will expose the mimic, regardless of the type of trap.

fix the typo added while fixing the typo in Coyote name

H2198: "Nemesis Ridiculii" is spelled wrong.

thrownobj, kick[ed]obj (trunk only)

     Rename ``kickobj'' to ``kickedobj'' so that the tense matches that
of ``thrownobj''.  Also, move their declarations to decl.h and their
definitions to decl.c since usage has spread from dokick.c/dothrow.c to
various files and is about to expand to another one.

monsters taking possession of shop items

     Noticed while looking through steal.c:  theft that takes multiple
turns uses stealarm() callback which removes stolen armor from hero's
shopping bill, but theft that happened without delay did not.  So theft
of an unpaid non-armor or non-worn item while in a shop left it on the
bill where it wouldn't show up for either ``I u'' or ``I x'', hiding the
charge from the player ('$' did disclose the total amount that the shk
was owed though), and the shopkeeper would persist in blocking the door.
This makes immediate theft behave the same as delayed theft; the stolen
item is removed from shop's bill when the thieving monster takes it away
from the hero.

     Dropped items that a shopkeeper doesn't want have their no_charge
bit set; that's only supposed to be used for floor items inside shops.
But no_charge would stick when an object was picked up by a monster, so
the object would stay free for player if that monster was subsequently
killed in another shop which stocked that kind of item.  Probably never
noticed because most monsters won't pick up items off of shop floors,
also most levels don't have other shops dealing with alternate types of
stuff.  This clears no_charge, except when the monster picking up the
item is tame (so that a pet picking up and then dropping a no_change
object in the same shop won't cause the shk to silently take possession,
which would certainly lead to reports of a bug...).