more #H267 - cursed figurine auto-activation

     Figurine activation timer had the same problem as burning objects:
it didn't clear up worn object pointers when destroying the object.

fix #H267 - wielded object burning up panic/crash

     From a bug report:  having a lit
candle or potion of oil be wielded or "worn" as alternate weapon or quiver
at the time it finished burning up would leave a stale worn object pointer
which could trigger a panic or crash.  Need to call useup() instead of
obj_extract_self()+obfree() for objects in inventory, similar to the way
hatching eggs are handled.

fix #H265 - applying wielded towel fails with odd message

     From a bug report:  attempting to apply
a towel which is currently "worn" in the weapon, alternate weapon, or
quiver slot fails with "you cannot use it while you're wearing it".  The
message sounds odd when the towel is wielded, and there's no reason why
you shouldn't be able to use it when it's in any of those weapon slots.
Compare it with current blindfold rather than checking its owornmask.

re-do the #H260 lava fix

     Instead of duplicating the bits of spoteffects() which are relevant
to pools of water and lava when standing still, split spoteffects in two
in order to call the relevant half directly.

H264 - FreeBSD compilation bit
I cannot currently verify this myself, but it seems likely to be correct.

fix #H260 - escaping lava let you stay there indefinitely

     <email deleted>, escaping from being stuck
by lava via jumping--or simply walking--got you out of the lava while being
at the same location.  You could then stay there for as long as you liked
without falling back in.  This makes a lava and water check on turns where
time passes but hero hasn't moved, performing a subset of spoteffects().
I think the water case only matters when using wizard mode to wish for a
pool or moat, which gets created at hero's feet without making him fall in
(unlike wishing for lava, where hero does immediately fall in).

held artifacts evading your grasp (trunk only)

     From a bug report, trying
to invoke a wielded artifact after changing alignment resulted in "the
<artifact> evades your grasp" but it remained wielded, contradicting the
message.  This adjusts the message in touch_artifact() if the object is
already in inventory, and adds retouch_object() to handle cases where
failing to be able to touch ought to force unwearing/unwielding.

fix #H254 - stethocoping mimics (trunk only)

     From a bug report, applying a stetoscope to
a mimic which was hiding would report that mimic's stats but not bring it
out of hiding, unlike the behavior for other types of hiding monsters.

more score file processing

     Reduce the amount of stack space needed for the new local variables in
readentry() by about half, from 3.5K to a bit over 1.75K.  Also, reorganize
writeentry(), mostly hiding NO_SCAN_BRACK handling from the actual output.

fix #Q101 - score file bullet proofing

     Guard against buffer overflows when reading in score entries, in case
`record' has become corrupted or been maliciously modified.  This addresses
the part of "#Q101: Security bug in nethack 3.4.3" that we have control
over.  A Gentoo bug tracking discussion pointed out to us by <email deleted>, describes how that particular Linux
distribution makes users be members of the games group, allowing them to
modify files in nethack's playground directory when it has been set up in
the usual ``setgid games'' manner, thus making score processing in that
environment be vulnerable to buffer overrun exploits.

truncating string copy

     The majority of our calls to strncpy are in the form
  (void) strncpy(dst, src, n);
  dst[n] = '\0';
so add a new routine, copynchars, which does that.  A few calls care
about strncpy's return value and at least one relies on it only copying a
substring without also terminating the output, but most don't care about
either and none seem to care that `n' ought to have type size_t instead of
int.  The new routine matches our usage better, but I haven't gone through
to change the existing strncpy calls.

revised ascension bonus (trunk only)

     Part of the final score is doubled for ascension.  Some players use
helm of opposite alignment in order to offer and ascend at the first astral
altar they reach.  This limits the score doubling to ascending with your
original alignment intact, penalizing (for the subset of players who care
about score) alignment manipulation.  Converting to a second alignment and
then using a helm of opposite alignment to switch back and offer to hero's
original deity yields a smaller bonus (one-and-a-half instead of doubling).
Offering to either of the other deities (either via permanent conversion
or temporarily switching via helm or both) gets no score bonus.

pets accompanying ascension or dungeon escape

     There was a report recently about "<pet> is still eating" coming out
on the console at end of game for player using X11 or Qt.  That happened
because the end-of-game pet handling takes place after the message window
has been closed.  It won't happen with the dev code any more because eating
no longer prevents pets from accompanying on final ascent or escape.  But
a pet carrying the Amulet should still fail to tag along and yield similar
result.  However, levl_follower() was changed (probably by me...) to have
pets not attempt to follow when they carried the Amulet, rendering code
in keepdogs()--which reported them as being confused--unreachable.  This
reverts levl_follower() to have Amulet-carrying monsters other than the
Wizard try to accompany the hero during level changes (and keepdogs still
prevents them from succeeding).  It also reorganizes keepdogs() a bit,
giving trapped followers an extra chance to escape from their trap and
preventing those who fail that chance from tagging along (previously,
non-pets ignored being trapped).

     After doing that, I got tty to behave similarly to the X11/Qt report:
a message behaved strangely.  In my case, it was delivered between a pair
of clearings of the screen and only visible by using terminal emulator's
scrolling buffer.  I think there's a wait_synch() missing somewhere, but
haven't tried to figure out where.  Instead, this makes the end-of-game
call to keepdogs() take place sooner, while pline() still works normally.

decl.{c,h} bookkeeping tidbit

     Move the declaration of `current_wand' to where the other struct obj
pointers are, after decl.h's `#include "obj.h"'.

 questpgr followup

questpgr support for special level arrival messages (trunk only)

     Suggested by <email deleted>.  The level compiler allows
MESSAGE directives to provide text given upon initial entry to particular
levels.  Modify the code that delivers them to support quest pager text
substitution.  It could also be tweaked to support deliver-by-popup-window
in addition to deliver-by-pline, but I didn't go that far.

     He also suggested revising the message for the Plane of Air, but it
seems ok to me.  Instead, I've changed the message for the Astral Plane to
announce that it holds "the High Temple of <your deity>" rather than the
quite lame "the High Temples of the aligned gods".

shop bones

     Dying at a shop doorway, or at the free spot one step in, while not
owing the shopkeeper anything would yield "<shk> gratefully inherites all
your possessions" but leave those possesions where the next hero could
just pick them up for free.  Move them all the way inside the shop, as
happens when the hero dies while owing the shk.  Also, if hero has gold
left after shopkeeper takes any payment owed, force it to go into shk's
inventory instead of having it end up in the pile of other stuff.

     finish_paybill() duplicated much of drop_upon_death(), but not the
two-weapon hack to avoid curse() causing hero's secondary weapon to be
dropped while in the midst of removing it from inventory (but unlike the
old 3.4.1 panic for that, this one just triggered a warning about nonzero
worn mask).  It also lacked the named fruit fixup, whatever that does.
Make finish_paybill() call drop_upon_death() instead of copying it.

hangup revisited (trunk only)

     More SAFER_HANGUP tweaking.  Delay its kicking in until main command
loop has been reached, and shut if off again once program is terminating.

wizard mode wishing - moat & traps

     When wishing for terrain, allow type "moat" as well as "pool".  And
when wishing for a trap, verify that trap creation succeeded instead of
always reporting that the requested type was made.

exploding potion of acid left in bones

     Noticed while looking at the dipping code:  #dip at a pool location
gives the chance to dip into the pool, and dipping a potion of acid into
such causes the acid to explode, causing damage and posibly killing the
hero.  Use-up handling was being done after the dip had finished, so the
potion would remain in final inventory during disclosure and end up in
the resulting bones file if there was one.

mind flayer vs ghost (trunk only)

     There's newsgroup discussion about a mind flayer sucking the brains
of a ghost, plus speculation that the fix for C343-121 has already taken
care of it.  I agree with them that ghost's brains are too insubstantial
to be hit by brainsuck damage from mind flayers' tentacles.  C343-121 is
vague enough to cover this; the corresponding fixes entry was more specific
and is augmented here.

saved game memory initialization (dev only)
Qt windowport crashed on startup because a couple alloc() calls in files.c
were not zero'ing out the memory afterward.  This resulted in uninit'd
memory access if there were no saved games.  This bug is in new dev code.

fix #H248 - 'speed monster' zap message not always necessary

     From a bug report:  zapping wand
of speed monster (or slow monster) at an immobile monster would give the
usual '<mon> is moving faster" (or slower) message even though the monster
couldn't move at all.  This fixes that for monsters who can never move
and also for monsters who are temporarily paralyzed or asleep, although I
wonder whether speed change magic ought to also snap the latter out of it.

status hilite bits
I noticed an unused array and missing ifdef in generic hilite code.

directions (trunk only)

     Some groundwork useful for the interface code I've been working on.
If we already have some direction to name-of-direction code somewhere, I
couldn't find it.

couple of #tipping bits (trunk only)

     Adjust some post-3.4.3 code.  Give feedback if you try to use #tip
on a statue--since it's a form of container, simple "nothing happens"
seems inappropriate.  (Unfortunately, the alternative used here isn't
much better.)  Also, you can use #tip to empty an inventory container
while swallowed; it was giving inappropriate levitation and drop-on-altar
behavior in that situation.

lockpicking while engulfed

     You can't begin or resume locking or unlocking a chest on the floor
while swallowed by a monster, but you could lock or unlock an adjacent
door in that situation.

surviving drawbridge destruction

     From a bug report:  you could end up
standing on water/lava if you survived being on an open drawbridge while
it was destroyed.  This fixes the bridge destruction case; opening and
closing are handled differently and I left them alone.

#force fixes

     Trunk and branch, noticed while working on an interface enhancement:
you could use #force to break the lock of a chest that's on the floor
while you're engulfed, also while levitating or mounted w/o riding skill.

     Trunk only:  refine an earlier fix that bills for breaking the lock
of a shop-owned chest.  The item which the hero is forced to buy showed
up in the bill as unlockable, which is accurate after the fact but didn't
reflect the shop's item.  Fix by billing for chest before altering it.

#tipping empty bag of tricks bit (trunk only)

     Check in something from a month ago before I manage to lose it.

explore/wizard mode docs (trunk only)

     Update the brief explore mode section (it hasn't been a conditional
feature for quite some time, there's an extra way to access it now, and
new game started with -X is different from switching via the 'X' command)
in the Guidebook, and add a short debug mode subsection there.

polyself weapon drop feedback

     Don't say "you must drop your weapon" when it doesn't actually get
dropped.  And make "weapon" be more specific, comparable to the handing
for slippery fingers.

more wielded, in-use leash

     Slippery fingers would cause a wielded, in-use leash to be dropped
without first unleashing.  The fixes entry for the polyself case applies
to this one too:
dropped wielded, in use leash should remain in inventory, since it's in-use

probing vs Schroedinger's Cat (trunk only)

     Someone in the newsgroup complained about zapping probing at a large
box dropped by a quantum mechanic and being told that it was empty rather
than that it held a corpse or live cat.  This sidesteps the issue by
reporting "the box seems empty" instead of "the box is empty", and not
setting its contents-known flag.  (That message is the main difference
between probing and the assorted other methods of observation [telepathy
and monster detection and possibly Warning for live cat, object detection
and food detection for dead cat's corpse] which might be expected to
trigger the cat's fate but don't.)  This also makes probing of self and
of monsters set the contents-known and locking-known flags for containers
in inventory, same as is done for probing which hits objects.  (Display of
container contents still only occurs for loose objects, not in inventory.)

nethack -X vs normal game (trunk only)

     Reported to the beta-testers list by <Someone> last April:
restoring a normal game save file in explore mode let you keep the file,
then after exploring and quitting without saving, you could restore it
again in normal mode and take advantage of whatever information you'd
gained.  This makes nethack -X (or playmode:explore) defer the switch to
explore mode when used while restoring a normal mode save file.  It now
performs a normal restore (with save file deletion) and then acts as if
the user had given the 'X' command interactively, requiring confirmation
to actually switch into explore mode.

yet more wizard mode handling (trunk only)

     Reorganize the recent wizard mode control:  move set_playmode() from
xxxmain.c to the core, and have it call new authorize_wizard_mode() to do
the port-specific part.  If the set_playmode() call during startup doesn't
result in running in wizard mode (either because not allowed or user
didn't request it), it will be called again during restore if the save
file is from a wizard mode game.

     For ports which check character name for authorization, players will
have to use `nethack -u whatever -D' (or options for name and playmode) to
restore a wizard mode save file if WIZARD has been changed from "wizard".
plname[] from a wizard mode saved game will always have that value, so if
it's not the right one players will need to get authorized by the startup
code before loading the save file.

more wizard/explore mode control (trunk only)

     Wizard mode or explore mode can be forced on (via -D or -X on the
command line, or now via OPTIONS=playmode:debug|explore) when restoring
a saved game; explore mode handling was confined to restgamestate(), but
wizard mode handling was replicated in every main().  Treat `wizard' the
same as `discover'.  Also, prevent a new game started when restore fails
from using the old game's option settings if partial restore attempt got
far enough to load the flags struct.  And update bemain.c and macmain.c
to catch up with the others modified by the playmode patch.

OPTIONS=playmode:normal|explore|debug (trunk only)

[see cvs log for src/options.c for some additional info]
     Relief for the command-line impaired.  Allow player to request
explore or wizard mode via run-time config file or NETHACKOPTIONS.
Validation is left to xxxmain() and has been updated for Unix, VMS, and
ports which share pcmain.  Mac and Be appear to allow any user to access
wizard mode, and may not need any modification, although they'll continue
to have the old buglet of running with both wizard and discover flags set
if player uses `nethack -X -D'.  This may or may not work as-is for the
Qt interface depending upon whether it goes through one of the xxxmain()'s
mentioned above [someone needs to make sure that it doesn't allow Qt on
Unix to bypass the (username == WIZARD_NAME) test when user requests
wizard mode].

OPTIONS=playmode:normal|explore|debug (trunk only)

     Relief for the command-line impaired.  Allow player to request
explore or wizard mode via run-time config file or NETHACKOPTIONS.
Validation is left to xxxmain() and has been updated for Unix, VMS, and
ports which share pcmain.  Mac and Be appear to allow any user to access
wizard mode, and may not need any modification, although they'll continue
to have the old buglet of running with both wizard and discover flags set
if player uses `nethack -X -D'.  This may or may not work as-is for the
Qt interface depending upon whether it goes through one of the xxxmain()'s
mentioned above [someone needs to make sure that it doesn't allow Qt on
Unix to bypass the (username == WIZARD_NAME) test when user requests
wizard mode].

     playmode:discov[ery] is a synonym for explor[e] and playmode:wizard
is one for debug.  Using -X or -D on the command line overrides any
config file or environment playmode value.  (We might want to add -N or
something to force normal mode when config/env specifies something else.)

     This suffers from the same bug as `nethack -X' and `nethack -D':  a
player can save a game in normal mode, then restore in explore or debug
mode and choose to retain the save file, obtain information about the
current game (identifying inventory or using enlightenment or mapping out
previously visited levels and so on), quit, then restore the original save
file normally in order to take advantage of the undeserved information.

wielded leash, monster bullwhip use

     Simplify <Someone>'s patch (the part for the secondary weapon wasn't and
still isn't needed since dual-wielding can only occur when both primary
and alternate weapon slots contain weapons or weapon-tools, but we might
as well keep it).  There was at least one other case where wielded in-use
leash could be removed from inventory without becoming unleashed first:
a bullwhip-wielding monster could snatch it away.

     That lead to some other whip issues:  monsters who select disarming
via bullwhip as miscellaneous strategy had 80% chance of not using it on
any given turn, but had no chance to select another misc strategy on such
turns--they always resorted to ordinary nonMUSE behavior and usually just
attacked.  The adjacency check missed diagonal locations, also would aim
the disarm attempt accurately even when displacement or invisibility made
the hero's precise location unknown.  [I took the easy way out here and
only let them try to disarm when they know the hero's location.  It's
tempting to aim at the guessed location and sometimes accidentally disarm
a nearby monster, but disarming is an action which targets a particular
weapon rather than just a location.]  Lastly, disarming always targetted
hero's primary weapon, never a dual-wielder's secondary one.

polymorph dropping in-use wielded leash part 2
forgot to handle the twoweapon case, and messed up the test logic (which
appeared to work in previous, incomplete testing)

polymorph dropping in-use wielded leash
From a bug report, if you polymorph into
something, like a killer bee, that causes you to drop your weapon, but the
weapon is a wielded, in-use leash, the leash would be dropped but retain
it's in-use state.  However, the leash was tied to you, so it seems it
should remain attached, just unwielded, just as it would if it hadn't been
wielded.  I've changed the behavior to do this.  I wonder whether one
should be able to wield an in-use leash.

fix #Q417 - gelatinous cubes can engulf Rider corpses

     From a bug report:  gelatinous cubes
could engulf Rider corpses, allowing g.cube and cargo to be teleported
away without triggering corpse revival, or to be hit with theft attack by
poly'd hero to get the corpse into inventory so it could then be put into
a container in order to prevent revival (or to be destroyed via bag of
holding explosion or cursed access).

umpteenth hangup bit

     From a bug report:  hangup during
screen updating at tail end of successful restore didn't create a new
save file when disconnecting.  Use his suggestion for moving the setting
of program_state.something_worth_saving sooner, before the save file is
deleted.  To do that, restlevelstate() needs to come sooner too.  I think
this is safe enough to include in the branch code.

     For the trunk, I'm not sure whether the SAFERHANGUP config will work
well here.  It has to survive long enough under autopilot to enter moveloop
before the chance to save kicks in.

more jumping (trunk only)

     Allow jumping via spell when hero or steed has wounded legs.
Otherwise the previous fix for immobilized steed--and the existing code
requiring limbs for physical jump but not for spell jump--is inconsistent.

fix #Q382 - jumping possible while riding a sleeping pet (trunk only)

     From a bug report:  when riding,
#jump command and jumping spell didn't check whether steed is able to move.
This makes #jump command, either magic boots or knight's innate ability,
fail if the steed can't move.  Spell still succeeds; its magic overrides
steed's immobility.  Fix is trunk only since it relies on a function that
isn't in the branch.

     Also, tweak hero movement to avoid an extra function call per move
when not riding.

sleeping gas trap vs steed

     Noticed while checking out the report that you can #jump when riding
a sleeping steed:  hero's sleep resistance or magical breathing prevented
sleeping gas traps from hitting steed.  "You are enveloped in a cloud of
gas" but your steed is untouched?  That didn't make sense.

gcc compilation warning bits

H238 - spelling of Dr Dolittle

Q387 - grammar fixes in Samurai quest
"Wakarimasu?" should be "Wakarimasu ka?"

fix #Q404 - monster wielding cursed corpse

     From a bug report, applying a bullwhip
towards a monster to try to steal its weapon would report that a cursed
cockatrice corpse was welded to the monster's hands even though corpses
wielded by the player never become welded.  Code for monsters deciding
what to wield knew that corpses don't weld; everywhere else seems to
assume that they only wield weldable weapons.  Add a routine to check
whether a wielded item is welded, similar to what's done for the hero.  I
fixed a couple of other spots besides use_whip() but didn't hunt all over.

typo in previous patch

finish_map prototype

     There's a newsgroup posting about building for Windows using minGW
(gcc) within the cygwin Unix emulation environment, and it includes diffs
for the changes used.  One of the items being patched is a straight source
bug triggered by altering the definition of `boolean'.  finish_map()'s
prototype doesn't match its definition (uses boolean args but has XCHAR_P
in the prototype).

fix #Q159 - segfault with super long item names

     From a bug report, putting an object with
really long specific and type names into a container with really long
specific and type names caused the program to crash.  pline() overflowed
the buffer it formatted into, and even though it was able to send that
for output and trigger a --More-- prompt, eventually a segfault occurred.
Give vpline and vraw_printf a much bigger working buffer, then truncate
the formatted text to BUFSZ - 1 characters so that we don't just push the
long line trouble into the separate interfaces.

Q416 kicking gold (trunk only)

<email deleted> on Monday, January 29, 2007:
>Hero is able to kick a pile of gold (say, 100) and have the entire pile move at
>once in the same direction; very easy to avoid gold on traps.  Kicking gold
>should probably scatter the pieces in multiple directions or at least not be
>quite so easy.

fix #Q367 - tinning Rider corpse when level is full

     From a bug report:  if you try to tin a
Rider's corpse and revival fails, you still get the gimicky message about
War not preserving his enemies.  Give the suggested alternate message in
that case:  The corpse evades your grasp.  I hope that we can do better
than that, but I'm too burned out to think of anything.

fix #H239 - doppleganger/mimic bug

     From a bug report:  a shapechanger
which becomes a mimic would always stay as 'm' rather than take on object
or furniture shape.  Same applied to monsters which hide in other ways.
The code did that deliberately, but I don't think that it's actually
necessary so this lets them mimic/hide when they're in the right shape.
If they change form to non-mimic/hider while concealed, concealment ends.

     It would be fun to have shapechangers-as-mimics actually change their
mimicked shapes periodically, but this doesn't do that.  They'd probably
change to non-mimic quicker than they'd mimic something else so it's not
worth the effort.

fix #Q295 - post-choking food side-effects

     From a bug report, but
just received:  if you choked while eating a cockatrice egg and survived,
the turn-to-stone sequence wouldn't be initiated.  For such eggs, turning
to stone starts when the food is finished rather than when it's started,
and fpostfx() wasn't called for food that triggered choking so the egg
went away without actually being finished.  Fortune cookies, lumps of
royal jelly, and a few other things suffered from the same situation.

typo in chest description

     From a bug report:  "The" should be "Then".

weapon rustproofing status

     From a bug report, hitting a rust monster with a
fireproof--but not identified as fireproof--weapon caused the rknown bit
to become set, identifying the item as fireproof.  That would also happen
for a monster's anything-proof weapon if it hit a rust monster, whether
you could see it happen or not.  The code involved is convoluted; I hope
this fix is correct.

redundant or inconsistent msleeping handling

     Eliminate some redundant monster sleep handling pointed out by <email deleted>.  I'm not sure if this is the right fix for mattackm(),
but the wakeup-after-hit was definitely wrong for the case where that hit
put the target to sleep.  (I didn't try to make that actually take place
but it is a possible outcome of monster-against-monster combat.)

fix #Q117 - vomiting by rodents & more

     From a bug report:  you could vomit when polymorphed into a rat but real life
rats can't/don't vomit.  The latter was confirmed by <Someone> and <Someone>.
While testing a fix for this, I discovered a couple of other problems.
Healing magic which cured sickness failed to heal Vomiting (potion or
spell; unicorn horn deals with them separately).  Enlightenment failed to
report Vomiting (it's not shown on the status line).  Most significant was
that vomiting_dialogue() called vomit() twice (also make_confused() and
make_stunned() three times for every once intended).  It was dividing the
remaining turns by 3 and then using that value to decide what to do, but
only message display took into account that the same divided value would
occur on 3 consecutive turns (or just 2 for the final countdown to 0,
because dialog routine gets called before timed-property decrement).

fix #Q108 - adding candles to Candelabrum while underwater

     From a bug report, but just received:
you can't affix candles to the candelabrum while underwater, because the
underwater check (can't light candles while underwater) is made too soon.
If you somehow managed to get a lit lamp, candle, or candelabrum while
underwater, you wouldn't be able to extinguish it for same reason.  The
bug report included a URL for a fix, but I didn't look at that.  This
changes use_candle() to rely on use_lamp() for underwater handling, and
changes use_lamp() and use_candelabrum() to check for extinguishing
before making the underwater check.

goto_level message reorg (trunk only)

     Clean up the code at the end of goto_level().  The only change in
behavior, aside from eliminating a couple of wizard mode quirks, is that
if a hangup save occurs while staring at the quest entry message, it will
be flagged as seen and not show up again if you leave and return to the
quest after restore.  (For wizard mode, you'll no longer find the Wizard
waiting if you use the level teleport menu to jump directly to the Astral
Plane from outside the endgame, and level teleporting away from astral
level to one of the elemental planes then returning won't make more fake
players or another guardian angel.)

fix #Q94 - quest portal bug

     From a bug report.  (Michael forwarded a newsgroup posting about it back
then, but I had trouble reproducing it and didn't figure it out until
trying again now.)  If hangup occurred while entering the quest, the magic
portal could be rendered inactive for the hero but still work for monsters.
That's because the hangup save stored the old value of u.uz0 before
goto_level set it to the new u.uz, and a magic portal won't operate when
u.uz0 differs from u.uz (to prevent a pair of portals from getting stuck
sending the hero back and forth).  The problem could also occur going from
the quest back to the dungeon, or either direction for Ft.Ludios, but the
--More-- prompt when the quest entry text is being displayed makes hangup
during level change most likely to occur during initial quest entry.

     This is just a bandaid, and the SAFERHANGUP config wouldn't be hit
by this situation.

more engraving with empty wands (#Q85)

     #Q85: Bug: wrest a wand in one turn through engraving
From a bug report:  engraving with an empty wand while not levitating, then using
ESC to abort when asked for the text to write, let you attempt to wrest
the last charge without using up a turn.  Between the time this report was
sent and received, someone else reported similar issue with levitation,
where no prompting occurs.  The fix for it also fixed the original problem.
Somewhat inadvertently though, since you can now no longer write in the
dust with a empty wand.  I'm going to leave it this way; all that's needed
is some feedback about failing to engrave.

m-prefix groundwork (trunk only)

     Set up to be able to use the m command prefix to request menu mode
for commands other than just pickup.  As a side-effect, a hardcoded ','
referencing that command is eliminated.  Also, the command handling for
pickup was accepting the other prefix characters (F,g,G,M,numpad 5) as
synonyms for m; this reverts all but 'm' to movement modifiers only (it
may be reasonable to retain M and 5, but this doesn't).

hangup paranoia (trunk only)

     If nhwindows_hangup() were to get called a second time, it would have
saved hup_exit_nhwindows() as the previous interface's shutdown routine.
Then if/when exit_nhwindows() gets called, hup_exit_nhwindows() would
have called itself with uncontrolled recursion.  So guard against that by
preventing the hangup shutdown routine from ever being saved as previous
interface shutdown routine.

     Also, avoid the exit_windows macro when using it as a pointer rather
than for a function call, since pre-ANSI compilers might be confused by
its expansion.

yet more hangup (trunk only)

     From two weeks ago:
>      The last of my intended hangup overhaul.  Once hangup is detected,
> replace currently loaded windowing routines with stubs that never do any
> terminal I/O.  Real interface routines call their siblings directly rather
> than via the windowprocs pointers, so this shouldn't pull the rug out from
> under them, but it also can't prevent whatever they have in progress at
> the time of hangup from attempting further I/O once the handler returns.

     hangup_nhwindows() shouldn't call exit_nhwindows() prior to replacing
windowprocs with no-ops.  Even though the original intgerface can still
access its own routines directly, the exit_nhwindows() routine probably
releases its dynamic data structures.  And those could be in active use if
the hangup occurs while an interface routine is executing.

hangup followup (trunk only)

     The hangup check added to xwaitforspace() (which gets tty user's
response to --More-- and "Press Return to continue: ") wouldn't be good
enough if hangup occurred while that routine's input loop was executing.

several hangup tweaks (trunk only)

     NOSAVEONHANGUP isn't documented anywhere.  I don't see why it should
wipe out recoverable level files just because it doesn't want to build a
save file out of them during the hangup.  Leave them intact if checkpoint
is active.  If someone really wants to make them always go away, they'll
need to disable INSURANCE as well as enable NOSAVEONHANGUP.

     tty's getret() -> xwaitforspace() could get stuck in a loop after
hangup, depending upon the state of terminal shutdown (accepting EOF or
ESC cares about cbreak mode?).  Make xwaitforspace() become a no-op during
hangup processing.

     vms's call to hangup() from an exit handler took place after the
terminal has been reset (the exit handler for the latter is registered
later so executes sooner).  Then exit_nhwindows() resulted in a second tty
reset attempt and settty() -> setctty() encountered an error (which it
reported, triggeting a getret() call).  Make the vms code correctly guard
against multiple resets.

acid vs iron bars (trunk only)

     Make yellow dragon breath destroy iron bars (unless their wall_info
is marked as non-diggable, which I think is currently impossible for bars).
The shop handling is untested; no shop has iron bars for its walls or
includes them as interior obstacles.  (The latter would require changes
to shop repair because lost bars will become solid wall if/when rebuilt.)

     Thrown potions of acid and spat or thrown splashes of acid venom
don't affect bars--at least so far--because those always pass through
without hitting.  Monsters who have a non-ranged attack which does acidic
damage can't use such attacks against iron bars.

monster ranged attacks (trunk only)

     A fairly recent change had a mistake in it which allowed monsters to
throw, shoot, and zap through walls and closed doors if there was at least
one unobstructed spot between the attacker and the wall or door.

engraving with empty wand

     From a bug report:  if you
attempted to engrave with an empty wand while levitating, it wouldn't use
a turn unless you successfully wrested an extra charge out of the wand.
So you could always get such charge in a single elapsed turn of game time
if you didn't care about zapping in any particular direction; extremely
useful for wishing.

     Noticed when checking this:  when you did wrest the extra charge,
the engraving code accessed freed memory for the wand after it had been
used up.

     Lastly, wands producing certain effects always become discovered,
even when you don't yet know what they look like.  (This part of the patch
is trunk-only since it utilizes the routine which fixes similar case for
zapping.)

kicking off edge of map

     From a bug report:  if you
were at one of the map edges and kicked away from map center while blind,
you'd get impossible("show_glyph: bad pos ...").  That was due to calling
feel_location() for the out of bounds location, which occurred after the
kick code had made use of invalid data so other problems might occur too.

     Now you kick "nothing" as if it was something (hence possibly wounding
your leg, taking some damage, potentially dying).  I didn't want to try to
classify the surrounding terrain as rock or air or whatever, and the thing
being kicked only shows up if the kick is fatal.

eating artifacts while poly'd

     From the newsgroup:  if polymorphed into a metallivore, you could eat
artifacts that you couldn't touch with your hands.  Now you can't eat ones
which evade your grasp, and you take some damage from other touchy items
on--actually, prior to--the first bite.  (Those still "taste delicious" if
you survive; I'm not sure whether this ought to be changed.)

Confused #loot (trunk only)

     Attempting to loot while suffering from confusion and not on top
of a container will drop gold if hero is carrying some, but it behaved
differently for GOLDOBJ config (gold dropped over a hole or down stairs
always stayed on current level) than for !GOLDOBJ (gold had a chance to
fall to lower level) when done at some location other than a throne.
This makes GOLDOBJ use dropx() instead of dropy(), same as !GOLDOBJ.

     And with access to a throne it can be used to repeatedly summon
monsters until they're extinct.  This makes it check for confusion before
finding containers, but the chest/exchequer code doesn't always kick in
so can't be attempted as many times before confusion expires, throttling
summoning a little.  Also, when placing hero's gold into a chest, it now
clears the contents-known flag and relocks the chest.

hangup tweaks (trunk only)

     Fix a typo in some conditional (NOSAVEONHANGUP) code, and tweak
SAFERHANGUP so that it doesn't defer hangup handling if the game hasn't
started yet or has already finished (it's possible to be waiting for a
--More-- prompt at end of game code before the hangup handler is reset,
so the regular handler could be called in that state).  Also, undefine
SAFERHANGUP if NOSAVEONHANGUP is defined, since there's no point in
deferring hangup for the latter.

hangup hangup bit (trunk only)

     Accidentally left out  of the previous patch.

hangup hangup (trunk only)

     The last of my intended hangup overhaul.  Once hangup is detected,
replace currently loaded windowing routines with stubs that never do any
terminal I/O.  Real interface routines call their siblings directly rather
than via the windowprocs pointers, so this shouldn't pull the rug out from
under them, but it also can't prevent whatever they have in progress at
the time of hangup from attempting further I/O once the handler returns.
[We might want to change nhwindows_hangup() into winprocs.hangup_nhwindows()
so that each interface has more control over its own fate.]

     This assumes that user input of ESC and menu selection result of -1
everywhere in the core will eventually cause active function calls to
unwind their way back to moveloop() rather than to continually re-prompt.
(This assumption is not a new one, just a bit more explicit now.)

hangup revamp (trunk only)

[See cvs log for src/cmd.c for more complete description.]

     This turns clearlocks() into a no-op during the period when the UNIX
port is asking the user to confirm whether to overwrite an existing game.
Also, this removes the duplication of code and function between hangup()
and end_of_input(), and it simplifies the check for whether hangups are
supported by adding new macro HANGUPHANDLING.  (I don't think global.h is
the best place to be defining that but I couldn't figure out where else
it would fit, other than repeating for individual xxxconf.h files.)  And
adds a couple more done_hup checks to try to cope with situations where
rhack() is being bypassed.  Lastly, having readchar() return EOF was
ignored for non-UNIX configs; now everybody gets ESC instead of letting
EOF be seen further inside the core.

hangup revamp (trunk only)

     The previous "hangup cleanup" didn't accomplish much (other than to
give everyone a good view of extern.h).  This one achieves more, and also
tries to fix the bug From a bug report:
> Buglet: Destroy old game -prompt can make game unrecoverable
>
> I haven't confirmed this myself, but few people playing on NAO
> have had the following happen:
> 1) play nethack
> 2) your network connection gets cut
> 3) reconnect, and get "Destroy old game" -prompt
> 4) your network connection gets cut, again, before you get to answer 'n'
> 5) game is not recoverable, because the level 0 file is gone.

     The reason for #5 is simple to explain; it's the expected behavior of
current hangup() routine (although that hasn't always called clearlocks();
I don't know why it was added).  The puzzle is why #2 left any lock files
around in the first place.  I suspect it was because SAFERHANGUP defers
until rhack(), and rhack() doesn't get called if the hero is immobilized or
in the midst of a counted operation.  I don't know how long a disconnected
process is allowed to run, but I don't think it's forever.  (Alternatively,
nethack might be attempting further terminal I/O and getting stuck on the
hung connection; this won't help much if that's the case.)

     This turns clearlocks() into a no-op during the period when the UNIX
port is asking the user to confirm whether to overwrite an existing game.
Also, this removes the duplication of code and function between hangup()
and end_of_input(), and it simplifies the check for whether hangups are
supported by adding new macro HANGUPHANDLING.  (I don't think global.h is
the best place to be defining that but I couldn't figure out where else
it would fit, other than repeating for individual xxxconf.h files.)  And
adds a couple more done_hup checks to try to cope with situations where
rhack() is being bypassed.  Lastly, having readchar() return EOF was
ignored for non-UNIX configs; now everybody gets ESC instead of letting
EOF be seen further inside the core.

!GOLDOBJ gold in inventory during save/restore (trunk only)

     Simplify the save/restore handling the !GOLDOBJ config does for gold
to maintain save/bones file compatibility with the GOLDOBJ config.

need hands to throw

     From the newsgroup:  slash'em lychanthrope character could throw
while in wolf form.  That came straight from nethack; any animal capable
of manipulating an object--possibly with its mouth--could throw things.
Now hands are required.  This doesn't require free hands, although it
probably should; it's kind of tough to imagine making a competent throw
while your hands are stuck to a cursed two-handed weapon.

hangup() cleanup; SIGXCPU handling (trunk only)

     While looking at a bug report from two months ago about how having
hangup take place while at the "destroy old game?" prompt causes an
interrupted game to become unrecoverable, I decided to try to clean up
convoluted hangup() a bit.  Didn't achieve much there, but did notice that
the Unix port was handling SIGXCPU (whatever that is...) inconsistently.
This attempts to fix that, but I have no way to test it.

     The original bug report is still unresolved.

     makedefs ought to add something for SAFERHANGUP and NOSAVEONHANGUP
to the #version output.

[ This is the missing bit from the patch on Monday which accidentally
  included all of extern.h as its log entry message. ]

hangup() cleanup; SIGXCPU handling

gold in inventory bit (trunk only)

     Update some disabled code in case it ever gets used.

wizard mode bit

     Wishing for a grave would say it made one even when it didn't.
[How come graves aren't allowed at corridor locations?]

shopkeeper/priest movement

     From a bug report:  shopkeeper
wouldn't move to block his doorway if there was a grave at that location.
Nothing supernatural; shopkeeper and temple priest movement was too
specific about what sort of terrain might be present and didn't know that
room floor might be replaced by a grave.

!GOLDOBJ gold in inventory (trunk only)

     Simplify the insertion into and removal from of gold in inventory for
the !GOLDOBJ configuration.  If GOLDOBJ ever becomes unconditional this
will be superfluous, but in the mean time it unclutters the container and
drop code.  Also, tweak a recent getobj() hack so that its purpose might
be a bit clearer.

gold in menus fix (tty; GOLDOBJ for branch, both GOLDOBJ/!GOLDOBJ for trunk)

     A recent change to force gold in inventory (during multi-item Drop or
applying/looting containers) to have '$' for its inventory letter for the
!GOLDOBJ configuration has revealed a bug which 3.4.3 has for the GOLDOBJ
configuration.  Specifying a count followed by '$' to use a subset of
carried gold didn't work under tty; the $ was treated as a group accelator
and overrode the count, so full stack was always used.  (The code a few
lines above this which counts the occurrences of group accelators already
includes this same fix:  ignore an item's group accelator when it matches
the selector.)

     I wouldn't be surprised if other interfaces are subject to the same
problem; since I can't test those I'm not attempting to fix them blindly.

container message tweaks (trunk only)

     "You carefully open the <container>..." is rather tedious after
you've opened that container multiple times, so omit "carefully" once the
contents and lock-status are both known.  (I don't think it's possible
for a container to still be trapped in such circumstances, but even if it
is, you'll now stop being careful....)

     "<The container> is empty." becomes "<The container> is now empty."
if it just released Schroedinger's Cat.  Do the same if a cursed bag of
holding just destroyed the last of its contents.  Also, there's no need
to count the number of items inside a container; that dates to before the
container-and-contents overhaul done for 3.1.0.

     And for the loot menu, change "q - do nothing" to "q - done" if some
prior action (prodding the Cat into life or death, loss of any cursed bag
contents, or using ':' to look inside when contents aren't yet known) has
been enough to cause this container access to use up a turn.  I haven't
bothered to do the same in the help text for non-menu looting, which seems
like more trouble than it'd be worth.

build warning (trunk only)

..\src\lock.c(184) : warning C4101: 'otmp' : unreferenced local variable

win32 build

- force time_t to be 32 bits via Makefile. (If struct u gets changed to not
store a time_t field, this can be removed).

- Latest Windows SDK (supporting Vista) causes a warning due to
a prototype in sys/winnt/nttty. Since we don't actually link with that
function and rely on a DLL find procedure at run time, comment out
the prototype. The function is now officially in the SDK in the
windows header files anyway.

streamlined container interface (trunk only)

     Reduce the number of questions issued when applying or looting a
container, and offer the opportunity to put things inside before taking
things out.  Instead of "Do you want to take something out?  [:ynq]",
followed by "Do you want to put something in? [ynq]", this gives just one
prompt; the result is similar to menustyle:full where you start out by
choosing between out, in, and both.  There are now two additional choices:
reversed, for both in the opposite order, and stash, to put a single item
inside.  Prompt phrasing is rather clumsy; I wanted to keep it short:
"Do what with <the container>? [:oibrsq or ?]", where picking '?' pops
up a brief help window.  Inappropriate choices (like 'o'and 'b' when
container is empty) are suppressed from the prompt but still acceptable as
input; " or ?" is suppressed if the cmdassist option has been toggled off,
but entering '?' still works to get help.

     Menu mode wouldn't allow 'b' when inventory was empty, despite the
fact that first taking things out might change that.  Now 'b' is a viable
choice if the container isn't empty, and the new 'r' is a vialble choice
when inventory isn't empty even if the container is.

container groundwork / splitting welded weapons (trunk only)

      Some miscellaneous changes preparatory to enhancing the container
interface.  This also fixes a minor inconsistency in object manipulation:
askchain() wouldn't let you split a stack of welded weapons but getobj()
would, so you couldn't get rid of part of the stack using 'D' or #loot,
but you could with 'd' (and post-3.4.3, with #adjust).  Now getobj() will
behave like askchain(); if you have 3 cursed daggers welded to your hand,
you won't be able to drop 1 or 2 of them anymore.

breaking lock of shop chest (trunk only)

     From the newsgroup:  you weren't charged anything if you broke the
lock of a box or chest which was owned by a shop.  Force the hero to pay
for the damaged container; any contents remain owned by the shop and don't
affect the cost of the forced purchase.  This existing entry in fixes35.0
is adequate to cover the fix:

various actions--such as enchanting--performed on an unpaid shop object
either force the hero to buy the item (when its value is lowered) or
increase the current bill (when its value is raised)

couple of container bits (trunk only)

     Don't use the phrase "seems to be locked" when you discover that a
container is indeed locked.  Also, using an alternate naming routine is
a simpler way to avoid redundant "the empty <container> is empty" than
suppressing the contents-known handling for xname.

monster ranged attacks (trunk only)

     Newsgroup posts mention "boulder forts" from time to time, where the
player surrounds the hero with boulders in order to prevent the majority
of monsters from being able to attack.  Since the hero can shoot or throw
or zap over/around/through boulders, monsters ought to be able to do so
too.  This makes the test for whether a monster is lined up properly for
its ranged attacks try harder when the original line-of-sight check fails.
If there aren't any terrain obstacles found, it allows a chance to attack
based on the number of locations in the path that contain any boulders.
Giants and any monster carrying a boulder-destroying wand of striking get
to ignore boulders, overriding the random chance.

statue trap tweaks

     Implement <Someone>'s suggestion/request that co-aligned unicorn not be
used for statue traps, so that the hero won't get hit with a big luck
penalty for killing such a unicorn when the trap releases one which is
hostile.  I think that set_malign() probably ought to override that, but
this just changes the monster type selection for the trap's statue.

     Also, noticed in adjoining code:  avoid counting the template monster
used to generate inventory for the statue towards extinction.  It gets
immediately discarded, and later statue activation counts the resulting
monster then.