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.

more ^R

> clear stale prompt
[...]
> Can someone who understands the relevant windowing code fix ^R in getpos()?

     I still don't understand why it wasn't working as expected, but moving
the existing cursor positioning after flush_screen() instead of before now
makes ^R work ok during getpos().  It doesn't restore the top line text so
isn't a transparent redraw but it now displays a prompt string there instead.
Likewise after typing '?' for help so that it should be move evident that
nethack is still waiting for you to move the cursor somewhere.

     Also add support for ^L in numpad mode.  I almost never use that and
didn't think of it the first time around.

clear stale prompt

     From the newsgroup:  applying various types of tools (example was a
mirror; figurine is another case) and then typing <ESC> at the "In what
direction?" prompt would leave the prompt displayed.  User complained that
he tried to answer the no longer valid prompt--even though the cursor had
correctly moved back to the '@' on his map--and ended up walking into lava
instead.  Suggested fix in the newsgroup was to use pline("Never mind.")
the way many commands already do, but it's simpler and more robust to clear
the message window before getdir() returns.  Callers can issue Never_mind
feedback on a case by case basis as before; I haven't added any here.
Perhaps getpos() should get passed an extra argument telling it to issue
that message; then a dozen or so pline(Never_mind) calls could be removed.

     I also was annoyed that ^R gave me the command assist display instead
of redrawing the screen with the prompt intact.  This fixes it for getdir().
The corresponding fix for getpos() doesn't work correctly; it successfully
redraws the screen but leaves the cursor at the end of the 2nd status line,
despite the fact that it is followed by an existing cursor position call.
Can someone who understands the relevant windowing code fix ^R in getpos()?
(Easiest test case is probably just ^T in wizard mode.)  I have't added an
entry for ^R to the fixes file since it isn't fixed yet.  And I didn't look
to see whether yn_function() ought to handle ^R too; it might be used in
contexts where map redraws don't make sense.

still more magic lamp

     I was going about the use of tmp_at() from the wrong direction.
Instead of trying to replicate how a monster has been displayed, just pick
whatever is shown at its location and then redisplay that after it's gone.

compilation bit
gcc whined about taking the address of a register variable

followup to fix for M63 - magic lamp wishes

     This uses Michael's suggestion for keeping the display up to date when
removing a djinni or water demon in advance of granting a wish (so that it
won't be present in a bones file if the wish is fatal--problem with earlier
fix was that player could notice monster was already gone while responding
to the wish prompt).  It's not quite as straightforward as I was hoping for
and would get a lot messier if it needed to cope with Warning & Warn_of_mon.

fix #M63: Problem with magic lamp changing

     Fix the problem From a bug report, so finding it in a bones file yielded a fully functional magic
lamp.  Fix as user suggested:  convert the lamp first.

     It also left the djinni who would normally have disappeared right after
the wish.  Water demons from fountains have that problem too.  Unfortunately
my fix is a bit buggy:  when removing the monster before granting the wish,
the player can notice.  Is there a straightforward way to display a monster
where none is present on the map?  Or do we need something comparable to the
obj->in_use flag for monsters, so that the bones code can discard particular
ones?

exploding wands

     Pointed out by <Someone>:  engraving with a cursed wand should pose a
risk of having it explode just like zapping does.  [At the moment when one
explodes, any existing engraving doesn't get changed.]  Suggested by someone
(<Someone>?) some time back:  explosion due to recharging could be consolidated
with explosion due to zapping cursed wands.  And noted by <Someone> in the
newsgroup:  '+' in an engraving--perhaps written by someone trying to leave
bones file notes--should have a chance of being partially rubbed out to '-'.

more statue animation and corpse revival (trunk only)

     Reviving a corpse or statue restores the monster to life before
deciding whether the object which was used up in the process belongs to a
shop.  This resulted in a rather strange situation when the revived monster
was the shopkeeper involved.  The object can't have been stolen; there was
no shk to own it at the time it got used up.

  Manlobbi's statue of a shopkeeper comes to life.
  You owe Manlobbi N zorkmids for it.

Suppress "of a shopkeeper" in such a case, and do not charge the hero for
using up the statue.  The corpse case only needed the second part.

     This revises post-3.4.3 code so doesn't warrant a fixes entry.

more duplicate gold

     My previous fix (trap.c) prevented the panic, but didn't actually stop
gold possessed by a reanimated statue from doubling.  That problem was due
to how the monster info was saved rather than to how it was restored.
The previous fixes entry applies.

fix "display_minventory: static object freed" panic (duplicate monster gold)

     From a bug report, using stone to flesh to
reanimate a petrified monster who was carrying gold (in his case, it was
a shopkeeper) resulted in gold in the monster's inventory.  Somehow it was
also being duplicated in the mgold field--I didn't try to figure that part
out--so killing the monster produced double gold.  More significantly,
probing such a monster prior to killing it caused a panic when the monster
inventory was being massaged for formatting.

     Fix is trivial:  use a routine which knows about special handling for
gold when transferring statue contents to resurrected monster.  Both aspects
of the problem only occurred for the !GOLDOBJ configuration (which is our
default).  However, any objects which confer something special when simply
being carried would have also been misbehaving--automagic animation of
cursed figurines is the only applicable situation; too rare for anyone to
have noticed.

Fire/Frost Brand vs rusting

     Implement the suggestion that Fire Brand avoids damage from rust traps
by boiling away the water.  Rather than making this be trap-specific, it
applies to all types of erosion which go through erode_obj().  That includes
hitting rust monsters but not dipping into potions or fountains, nor falling
into moats.  And it doesn't provide 100% protection, just a high chance of
avoiding rust damage.  Also, Frost Brand gets similar protection by freezing.

     The message handling needed some rewriting for the branch version.
That compiles ok but hasn't been tested.  It would have been simpler just to
move Yobjnam2() over even if nothing else was changed to use it yet....

#M32: Astral vision vs normal vision
While wearing EotO, ";" and selecting a monster behind a wall would display
"normal vision" as well as "astral vision".  This is because cansee() gets
set for things seen via astral vision.  However, couldsee() is only set for
things that could be seen normally, so check both values.

confused remove curse

     When confused remove curse acts upon an object to randomly bless or
curse it, clear the bknown flag.  Do this for all objects which get subjected
to the effect, even ones which are already blessed or cursed and hence don't
change state.

costly_alteration() tweaking (trunk only)

     For cancellation I accidentally used terrain type WATER when I meant
object type POT_WATER, so being charged for cancelling holy or unholy water
wasn't working.  When I first put in COST_UNHOLY the name made some sense
based on its usage, but after later adding COST_UNBLSS it didn't any more;
change it to COST_UNCURS.

     A shopkeeper's complaint that you're uncursing or unblessing his wares
(only applies to water) now sets bknown flag since you know that the object
has become uncursed.  I hadn't realized that confused remove curse only
affects uncursed objects; this greatly simplifies extra code I added there
for costly_alteration().

[No fixes entry needed.]

finding traps while blind [missing pieces]

     <Someone> reported that when levitating and blind, he was getting
"You float over the hole" without it showing up on the map.  Easiest way
to reproduce:  zap a wand of digging downwards while levitating blind,
move off the spot and back over it.

     Make sure that all traps created by the player are mapped.  For other
traps, it was about 50:50 whether the trap triggering message yields enough
information to warrant forcibly mapping the trap when blind.

finding traps while blind

     <Someone> reported that when levitating and blind, he was getting
"You float over the hole" without it showing up on the map.  Easiest way
to reproduce:  zap a wand of digging downwards while levitating blind,
move off the spot and back over it.

     Make sure that all traps created by the player are mapped.  For other
traps, it was about 50:50 whether the trap triggering message yields enough
information to warrant forcibly mapping the trap when blind.

throttle eating of rings

     A few weeks ago someone in the newsgroup posted how he got an intrinsic
value for increased damage up to something like +74 via eating rings (on his
way to killing the Riders a zillion times for maximum score--he wanted to be
sure to kill them in a single hit each time so that his use of keystroke
macros wouldn't get out of sync by extended combat).  Make it moderately
difficult to get beyond +20 and impossible to get past +40 for corresponding
attribute when eating rings of increase damage, increase accuracy, and
protection.  Since you could also wear a pair of +7 rings you can still get
an awfully high total, but it won't be unlimited any more and most people
willing and able to go to such extreme lengths would undoubtedly prefer to
be wearing other types of rings.

autocursing armor worn by monsters

     From the newsgroup:  non-cursed dunce cap or helm of opposite alignment
which would glow black and become cursed if worn by the hero wasn't doing
the same when worn by a monster.  Fixing this gives players a new way to
recognize bad hats--drop on altar, then drop in front of approaching goblin
or other wimpy monster capable of wearing armor--but I think that's fair.
Since helms of opposite alignment are usually already cursed it won't make
much difference for them; most players seem to avoid all conical hats so it
won't make much difference for dunce caps either.

redundant feedback for containers (trunk only)

     Looting or applying an empty container whose [lack of] contents is
known yields "Your empty <container> is empty."  Suppress the first "empty".
No fixes entry needed; this is post-3.4.3 code.

redundant feedback for `I u'

     When 3.4.0 added the shop price to inventory display of unpaid items,
it resulted in showing that price twice if you used the `I u' command while
carrying just one unpaid object.

k - a potion of object detection (unpaid, 150 zorkmids)    150 zorkmids

With two or more unpaid objects it uses a menu style display and explicitly
suppresses "(unpaid, N zorkmids)" from the inventory formatting.  Do the
same suppression when there's one item.

k - a potion of object detection                     150 zorkmids

alteration of shop-owned objects (trunk only)

[This ought to be suitable for the branch version too but I'm not going to
spend the effort to migrate it there.]

     Recently From a bug report, reducing
the value of a shop object via cursed enchantment was ignored by shopkeeper.
This replaces the existing costly_cancel() routine with costly_alteration()
which performs a similar task:  bill for any item whose value has been made
less.  The hero owns the resulting object but must pay for the original one
before being allowed to leave the shop.

     This covers the majority of cases where bill_dummy_object() was already
being used:  cancelling a charged or enchanted item, casting drain life at
same, diluting potions or blanking scrolls or books by dipping them into a
potion of water, dulling a weapon by engraving with it, eating unpaid food
or opening unpaid tins, applying a cream pie to hit yourself with it in the
face, applying a wand to break it, burning something by dipping it into lit
potion of oil, and clearing potions by dipping a unicorn horn into them.
The shop billing behavior for those actions hasn't been changed, just
consolidated into one place which delivers a common message for them.

     This also covers many cases which weren't being handled:  stripping
wand or magic tool charges via cursed scroll of charging, reducing a charged
ring's enchantment via same, reducing weapon or armor enchantment via cursed
scroll of enchant weapon or armor, stripping an item's rustproofing via
confused enchantment, making a crysknife revert to a worm tooth, unblessing
potions of holy water or uncursing potions of unholy water.  (That last one
won't be billed if it's the result of prayer rather scroll, spell, or #dip.)

     And this tries to handle the reverse situation more thoroughly too:
many actions which improve the value of an unpaid item now also cause the
shop bill to be updated to reflect its new higher price.  Aside from the
basic enchanting and charging magic, it covers converting dragon scales into
dragon scale mail and worm tooth into crysknife.  Some things which might be
expected to inflate shop prices, like rustproofing or increasing the number
of charges in a wand, don't actually affect the price.  And there are bound
to be cases where the price is affected but I've overlooked.

smartphone keypad input tweaks (from <Someone>)

clicklook on win32

Make clicklook option a little safer/easier on win32 by letting
right-mouse button work as expected.

smartphone keypad input tweaks (from <Someone>)

<Someone> wrote:
> Some keypad input tweaks for Smartphone port:
> - added "Type Cmd" command that allows to type arbitrary commands using
> phone keypad
> - added Q(quiver) command to "Attack" layout
> - fixed F command to prompt for direction
>
>
>>2) I can't find a way to do the equivalent of d<number><item> and the
>>same for picking up (for example when multiple rations are on top of each
>>other and you can only afford 1)
>>
>>3) I can't find a way to change the quiver (the Q command)

M36 - can see through polymorphed boulder
The vision matrix was updated in the boulder->statue case, but
not in the statue->boulder case.

bill_dummy_object

     Various actions (potion dilution, igniting candles or oil, dulling a
weapon by engraving) on an unpaid object can modify it in such a way that
a shopkeeper will force the hero to buy it.  bill_dummy_object() is used
to make a copy for the shop bill; play continues with the modified item
now owned by the player.  bill_dummy_object() was setting the no_charge
flag unconditionally on the modified object but the flag shouldn't be set
for items in inventory.  It was possible to drop the object and sell it,
pick it back up for free due to that flag setting, then drop it and sell
it again.  One easy way to reproduce is to zap yourself with a wand of
cancellation while carrying unpaid positively enchanted armor or weapon.

     The no_charge flag gets cleared when you pick something up off the
floor or take it out of a container, so this sell-it-again case would only
repeat once.  Selling a dropped item ought to clear the flag, but my head
is still spinning after looking at the shop code to see about implementing
that.  This fix just prevents bill_dummy_object() from mis-setting the
flag in the first place; sellobj() still can't fix it up after the fact.

shop billing

     Shop internals:  funnel all checks for whether an object is something
a shopkeeper will charge the hero for through one routine instead of having
duplication code which might eventually get out of synch.  There shouldn't
be any detectable change in behavior due to this.  No fixes entry necessary.

Drawbridge collapse bug
From a bug report, it is possible for the hero to
appear embedded in the wall after destroying the drawbridge.  This is because
The variable "lev1", which was the entity's location, was being referenced
after e_died, but e_died can change the entity's location.  So, as <Someone>
suggested, refer to the current location directly.

typo

M29 - unconscious effects when not unconscious
While auditing nomul() I noticed unconscious() treats (multi < 0 && !nomovemsg)
as unconscious.  This explains the behavior in M29 (unconscious message
while performing #turn).  I checked all the places with this combination,
and found a few that did not appear to fall under the "unconscious" category.
Most I changed to use You_can_move_again to ensure the same display w/o the
unconscious behavior. Also:
- found another string that unconscious() should have considered
- vomit() now sets nomovemsg, one caller was also doing this redundantly
- vomiting_dialogue() was calling stop_occupation() after vomit(), which can
  reset multi.  I reversed the order and removed a doubly-redundant nomul call.

tele() still has a problem: some cases where multi < 0 should probably take
a branch like the unconscious() branch but with a different message.
doturn()'s behavior - turn then wait - is also less than perfect, but I
think this is a known problem.

code cleanup
removing the remains of sync_hunger() which has been #ifdef'd out for years.

finally finished but not eating
Finally apply the patch sent by <Someone> in 11/2003 for slashem-Bugs-799278,
updated to match the current code and handle additional cases.  The fix
is brute force: always ensure nomovemsg is set when nomul is called with
a negative value.  I also scanned the code for places manually setting
multi negative, they all set nomovemsg.  It would be nice to have a function
that did the right thing, but there are several special cases and I was
not feeling creative.

pet ascension

     From the newsgroup:  player offered the Amulet with a pet adjacent
to his character, and instead of getting "You and Fido ascended" he got
"Fido is still eating" followed by "You ascended".  Make all adjacent pets
eligible to accompany an ascension even when they're in circumstances where
they'd be prevented from coming along on a normal level change.

monster aggravation spell

     When testing drawbridge stuff recently I ended up with an unseen
monster who evidently cast the aggravation spell repeatedly, yielding a
steady stream of "you feel that monsters are aware of your presence"
messages.  This patch makes monsters tend to avoid repeating that spell
once everyone on the level has already been woken up.  It also extends
the spell effect so that it will wake monsters like quest nemesis and the
Wizard who ordinarily wait until you get close before they become active.

seeing lightning while blind followup
As soon as I did the commit, I saw I was missing a test before the
"tingles" message.

seeing lightning while blind
<Someone> reported that even when blind, you can get
"The bolt of lightning whizzes by you".

shop statues & boulders

     Fix a buglist entry:  fracturing a boulder or statue owned by a shop
was ignored by the shopkeeper.  The existing vague fixes entry of "some
shop thefts weren't charged" covers this.

dipping in acid
Add checks to allow erosion of objects #dip'd in acid.
From a bug report.

vision thing
<Someone> reported: You kill it! A potion of invisibility shatters!
Change the rule in hero_breaks() to avoid giving info for things out of
sight, except when from_invent is set, to preserve desired behavior.

avoid more QBUFSZ buffer overflows
Several places were not using safe_qbuf or anything equivalent to avoid
overflowing a QBUFSZ buffer.  Add more uses plus one special case.  For
the current max lengths returned by xname(), I think this is
sufficient.  This addresses a reported buffer overflow for a
"thoroughly rusty thoroughly corroded helm of opposite alignment", plus more.

land mine vs drawbridge

     Fix the reported problem that having a land mine explode on an open
drawbridge or under its portcullis did not cause the bridge to be destroyed.

sliming ghosts
From a bug report.  Green slime would slime noncorporeals.
Added missing checks.

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.