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.

fixes fix [trunk]

fix #U782 - undead turning in a shop [trunk only]

     Reported last December by <email deleted>.  Using
a wand or spell of undead turning inside a shop used up corpses without
checking whether they were owned by the shop.  Although the report didn't
mention it, using stone-to-flesh on statues had the same problem.

     I'm not completely satisfied by some aspects of this code, but if I
don't commit what I've got now I probably never would.  My original notes
are lost; I thought that there were some additional fixes present, but
looking at these diffs I don't see anything else significant enough to
warrant mention in the fixes file.

two grammar bits

     Fix the two minor grammar problems for messages given when eating
that were From a bug report:  inappropriate or inconsistent
capitalization in mid sentence for
        Ulch - That <object> was rustproofed!
and missing punctuation for the appended clause for cannibalism in
        Ulch - that meat was tainted cannibal!

prevent a panic splitbill: no resident shopkeeper
Patch was sent in by <Someone> on Sep 8:
This bug causes a number of impossible messages (starting with splitbill:
no resident shopkeeper??)

Repeat by:

Enter a large shop.
Wish for a large stack of projectiles.
Sell your projectiles and then pick them up again.
Trap shopkeeper against the door with a scroll of earth.
Throw the projectiles at the shopkeeper to anger him.
Move away from the boulder trap and wait for the shopkeeper to leave the
shop.
Throw one of the projectiles at the free space.

X11 map scrolling behavior [from Steve VanDevender]
This isn't really a bug, but I find it does make the map scrolling in
the generic X11 version a lot less distracting.  The original behavior
produces certain boundaries where, when the cursor moves back and forth
across that boundary, the map scrolls with each crossing.  This is
particularly annoying in places like Sokoban where the player makes that
kind of movement frequently causing large jumps of the map each time.
Changing the border and delta constants in winmap.c as below eliminates
that behavior, as well as making the cursor easier to track by tending
to recenter it whenever the map shifts.

missing scrollbar in X11_display_file [from Steve VanDevender]
It appears that the Athena text widget in recent XFree86 distributions
does not properly honor the XawtextScrollWhenNeeded flag, so the text
widget created by X11_display_file() does not have a vertical scroll bar
when the text does not entirely fit in the window.  I have seen this bug
in XFree86 versions from 4.0.2 through 4.3.0.  Using XawtextScrollAlways
for the vertical scrollbar ensures it will always appear.

fix #U1150 - burning armor with oil

     Objects which were destroyed by dipping them into lit potions of oil
didn't get unworn or unwielded in cases where that was needed.  This left a
stale pointer which could result in various strange things (user saw it be
formatted as "glorkum" but that isn't guaranteed) and there was no update of
any attributes or intrinsics conferred by the item, so persistent levitation
or water walking or dexterity boost could occur.

very trivial typo

bad luck quote

     Nothing to do with <Someone>'s recent list of missing entries, just
an amusing quote I like.  The book itself isn't remotely nethackish; it's
about a teenage boy and a teddy bear who are operating as hardboiled-style
detectives in a land of sentient toys where nursery rhyme characters start
getting murdered.

rnl() tweaks

     Eliminate two minor anomalies in the behavior of the rnl() function
which returns a random number that is modified by the hero's Luck attribute.
Integer division by 3 on requests for small ranges and the fact that the
chance of making a modification was lower for good luck than for bad luck
meant that highest luck did not produce best chance to avoid worst result.

     The actual effect on game play is sure to have been negligible.  More
troubling is that the program has several rnl(3) and rnl(4) calls.  These
practically guarantee a result of 0 when the hero has maximum luck.  The
rnl() function really shouldn't be used for such tiny ranges (unless the
actual intent is that high level characters are expected to almost always
have the 0 outcome...).

follow-up bit

ensure that a sleeping steed doesn't answer you

rolling boulder not in bones files

<Someone> Cced from rgrn:
  <email deleted> (<Someone>) writes:
  [killed by a boulder trap, left bones]

  > Then I realized... there's no boulder.  Did the boulder disappear
  > because I died from the attack, thus bypassing the code that moves the
  > boulder to its intended destination?  Did the creation of the bones
  > file destroy the boulder?  Do boulder traps sometimes get
  > "deactivated" when bones files are loaded?

  The first of these. If you look at launch_obj(), there's an
  obj_extract_self() early on, then all the tracking its trajectory,
  then a place_object() when it comes to rest; since the thitu() call
  kills you during the trajectory part, the boulder never gets re-placed
  onto the map. This is, I think, a bug (and one that will apply to any
  monster-thrown object that kills you, as well); reported to the
  DevTeam.

killing pets by displacing them into traps

     A user pointed out that you lose pacifism conduct if you kill your
pet by displacing it into a trap but you don't gain any experience in
the process.  Make this consistent with killing monsters in other ways:
if you get blamed for it then you should also get credit for it.

     Probably minliquid() and mintrap() should take another argument so
they can call killed() instead of mondead() when necessary, but I didn't
go to that much effort....

monsters throwing greased objects

     Make the chance for thrown object to slip or shot object to misfire
be the same for monsters as it is for the hero.

Mac Carbon addition

Mac Carbon updates

Mac Carbon addition

C340-18 redux
Fix the test of otrapped in ohitmon pointed out by <Someone> that was causing
my previous fix to do the exact opposite of the intended behavior.

fractured rock descriptions

     From a bug report:  fracture_rock() was unintentionally propagating
the boulder or statue's dknown flag to the resulting rocks, producing a
trivial but noticeable difference in description of "rock" vs "stone" if
the source object had been seen up close prior to being broken and the
rocks are then examined remotely or while blind.

     The curse/bless state is propagating too, but this seems reasonable
so I've left it alone.

fix "dropping Medusa's corpse down the stairs"

     User reported the following incorrect feedback:
You drop Medusa's corpse.  corpse falls down the stairs.
and apparently thought that the problem was a glitch in the middle of the
sentence; the actual problem is that the second sentence lacks its start.

     This fix isn't perfect.  You'll now get
Medusa's corpse falls down the stairs.
for the second sentence, but
The Oracle corpse falls down the stairs.
when dealing with a unique monster who doesn't have a personal name.
Either form seems acceptable to me, but mixing them appears inconsistent.

     Probably all the uses of corpse_xname() (and its callers back up the
chain cxname(), aobjnam(), yobjnam()) need to be reviewed for usage.  I
don't have the energy for that.

Make "black" characters visible.
Stop RIP window maximizing (C syntax!).
Make Cancel button more sensible.

fix U1079 - loss of water walking over lava

     Fix the reported problem of being able to safely stand on lava after
taking off fireproofed water walking boots.  The situation was more wide-
spread than that; the same thing happened when non-fireproofed boots were
burned off while walking over the lava in the first place.  Now you'll
fall in and end up getting stuck (you have to have fire resistance for any
of this to happen and that resistance makes falling in be survivable).

hostile djinni from potion

     Fix the situation <Someone> reported where the "You disturbed me, fool!"
result when releasing a djinni from a cloudy potion sometimes produced a
peaceful djinni for neutrals due to the usual randomness in how monsters
react to characters of the same alignment.  Explicitly force it to be
hostile for that outcome.

     Also, for the "it's about time" result, suppress the "It vanishes"
message when the character doesn't see the djinni depart.

shop repair messages

     Fix the situation <Someone> reported where a shopkeeper removing a trap
from the shop doorway yielded "you see the shop door reappear" instead of
reporting about the trap.  It made sense if the door had been destroyed
but not when intact.

     For trunk only, try to fix up the shop repair message situation when
multiple repairs occur at the same time.  Some things were being treated
as mutually exclusive when they aren't.  This part needs more testing,
probably using a debugger to force multiple pending repairs to all occur
on the same turn.  At any rate, using wizard mode and hoping for some
simultaneous activity was ineffective.

vampires now shapeshift [trunk only]

- can shift into fog clouds, vampire bats, and vampire lords into wolves
- after being "killed" in shifted form, they transform back rather than get
  destroyed, and you must take them on in vampire form to defeat them
- can deliberately shift into fog clouds to pass under closed doors

cham changes (trunk only)

This is a foundation patch for patches to follow.
- use a full short index for mon->cham field.
- The current system of providing CHAM_XXX values
  was limited to the 3 bits allocated in the bitfield and invalidated
  save/bones if the field was expanded.
- The current system didn't provide an easy backwards  change
  if multiple monster types wanted to use the bit, there was a one
  to one mapping:  For instance, if you wanted a CHAM_VAMPIRE,
  and you wanted vampires, vampire lords, and Vlad to use it, you
  would have to have CHAM_VAMPIRE, CHAM_VAMPIRE_LORD,
  and CHAM_VLAD defined to achieve that with the one-to-one backward
  mapping.
- This new way just uses the mon[] index in the mon->cham field and
  eliminates the need for CHAM_XXX  (CHAM_ORDINARY is still used).
- no longer requires the cham_to_pm mappings

water flow into pits (trunk only)

water should flow into chasms from Drum of Earthquake.
Exploding wands of digging had been handled in the trunk earlier.

invisible troll revives and can appear visible
Play a character without see invisible. Wear speed boots. Generate a troll.
Zap it with a wand of make invisible. Kill it. Stand on the same square and
wait for it to rise from the dead. It will appear as a 'T'. Hitting it then
produces the normal "Wait, there's something here you can't see!"
[ incorporate slashem-Bugs-951439 fix ]

name followup (trunk only)

skipping stones (trunk only)

Allow a chance of rocks thrown over water to skip
in such a way that they could bounce right over a water
creature.

followup bit

potion of poison

<Someone> wrote:
> It is a little odd that, if you are poison resistant,
> potions of sickness can kill you if and only if they
> are blessed.

djinn/ghosts from potions

<Someone> wrote:
>It seems silly to have two flags being used for counting djinn and
>ghosts, now that there's mvitals.born...

This does not break save and bones compatibility in the 3.4.x branch,
it changes the code, but leaves the obsolete fields in flags.

djinn/ghosts from potions

<Someone> wrote:
>It seems silly to have two flags being used for counting djinn and
>ghosts, now that there's mvitals.born...

This does not break save and bones compatibility in the 3.4.x branch,
it changes the code, but leaves the obsolete fields in flags.

fire traps on ice

"<Someone>" on January 8, 2004, wrote:
> A Valkyrie on the Quest home level, wearing an
> amulet of magical breathing, enters a fire trap
> out on the ice:
>
>> A tower of flame erupts from the ice!
>> The ice crackles and melts.
>> You fall into the water.  You sink like a rock.
>> But you aren't drowning.  You touch bottom.
>> A cascade of steamy bubbles erupts from the bottom!
>
>Should the trap really be being triggered twice, once on ice and
>once underwater, when I've only moved onto the location once?

hearing a boulder fall

As From a bug report, if you couldn't see a rolling boulder
fall into a pit, you only heard the sound if you were blind.
Also fixes the article used in the message.

marilith thrusts

<Someone> reported:
>> The marilith wields 5 daggers!
>> The marilith thrusts her dagger.  The marilith misses.
> Shouldn't she thrust her daggerS?

Change to:
"The marilith thrusts one of her daggers." in that case.

C342-46: cleric cast lightning

Get rid of an old known buglist entry C342-46
> Cleric cast lightning doesn't blind as other lightning does

remove unused variables

"offering" lookup

     Fix the situation <Someone> reported where requesting information about
the not too unlikely word "offering" would match the "ring" quote.  I didn't
add a new quote for it but made "offer[ing]" and "sacrific[e|ing]" match the
existing altar quote.  I also added one small quote I've had laying around
for a while.

fixes3x.x

#U986: <email deleted> wrote
on Sunday, April 4, 2004 at 20:27:06:
> On occassion when restoring a game where the
> character is wielding Sting, floor glyphs
> will show up before the --more-- prompt.
> These floor glyphs usually correspond to the
> location of monsters (sometimes they are just
> cavern features such as walls).  Some of these
> floor glyphs are not in the character's line
> of sight upon restoring.

Also in this patch is a restore of Sting's ability
to glow blue.

polywarn followup (trunk only)

polywarn (trunk only)

This patch increments editlevel making existing save and bones files useless.

Add polywarn() code to grant the ability to detect certain monster
types while polymorphed into other specific monster types.

If you polymorph into a vampire or vampire lord, you are able to
sense humans.

And just for fun, if you polymorph into a purple worm, you are able to
sense shriekers :-)

more debug enlightenment

win32gui temporary build fix (from <Someone>)

> The trunk did not compile when STATUS_VIA_WINDOWPORT was set. > This patch fixes that (for the time being).

debug enlightenment follow up

enlightenment

Give more information about your attributes in debug mode
via Control-X.

I'd like to see some way of getting bits of this info to the
player during the game (from the Oracle or something),
but this patch keeps it limited to debug mode.

monsters using teleport traps
While trying in vain to find code that would cause the reported
priest-on-players-location behavior, I did find that the code to find
a usable teleport or similar trap was disallowing lots of locations due to
an && that should have been an ||.

U979 followup - mimic mimicking a boulder on Sokobon hole
The previous change only affected mimics that started mimicing after the
level was created.  This change tries to perform a similar behavior for
randomly placed mimics that are forced to mimic a boulder on special levels.
In this case, since the symbol is fixed and the location is "random", try
several times to find a non-trap location for such a mimic.