protection enlightenment (trunk only)

     Yesterday's change to have enlightenment give "you have a <small,
moderate,&> defense bonus" instead of "you are protected" would yield
"you have a small defense penalty" if the combined protection value (from
rings, divine gift, and spell) was 0.  This changes the formatting routine
to give "you have no defense bonus" in that situation, then changes the
caller to only display the protection/defense attribute when non-zero so
the "no bonus" case will never actually happen.

enlightment for protection and magic cancellation (trunk only)

     The bug report about losing/regaining the Protection intrinsic reminded
me of a couple of things.  First, as an intrinsic, Protection seems to be
completely useless and we ought to redo it.  Second, periodically people in
the newsgroup have complained about how it's nearly impossible to figure
out the important--possibly crucial--armor attribute of magic cancellation.
Wearing a cloak greatly increases characters' survival rates, but beyond
that, magic cancellation is just spoiler fodder.

     This doesn't do much about Protection other than to change "you are
protected" into "you have a <small,moderate,&c> defense bonus" similar to
how the attributes conferred by rings of increase damage and increase
accuracy are handled.  For magic cancellation, it adds new feedback:
  You are protected.  -- mc factor 3
  You are guarded.    -- mc factor 2
  You are warded.     -- mc factor 1
(with no extra feedback for mc factor 0, the normal naked state.  The mc 3
case might cause some confusion over the changed meaning of a previously
existing item, but I think it'll be ok and not need re-wording.)

fix [part of] #H103 - misleading prompt when choosing role,&c

     From a bug report, specifying role and race
along with invalid alignment for that role/race combination resulted in a
prompt of "pick the alignment of your chaotic human Valkyrie".  This fixes
that particular problem, but the role selection code is incomprehensible
and I don't have a lot of confidence about whether other combinations have
similar trouble.

     This also fixes an obvious typo in ok_align().  Unfortunately I can't
figure out what to do with the if-then-else block in root_plselection_prompt
which has identical code for its `then' and `else' halves (in the alignment
code that the new ok_align() test skips).

fix #H105 - inconsistent handling of "meditating" monsters (trunk only)

     From a bug report, monsters with the wait
strategy (described as "meditating" by stethoscope probing) could be
affected by music but left meditating.  Various wake up attempts shared
the same situation.  Finish waiting if the monster would have been woken
(or pacified).  I didn't search for places that diddle the msleeping bit
directly instead of calling one of the assorted wake() routines.

     A fair bit of this is making usage of DEADMONSTER() be consistent.
Sooner or later there'll be another monster movement overhaul and those
    if (DEADMONSTER(mon)) continue;
statements will all go away.  (Probably just wishful thinking.)

fix #H104 - misnamed high priestess

     When high priests have their affiliation suppressed to avoid giving
away which altar is which on the Astral level, the name formatting also
bypasses the code that converts "priest" into "priestess" for females.
(The bug report was about Moloch's high priestess; the occupant of the
Sanctum's temple gets similar handling to those on Astral.)

     Also a tidbit for a change made a couple of days ago.  Avoid using
"Manlobbi the invisible shopkeeper" or "Asidonhopo the newt" in the message
given when a shk refuses an attempt to be renamed via the 'C' command.

renaming shopkeepers and priests

     From a bug report, the 'C' command wasn't reporting that
"<shopkeeper> doesn't like being called names" even though the user's
supplied name was ineffective.  Same thing for temple priests and other
minion monsters; the name was accepted but didn't do anything.  Make such
monsters reject new names.

adjattrib() feedback (trunk only)

     Fix a bug described in the slash'em bugs page at Sourceforge.  When
attributes are undergoing adjustment (from drinking a potion of gain
ability, for instance), don't display "you feel wise" or "you feel weak"
messages if worn equipment is keeping the relevant attribute at some point
below max or above min and the current value doesn't actually change.
The old logic just checked whether you were at max or min and assumed that
when not, the value would be changing.  Now it checks whether the value
actually did change.  But it doesn't intercept attempts to go over max or
under min at the same point any more; I hope it hasn't introduced any new
bugs in the process.

shktalk patch - speech by polymorphed shopkeepers (trunk only)

     Add a patch attached to one of the bug reports sent by <email deleted>
which prevents shopkeepers who have been polymorphed into animals from
speaking.  Some messages are altered so that the player gets informed about
shop interactions without it seeming to be spoken by the shk, other messages
are suppressed outright.  I cleaned it up a bit (mostly formatting, but the
``getcad'' section seemed to have a logic error--using goto to jump into
the middle of an if-then-else is evil...) and implemented a TODO comment he
added (to use mbodypart() when second shopkeeper at end of game shakes his
head; also, skip that phrase if shk is in headless form--futility while
attempting to test this led to discovery of the misplaced parenthesis bug).

end of game shopkeeper messages

     Fix something I accidentally broke nearly three years ago (post 3.4.2,
so the bug appeared in 3.4.3).  A misplaced closing parenthesis caused an
in-sight check to always fail, so the "<shk> looks at your corpse, shakes
his head, and sighs" message when game ends would never occur.  That
situation is extremely rare anyway; it only happens after some other shk
has taken the hero's possessions.

elven boots

<email deleted> wrote:
> While levitating, I put on an unknown pair of boots.  They turned out to be
> elven boots.  I received the message, "You finish your dressing maneuver.  You
> walk very quietly."  Incidentally, I was hallucinating at the time.
>
> It seems to me that levitating individuals shouldn't be able to tell that they
> walk quietly.

player control of spellbook order (trunk only)

     Add the capability of sorting the entire spellbook by various criteria,
augmenting the existing ability to swap pairs of spells.  In the menu that's
put up for the '+' command, add a non-spell entry after the last known spell
        + - [sort spells]
Selecting that brings up a new menu

        View known spells list sorted

        a + by casting letter
        b - alphabetically
        c - by level, low to high
        d - by level, high to low
        e - by skill group, alphabetized within each group
        f - by skill group, low to high level within group
        g - by skill group, high to low level within group
        h - maintain current ordering

        z - reassign casting letters to retain current order

'a' corresponds to the normal ordering; 'b' through 'g' cause the order
to change, but during the current invocation of the '+' command only.
(Entry 'h' is a no-op, something aside from ESC to get out without doing
anything.  'a' is only a no-op if you haven't picked any of 'b' through
'g' yet.)  After making a choice, you're taken back to the '+' command to
view the spells in the requested order.  And once back there, you can pick
'+' again to come back to this menu, where picking 'z' will cause casting
letters to be shuffled such that present display order becomes the actual
spellbook order.  Newly learned spells get appended to the end as usual;
the most recent sorting order isn't sticky even if finished off with 'z'.

     No doubt seeing it in action will be clearer than this description.
This also updates the Guidebook to mention the spell retention field added
to the '+' menu some weeks back.

quest artifact handling (trunk only)

     When the hero receives the quest artifact "got it" message, set the
artifact's dknown bit in case the hero is blinded.  That message describes
the object by name, effectively the same as seeing it up close.  (This
would have prevented the "now wearing an Eyes of the Overworld" grammar bug
for monks but not for non-monks, so the previous fix is still necessary.)

Eyes of the Overworld grammar

     Putting on the Eyes while blind causes sight to be regained, which in
turn causes xname() to set the dknown bit and start using the previously
unseen object's name.  But obj_is_pname() was being called before xname in
the "you are now wearing ..." message, while dknown was still clear.  So
obj_is_pname thought the name was being suppressed and returned false,
resulting in "an Eyes" instead of "the Eyes".  Fix is to call xname first.

grammar bit

<Someone> wrote:
> You find an anti-magic field.
> Where do you want to jump?  (For instructions type a ?)
> You pass right over _a_ anti-magic field.

additonal oextra care

Be deliberately careful with copies taken of
oextra pointers and clear the pointer if it
truly is a redundant copy that will become
invalid if/when the original holder is deallocated.

add pickup_thrown option (trunk only)

     This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em.  It is
extremely useful while using ranged weapons.  When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]

add pickup_thrown option (trunk only)

     This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em.  It is
extremely useful while using ranged weapons.  When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
(Autopickup exceptions weren't around when the patch was first developed
and while those can be used for this purpose if you're willing to name
every object prior to throwing it, pickup_thrown is much more convenient.
Especially when you run out of weapons and resort to throwing pick-axes,
unicorn horns, and spare suits of banded mail at that floating eye who
rudely refuses to die.)  If you drop a previously thrown object (after
getting it back into your inventory again, of course), its was_thrown bit
will be clear and subsequent walking over it behaves in the regular
autopickup manner.  There's no special stacking handling; if a thrown
object lands on a compatable object and they stack, the combined stack is
subject to pickup_thrown handling.

     The original patch updated makedefs to add an entry for pickup_thrown
patch to the options list displayed by #version; I've left that out.  It
also cleared the was_thrown bit in the pickup code, resulting in being
sticky for boomerangs and Mjollnir (where throwing, catching, and then
dropping those would result in behaving as if they had most recently been
thrown rather than dropped).  I've moved that to the add-to-inventory code
instead to fix this.  The original patch also put the pickup_thrown bit
into iflags instead of flags in order to avoid invalidating save files;
I've moved it to flags where it belongs and added a patchlevel.h update.
I've also reworded the Guidebook entries slightly.  [The original patch
can be obtained from <Someone>'s "NetHack Patch Database" at
http://bilious.homelinux.org/ under the "browse" heading.  I didn't hang
on the exact URL; sorry.]

     I think objects stolen from the hero should have their was_thrown bit
set (or else add a new was_stolen bit, which seems like overkill) so that
recovering stolen objects will become simpler after the thief has been
tracked down and dealt with, but I haven't done that here.

xorn comment

Delphi follow-up 2 (trunk only)

oops, Pat pointed out that I altered the logic.

fixes typo

     Pointed out by <Someone>.

candelabrum in shop (trunk only)

     The code to have Izchak recognize the Candelabrum of Invocation
instead of just being uninterested in an item not stocked in his shop was
being skipped when the character is hallucinating.  Make it work for any
lighting store (slash'em sometimes has another candle shop, run by a
randomly named shopkeeper), and make it recogize Izchak even when
hallucinating.  Also, have him give a message about the need for 7 candles
if the candelabrum doesn't already have them attached.

Delphi follow-up (trunk only)

water vs acid

     Fix the bug From a bug report.alt.org server, where killing a monster by closing the
castle drawbridge resulted in a panic after the dead monster's possessions
were dropped into the moat and a potion of acid exploded in the process.
water_damage() deleted the object but had no way to tell flooreffects()
that it was gone, so flooreffects() couldn't tell its own caller not to
place and stack the object.  After that, a chunk of freed memory became
part of the floor objects chain and eventually triggered a panic which
tried to make a save file but whose reason didn't get logged properly.

Delphi msg (trunk only)

<email deleted> wrote:
> * Angering the Oracle then entering her room still gives
> "Hello, <Dudley>, welcome to Delphi!"

selling candelabrum in lighting store

<email deleted> wrote:
> * You can't sell a candelabrum (with candles attached) to a lighting store.

You still can't sell the candelabrum after this, but acknowledge
the situation by having Izchak say something unique.

set_corpsenm()

Provide a common routine that always does the right
thing with respect to timers and weight when altering
obj->corpsenm, and use it throughout the code.

#H85: create_object() bugs

From a bug report.c was first creating  a corpse
complete with revive timer if it was a troll, or without
a timer if it was a lizard or lichen corpse. Then it might
change the corpse type, leaving strange corpse
types that revived, or that lasted forever.

dungeon open failure

We've been getting numerous complaints from people
about "dungeon failure", often related to attempts
to start NetHack from within various zip utilities
that present a folder-like view.

The dungeon failure was actually misleading. The
real problem was a dlb file open failure, but the
return value of dlb_init() was not being checked
in pcmain.

This moves the dlb_init earlier in the startup,
checks for failure, and provides some feedback
around the common zip utility problem for win32.

more rumors processing (trunk only)

     This fix should work for both DLB and non-DLB without forcing binary
mode for the latter.  And it should continue to work even if we later
decide to force that mode (which I think we should do...).  Use actual
file positions to calculate the size of the true and false sections,
rather than counting the bytes of each rumor (that counting has been left
in place but it gets overridden now.)  Those two sizes will be bigger on
platforms which use CR+LF line ends and maintain dat/rumors as non-DLB
text file.  But due to the way that nethack uses the sizes, such size
differences don't matter.

     The branch variant shouldn't need any corresponding fix.  It uses
the counting method when the output is binary, where the accumulated
value is accurate, and the check end-of-file shortcut when using text,
which should not be affected by stdio converting CR+LF into \n for text
input and back to CR+LF again for text output.  (The original bug was due
to starting out with the EOF shortcut when input had CR+LF line ends, but
then writing less data due to binary output keeping just LF instead of
putting CR back.)

win32 Makefile updates

- DLB wasn't defined during util builds, including makedefs.
- spotless wasn't spotless

rumor consumption during level creation

     I've forgotten who pointed this out recently, but the hero was having
wisdom exercized (if true rumor chosen) or abused (for false one) whenever
level creation made a random floor engraving which used a rumor for its text.

fixes entry for rumors fix

more thorough rumor processing (trunk only)

     To fix the gibberish rumor observed by at least a couple of players on
Windows (where if rumors.tru had <cr><lf> line ends and DLB was defined,
makedefs built a file that caused nethack to end up in the wrong place when
it reached EOF and tried to jump back to the first false rumor), change
the way that makedefs builds the rumors file.  It now will collect more
information about the true and false rumors.  Instead of one hex value on
the second line, there are nine values (three groups of three).

1,2,3;4,5,6;7,8,9

1 = number of true rumors; not previously collected and not currently used
2 = size in bytes for all true rumors (in decimal, as is #1)
3 = offset to first true rumor (in hexadecimal; not previously collected)
4,5,6 = same as 1,2,3 but for the false rumors section
7,8 = always 0 (imaginary third section has no entries, no size)
9 = offset to end-of-file (could be used for sanity checks; currently isn't)

Adding #2 with #3 yields #6; adding #5 with #6 yields #9.  The old format's
lone entry was the same as the new format's #6.  #2, #3, and #5 are values
which nethack was previously calculating on the fly after opening the file.

     This also extends rumor_check() a little bit (displays the last rumor
for both sections in addition to the first), but I think it can probably
now be demoted to ``#if 0'' and removed from the extended commands list.

The last straightforward additions.

Now I have to figure out which of the shifts from here to there we
want from the <email deleted> submissions.

And another handful of submitted entries.

work around win32 rumor issues (#H80)

With makedefs changed to open the files as binary, the
rumors generation and retrieval seems to work consistently.

win32tty
T start=000067 (000043), end=020658 (0050b2), size=020591 (00506f)
F start=020658 (0050b2), end=043641 (00aa79), size=022983 (0059c7)
T 000067 A blindfold can be very useful if you're telepathic.
F 020658 "So when I die, the first thing I will see in heaven is a score list?"

win32gui
T start=000067 (000043), end=020658 (0050b2), size=020591 (00506f)
F start=020658 (0050b2), end=043641 (00aa79), size=022983 (0059c7)
T 000067 A blindfold can be very useful if you're telepathic.
F 020658 "So when I die, the first thing I will see in heaven is a score list?"

wizrumorcheck update for trunk

debug mode #wizrumorcheck

Provide a command to easily verify that the rumor true/false
boundary offsets are correct for the rumors file.
If the boundary is pointing mid-line, the rumor at the boundary
won't decrypt properly.

guidebook autopickup_exceptions

autopickup_exceptions is no longer in the experimental section of config.h

Yet more of the <email deleted> entries.

And another batch from <email deleted>

The next few from <email deleted>

The next <email deleted> batch.

Another batch from <email deleted>

And some space removal after I noticed some on incoming entries.

gcc compilation warning bits
some rather complex boolean operations needed more parentheses to avoid
warnings.  I think I put them in the right places.
A couple other items: naked assignments in if stmts, and an extra function decl

fix W343-1 open win32 bug from known bugs page

W343-1 Redirecting score output through a pipe doesn't work.

Next batch from <email deleted>

First batch from <email deleted>

Update dungeoneers for data.base entries.

digging land mines sequel (trunk only)

     Axes can't dig through the floor, but attempting to dig down with one
shouldn't just "scratch the floor" if there is an armed land mine present.
Have it set off a land mine or bear trap, in addition to the possibility
of chopping your way out of being stuck in a bear trap (a recent change).

dungeon overview build fix

experimental - dungeon overview (trunk only)

Add Hojita Discordia's Dungeon Map overview as
conditional code for experimentation and testing.
Everything is guarded by
#ifdef DUNGEON_OVERVIEW
#endif

The notes that accompanied the original patch follow.

Dungeon Map Overview Patch for Nethack 3.4.3
Version 3
=============================================================================
Changelist:
    v3: Changed #level to #annotate to avoid #levelchange collision.  Fixed
        handling of elemental planes and astral plane (oops).  Changed
formatting to be slightly closer to print_dungeon()'s.  Should be
"final" version for 3.4.3.
    v2: Added tracking of trees.  Changed ctrl-m command to ctrl-o.  Portals
        displayed as "sealed" instead of "closed".
    v1: First release.
    (Note: all versions are mutually save compatible.)
=============================================================================
This patch creates a dungeon map overview that is recorded as the player
explores the dungeon.  I was tired of returning to a game a few days later
and having no idea what the dungeon looked like.  Trying to name pieces
of armor with shorthand didn't work so well as an intermediate solution
either, especially around nymphs.

It can be assumed that this map is in the mind of the hero and thus
can't be stolen, can be read when blind, or when buried, or when the hero
doesn't have any hands, or eyes, or hands free, or...etc. On the other hand,
this implies that the hero doesn't remember all of the details ("a fountain",
"some fountains", "many fountains") and that the map is subject to amnesia
when applicable.

This overview tracks fountains, altars, stores, temples, sinks, thrones,
trees, and dungeon branches.  It attempts to not spoil the player nor
reveal more information than the hero knows.  For this reason, it only
tracks dungeon features found in the guidebook and dungeon branches.

This patch breaks save file compatibility.  Sorry.

Added commands
=============================================================================
#overview (ctrl-o, if not in wizard mode) - displays overview
#annotate (ctrl-n, if using numpad) - names current level

Example Output From #overview
=============================================================================
The Dungeons of Doom: levels 1 to level 15
   Level 1:
      A fountain
   Level 3: (My stash.)
      An altar, some fountains
      Stairs down to The Gnomish Mines
   Level 7:
      Many fountains
   Level 8:
      Stairs up to Sokoban, level 7
   Level 15:
      A general store
      Sealed portal to The Quest
The Gnomish Mines: levels 4 to level 7
   Level 7: <- You are here
      Many stores, some fountains, a temple

More Details
=============================================================================
The overview shows only levels that have anything interesting to display and
doesn't show branches that don't have any interesting levels.

To avoid the map revealing more information than the hero knows, the overview
only displays things that the hero has seen or touched.  (If the hero
blinds herself, levitates above a known fountain, and obliterates it with a
wand of digging, the overview will still say that there is a fountain.)

This is done, sadly, by adding 6 bits to the rm struct to track the last
known dungeon type.  On the other hand, this change could potentially allow
a window port to do something like drawing an item and a fountain on the same
square.

Things That Could Be Better And Maybe Some Feedback Would Help
=============================================================================
"<- You Are Here" is pretty goofy
    -...but an indicator of some sort is nice.
=============================================================================
Many thanks to all the kind folks on r.g.r.n. who had very good feedback
about this patch, in particular L (for the trees), <Someone> Papaganou (for the
#annotate suggestion and some formatting feedback), and <Someone> (for the suggestion
of just overriding ctrl-o instead of using the very broken ctrl-m.)
=============================================================================
20060311. Hojita Discordia. (My usenet email is bogus. Sorry.)

comment bit (trunk only)

Starting with a formatting sweep, including adding Pat's [] breaks.

fix #H79 - steed disintegration

     From a bug report, a steed hit by disintegration
breath survived via life-saving, but the program was confused about whether
the hero could still ride and issued some impossible warnings.  The code
to disintegrate a monster's inventory didn't bother to unwear worn items as
it destroyed them, presumeably assuming that the monster was sure to die,
so steed was left with a flag bit set claiming it was saddled even though
the saddle was gone.  This fixes that, and the rider will end up being
dismounted as the saddle gets destroyed, regardless of whether the steed
ultimately survives.  [Since the steed is still present at the time of
dismounting, the hero will get bumped to some other location, possibly to
the next spot about to be hit by the same black dragon breath attack which
just vaporized the steed.  That's suboptimal, to put it mildly....]

     I couldn't test the circumstances of the original report.  Post-3.4.3,
ki-rin has been marked no-hands and is no longer capable of wearing armor
or amulets.  I looked to see whether any other potential steed could wear
an amulet of life-saving and couldn't find one.  But the original bug also
applied to conferred properties of special armor worn by non-steed monsters
too, so the fix was needed anyway.

     The branch and trunk patches are different.  For the trunk, I moved a
big chunk of code out of buzz() into a seperate routine.  That actual fix
is the same in both variants.

more munstone fixes

      Move part of the recent "munstone fixes" patch to the branch code
since one of those fixes prevents accessing freed memory.  The part that
lets monsters eat tins of lizard meat or tins of acidic monsters in order
to get the same benefit as the corresponding corpse has been left out.

another safe_oname() bit (trunk only)

safe_oname (trunk only)

There were routines that were passed the
object name as an argument.  Before the oextra
patch, ONAME() always returned a valid pointer
to a location within the obj struct. The oextra
patch worked around those cases by
using a temporary variable that was either set
to ONAME (if the obj passed the has_oname() test),
or to ""  (pointer to an empty string) if no name was
present.

Since that might be a common thing to do, provide
the safe_oname() routine that you can use as a
function parameter without having to worry about
about whether ONAME(obj) is valid, and without
the need for the temporary variable.

increment editlevel

That last merge update should have included this.

oextra follow-up - merging (trunk only)

It seemed inappropriate to allocate and tack on an oextra
structure just to mark it as unmergable, and the oextra
struct itself wouldn't be released until a save/restore took
place.

This uses one of the freed up oattached bits to prevent the merge.

oextra obj.h follow-up (trunk only)

Just add some notes to obj.h around oextra.

omailcmd (trunk only)

     The revised newmail() wouldn't compile (Strncpy doesn't exist, `buf'
was an array of pointers rather than of char).  Simplify it substantially,
and adjust the one caller (vms) that relied on the old convoluted bit.

drum of earthquake follow-up

code change - oextra

move oattached and oname and other things that vary
the size of the obj structure into a separate
non-adjacent oextra structure, similar to what has
already been done for mextra. The obj structure
itself becomes a fixed size.

New macros:

#define ONAME(o) ((o)->oextra->oname)
#define OMID(o) ((o)->oextra->omid)
#define OMONST(o) ((o)->oextra->omonst)
#define OLONG(o) ((o)->oextra->olong)
#define OMAILCMD(o) ((o)->oextra->omailcmd)

#define has_oname(o) ((o)->oextra && ONAME(o))
#define has_omid(o) ((o)->oextra && OMID(o))
#define has_omonst(o) ((o)->oextra && OMONST(o))
#define has_olong(o) ((o)->oextra && OLONG(o))
#define has_omailcmd(o) ((o)->oextra && OMAILCMD(o))

changed macros:
has_name(mon) becomes has_mname(mon)  to correspond.

The CVS repository was tagged with
NETHACK_PRE_OEXTRA
before commiting these, and
tagged with
NETHACK_POST_OEXTRA
immediately after. The diff
between those two tags is this oextra patch.

The associated mail daemon changes to use an oextra
structure instead of a hidden command located in the
name after the terminating NUL, have not been tried
or tested.

hostile prisoner chat

<email deleted> wrote:
> * #chatting to hostile prisoners gives "This will teach you not to disturb me!"
> This only makes sense for djinn and water demons.

I don't have a clue what they should say, this only deals with
what they shouldn't say.

drum of earthquake - monster portion

<Someone> wrote:
> When applying a drum of earthquake, should you "fall into a chasm" if
> you're already at the bottom of a pit? (Likewise monsters.)

monster already in a pit won't "fall into a chasm" from drum of earthquake

drum of earthquake - hero portion

<Someone> wrote:
> When applying a drum of earthquake, should you "fall into a chasm" if
> you're already at the bottom of a pit? (Likewise monsters.)

hero already in a pit won't "fall into a chasm" from drum of earthquake

munstone fixes (trunk only)

     From a bug report, a monster who eats a lizard
corpse in order to cure confusion was treated the same as one who did so
to cure petrification, losing intrinsic speed in the process.  In the same
report by <l>, monsters wouldn't eat lizard corpses to cure being stunned,
and those who ate them for another reason weren't cured of stunning, even
though the hero gets that benefit.  While fixing those, I added some code
to let monsters who are carrying tins of lizard or acidic monster use them
if they're also carrying a tin opener, dagger, or knife.  I don't think
any monsters except for nymphs are willing to pick up tins, so it won't
have much effect.  It now works for nymphs though.

     Examining the code while testing showed that mon_consume_unstone()
has been accessing the potion (acid) or corpse (lizard or acidic monster)
after the item had been used up, so that has been fixed too.  I never saw
any detectable problems due to this, but folks using a debugging malloc
implementation which overwrites freed memory may have not been suffering
collateral acid damage or receiving intended confusion cure, or perhaps
did get either or both of those effects when they shouldn't have.  Since
it only applied to monsters it wouldn't have been easy to observe.

don't reveal surface when Blind and levitating

<email deleted> wrote the following on April 10, 2006:
> When blind and levitating, you can produce a message - "You try to feel what
> is lying here on the ice. But you can't reach it!" - which reveals too much
> about the terrain below you.

digging land mines & bear traps (trunk only)

     <Someone> suggested that digging down on a land mine with a pick-axe ought
to set if off.  I agree; this implements that and also for bear traps.  In
the bear trap case, if you dig down once trapped, you will destroy that
trap explicitly rather than replace it with a pit, so it's now possible to
escape from one without leaving another trap in your wake.  Once the bear
trap is gone, further digging there will make a pit as usual.  While stuck
in one, digging down poses a modest risk of harming yourself.

|You now wield a pick-axe.
|You start digging downward.  A bear trap closes on your foot!
|You start digging downward.  You destroy the bear trap with your pick-axe.
|You continue digging downward.  You dig a pit in the floor.
|You start digging downward.  You dig a hole through the floor.
|You fall through...

[It seems a bit strange that finishing a pit discards all digging context,
so that resuming within the pit in order to make a hole "starts" digging
rather than "continues" it.]

     Digging down with a wand or spell will disarm these two types of traps
and then leave the corresponding object (which may or may not fall through
the resulting hole, like any other object there).  Digging to the side via
magic while trapped in a pit will also disarm such traps when it encounters
them.  (When not in a pit, a digging beam which simply passes over an armed
bear trap or land mine won't have any effect on the trap.)  Digging to the
side via tool behaves somewhat oddly ("no room for the rubble"?) and will
probably need some tweaking before eventual release; at present it doesn't
reach adjacent traps so didn't need any land mine or bear trap handling.

     I put the fixes entry in the new features section.

silver vs poly'd hero (trunk only)

     <Someone> reported that thitu() was adding d20 damage for silver object
hitting silver-hating hero even though all the callers were using dmgval()
which also does that, resulting in doubled silver bonus/penalty.  This
fixes that (including for boomerangs thrown by player, which weren't using
dmgval(), to handle a hyptothetical silver boomerang).  While testing it,
I noticed that there was no "the silver sears your flesh" message when a
monster hit you with a wielded silver weapon, so this fixes that too.
(How did we miss that?  And how did <Someone>? :-)

autopickup during failed #untrap attempt (trunk only)

     From a bug report, moving into a trap
during a failed untrap attempt didn't autopickup any objects there or
report about objects which aren't picked up.  Although that appears to have
been intentional, change move_into_trap() to behave more like a regular
move.  (I wrote this bit of code and don't remember whether the no pickup
aspect was deliberate; I suspect it might have been to avoid the redundant
"there is a trap here" message which you get when pickup checking is done
but not everything on the spot gets picked up.  This patch suppresses that
message.)

main() reorganization (trunk only)

     Move some internals-related code out of port-specific main so that
it isn't duplicated a bunch of times.  One minor side-effect of this
change is that if you auto-pickup something at the very start of a game,
it will happen after any full moon/new moon/Friday 13th message rather
than before.  There's a second change for some:  the shared main() used
by several of the micro ports had a small difference in game play--if you
saved a game while on an engraving, it would automatically be read when
you resume--that will now occur for everybody [Elbereth weenies rejoice!].
pcmain() was also calling update_inventory() at start of play.  That's
unnecessary for new games, where inventory initialization triggers a call
to it for each item added to your pack; but I wasn't sure about restored
games, so everybody gets it there now.

     The Mac and BeOS ports evidently haven't been touched it some time;
they still referenced flags.move which got replaced by context.move quite
a while back.  The Windows GUI code has a declaration for mswin_moveloop()
which appears to be non-existant, but I left it alone.  I assume that the
Qt interface uses the existing main() routines; at least I couldn't find
any start of game code specific to it.  vmsmain's revised main() is the
only one which has been tested.

#terrain (trunk only)

     I've been using this for a while; it is occasionally handy.  #terrain
is a new wizard mode command which brings up a text display where the map
topology is revealed, similar to the obscure #wmode command but showing
different information.  Also, #wmode has been tweaked a little so as to
actually overlay the tty-mode map exactly, rather than being off by one
line and one column.  (That shouldn't really matter for other windowing
schemes where the map and a text rendition of it aren't very likely to
have a given location be displayed at the exact same screen position.)

     The line of formatted flags info below the terrain display probably
belongs in a separate debugging command altogether where it wouldn't have
to be displayed in such a terse fashion.

shattering monster's weapon stack

     Something I encountered while playing slash'em a while back, but
relevant to nethack:  "Its orcish spears shatter from the force of your
blow!".  I was using a two-handed weapon (at skilled or expert level) to
fight an invisible monster which was wielding a stack of multiple spears
(slash'em gives them out in groups of 3 for monsters' starting inventory).
After killing it, I found 2 orcish spears along with an invisible corpse
of somebody-or-other the Kobold King.  The message suggested that the
whole spear stack had been destroyed (and the weapon shattering code in
hmon_hitmon() clearly expects that to be the case), but only one of them
had actually gotten used up.

     I can't recall whether "shatter" was actually given as singular or
plural at the time; nethack handles that aspect correctly.  Only object
destruction needed tweaking.

swallowed time (trunk only)

     From a bug report, making engulf time longer for high AC
didn't make sense for non-digestion attacks:  taking longer to die from
being digested (high AC lets you last longer there) is much different from
being stuck inside a vortex or elemental and suffering extra buffettings
or whatever.  Calculate swallow time differently for non-digestion than
for digestion.  (The adjustment based around level 25 doesn't make much
sense either, but I left that in.)

     If you survive total digestion via life saving, you get a message
about the monster not liking your taste.  I don't think that's appropriate,
but haven't tried to figure out how to fix it.

eating gold in front of the vault guard (trunk only)

<email deleted> wrote:
> Eating gold in a vault (or polymorphing a pile of gold into 1 gold piece)
> doesn't anger the guard.

This addresses the eating part of that report, but the hero
has to get caught doing it.

wording bit in fixes35.0

clear pits in temporary corridor

From a bug report, then leave the corridor (causing it to
> vanish), the pit will be embedded in rock instead of being removed.

clear any pits that the hero digs in the vault guard's temporary corridor

prevent possible minor MAIL abuse

<email deleted> wrote:
> * MAIL Abuse: one can polymorph into a gelatinous cube, send themselves lots of
> scrolls of mail, and eat them, gaining free nutrition.

digging conjoined pits follow-up (trunk only)

Pat Rankin wrote:
>      Isn't an array of booleans overkill?  A single byte bitmap
> could achieve the same result.

vms Makefile bit

Old copy/paste typo.  This alternate target obviously doesn't get much use.

wizard mode level teleport (trunk only)

     Responding with '?' to the "what level?" prompt when using ^V in
wizard mode brings up a menu of special level destinations that lets you
move across dungeon branches.  But getting in and out of Fort Ludios
didn't work, and jumping to the endgame forced you to arrive on the Plane
of Earth.  Now Fort Ludios will not be selectable in the menu until after
the portal ordinarily used to reach it has been created (so you'll need a
level between Bigroom and Medusa with a vault on it to be created before
you can bypass the magic portal and jump directly to the Fort), and you
can go directly to any of the elemental planes, including Astral, without
stopping at Earth first (the Wizard will be there to greet you, whichever
level you pick).  Also, this limits the menu to endgame entries once you
are in the endgame.  (Previously, picking a non-endgame level would yield
"you can't get there from here"; you can still get that, if you really
want to see it for some reason, by giving a destination level number
outside the range of -1 to -5 instead of using the menu.)

     I hadn't realized that this feature has been around since 3.4.2 until
I couldn't find any new feature entry for in the current fixes file....

chameleon/genocide fix (trunk only)

     While testing some pending teleport changes, I was baffled by having
my adjacent pet sometimes vanish when accompanying me on a level teleport.
Tracing through parts of execution:  keepdogs() kept it; losedogs() called
mon_arrive() which called place_monster() for it, but then right after that
kill_genocided_monsters() removed it.  Turns out that `kill_cham' was left
uninitialized for the first iteration through the fmon loop (and pet had
always just been inserted as first entry of the fmon list).

     No fixes entry; this revises a post-3.4.3 revision.

digging conjoined pits (trunk only)

This one turned out to be more effort than I had
originally anticipated.

We had a bug report requesting that zapping a wand of digging
laterally while in a pit should dig beside you. That seemed
like a reasonable enough request, but this ended up with
the following results:
- needed to check where this should not be permitted, or at
  least where there should be special-case code because there is
  something such as furniture on the surface above the dig
  point.
- now tracks conjoined pits through new fields in the trap
  structure, hence the pathlevel increment. The array of
  8 boolean values represents each of the 8 directions
  around a pit.
- Previously, pits could be adjacent to each other as two
  individual pits, in which case moving between them
  results in a fall as you went into the next pit. That
  behavior is preserved.
- Pits created either by zapping a wand of digging
  laterally while in a pit, or by "clearing debris"
  between two adjacent pits via a pick-axe, sets the
  conjoined fields for those two pits. You cannot
  create a brand new adjacent pit via pick-axe, only
  with the wand.
- The hero can pass between conjoined pits without
  falling.
- dighole() was hijacked for adjacent pit digging,
  so the ability to pass coordinates to it and
  its downstream functions was added (dig_up_grave()
  for example). dighole() does pretty much everything
  appropriately for this adjacent digging, more so
  than calling digactualhole() directly.
- moving into a conjoined pit that has spikes still
  does damage, but less so that "falling" into the
  spiked pit, and you "step on" the spikes rather
  than falling into them.
- Not done: should pits with the conjoined fields
  set be referred to as 'trenches' rather than pits
  in messages and identifications?

digactualhole() bit

I'm pretty sure this check at_u should be included since x,y
can be passed to digactualhole().  The lack of any related
bug reports suggest that at_u is currently always
true for any code that calls digactualhole().

dungeon tidbit

     Nothing actually uses the s_level.flags.rogue_like flag, but since the
dungeon compiler is prepared to handle it we might as well have it do so.

leather spellbook build warning cleanup

The tile was not adjusted for the leather -> leathery change.

cancelled nurse #chat

On May 17, 2005, <email deleted> wrote:
> Cancelled nurses shouldn't say "Relax, this won't
> hurt a bit."

remove hard-coded cmd letters in feedback (trunk only)

chameleon behaviour

- restore intended behaviour of kill_genocided_monsters().
  It has been incorrect since  the chameleon overhaul in June 2004.
- eliminate CHAM_ORDINARY and use NON_PM instead.

filling antholes

     From a bug report:  when creating a
level, anthole rooms can be generated even when no ants are left, unlike
beehives which get suppressed once killer bees are gone.  Also, if some
ants are available but the type chosen for the current level isn't (in his
case, soldier ants had been genocided), the anthole was filled will random
monsters instead of picking another type of ant.  This fixes both issues.
Random monsters will only occur if the last type of ant gets used up while
filling an anthole that was started when some ants were available, same as
how monster generation for beehives and barracks works.

wand of locking message (trunk only)

<email deleted> wrote:
> BUGS TO REPORT:
>
> * Zapping a wand of locking at an open door with an object on it probably
> shouldn't give a "Something's in the way." message - especially if the wand is
> unidentified.

avoid "Something's in the way" message with unidentified wand of locking

broken wand of striking vs door (trunk only)

<email deleted> wrote:
> * Doors absorb the blast of a broken wand of striking. What's more, the message
> reads "The door absorbs your bolt!" rather than "blast".

passes wand type to explode() as a negative value for the case
where the wand type isn't mapped to an AD_* explosion type.

Then explode() converts it to a positive and passes it to zap_over_floor().

magicbane grammar

I don't know for sure what all the possible values of hittee passed to
Mb_hit() are, but this checks to see if it matches the name of the
mdef monster and forces the word "is" if it does.

confused scroll of light follow-up (trunk only)

Provide an opportunity to name the scroll when known is not set

minor scroll overhaul (trunk only)

     The recently revised scroll of charging left out making it become
discovered.  When fixing that I decided to remove all the early returns
from seffects(), so that its logic is easier--at least for me--to follow.
I think the return values of seffects(), chwepon(), and the various
xxx_detect() routines are backwards (True denotes failure, False indicates
success), but they're all consistent with each other so I left those alone.

luck confusion

     Remove a couple of false comments about Luck, and an unreachable
switch case based upon them.  I don't know if the comment in you.h was ever
true, but it was false by the time Kevin brought across assorted changes
from slash'em however many years ago.  Full moon does not change the range
of possible Luck values, and ``rn2((Luck + 6) >> 1)'' produces a value
between 0 and 8 for prayer result, never 9.  Natural luck is always within
the range of -10 to +10, and extra luck from carrying blessed or cursed
luckstone can add or subtract another 3.  Full moon and Friday the 13th
change the equilibrium point for luck timeout but do not change the overall
range of possible values, which remains at -13 to +13.

doorless doorways (trunk only)

     Simplify some door checks.  No change in game behavior.

typo