fix #H11 - forcing lock with mattock

     From a bug report:  dwarvish mattock was
subject to breaking when attempting to force a lock, because it is treated
as a bladed weapon.  So is pick-axe; they're both defined as blunt (WHACK
attack mode), but the definition of is_blade() erroneously includes them
since P_PICK_AXE falls between P_DAGGER and P_SABER.  That skill should be
renumbered, but I haven't investigated what else might happen when that's
done so this fix uses a special case instead.

     I noticed that there was an unnecessary old check for rubber hose;
it's excluded along with whip by the skill > P_LANCE test.  When fixing
that up, I realized that the obscure feature of forcing via statue was
broken; it always failed the skill < P_DAGGER test.  Also, I took away the
exception for aklys; even though designed as a throwing weapon, it is used
as a club.  I wasn't sure about the exception for flail; it is perfectly
capable of bashing things but the code apparently excludes it for use as
a prying implement.  Switching its check to P_FLAIL catches grappling hook
along with it.

genociding mindflayers

     When looking at name_to_mon() to teach it how to cope with possessive
suffices, I discovered that it already knows how.  But while looking at
it, I remembered a newsgroup complaint from a while back by someone who
accidentally committed suicide by attempting to genocide "master mindflayers"
(when he meant "master mind flayers").  name_to_mon() didn't recognize that
misspelling but it did match "master" as a role title.  Unfortunately for
the player, his character was a monk; the game allowed him to genocide his
own role and he died.  That's kind of harsh for such a likely misspelling.
(I don't think a monk is very likely to ever use "master thief" as a mistake
for "master of thieves", but catch that one too just in case.  Conversely,
recognize "master of assassins" as an alternate for "master assassin".)

     Also, wishing for "the <something>" strips off "the" and finds (or not)
<something>, but genociding didn't.  You could specify "a wolf" to wipe out
all wolves, but "the wolf" yielded "such creatures don't exist", and ^G had
similar unfriendly behavior.  This extends name_to_mon() to handle it.

corpse_xname overhaul (trunk only)

     Extend the capabilities of corpse_xname() so that various callers can
be simplified.  It can how handle an article prefix, effectively turning it
into corpse_doname() (not quite; still need doname() to see a count when
quantity is more than one, or to see bless/curse state).  It can also handle
inclusion of adjectives like "partly eaten" or "bite-covered".  For unique
monsters those come out in the form
  the Chromatic Dragon's partly eaten corpse
instead of the old
  partly eaten Chromatic Dragon corpse
[so wishing probably needs to be taught about potentially finding a monster
name before assorted adjectives such as blessed; also, name_to_mon() needs
to learn how to cope with the possessive suffix].

     A sizeable chunk of this patch deals with consolidating some of the
redundant "petrified by a cockatrice corpse" handling.  It may be possible
to consolidate all remaining instances together since they're quite similar,
but I didn't think about that until just now and I want to get this patch
over with.

you summoned it!

     From a bug report, "You have summoned it!" (when human
sacrifice brings a demon which you can't see) is poorly worded, to put it
mildly.  I'm sure there are plenty of other places where "it" seems odd,
but this one is now fixed....

diagonal blockage exceptions

     From a bug report, amorphous creatures can fit underneath
closed doors but could still be considered too big to fit through diagonal
gaps.  Let them and several other shapeless or flexibly shaped critters
squeeze through provided that they pass the not-carrying-too-much check.

fix #H4 - remote recognition of Astral Plane high priests

     From a bug report:  the Call command's
prompt is careful not to include "of <deity>" when asking what name to give
a high priest on the Astral level, but the resulting rejection message of
"the <unique monster> doesn't like to be called names" did not, resulting
in feedback of "the high priest of <deity>" and giving away which temple it
is from afar.

"can't reach from steed" message bits

     These should have been included with a "#dipping from steed" patch
three years ago.  I don't know whether I missed them outright, neglected
to cut diffs at the time, or just forgot to apply the diffs to my cvs
directory prior to committing the rest of that patch.

gold theft while mounted (trunk only)

     From a bug report, "The leprechuan quickly snatches some
gold from between your feet!" doesn't make much sense when you're riding.
Fix started out simple, but "between" isn't right if you're above the floor,
and "rear hooves" for horse or "rear claws" for dragon didn't sound right
for steed (or poly'd hero), so it got a little more complex.  Complicated
even more due to requiring two copies; ick.

     A minor side-effect of this change is that somewhat naughty sounding
"The leprechaun quickly snatches some gold from between your rear regions!"
won't occur anymore.  :-}

shopkeeper names when hallucinating (trunk only)

     A bug report complained that Izchak is identifiable when the hero is
hallucinating.  That's true but it wasn't particular to him; all shop
transactions were giving accurate shk name regardless of hallucination.
This is a quick fix that avoids changing shk message handling:  pick some
shk name at random each time one is used.  I didn't intend for it to also
force Izchak to use the general chat response instead of his set of special
messages, but that ends up happening due to randomized name not matching
his, so you really can't recognize him when hallucinating anymore.

     The almost never seen names now have a chance to come into play....

updates for gcc warnings

levitation timeout

     Forwarded from the newsgroup by Michael:  giving a count before '.' to
rest many turns wouldn't be interrupted by having levitation end (despite
autopickup taking place at the time, which is what the thread is about but
not all that relevant to this particular issue).  Stopping counted activity
is easy, so that's all I've done.  Stopping a timed occupation would be a
lot harder due to message sequencing; I'm not going to attempt it.

redundant includes

     Remove several duplicate includes I discovered while reconciling the
vms Makefile.  All of these are already being brought in via hack.h so don't
need to be explicitly included after it.

depend.awk (trunk only)

     I don't have any way to test this, but zlib.h needs special handling
to prevent compilation problems for anyone who doesn't have it.

vms Makefile (trunk only)

     I couldn't find the original depend.awk (which started out on vms) and
didn't feel like attempting to recreate it, so did this the old fashioned
way (grep,&c of src/*.c).  I think that all of the various Makefiles need
one or more of these changes.  Adding context.h to the hack.h dependencies
and emin.h to monst.{o|obj} are the most significant ones.

in_lava_effects (trunk only)

     The in_lava_effects flag should never be saved and restored; putting
it into the context struct was a mistake.  Move it to the iflags struct
(where the branch code already has it).  I haven't bumped the EDITLEVEL
setting.  Save and bones files from more that a few days ago were breifly
invalid but should be viable again.  Save and bones files from the past
couple of days are now no good; sorry about that.

killer_xname changes (trunk only)

     Have killer_xname() handle corpses properly and also avoid having it
use user-supplied fruit names as per <Someone>'s suggestion.  Also make
a start at eliminating the umpteen inconsitent checks for whether a monster
type (like "Oracle") ought to be prefixed by "the ".

     I used a stub which looped over all object types, all artifacts, and
corpses of all monster types to print the output of killer_xname() for each
one; its prefix choice among {[no article], a, an, the} looked right.

build fix (trunk only)

     Noticed by Michael:  I accidentally put a declaration in the wrong
spot and my compiler used C99 semantics to accept it there.

fix object lost panic (trunc only)

     While testing some killer_xname() changes, I noticed that it was
feasible to avoid having some gear destroyed by causing a hangup after
getting the destruction message.  And while testing the fix for that, I
stumbled across a panic situation (not caused by my changes).  If you
survive entering lava while wearing water walking boots (and aren't fire
resistant yourself, and don't have enough hit points to survive 6d6
damage, and your boots aren't fireproofed...), having those boots be
destroyed will dump you back into the same lava recursively (lava_effects
-> Boots_off -> spoteffects -> lava_effects).  And if you survive that
(wizard/explore mode or life-saving), there will be a panic when finishing
deletion of the boots (useupall) because the recursive call will have
already done it (since they aren't worn anymore when inner call handles
them, no additional recursion gets triggered and object deletion happens).

     Some of the other stuff I was working on is mixed in here because
this is the configuration I ended up using to test the panic fix.

     Several Makefiles are missing the dependency for context.h (post-3.4.3
revision).  If yours is, then you'll need to force a full rebuild after
applying this or you'll end up with havoc.  (Mine was, but I noticed that
the expected full build wasn't happening and interrupted it to fix that.)

terminate eating if pet falls asleep or becomes paralyzed (trunk only)

     From a bug report:  sleeping pet could
be shown as "eating" by stethoscope.  Fixing that is a one-liner since all
(or should be all; sleeping gas trap wasn't utilizing it) cases of monster
being forced into sleep go through one routine.  That wasn't the situation
for paralysis, but now it is.  Paralyzed pets won't continue eating either.

drawbridge feedback

     From a bug report:  playing mastermind
with the castle drawbridge yields a sequence of "you hear tumblers click and
gears turn" messages when the notes are partly right, but no sound when all
notes are right and you succeed in opening the bridge.  Blinded hero won't
know that it has opened and could reasonably expect to have heard 5 gears
turning.  This gives a general gears turning message (for any bridge changed
by any means, not just castle's tune) when it opens or closes out of view of
the hero.  So, you get a message about seeing it open when that is the case,
or about hearing gears if you can hear but not see, or no feedback if you
can't see it or hear it (You_hear() is a no-op when you're deaf).

     Also, scatter some iron chains when a drawbridge gets destroyed.  Iron
chain seems to be the only really suitable item available for bridge debris.

spheres vs objects

     Another one from <email deleted>:  freezing spheres have the NOTAKE
attribute but flaming and shocking spheres don't.  That means that tame
critters of the latter two types will pick up and drop things.  I only saw
it happen with single gold pieces in my limited testing; I guess they're
really weak.

     This one sounds sort of familiar; I think it might have been reported
before.  The fix is so trivial I don't know why it didn't happen.

demon graft

      From a bug report, bribeable demons will demand money when
hero has fainted from lack of food and hero can pay while unconscious.  I
decided to just borrow from vault guard behavior and have the hero regain
consciousness.  It turns out that reset_faint() has been broken since a
long ago (before my time...) change to nomul() [nomul(0) is a no-op while
fainted since multi is negative then].  Now fixed; both bribe-demanding
demons and vault guards will cause fainted hero to wake up when they arrive.
If hero can't move for some reason other than fainting, demons will skip
the bribe demand and immediately become hostile (vault guard in that case
goes away after saying that he'll return).  There is no deafness handling;
perhaps the bribe demand is accompanied by sufficient pantomiming for the
hero to figure it out?  ;-)

     Also fix an unintended potential alignment hit against the player if
bribeable demon is killed after becoming hostile due to misjudging displaced
hero's location.

quest message tweaks

     From a list of bugs sent by <email deleted>, the initial message for
the knight quest included the phrase "looking closer" which isn't suitable
if the hero is blind at the time.  Also, one samurai guardian message used
"ninja" (assassin, more or less) where it ought to have been using "ronin"
(samurai without any master, a disgrace).

     The archeologist and tourist quests' initial messages had similar
blindness problems with "look".  (There are still at least 3 other places
which use "appear"; I've left those alone.)

killer reason tweaks

      A couple of items pointed out by <Someone>:  the killer reason
when hit by mis-return of thrown Mjollnir would vary depending upon whether
it was fully identified, unlike several other death-by-missile cases which
force the object to be described as if fully ID'd.  Also, the killer reason
when death is caused by kicking an object would give way too much detail
about the object if it was ID'd.  Fix both by switching to killer_xname().
Now "killed by a war hammer named Mjollnir" becomes "killed by Mjollnir"
(same as when already ID'd), and "killed by kicking 5 cursed poisoned -1
orcish arrows" becomes "killed by kicking orcish arrows" whether ID'd or not.

     [Trunk only] question?  Should being hit by returning Mjollnir really
be receiving half-physical-damage reduction when hero has that attribute?
It ignores the fact that Mjollnir is also dishing out lightning damage.
Are other artifact hits ignoring such things too?

fix #Q241 - swallowing Medusa (trunk only)

     From a bug report, eating Medusa's corpse is fatal
but devouring her whole (purple worm or poly'd hero) was not.  Now it will
be.  Also, being killed by swallowing a cockatrice or a Rider could have
disclosed "you went without food" if you hadn't eaten anything else prior.
This fixes that too, although it might be a little silly if it happens to
a monk since he'll feel guilty (for non-vegetarian diet) right as he dies.

grammar bit: fatal cockatrice corpse theft (trunk only)

     From a bug report, stealing a cockatrice corpse
from a monster while polymorphed into a nymph and not wearing any gloves,
the cause of death ended up being "petrified by cockatrice corpse".  It would
also have said the same thing if a stack of multiple corpses was involved.
This fixes both cases, and also hypothetical unique monsters with petrifying
touch.  (Last bit tested by temporarily adding Medusa to touch_petrifies().)

fix #Q235 - rubbing against known touchstones

     Allow rubbing any object against any touchstone even when the latter
is known so only gems make sense.  Also, propagate an earlier fix which
allowed rubbing gold against known touchstones to the branch (it had been
trunk only).

number_pad:3,4,-1 (trunk only)

     I left out the Guidebook updates when I checked in the number_pad
changes yesterday.  I no longer have any way to preview either format but
at least LaTeX doesn't give any warnings about the TeX one.  I suspect that
the list of valid settings is going to be too wide; it will likely need to
become an actual item list or table to make the descriptions wrap sensibly.

     doc/Guidebook.txt hasn't been updated in a long time.  Can someone
generate an up-to-date copy and check it in?

build clean-up (trunk only)

../src/detect.c(715) : warning C4101: 'obj' : unreferenced local variable

number_pad:3,4,-1 (trunk only)

[See the cvs log from flag.h for comments pertaining to iflags.num_pad
and Cmd.num_pad, Cmd.commands[], Cmd.serialno.]

number_pad:3,4,-1 (trunk only)

     Add support requested by a user for number_pad:3 to use a phone-style
keypad layout where 1,2,3 are on the top row and 7,8,9 on the bottom,
opposite of the adding machine layout adopted by computer keyboards.  Also
number_pad:4 combines that with the number_pad:2 hack to give different
behavior for the 5 key (also meta-5 and meta-0).  And number_pad:-1 is a
rather absurd way to support German keyboards which have y and z keys
swapped, avoiding the need to add a new option for that.  With it, z moves
upper-left and y zaps wands, with corresponding swap of the upper case,
control, and meta variations of those two letters.  (There is a "German
keyboard patch" for this floating around the net, but it implements a
compile time configuration setting which results in hard-coded behavior
for those keys.  This implementation lets it be toggled on or off at will.)

     There's more here, intended to ultimately simplify rhack() quite a
bit.  Most of that isn't finished yet.  However, the part that is done
should produce same run-time behavior as before.  I hope....

     iflags.num_pad and iflags.num_pad_mode should now be viewed as opaque
items used for communicating dynamically updated option settings to the
core only.  Ports and/or interfaces which feel inclined to peek at them
should switch to Cmd.num_pad,&c instead.  (I've made that switch for a
couple of places which would have stopped compiling due to sdir and ndir
going away, and for vms+tty where I could directly test the change(s),
possibly plus one or two places which got heldover over from my earlier
attempt that did try to update all of them.  Ports which haven't made the
change yet ought to continue to work as-is though.)

     Eventually ports/interfaces which implement alternate ways to invoke
commands (pull down menus or extra keyboard buttons or whatever) should be
able to scan Cmd.commands[] to figure out which input characters trigger
which nethack functions.  The ones that currently use hardcoded key lists
will probably need to migrate before any dynamic key binding functionality
gets implemented.  (Which may never happen; it's definitely not on my own
to-do list.)  Cmd.serialno is intended to be the way for them figure out
when the commands have been changed (which right now only happens when 'O'
is used to alter the number_pad setting); perhaps a new interface callback
would be better suited for communicating this.

     It may be necessary to rearrange header inclusion so that func_tab.h
gets included before flag.h (and/or struct cmd gets moved from the latter
to the former--but then func_tab.h would be needed in a bunch of places
which don't currently use it) to support some pre-ANSI compilers.  And the
command initialization might need to be moved to somewhere earlier than
init_options() at some point if port/interface initialization starts caring
about it.

wishing bit (trunk only)

     The code let you wish for trapped containers in wizard mode and tried
not to let you do so in normal mode.  But it handled the trapped attribute
by overloading the poisoned one, so wishing for a "poisoned chest" would
produce a trapped chest in any mode.  This fixes that by removing the
overloading.  You can wish for a trapped box/chest (or tin) in wizard mode
and you can now also explicitly wish for an untrapped one in any mode.
Asking for trapped in normal mode--most likely hoping to seed a dangerous
bones file--just negates any preceding "untrapped" handled earlier within
the same wish, and specifying "poisoned" for a container no longer has any
effect.

magically detecting chest traps (trunk only)

     (Nothing to do with the recent suggestion that the search command be
extended to find traps on adjacent containers.)  When a crystal ball or
confused/cursed gold detection performed trap detection, it found trapped
chests on the floor but not any which were buried or carried by the hero
or by monsters.  This fixes that.

     Still needs fixing?  The message "your toes stop itching" when the
only trap on the level is at the hero's current location is pretty strange
if that trap happens to be carried rather than stood over, but I don't
know what to change it to.  I guess it's always been strange if there was
a ceiling trap rather than a floor trap involved.

fix #Q227 - cancelling items in shop entrance (trunk only)

     From a bug report:  cancelling objects
in a shop doorway or one step inside would cause the shopkeeper to brand you
a thief.  The relevant code is trying to handle the case where you're inside
one shop and zap a wand or spell from there into another one; it didn't cope
with being in the neutral area of a single shop.

yet more artifact name handling (trunk only)

     The fix to prevent naming an unknown gray stone "the Heart of Ahriman"
from revealing whether the object was a luckstone was inadequate to prevent
using the same trick with "the Mitre of Holiness" to determine if an unknown
helmet was a helm of brilliance.  (I don't know whether whoever figured out
the first one has realized the second yet; no one had mentioned it in the
newsgroup the last time I looked.)  To get this right we need to check for
objects sharing the same set of shuffled descriptions in addition to testing
whether they have identical descriptions.  Doing that meant reorganizing how
object shuffling is done, but it produces the same behavior as before.

X11 typo

     From a bug report:  fix a typo for mouse
position handling in set_button_values().  I have no way to test this,
nor can I tell whether it could have ever impacted anyone.  The old code
clearly had a mistake and the fix is obvious.

more luck stone ID (trunk only)

     Refine yesterday's change in how attempting to assign an artifact's
name to some object works:  only check object descriptions for undiscovered
object types.  Once you know that a particular gray stone is a flint stone,
you could name it "the Heart of Ahriman" as before the previous change.
Conversely, once you learn luck stones, you could give that name to any
other unknown gray stone.  This restores the ability of a player to name
his elven broadsword such that some unsuspecting other player might find
"a runed broadsword named Stormbringer" in a bones file.

gas spore explosions while hallucinating (trunk only)

     From a bug report:  when hallucinating,
messages for affected monsters and/or hero referred to "the gas spore's
explosion" instead of supplying random monster names.  This is a little bit
tricky; since it can be displayed multiple times for one explosion, it needs
to be constructed on the fly in explode().  (Caller couldn't have handled
this anyway since it's using the value for killed-by reason which mustn't
be distorted by hallucination.)

plug luckstone identification hole (trunk only)

      From the newsgroup:  when you pick up a gray stone, you can determine
whether it is a luckstone by attempting to name it "the Heart of Ahriman".
Your "fingers slip" if it is, they don't if it isn't.  That's way too
cheesy for my tastes.  This patch will make the finger slipping occur for
any item that has the same description rather than just for the exact type.
Now you won't be able to name any type of gray stone "the Heart of Ahriman"
(nor an elven broadsword "Stormbringer"; however, assuming that you manage
to acquire a non-artifact runesword, you can still uselessly name it
"Orcrist" if you want).

fix #Q221 - inappropriate vault guard message when embedded gold reached

     From a bug report:  when a guard who's
leading the character out of a vault comes across gold (from mineralize()
usually, but a player could deliberately seed the area in xorn form), the
message "the guard calms down and picks up the gold" was given even though
the guard wasn't angry.  Pick up such gold as soon as temporary corridor
reaches it so that on his next move the guard won't mistakenly think that
the hero has just dropped it.

more container flags (trunk only)

     cknown and lknown flags for containers are now checked when deciding
whether an item is fully identified, and they're set when identification
takes place.  (You'll learn how many items are inside even if you haven't
looked to see what they are yet.  This means that an inventory listing of
unpaid items will reveal the contents after you've used enouch magic to ID
an unpaid container.)  Also, set those flags for any container in initial
inventory; rogues should know that sack starts out empty.

container status bits (trunk only)

     Couple of post-3.4.3 things:  using ':' to view the contents when
looting or applying a container wasn't setting its cknown flag (contents
known); probing a container wasn't setting lknown flag (lock state known).

minions/Angels (trunk only)

     Angels used the epri extension even though they're never priests,
presumeably because they're sometimes flagged as "renegade".  Since the
only priests ever flagged as renegade are roaming minions rather than
temple priests, move the renegade flag to the emin extension and switch
Angels over to that.  Summoned Angels will now always have the isminion
flag set.

     Makefiles need updating:  monst.{c,o} now depends upon emin.h.

thy/thine usage

     According to the dictionary, "thine" is used in place of "thy" when
preceding a word which starts with a vowel or "h".

guardian angel

     Move the guardian angel creation and removal code to minion.c.

chest trap bit

     From a bug report, the "you stagger"
message when a trapped chest releases a cloud of gas shouldn't include the
inaccurate phrase "and your vision blurs" if hallucination is blocked by
Grayswandir.  Suppress it in that case.

fix #Q211 - inappropriate vault feedback

     From a bug report, you'd get the message
"the corridor disappears" whenever a vault guard was killed, even if the
temporary vault corridor was already gone due to leaving its vicinity.  This
fix seems to work ok, but I don't pretend to understand how the convoluted
vault code actually works.

makeplural/makesingular support for foo-at-bar (trunk only)

     Suggested by Janet, after inhaling paint fumes.  Unlike mother-in-law,
which is an entry in the hallucinating monsters list and would be pluralized
if chosen as a tin description, I think the rank title man-at-arms will only
ever go through plural/singular handling if used as a fruit name.  But since
the man/men part was already implemented for pluralization, adding the -at-
part is trivial.  Also adds men/man singularization for the general case
where -at- isn't involved.

fix M203 - grammar for tin of hallucinated "mother-in-law" (trunk only)

     From a bug report, (is that name just
a coincidence, or is it our Matt?), "this tin smells like mother-in-laws"
should be "this tin smells like mothers-in-law".  That led to a small can
of worms when I tried experimenting with mother-in-law as the named fruit.
Naming your fruit "pomegranates" would result in "pomegranateses" if you had
more than one.  These changes are mostly just band-aids for that; I think
the proper solution is to singularize the user's value when fruit name is
being assigned.  Force it into lower case at the same time, then some other
special casing could be eliminated.  There's no particular reason to keep
"grapes" and "grape" as separate entries, nor "matzot" and "MATZOT" either.

     One of the non foo-in-bar changes prevents "grapefruit" from getting
a false match against named fruit "grape".  (Are there any legitimate cases
where trailing text should be ignored?  I couldn't think of any.)  Another
results in a wish for "kumquats"--when fruit name "kumquat" exists--yielding
two instead of a random amount, the way that specifying plural works with
other sorts of objects.  And if you're strange enough to name your fruit
"kumquats" in the first place, asking for "kumquat" will produce exacly one.

     This patch applies cleanly to 3.4.4 but I don't think it's been tested
adequately enough to be included there.

more monster key use

     Let monsters use lock picks and credit cards in addition to keys for
opening doors.  And the earlier code to have pets hang on to a key didn't
work as intended.  It worked fine if the key was the only object carried,
but the monsters' item dropping code didn't give any special handling to
keys so they'd be dropped too if the pet carried another droppable item.
This eliminates second set of checks for handling some items specially--
dropping now uses the same routine as is used when pet movement decides
whether there's anything to drop.

     Also, a couple more door message tweaks.  "You see a door open" seems
strange when you watch your pet do the opening.  Previously fixed for the
"unlock and open" case, this does the same for opening already unlocked
doors and for giants smashing down doors--it now gives a more specific
message when you see a monster perform the action.

     Possible change in play balance:  pets capable of picking up the
rogue's Master Key of Thievery or tourist's Platinum Yendorian Express
Card will keep one of them.  So a player might accidentally lose one by
leaving it on the floor in a pet's path, or more significantly, the Card
will yield a means of giving magic resistance to a monster who can't wear
a cloak or dragon scales.  It's neutral and the most interesting high-end
pets are lawful (hence won't pick it up), so that probably won't have much
impact.

SC343-9 followup (trunk only)

     monst->cham usage bit.  CHAM_ORDINARY probably ought to be discarded
and replaced by NON_PM; then mons[0] wouldn't be ineligible to become a
shapechanger.  (Not that we want giant ants to mutate on the fly, but in
case someone ever inserts something interesting in front of them.)

key use by pets

     Spotted when fixing the Rogue level digging/phasing bug:  pet movement
was setting up the wrong flag for pets who happened to be carrying a key.
This wasn't particularly noticeable because they tended to drop keys right
after picking them up.  And apparently the checks elsewhere in movement
prevented that wrong flag from having any effect; once I changed it so that
pets would hang on to keys, I never saw them break a door down with one.
Now they'll keep keys, similar to unicorn horns and pick-axes, and use them
properly.  The door unlocking message needed a tweak because it assumed
that the opener was on the far side trying to reach you and looked quite
odd when you could see the action taking place.

     I've put this into the fixes file as a new feature rather than a fix.

fix C343-3 / #U793, tame h and U don't dig on Rogue level

     From a bug report, 2003:  a
pet who normally would dig could pass through walls and solid rock on the
Rogue level without leaving a tunnel in its wake.  Monsters are explicitly
prohibited from digging on the Rogue level, but pet movement ignored that
and specified that locations accessible via digging were valid destinations;
actual movement bypassed the digging step so it acted like passthru.

fix SC343-9, bones handling for corpse/statue of unique monster (trunk only)

     The logic in cant_revive() was a little off, so reviving a unique
corpse or statue on a bones level would recreate that unique monster instead
of making a doppelganger who's imitating it.  Fixing that was simple but had
the unintended side-effect of making it impossible to deliberately create
unique monsters with ^G in wizard mode.  So create_particular() has been
modified to let the user override the zombie or doppelganger conversion.
And then when not overriding, shapechangers took on random appearance, so
this also changes create_particular() to override shape changing.  And that
has the side-effect of making chameleons or vampires start out as themselves
instead of as random critters or bats/fog clouds.  [Better stop now! :-]

    resetobjs() also needed to have extra corpse handling when saving bones
because the fix for revival wouldn't prevent you from turning to stone by
eating apparent-Medusa's corpse.  Statues of uniques and corpses of special
humans like vault guards and shopkeepers didn't need anything extra; they
can retain original form until an attempt at revival is tried.

    I'm not going to try to adapt this for 3.4.4.

vampire bit (trunk only)

     Vampires' aversion to altars is retained when they've shapeshifted
into their assorted alternate forms.

more monster alignment

     Simplify is_lminion(); as a result, several source files no longer
need access to epri.h.  (mondata.c already could have lived without it;
eshk.h as well.)

Makefile dependency changes:
  mondata.{c,o} -- doesn't need epri.h or eshk.h
  monmove.{c,o} -- doesn't need epri.h
  wizard.{c,o}  -- ditto
  pline.{c,o}   -- ditto (yesterday's patch)

alignment of Angels followup

     No need to retain sgn() here; mon_aligntyp() takes care of that now.

alignment of Angels

     From a bug report, the probing/stethoscope code assumed that all Angels
(the specific monster type, not the whole 'A' class) used the epri extension
to hold alignment, but that's not true for randomly generated ones.  So
monster status feedback gave erroneous results, and it would vary based on
pet behavior if the random Angel had been tamed.  Also, touch_artifact()
didn't know about special alignment handling for Angels and aligned priests
so always used their default alignment.

     There are other problems with Angels--such as whether they should even
be allowed to be generated randomly in the first place--that this doesn't
attempt to address.  The patch for that was starting to sprawl all over the
place so I pulled this simpler bit out for a first cut.  Probing now shows
the Wizard of Yendor as unaligned instead of lumping him in with chaotics.

     Another Makefile update needed:  pline.[c,o] no longer needs epri.h.

nethack.rankin wrote:
>      Makefiles need a dependency update to add edog.h for eat.c.

mind flayer brain attacks (trunk only)

     Fix a couple of problems From a bug report.  Eating a Rider corpse is fatal, but eating a live Rider's
brain was not--now it will be, both for monster mind flayers and for player
poly'd into one.  Also, there was no check for cannibalism when poly'd hero
eats brains--now there is.  Not mentioned in the report:  eating Medusa's
brains will now be fatal just like eating her corpse.  And pet mind flayers
who eat the hero's brains will gain some nutrition like they do when eating
monster brains.

     Creating a common eat_brains() routine turned out to be something of
a mistake; there is only a tiny amount of overlap among the u-vs-m, m-vs-u,
and m-vs-m cases.

     Makefiles need a dependency update to add edog.h for eat.c.

more graphics option parsing

     The recent fix for OPTIONS=noDECgraphics,IBMgraphics would have been
subject to lint complaints for some configurations.  Declare the extra
variable with the same conditional tests which control its use; somewhat
messier, but lint free.

     My previous fix only solves this problem for the initial config file
parsing.  If you enable IBMgraphics (by any method), then interactively
use the 'O' command to try to enable DECgrahpics and to _simultaneously_
disable IBMgraphics instead of letting it be overridden, you will end up
with IBMgraphics on and DECgraphics off.  That's because the menu entries
are processed in order, and after it has acted upon the request to set
DECgraphics on, the IBMgraphics flag will have been switched off; then
when it acts upon the request to toggle IBMgraphics, that flag will end
up being switched back on (switching DECgraphics back off in the process).

     This erroneous behavior was the same prior to last week's patch;
I just hadn't noticed yet.  It looks like we really do need to change
{ASCII,DEC,IBM,MAC}graphics into a single compound option.

handling of {DEC,IBM,MAC}graphics options

     Fix the problems From a bug report.  So having
  OPTIONS=IBMgraphcs
  OPTIONS=noDECgraphics
would yield an ASCII display instead of showing IBMgraphics, but IBMgraphics
flag in the Options list would falsely show as on.  Manually toggling it off
put things back into sync.

     Avoiding the false setting is completely trivial.  And fixing the
inappropriate override turns out to be easy too, unless I've bungled this.
One thing it does not do is try to warn about attempts to set conflicting
options like
  OPTIONS=IBMgraphcs
  OPTIONS=DECgraphics
Fixing that seems to be too messy to bother with, particularly since the
game runs ok (leaving the setting handled last in place).

level drain while polymorphed (trunk only)

     Noticed when incorporating the "vampire dancing" patch:  losing a level
while polymorphed would subtract from your normal hit points but didn't
affect your monster hit points.  Now they'll lose d8 from max and current,
similar to the amount they increase when gaining a level.

     This also addresses an issue from the newsgroup a few weeks back:
someone mentioned an assumption that Stormbringer drained an amount other
than d8 for monsters who use some other formula for their hit points.  It
wasn't true, but now it will be (approximately).  Most monsters with unusual
hit points aren't subject to level drain, so it shouldn't have much impact.

fix #M178 - mirror feedback for unID'd looking glass

     From a bug report, applying a
mirror at sleeping Medusa yielded "too tired to look at your mirror" even
even though the item being used was listed in inventory as "looking glass".
Several other messages and any target monster would produce similar things.
Perhaps they should auto-ID when applied, but I changed messages to use
the description if real name isn't known.

     This also treats incubi identically to succubi regarding mirrors:
they like to see their own image and will take the mirror away when one is
applied at them.

HP and Pw multiplication (trunk only)

     Fix the problem pointed out by <email deleted>
where polymorphing into a new man at level 1 could be used to approximately
double or triple your hit points and spell power.  With means to drain
level back down to 1 and with amulets of life saving to survive those times
you lose levels instead of gain, you could do this repeatedly and end up
with HP and Pw values in the millions.

     This uses the earlier patch that records the HP and Pw increments from
level gains.  Now when polymorphing into a new man, level based HP and Pw
are removed from the current values, remainder get multiplied by 80%, 90%,
100%, or 110% (average 95%, so tend to drop slightly), then a brand new set
of level gain increments (reflecting new man's Con and Wis) are added in.

     Code for calculating spell energy is moved from pluslvl() and u_init()
into new routine newpw().  It and newhp() take over responsibility for
remembering the level based increments from pluslvl() which didn't deal
with the initial amount (stored in slot [0]; earlier patch didn't need it).

"vampdance" patch for avoiding unlimited HP and Pw gain (trunk only)

     <email deleted> sent a report with
subject "Vampire-dancing can give you unlimited maxhp/maxmp" about how you
can manipulate your hit points and spell energy by using equipment to
lower Con and Wis prior to deliberately losing a level, then switching to
alternate gear to raise them prior to gaining the trivial 1 XP needed to
regain the lost level.  With Stormbringer (to toss up so that it falls on
your head) or spell of drain level (to cast at yourself), you can do this
level toggling as much as you like since it doesn't consume any resources
in the process.  All you is a supply of non-threatening monsters to kill
for the regaining half.

     In March he sent "vampire-dancing (patch)" which didn't include a
patch but did give a URL ( http://nethack.angband.pl/vampdance.patch )
for one.  That contained his suggested fix:  recording the hit points and
energy points given each time you gain a level and then using those exact
amounts when you lose the corresponding level.  It's still possible to
manipulate HP and Pw by losing multiple levels after you've boosted Con
and Wis to ascension ready status (you'll lose the original values but can
expect to get better ones when gaining levels back), but can only gain a
modest improvement and repeating it doesn't augment the effectiveness.
Plus it's much harder to regain multiple levels than it is to get just one.

     His patch had a couple of bugs which I've fixed.  I suppose that there
could be additional potential problems but the idea and its implementation
are both pretty straightforward.  (This doesn't address the other recently
reported situation of using polymorph into "new man" while at level one to
multiply HP and Pw.)

choking on gold

     From a bug report:  "choked on an a very rich meal".

gems vs snoozing unicorns

     From the newsgroup three or four weeks ago:  sleeping or pararlyzed
unicorns would catch thrown gems despite being unable to move.  Now they'll
magically dodge instead--in other words, thrown gems will always simply
miss the target (and land at its feet) when a unicorn is unable to move.
The unicorn won't be angered or awakened by the attempt.

fix vision bug - moving a subset of boulders from a location

     From a bug report.  Pushing one
boulder from a location which had more than one would open up line of sight
at that spot as if all boulders there were gone.

consistent level change messages

     From a bug report: #M30: 3.4.2 bugs and ideas); describe
flyers (poly'd hero or riding flying steed) as flying when they use ladders
or jump down holes.  This also gives feedback when using the stairs in the
ordinary up or down case, where no message was previously given.

fix M167 - hero lycanthrope vulnerable to level drain

     From a bug report, player's character inflicted
with lycanthropy doesn't gain level drain resistance when in normal form
even though lycanthrope monsters do have it when in their human form.  The
report claimed that the character didn't gain it when in beast form either,
but the code--and testing--suggests otherwise.

     The same resist_drli() call used for monsters is used for the hero,
but the is_were() check there isn't able to recognize a lychanthrope hero
since youmonst->data doesn't track that when in human/normal form.  This
adds another more specific check to handle that case.

fix M159 - crash at end of prayer

     Fix the crash caused by division by zero (attempt to compute rn2(0))
when deciding prayer boon for a character whose Luck went negative during
the course of the prayer.  <email deleted> triggered it
by killing a shopkeeper with the ongoing damage from a scroll of stinking
cloud; his non-chaotic character was branded a murderer and lost two points
of Luck after the prayer was already in progress.  (Prayers fail when Luck
is already negative, so the code to pick a boon expects non-negative values;
the fact that is always adds at least +2 leads to me to suspect that someone
already realized that luck timeout on Friday 13th could result in Luck of -1
at the end of a successful prayer--that value doesn't trigger this crash.)

grammar for graveyard sounds

     For "the hair on the back of your neck stands up" or "the hair on
your head seems to stand up" make subject and verb agree when poly'd into
forms where "hair" is replaced by something explicitly plural like "scales"
or "cilia".

tourist leader's greeting

     Fix typo From a bug report.

Amazingly many players have never heard of kelp...

steed corpse

     Fix the problem From a bug report.  Presumeably the corpse exclusion at <u.ux,u.uy>
was intended to be for killing your way out of an engulfer, but there wasn't
any comment to that effect.  The exclusion still applies if you were inside
the monster when it died; ridden steed is the only other way I can think of
to have a monster die at your location, so it should be the only case which
gets affected.  Neither steed nor engulfer is allowed to generate a random
item when upon death; you already know what was carried in those cases.

     The bulk of the diff is from reorganizing the relevant `if' and
subsequent indentation changes.

pudding farming (trunk catchup)

farmed pudding (trunk only)

     I've gotten tired of seeing newsgroup claims along the lines of
"since devteam is aware of this and has chosen not to eliminate it, they
must endorse it", so weaken the tactic of "pudding farming".  It is still
possible to gain unlimited experience (past level 15 or so there's not
much point), but will be less effective for gaining items and for providing
sacrifice fodder.  Keep track of which monsters have been created via
cloning (mostly puddings; gremlins and blue jellies are affected too but
nobody's likely to care much about them) so that they can receive special
handling.  Make cloned monsters progressively less likely to leave corpses
as the number killed for a particular type goes up, and also much less
likely to drop random items at death.  This is sure to need some tuning
once hard core farmers point out how they can still abuse it.  For the
absurdly extreme case, see

http://scavenger.homeip.net/farmbot/HomePage

FYI, farmbot/PuddingFarmingHOWTO includes an impressive screen shot of a
dungeon level where rampant farming is taking place.

creating artifacts by naming shop gear (trunk only)

     A cased missed by "alteration of shop-owned objects" patch in April.
If Sting or Orcrist is created in a shop using an unpaid weapon, update the
bill to reflect that weapon's increase in value.  No new fixes entry needed.

fix #M132 - Sunsword glows after its wielder dies

     When lit due to being wielded by a monster, Sunsword continued to emit
light after that monster was killed.  This was fixed by <Someone> in 3.4.1 but a
change I made for 3.4.3 broke that fix.  When mdrop_obj() was split out of
relobj(), relevant unwielding code ended up only being executed for monsters
who were still alive.

scum bug

     Fix the reported bug about an inappropriate space in the message
  "For you, scum ; only N zorkmids for that foo."
when an angry shopkeeper quotes a price for an item which has just been
picked up.  Also, suppress "only" in that case; just include it when the shk
isn't angry.  And the word "zorkmids" was actually missing, so I added it.
I think the semi-colon should actually be a comma, but I've left that as is.

zombie lookup

     Make the variant spelling "zombi" as used in the quote work when
attempting to look up the zombie quote via "/ n".

castle tune prayer result

     From <Someone>, half a year or so ago:

> When you've already entered the Castle, I think your God shouldn't be
> giving you the two Castle-related messages anymore.
>
> This might be difficult to track, I realise that.

It already suppressed the tune delivery feedback if you had opened the
drawbridge with music or if that drawbridge had been destroyed.  And if
you've entered the castle by the back door or via wand of opening/spell of
knock, learning the tune could still be useful, so I didn't try to extend
dungeon tracking to the point of "entered the castle".  However, if you've
already passed beyond the valley below then you most likely no longer have
much interest in the drawbridge, so add a check for that to the prayer
feedback suppression.

     <Someone>'s real concern was probably more about the message phrasing
than the "useless" prayer boon (since it says "to enter the castle" rather
than "to open the castle drawbridge"), and that does make the god sound a
bit silly if you've already entered the building.  It would make sense to
skip the first of the two messages if you make it inside without opening or
destroying the bridge, but this patch doesn't attempt to address that.

entering gehennom

     When you first attempt to walk down the stairs from the Valley of the
Dead to the second level of the Gehennom branch, the game prompts you about
whether you really want to proceed.  But if wasn't keeping track of whether
you had previously level teleported past that point (which is possible when
starting from the Valley rather than from higher up), so would still issue
that once-only prompt if you used the stairs later.  Mark the prompt as if
it has already given whenever you reach a Gehennom level beyond the Valley.

fix #M100 - mind flayer's psychic blast during prayer

     From a bug report:  the invulnerability conferred
during the multi-turn delay for a successful prayer was not protecting
against damage inflicted by hostile mind flayer's "wave of mental energy".

praying for health (trunk only)

     Make it easier for a low level character with ordinary Max HP to get
the healing result from a successful prayer.  Mid level characters are the
same as before:  will be healed if at 1/7 (or worse) of max.  High level
characters, or anyone with Max HP really high for their level, will need
to wait until current HP is lower before being able to obtain that result.
This mainly affects spoilers; the actual impact for any player who doesn't
know the old formula is fairly small.  The exception is for "protection
racketeers" who manage to build up a high HP without gaining any levels;
a level 1 character will only get healed when at HP 5 or less, regardless
of what percentage of max their current hit points are.

     Under the old system you could get healed at 6 HP if you had 42, at
7 HP out of 49, and so forth.  Now you'll need to be at least level 2 to
get healed at 6 HP out of 30 or more, at least level 3 for 7-9 out of 35-45.
"Normal" max is capped at 15 times level and anyone above normal is treated
as if their max was that lesser normal value.  Levels 1 to 5 use a new
threshold of current HP being 1/5 (or worse) of max, levels 6-13 use 1/6,
14-21 retain old 1/7 threshold, 22-29 now use 1/8, and level 30 uses 1/9.
The somewhat odd level break points are based on where rank titles change.

fix #M108 - seeing while asleep

     I think being asleep or unconscious ought to override vision the way
that being blinded does, but that's a more ambitious change than I care to
tackle.  This replaces You("see ...") with You_see("..."), comparable to
You_hear().  It catches the reported door case and several variations of
light sources burning out while on the floor rather than in inventory, but
it probably misses some other cases.  zap_over_floor() in particular is
highly suspect.

avoid crash when thrown potion hits bars before a monster
From a bug report. <Someone> as slashem-Bugs-883643 on 1/24/2004.  To avoid
using the possibly invalid object pointer after calling bhit(), changed as
suggested to add another level of indirection allowing bhit to null the
object pointer before returning.  Callers that are affected update their
object pointers after bhit returns.

Stoning management (trunk only)

     Make petrification initiation or termination go through a new routine,
make_stoned(), instead of manipulating its countdown timer and delayed
killer directly.  No change in behavior.

     There's no reason in terms of bug risk or game play or saved data why
this shouldn't be done in the branch too, but so much of the surrounding
context has already diverged between trunk and branch that it's trunk only.

senseself()/canspotself()

     Make the names of the macros for handling the hero be similar to those
for monsters (where mis-use of `sensemon()' was the cause of a recently
reported bug).  `senseself()' becomes more restrictive in what it specifies,
and current uses of it are replaced by new `canspotself()'.

fix #M107 - blindness and secret doors

     From a bug report:  zapping force
bolt broke an adjacent potion of blindness (possibly carried by the monster
he was attacking) which caused "it suddently gets dark" but further course
of the bolt resulted in now blinded hero recieving "a door appears in the
wall".  make_blinded() was deferring vision recalculation until next pass
through moveloop() (or until next pline()--if the "gets dark" message had
been delivered after the call to make_blinded() instead of before, this
wouldn't have been noticeable).  Fix is trivial:  just recalculate vision
immediately when temporary blindness is toggled.  [It might also be needed
for involuntary blindfold removal, although I suspect that that is always
accompanied by corresponding pline() which gets vision back into synch.]

growing into genocided form

     <Someone> recently reported that after lieutenants had been genocided,
he saw a sergeant drink a potion of gain level and then vanish, leaving
behind its gear but no corpse.  The message about growing into a lieutenant
and subsequently dropping dead would only be given if the monster could
be sensed via telepathy, not when it occurred in plain sight.  I'm not
absolutely sure that this was unintentional, since sensing the dying
monster's mind might be giving additional information about what was
happening.  But there was no comment stating that and I think such behavior
violates the principal of least surprise, so seeing it happen will now give
the message too.

breaking polyselfless conduct

      Because the description seen by the player is "you have never changed
form" rather than "you have never polymorphed yourself", make death by fully
turning into green slime (even if that death is avoided via lifesaving)
violate the conduct.  Suggested by <Someone> 9-Dec-2004.  Likewise, eating
a mimic corpse and temporarily turning yourself into a pile of gold also
violates that conduct.  Mentioned by someone--probably <Someone>, or possibly in
the newsgroup--a long time ago.

floor access

     A post-3.4.3 change dealing with reaching into pits resulted in "you
sit on the air" if you used the #sit command after escaping a pit trap.
Change can_reach_floor() so that caller explicitly controls whether being
on the brink of a pit is a condition that prevents reaching the floor.
This also splits a fairly common message about not being able to reach the
floor into a separate routine.

     There is still oddness here:  if you're polymorphed into a flyer,
#sit yields "you sit down" followed by "you fly over a pit" (latter occurs
when escaping trap activation).  A ceiling hider behaves similarly, but
the second message is "you escape a pit" and doesn't sound quite as silly.
Perhaps #sit should pass TOOKPLUNGE to dotrap(), or maybe there's some
better way to handle this?

pettype=horse

     Accept OPTIONS=pettype:horse quietly instead of issuing "unrecognized
pet type 'horse'" message.  It doesn't actually do anything from player's
perspective--knights always get a pony and other roles always get a cat or
dog, as before.

     I had a much more elaborate version which recognized "pony" (plus
"kitten", "little dog", "puppy" and assorted other variations of the
acceptable types), but it was absurd overkill for something that never
come up during actual play.  If someone tries to specify "kitten" and gets
"unrecongized type", it shouldn't take him longer to figure out "cat" is
what's needed even without resorting to actually reading the Guidebook.

     Can someone generate an up to date Guidebook.txt and check it in?

reviving quest leader

     <email deleted>, attempting to #chat
with quest leader who was raised from the dead yielded "impossible: invalid
quest character".  The code attempted to handle that but the conditional
logic for preserving the m_id field was backwards.  3.4.3 only dealt with
the corpse revival case; dev code tried to support it for statue animation
too but still had the same problem.

     Several apparent bugs remain:  if the leader is angry (perhaps hero
killed him before reviving him) he won't give an angry response if the
player initiates #chat rather than wait for adjacent leader to do so.  If
it's an archeologist reviving the statue of petrified Lord Carnarvon, hero
gets a rather ironic message about feeling guilty for destroying historic
statue.  Lastly, shouldn't there be a comparable quest_status.nemesis_m_id
so that if one player lugs the corpse or statue of his quest nemesis back
into the main dungeon and another one revives that, it won't start behaving
like 2nd player's nemesis?  Live nemesis is explicitly kept out of bones
but I don't think the corpse or statue of one is blocked and its monster
behavior after revival is based on mon->data->msound==MS_NEMESIS rather
than on m_id of current game's active nemesis monster.

autopickup exceptions bit

     My previous change underwent a last minute simplification that changed
behavior.  This puts things back to how I intended:  at the "add new
autopickup exception pattern" prompt, empty input returns you to the upper
add/list/remove/exit menu and ESC returns you past that (back to play or to
other pending 'O' changes, if any).  The previous change accidentally made
empty input behave the same as ESC.

autopickup exception tweaks

1) in the autopickup exception sub-menu from 'O', change the selector for
   "exit" from 'e' to 'x' so that the entries occur in alphabetical order.
   Also frees up 'e' for some hypothetical future "edit" entry (I'm not
   planning on attempting to implement anything along those lines though).
-1) I wanted to make 'x' start out preselected to show that it's the default
   choice, but that doesn't work correctly--at least for the tty interface.
   PICK_ONE menus don't know how to deal with having a preselected item and
   in this case it ended up returning 'x' no matter what choice I made.
   Even if that aspect gets fixed, it might have trouble with explicitly
   picking the preselected entry since that would probably be toggled off
   in the process.  So the preselection bit of this menu is commented out.
2) at the prompt for adding new exceptions, quit adding instead of giving
   "invalid syntax" warning if user enters empty input.
3) allow <ESC> in the "list" or "remove" submenu to quit all the way out of
   the upper menu too.
4) simplify the way magic numbers are used for action_titles[] menu setup.
5) greatly simplify return value of special_handling().
6) avoid a potential for getlin() or strcat() buffer overflow if getlin()
   were ever to be changed to return BUFSZ-1 characters instead of COLNO or
   whatever its narrower current limit is.

I'm pretty sure that I've run into the issue of being unable to have a
preselected entry in a PICK_ONE menu before, but I can't recall if I ever
mentioned it.  Fixing that looks like it'd be pretty messy and would need
to be done for all the interfaces.  Ick.

options.c whitespace cleanup

     I ran into a bit of a mess while working on some other minor change.
Remove trailing spaces and tabs, convert multiple spaces into tabs when
appropriate, discard spaces in <space><tab> sequences, plus a couple of very
small reformatting bits.  No change in game behavior, or even any difference
in generated object file once line information is suppressed.  Some of the
whitespace cleanup is for post-3.4.3 code, so the trunk and branch diffs
aren't equivalent.

stale prompt revisited

     Further discussion in the newsgroup pointed out a case not involving
<ESC> where the "In what direction?" prompt remained displayed after it was
no longer applicable:  throwing something where there's no monster target
in the line of fire.  You don't get any hit or miss message in a case like
that, so the last message (the prompt) stays in view.  I don't think there
are any cases where getdir()'s caller deliberately wants to leave the old
prompt up, so just clear it unconditionally as soon as the user answers.