passive damage
As From a bug report, twice.  Change max_passive_dmg to multiply the
result by the number of direct attacks the aggressor can make.  This way, a
tame mind flayer, for example, will avoid pounding on a spotted jelly and
dying as a result of the Nth passive response.

compilation bit
remove unused label gcc whined about

Mr. Izchak

     Suppress "Mr" or "Ms" title for shopkeepers when they're going by a
first name rather than a surname.  The bug report was for Izchak, but it
would have happened with the two last resort names (which I've never seen
in actual use) and for the "hippie names" used in post-3.4.x health food
shops.  I have not attempted to specify gender for those, just flagged
them as first names.  This prepends a prefix character to the name string
(see comment in shknam.c) to specify gender and/or first name vs surname.

more health food shops (trunk only)

     Allow health food stores to carry eggs and tins of veggy contents in
their stock.  The tins will almost always contain spinach because random
tins containing meat are converted into that.

     Also, allow health food stores to be placed with the level compiler
(not tested) and to be forcibly placed in wizard mode via SHOPTYPE setting
of "V".  Increments EDITLEVEL in patchlevel.h because lighting store in
Minetown got renumbered and the special level for it needs to be rebuilt.

digging holes

     If you manage to escape a hole and then dig down with a pick-axe at
that location, finish on the first move instead of after the usual N turns.

health food tins

     Groundwork for having health food shops carry tins as part of their
stock.  (That part isn't finished yet.)  The choice of which types of tin
preparation might be sold as health food is rather arbitrary.  Tweak if
needed--but keep in mind that just because something is marketed as health
food doesn't necessary mean that it's actually healthy; vice versa as well.

     Tin handling could be simplified if tin->spe for spinach was changed
from 1 to -1.  Then checks for spinach could compare against SPINACH_TIN
instead of a magic number, and with non-spinach tin->spe would be a direct
index rather than needing negating and offsetting.

theft detection

     Shop items stolen or destroyed without being in inventory were handled
inconsistently compared to simply picking up unpaid items because different
criteria got used to decide whether the shk cares about something.  Last
December a hack to deal with this for container contents was introduced but
that left the problem for ordinary items.  This patch attempts to address
it by using a common check for theft and for pickup's add-to-bill.

     It hasn't had nearly enough testing and I won't be very surprised if
one or more new obscure shop bugs have now come into being, but perhaps
they'll at least be consistent bugs as far as shop billing is concerned....

selling health food (trunk only)

     I didn't remember a new shop type of "health food store" being added.
While trying to test some shop changes, it sure threw me for a loop when
a shopkeeper who sold lots of food refused to buy any.  This patch teaches
such shks to buy vegetarian food.  (No fixes entry included since the
relevant code hasn't been released yet.)

     Shouldn't such shops sometimes carry tins and eggs in their initial
stock?  They currently don't because those items fail the material==VEGGY
test.  Adding eggs would be easy; tins are messier since you can't decide
whether they're vegetarian until after they've been created.

tile renumbering

tile synch and a warning fix

copy/paste error in horse_parts: foreclaw vs forehoof
When horse_parts were separated from animal_parts, one "forehoof" was missed

more ring theft

     Neither nymphs nor monkeys can steal a ring worn underneath gloves
since they can't see them.  If such rings are randomly targetted, try to
take gloves instead.

     Succubi trying to take worn ring of adornment will attempt to take
off worn gloves first.  (Presumeably they can sense magic rings hidden
beneath gloves better than nymphs can; they're about to try to take all
worn armor off anyway....)  If the glove removal fails, ring theft will
too.  Likewise for incubi, remove gloves before trying to force the hero
to put on ring of adornment.

     At the moment succubi and incubi can't remove gloves which are
blocked by a welded weapon, but they can manipulate rings then if there
aren't any gloves involved.  I don't think that's right.  The latter is
nymph-like and could be attributed to magic, but if that's the case why
aren't they able to remove gloves from under cursed weapons too?

ring theft

     Prevent monkeys from stealing any ring which the hero can't remove due
to it being stuck inside the grip of a cursed weapon.  Nymphs can still do
so though.  From a bug report.

yet more exploding magic pointers

     Revert mostly to <Someone>'s original approach for keeping track of whether
a container being applied or looted had been destroyed by the operation.
askchain() now knows not to attempt to re-merge an item that has been
destroyed (a theorhetical action since no stackable items can trigger a
magic bag explosion) like the earlier change to menu_loot().  Also have
use_container() clean up after itself so that current_container never has
an old pointer value left around.

morer exploding magic pointers

     Just a comment update this time.

more exploding magic pointers

     My simpler fix for dealing with stale pointers caused by magic bag
explosion didn't handle menu_loot() checking whether to merge a destroyed
object with a stack it had been split from (the case <Someone> didn't attempt to
address either).  That only needs a one-line change, but this also removes
the illusiion of generality that menu_loot() tried to maintain.  It always
operates on current_container and relies on calling in_container() and
out_container() which do the same, so passing a container argument to it
was not useful.  If that had been taken out first, <Someone>'s method of fixing
the original problem would have been simpler than mine but I'm not planning
to back out the earlier change.

     Also fix a minor post-3.4.3 bug with a container-contents-known flag
being set incorrectly.

exploding magic pointers

     Fix the two problems that <Someone> reported about stale pointer use
after a bag of holding has exploded.  use_container() passed the wrong
variable for quantity when calling useupf(), and doapply() had no way to
tell if the object being used had been destroyed so could use an invalid
pointer when checking for speaking artifact.  The fix for the latter is
much simpler than what <Someone> suggested.

sanctum level shortcut

     Newsgroup discussion has pointed out that after performing the
invocation ritual to gain access to the bottom level, it is possible to
skip almost all of Moloch's Sanctum by level teleporting in (and back out
to retry if necessary) directly to the high priest's temple.  This fix
doesn't prevent entering that level via teleport or make you end up at
the stairs, it just forces arrival to be on the right side so that you'll
need to slog through the morgue room and the big chamber surrounding the
temple.  Since there isn't much before the morgue aside from a few small
rooms with a secret door or two, it's no longer a very worthwhile shortcut.

medusa meat

     Someone in the newsgroup mentioned that there is no warning from blessed
food detection if you attempt to eat a tin of Medusa meat.  touch_petrifies()
isn't enough to catch that.  A warning was given about Medusa's corpse, but
only if you lacked poison resistance.  Eating a tainted Medusa corpse had a
similar problem; the check to override food poisoning so that petrification
takes effect missed it.  This makes the petrification checks be consistent,
including hypothetical case of Medusa egg.

wishing tweaks

     When a wish request for "<foo> armor" fails to match anything, check
whether it matches "<foo> mail" before resorting to selecting a random piece
of armor.  Most of the suits are named "mail", and while I don't think many
people will ask for "ring armor", I do think that "crystal plate armor" and
"gray dragon scale armor" are sometimes tried.

     This also greatly simplifies the handling for spelling variant "armour"
by rewriting it to "armor".  Unfortunately "grey" vs "gray" can't be handled
the same way since both spellings are used by the program.

stop occupation during problem countdown

     A user recently complained that he started an activity such as
searching and specified a repeat count, right after getting--and not
realizing the significance of--the first message in the countdown
sequence for turning into stone.  He suggested that subsequent messages
interrupt multi-turn activity so that the player has a chance to do
something to prevent imminent death.  This implements that, with the
added wrinkle that it won't interrupt if the activity is something that
might save the character's life:  attempting to eat a tin that is either
sure to help (if ID'd as food that cures stoning) or a desparate gamble
(if unID'd).  Some hooks for similar behavior for other conditions like
turning into slime are included, although no tins can help for anything
other than petrification so far.

     Shouldn't fatal illness have an end-is-near countdown too?

minor build fix

     same_race() recently added to mondata.c (trunk only) exposed an old
inconsistency in mondata.h (trunk and branch).

intelligent pets vs cannibalism (trunk only)

     Implement a user suggestion that tame humanoids should avoid eating
corpses of their own species.  Prevent them--except for kobolds, orcs, and
ogres--from doing so unless starving.  Arbitrary:  tame elves won't eat
other elves even when starving.  A polymorphed character will incur the
effects of cannibalism when eating either his/her underlying race _or_
the current one (player orcs and cavemen aren't affected though).

U1270 - monster evading kick produces a teleport message in Sokoban
This time, it was just the message that was incorrect.  Added a
!level.flags.noteleport check before displaying "teleports".

use of NULL (trunk only)

There were 2 files where NULL had crept into the sources,
even though we are not using it anywhere else.

win32 and wince
Remove the email address which is no longer valid from
several NetHack source files.

djgpp zlib support

Tested the djgpp MSDOS build with zlib support.

followup to compression changes

bones follow-up

include the savefile info in bones files

config.h follow-up

I had uncommented ZLIB_COMP for testing in config.h, but it should
have been commented when the diff was cut.

increment patchlevel

zlib support; also internal compression changes

o Add support for zlib compression via ZLIB_COMP in config.h (ZLIB_COMP
  and COMPRESS are mutually exclusive).
o rlecomp and zerocomp are run time options available if RLECOMP and
  ZEROCOMP are defined, but not turned on by default if either COMPRESS
  or ZLIB_COMP are defined.
o Add information to the save file about internal compression options
  used when writing the save file, particularly rlecomp and zerocomp
  support.
o Automatically adjust rlecomp and zerocomp (if support compiled in)
  when reading in an existing savefile that was saved with those options
  turned on.  Still allows writing out of savefile in preferred format.
o In order to support zlib and not conflict with compress and uncompress
  routines there, the NetHack internal functions were changed to
  nh_uncompress and nh_compress as done in the zlib contribution received
  in 1999 from <Someone>.

I tagged the sources NETHACK_3_5_0_PREZLIB prior to applying these
changes.

U1258 - removing ring of levitation while riding a flying steed
As reported, you'd get the "float gently to the ground" message even while
riding a flying steed.  Rearranged the code and added a new case for this.
I found it odd that Hallucination protected you from falling out of the
saddle due to the Sokoban air currents.  The message implied otherwise, so
I've made the sokoban_trap code apply in both cases.

polymorphing into a flyer while in a pit
<Someone> reported that if you polymorph into a flying monster while in a
pit, you must take u.utrap turns to first climb out before you can fly.  Of
course, once you're out, you can swoop down into the pit to pick things up
w/o delay.  Rather that have you automatically fly out (e.g. like quaffing
a potion of levitation), I thought it was better to take a turn to fly out,
so that's what I've implemented.

The code to deal with exiting a pit is moved to a new climb_pit function
and the "up" command now lets you climb from a pit too (something I've
found non-intuitive in the past).

Finally, I noticed that non-moving monsters could still go up/down even
though they couldn't move around.  Added non-moving checks in doup/dodown.

U1231 - messages ordering when displacing a pet into a trap
move the message so it's before the mintrap test.  newsym's are needed
to ensure the display is correct if a --More-- prompt results.  I left the
"frighten" message alone, except for tense.  As per Pat's suggestion, I
changed the wording to future-proof the message.

experience calculation
fix the bug <Someone> noticed WRT experience calculation for nonphysical damage.

comment isqrt
Help code divers to understand why isqrt is not a complicated function.

Guidebook update

fixes35.0 update

win32tty: prevent early messages from flashing by unseen

customize role, race, gender, align choices (trunk only)

Support negation syntax to restrict unwanted race, role, gender, align
options:
        OPTIONS=role:!knight, role:!tourist, race:!orc
prevents them from being picked randomly or
appearing in the pick lists at the start of the game.

startup problems on Unix
I found I was no longer able to start "nethack", I think due to the change
in the save file structure.  But, it looks like the Unix-specific check in
bufon() was never quite correct.  I'd have to guess we've been lucky up
until now.

files.c fixup
With recent files.c changes, code required for Qt compilation on Unix no
longer worked.

missing copyright
<Someone>, I think, noticed there was no copyright on the window.doc.
Add one.  I don't recall when I originally wrote it, but I last changed
it in 2003, so that's the year I'm putting in.  Anyone else that wants to
share the blame, please add your name and update the year as needed.

followup: drinking from sinks while levitating
This is a followup to the patch I made a couple months ago.  It replaces
the "!Levitation && !u.uswallow" checks with can_reach_floor(), which
makes a more complete set of checks and is more consistent.  I applied
this to fountains too.  I doubt that fountains hit the ceiling, and the
checks also seem reasonable for heights in between (e.g. while mounted).

yet another bit

AltGr-4 and alternate tiles in menus - trunk only (from <Someone>)

On Mon, 03 Jan 2005 12:04:29 +0000, <email deleted> wrote:
> Dear NetHack win32 developers,
>
> This bug does not affect the win32 binaries that you distribute but it
> does affect NetHack 3.4.3 if I build it from source. The difference may
> be due to different compilers or whatever. I'm using mingw32-gcc v3.2
>
> I don't quite understand what's going on (I never was much good at
> win32 programming), but it appears that the WM_KEYDOWN message for
> AltGr-4 is being translated into a WM_CHAR message with a wParam of
> 128. I don't understand why that should be, but anyway. The problem
> then occurs when NetHack casts wParam to char which, since char is
> signed, gives -128. onListChar() then passes -128 to isdigit() which
> causes the crash. The fix appears to be to simply drop the cast:

Also
> <email deleted>
> Newsgroups: rec.games.roguelike.nethack
> Subject: Changing tile set for item list?
> Date: 1 Jan 2005 20:03:08 -0800
> <email deleted>
>
> I'm using the windows interface for Nethack 3.4, and I've successfully
> changed the tileset used by changing defaults.nh.  The only problem is,
> the item list (i.e. The list that comes up when I press "i") still uses
> the old tiles.  Is there any way to change the list so it uses the new
> tiles?  I've searched the guidebook to no avail.  I'm debating if it is
> even possible.
>
> Thanks for the help,
> -Zmann

trunk patch:
- menu: display custom tiles if map is not ASCII
- menu: display '-'/'+'/'#' in place of a tile if map is ASCII
- fix isdigit() crash on AltGr-4 with mingw

It looks kinda weird with huge tiles (e.g. absurd96) but that could
be just me. Comments/suggestions are welcome.

-<Someone>

selectsaved follow-up bit  (trunk only)

fix a cut-and-paste error that I didn't catch earlier.

selectsaved follow-up bit  (trunk only)

selectsaved option (trunk only)

- always write plname into save file, no longer conditional
- add 'selectsaved' wincap option to control the display of
  a menu of save files for ports/platforms that support it.
- add support for win32 tty using normal nethack menus.
- the win/tty/wintty code is generalized enough that any
  tty port could support the option if the appropriate port-specific
  code hooks for wildcard file lookups are added to src/file.c
  specifically in the get_saved_games() routine. There is posix
  code in there from Warwick already, and there is findfirst/findnext
  code in there from win32. Warwick has the posix code only
  enabled for Qt at present, but with wintty support, that could be expanded
  to other Unix environments quite easily I would think.

Here is what the tty support looks like:

    NetHack, Copyright 1985-2005
         By Stichting Mathematisch Centrum and M. Stephenson.
         See license for details.

    Select one of your saved games
    a - Bob
    b - Fred
    c - June
    d - mine3
    e - Sirius
    f - Start a new character
    (end)

The following files existed in the NetHack SAVEDIR directory
at the time:
    ALLISONMI-Bob.NetHack-saved-game
    ALLISONMI-Fred.NetHack-saved-game
    ALLISONMI-June.NetHack-saved-game
    ALLISONMI-mine3.NetHack-saved-game
    ALLISONMI-Sirius.NetHack-saved-game
Note that despite the file names, the actual character name
is drawn from the savefile.

The WIN32CON support passes
    USER-*.NetHack-saved-game
to findfirst/findnext where USER is your login name of course.

filled trap doors on castle can be re-dug

extern.h bit

no message

more trunk 3.5

housekeeping: mark trunk sources 3.5 (misc)

housekeeping: mark trunk sources 3.5 (doc)

housekeeping: mark trunk sources 3.5 (dat)

housekeeping: mark trunk sources 3.5 (include)

housekeeping: mark trunk sources 3.5 (src)

new year

region player_flags follow-up correction [trunk only]

region boolean field [trunk only]

Since the trunk breaks savefile compatibility anyway,
remove some code that was inappropriately loading a boolean
with multiple values in order to preserve savefile compatibility in 3.4.x

[Note: this patch increments EDITLEVEL rendering existing bones
and save files obsolete]

minor doorganize() addition

This is a minor addition to Pat's doorganize() patch.

This just allows you to press '?' in the midst of an #adjust command
to see what letters are already in use. It is a PICK_NONE menu for
viewing only, because your actual response to the #adjust must not
be limited to the letters already used. It helps to be able to see
what's already consumed without having to terminate the command,
inventory, then start it again.

add May 2004 trunk patch to the branch

Bug Report:
>> Status of the doppelganger (neutral): Level 13 HP 1433(1433) AC 5.
>> [See the HPs!! ]

Michael:
> I used a debugger and traced this massive hit point growth
> to this line in mon.c, function newcham(). (I watched the mhp
> jump from 58 to 567 with this one calculation!
>> Ah, I see that this problem is fixed in the trunk but still present in
>> the branch. This seems serious/abusive enough to warrant the fix to be
>> applied to the branch too, doesn't it?

Pat:
>      I don't think it's all that important but you're welcome to
> extract and adapt the patch if you like.

obj->quan bits

spelling bit

...on the word "grammatical" no less.

replacement meaningless_code patch
I moved the "else" into the comment rather than the suggested removal of
the comment.

fix monster summoning message

     From a bug report:
> If the Summon Nasties monster spell gates in two minions instead of one,
> the message still says "A monster appears from nowhere!"

The code wasn't counting any summoned monsters who had an opposite alignment
to the summoner.  It also assumed that the 10% chance for demon summoning
in Gehennom always yielded exactly one monster even though that can produce
zero or more than one.

candelabrum wording

On Sat, 18 Dec 2004 14:07:14 +1300, <email deleted> wrote:
> Adding one of several candles to a candelabrum which already has six
> gives an ungrammatical message.

treat statues and containers alike in follow-up

more follow-up for container flags

Set cknown and lknown when identifying possessions at game end.
Clear cknown and lknown when creating bones.

statue trap triggered by Blind searching

<Someone> wrote:
> Blind, s)earching unknown territory...
>
>   "You find something posing as a statue."
>
> Shouldn't this map_invisible()?

monster order rules

<Someone> wrote:
> From the mkclass() comments:
>
> /*      Assumption #2:  monsters of a given class are presented in ascending
> *                      order of strength.
> */
>
> And monst.c:
>
>  *      Rule #2:        monsters of a given class are presented in ascending
>  *                      order of strength.
>
>  *      Rule #4:        monster subclasses (e.g. giants) should be kept
>  *                      together, unless it violates Rule 2.  NOGEN monsters
>  *                      won't violate Rule 2.
>
> Inspecting my monster-difficulty spoiler, I see the following places
> that these precepts are violated: do they cause potential problems?
> (Insofar as occasionally incorrectly miscalculating the probabilities
> for monster generation is a "problem", that is...)
>
> SPECIES                DIF
> ~~~~~~~~~~~~~~~~~~~~~~ ~~~
> d                  dog   5
> d            large dog   7
> d                dingo   5
>
> d                 warg   8
> d      winter wolf cub   7
> d          winter wolf   9
>
> u        white unicorn   6
> u         gray unicorn   6
> u        black unicorn   6
> u                 pony   4
>
> H          frost giant  13
> H          storm giant  19
> H                ettin  13
>
> P        black pudding  12
> P          green slime   8
>
> S            pit viper   9
> S               python   8
> S                cobra  10
>
> Z         giant zombie   9
> Z                ghoul   5
>
> @                nurse  13
> @              soldier   8
> @             sergeant  10
>
> &         horned devil   9
> &             succubus   8
>
> &               balrog  20
> &            sandestin  15
>
> (I've just realised that these may have already been fixed, and
> waiting on a file-compatibility-breaking release; if so, ignore me :-)

coaligned unicorn in bones

<Someone> wrote:
>> If the previous character was non-neutral, the unicorn would have
>> started off as hostile.  When a bones file is loaded, I don't think
>> hostiles are made non-hostile, although the reverse is certainly true
>> (pets of the deceased are usually hostile).
>
>  In the general case, they are, or rather their hostility is
>  re-evaluated with respect to the new character; see the peace_minded()
>  call in getlev(). However, co-aligned unicorns always being created
>  peaceful is a special case in makemon(), _not_ part of peace_minded(),
>  so they'd just have the usual chance of being made peaceful or not
>  depending on alignment strength, as for any other co-aligned monster
>  not explicitly declared always peaceful or always hostile.

Master of Thieves

<Someone>  wrote:
> The "/* Fix up the quest nemesis */" code in role_init()
> adds M3_WAITFORU but _doesn't_ remove M3_CLOSE;
> since the Master of Thieves as the Rogue Quest Leader is
> defined with that flag, he keeps it when acting as the Tourist
> Quest Nemesis. Thus, when STRAT_WAITFORU
> is cleared by your actions, STRAT_CLOSE may stay in
> place making him stay meditating when another Nemesis
> wouldn't.

another follow-up bit

shrieking monster failed to wake others

<email deleted> wrote on Friday, December 10, 2004:
> I was in a barracks with the soldiers sleeping.  I started fighting one soldier
> and threw a potion of acid on him.  I got the "The soldier shrieks in pain!"
> message, but none of the other soldiers in the barracks woke up.

follow-up bit

shadowed declaration warning

<Someone> complained that his compiler was giving these
warnings:
cmd.c:2119: warning: declaration of `expl' shadows a global declaration
dungeon.c:292: warning: declaration of `rand' shadows a global declaration
exper.c:100: warning: declaration of `exp' shadows a global declaration
files.c:278: warning: declaration of `basename' shadows a global declaration
hack.c:1102: warning: declaration of `expl' shadows a global declaration
pickup.c:2081: warning: declaration of `select' shadows a global declaration
role.c:1060: warning: declaration of `conj' shadows a global declaration

static placement warning

<Someone> complained that his compiler was giving these
two warnings:

weapon.c:835: warning: `static' is not at beginning of declaration
version.c:132: warning: `static' is not at beginning of declaration

new container flags

[Attention: This patch increments EDITLEVEL in patchlevel.h, rendering all
 previous save and bones files obsolete.]

Here's the first cut at the two recommended flags lknown and cknown.
I've attempted to stay close to Pat's recommendations:
   "Containers ought to have two new flags:  lknown for lock status known,
    and cknown for contents known (ie, `secret').  Formatted box and chest
    descriptions should include locked/unlocked/broken when that is known
    and empty/nonempty (or something like "holds N items") when contents
    are known. The contents indicator would also apply to nonlockable
    containers."

I probably overlooked a place where a flag should be adjusted, but this
should give us a good starting point.

I wasn't sure what to do with the case of the auditory feedback for
magical locking "Click" and "Clunk". The question that came to my mind
was: Should those reveal the locked or unlocked status of a box?
I suppose if you knew the type of wand you were zapping or the spell
you were casting, you could argue that they should.

In the end, I opted for setting lknown right off the zap/cast effect
for anyone playing a Wizard role, and not setting it for anyone else,
thus advancing class differentiation a little bit too.

I haven't checked the cknown results under all flags.menu_style options
at this point, only MENU_FULL.

upper case correction

Fix for first issue reported in this bug report:

<email deleted>
Sent: Thursday, December 09, 2004 7:13 AM
Subject: Two wrong messages

I would like to report two cosmetic issues:

1. "its gaze is reflected by the invisible [pet]'s shield."
Wrong capitalization.

2. The message given when decapicating an ettin {,zombie} with the Vorpal
Blade fails to mention the second head.  This could be pretty tricky to
fix, but, per <Someone>'s suggestion, the easiest explanation would be
to say that the blade's wielder cuts off both heads at once.
The patch would look similar to:
                         *dmgptr = 2 * mdef->mhp + FATAL_DAMAGE_MODIFIER;
>                        if(mdef->data==&mons[PM_ETTIN]
>                          ||mdef->data==&mons[PM_ETTIN_ZOMBIE)
>                                pline("%s goes through both necks of %s at once like butter!",
>                                      wepdesc, mon_nam(mdef));
>                        else
                         pline(behead_msg[rn2(SIZE(behead_msg))],
                               wepdesc, mon_nam(mdef));
                         otmp->dknown = TRUE;
(and the same for youdefend)

stinking cloud feedback

     Add the extra feedback suggested by <Someone> so that being blinded
by moving into a stinking cloud is explicitly pointed out to the user.  It
makes things more verbose but seems reasonable.  You get blinded for 1 turn
with every step, so the message gets repeated each time too, but since you
also get a choking or coughing message on each step it's only a modest
increase in the overall verbosity.

avoid hallucinatory effect on black light as it explodes

     From a bug report:  when a black light explodes and triggers
hallucination, its own monster symbol--or warning marker for same--could
be seen changing.  Since nothing is left after it explodes, you shouldn't
hallucinate anything at its location.  Fix by killing it off (so removing
it from the map) before initiating Hallucination.

remove an unused variable
gcc w/warnings whined

U1182 - Can drink from sink while engulfed
The same occurred for fountains and drinking surrounding water while
underwater.
I also added a !Levitation check for sinks, like already exists for
fountains.  I cannot believe sinks are taller than an altar, and if you
can't pick up stuff from an alter while levitation, it stands to reason you
cannot drink from a sink then either.

fix steed eating feedback

     <Someone> reported that riding a steed into a magic portal can
give "steed is still eating" message, feedback normally used to explain why
you can't go down stairs.  Rather than preventing portals from activating
in that situation, just force the meal to be finished in order to suppress
the message.  Proper fix is probably to prevent all steed movement while
eating, but that would most likely result in no one ever riding again.

fix #U1206 - Quest artifact in WIZKIT file aborts program

     Fix the wizard mode crash From a bug report.  Move the WIZKIT
message suppression to a lower level instead of trying to guard against
present and future pline() calls in the wishing code.  The way that was
being handling wasn't suitable for dealing with quest feedback.

     This also includes a couple of additional wishing synonyms.

tastes like chicken...

     Someone in the newsgroup expressed surprise that he didn't get any
special message after surviving the eating of a cockatrice corpse.  Combine
the cliche that unconventional meat inevitably tastes like chicken with
the mythology that cockatrices are a bizarre hybrid of chicken and reptile
(or whatever).  This will give a message about tasting like chicken for
corpses or smelling like chicken for tins when the hero has petrification
resistance (poly'd into a xorn, for instance) or is hallucinating.

fix #U1202 - shop robbery oversights

     A user reported that when breaking potions inside a box in a shop, he
wasn't charged for them.  The code was calling stolen_value() as intended,
but that routine only charged for types of items which the shop normally
carries.  That meant that breaking the contents of a box in a general
store would charge for them but doing so in a tool shop would, not even
though the tool shopkeeper would gladly sell such things when you picked
them up instead of causing them to go away.

     When fixing this, I noticed that stolen_value() was only charging
for single items.  Most of the time that was right, because throwing and
kicking things always split one off, but there are cases (such as zapping
a wand of teleportation at shop goods) where an entire stack gets stolen
as a group.  This makes stolen_value() handle all quantities.

cockatrice eggs vs gravity

     Eggs thrown straight up which don't splatter on the ceiling yield
"you've got it all over your face", so wearing a helmet shouldn't protect
against petrification from cockatrice eggs in that situation.  This was
part of my delayed helm vs hat stuff; I can't remember whether it was done
before or after this same issue came up in the newsgroup.

hats vs helms

     Something from <Someone>'s list:  some messages have hardcoded references
to "helmet" which sound strange when the character is wearing a hat or cap.
helm_simple_name() is comparable to the existing cloak_simple_name().  It
returns "helm" or "hat" depending upon whether the helmet provides the
same protection that yields the assorted repetitions of "fortunately,
you are wearing a hard helmet".  This choice ends up categorizing elven
leather helm as a hat (which I think is ok given that its undiscovered
description is "leather hat"), contrary to <Someone>'s suggestion that the
distinction be made based on whether the helmet was made of cloth.

     I started on this a year and a half ago but didn't commit it.
Unfortunately I don't remember why and haven't done any significant
additional work now--just recovered from some intervening bit rot and
confirmed that the patch as is seems to be working ok (in the trunk; the
branch side has not been tested).  I suspect that I meant to look for
additional helmet messages which could benefit from conditional headgear
description.  (Those "hard helmet" ones don't need it, although they
should perhaps be moved into a common routine instead of being replicated.)

#adjust enhancement - splitting stacks

     Allow the #adjust command to be used to split an inventory stack
as well as for moving things to specific slot letters.  Splitting is
accomplished by specifying a count along with the letter of the stack to
operate on, similar to when dropping a stack with 'd'.  The comment above
doorganize() has more details.

     This change will make it possible for users to split stacks of cursed
loadstones which they couldn't easily do before, but I don't see anything
wrong with that.  It was always possible to have multiple stacks of load-
stones by starting with ones that had different curse/bless status, so this
hasn't introduced a totally new situation.  On the other hand, I haven't
tested this with the GOLDOBJ configuration and am not sure whether there is
any need to prevent gold from being split there.  The getobj() call doesn't
specify COIN_CLASS so perhaps it's irrelevant (unless it ought to be
changed the other direction by adding that to intentionally allow gold to
be split?).

doorganize() tidying

     I've cleaned up the #adjust routine somewhat while revising it to
support splitting stacks as well as moving them, then have separated the
cleanup from the more substantial changes.  The most significant change
here is that #adjust will give up early if used when inventory is empty;
the user used to be forced to choose a letter from an empty list in that
case, then it gave up when no object was selected.  There's also a minor
change for users who turn `fixinv' off; the prompt's list of likely
candidate letters for destination slot is reduced to one letter beyond
current usage instead of showing the rest of the alphabet.  (Picking any
letter--which users can still do--beyond current usage results in moving
the adjusted item to the end of the list, although it ultimately ends up
with a different letter than the user chose because adjusting from some
other slot frees up that slot; all items past it--including the new last
element--effectively move up one letter [or more if merges occur].)

pickup into quiver

     Despite lack of feedback from the beta testers about it, add the code
which tries to stack an object being added to inventory with the quiver
before trying with other carried objects.  Only matters to user if quiver
is non-empty and one or more other slot(s) are compatible with it, but
that's not uncommon for someone who starts a rogue by splitting the initial
daggers into separate wield and throw slots.  Firing a dagger from quiver
and then having it merge with wielded weapon instead of back into quiver
when picked back up leads to tedious inventory manipulation.  Assigning
different names to the two stacks solves this, but can't help when picking
up an unnamed item which is otherwise compatible.  (A rogue with starting
daggers wouldn't encounter that since unnamed ones won't be sufficiently
identified to stack, but any character who just gathers unID'd daggers and
uses them for both melee and throwing has a chance of running into the
"picked up into less desireable slot" trap whenever new ones are found.)

Glib messages when dropping weapons

     <Someone> reported that she got "your weapon slips from your hands" when
inflicted with slippery fingers while wielding multiple daggers.  That
should be "weapons" plural and they're only being dropped from one "hand"
singular.  Fix that and also give more specific feedback than "weapon"
for non-swords based on their weapon skill category names.  This works
pretty well for most common weapons but might need some more tweaking for
ones where different types have gotten lumped together in the skills.

old feedback:
  Your weapon slips from your hands.
  Your tool slips from your hands.
  Your food slips from your hands.
twoweapon:
  Your sword slips from your hands.
  Your other sword also slips from your hands.

new feedback:
  Your daggers slip from your hand.
  Your <one-hander> slips from your hand.
  Your <two-hander> slips from your hands.
  Your pick-axe slips from your hand.
  The corpse slips from your hand.
twoweapon:
  Your sword slips from your left hand.
  Your other sword also slips from your right hand.

#enhance docs again

     Since "weapons and spell skills" is grammatically suspect and
"weapons and spells skills" sounds odd, change to "weapon and spell skills"
in both the Guidebook and the game's online descriptions.  The #enhance
command itself uses "current skills" and doesn't need any alteration.

petrified engulfer (display glitch & potential panic)

     From the newsgroup:  if you were polymorped into a cockatrice and
a trapper attempted to swallow you, the 't' displayed at its location
would be left behind after it turned to stoned.  This fixes that and a
much more serious issue as well:  if you were punished at the time, the
game would panic on your next attempt to move because the ball&chain were
left in limbo.  There would also have been strangeness (monster sharing
your location, stale u.ustuck setting) if the swallower was life-saved,
but I didn't try to make that happen so am not sure how bad things would
have been.

doc bits

     Per <Someone>'s request, make the game's description of the ``#enhance''
command be the same as in the Guidebook by mentioning spell skills.
Combining weapons plural with spell singular isn't right, but I'm not
sure which way to change that so am leaving it alone.  On the other hand,
the poor grammar used to describe the ``#conduct'' command is easy to fix.

gas spores attempting to attack

     From a bug report, but pulls back" while successfully
praying.  Gas spores' only "attack" is to explode when dying, so the code
that checks whether the monster has any attack needs to handle AT_BOOM as
a special case.  Unfortunately this change means that you won't interrupt
an occupation when a gas spore approaches, and a subsequent kill by your
pet might end up causing you harm while still occupied.  The callers of
`noattacks()' are messy enough that I didn't want to try to address that.

     This also moves noattacks() from mhitm.c to somewhere more sensible.