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.

statue trap activation

     Make monsters created by statue trap activation start out awake and
hostile in addition to being unhidden.

endgame trap fix

     Someone in the newsgroup claims to have reported this in mid-October,
but he uses a fake address in news and maybe he did so with his mail too,
resulting it not being delivered.  Anyway, arming a land mine on the Plane
of Air, then setting it off, produced a pit in the air.  This fixes that
directly, in case someone manages to do it again, and it also prevents
land mines and bear traps from being armed in midair in the first place.
Ditto for Plane of Water; water/pool locations were already covered (can't
arm there), and the bubbles ought to be treated similarly to Plane of Air.

     When testing this, I managed to get a crash while restoring a saved
game.  I had worn a blindfold and armed a land mine on the water level
(with just the no-pit part of the patch in place), then saved.  When
restoring, I got a crash in restore_waterlevel() at one or the other of
these lines (traceback pointed at the first, but it has to have actually
been the second; an access violation from an address derived by applying
a small offset to a null pointer):
ebubbles = b;
b->next = (struct bubble *)0;
After that, I couldn't reproduce it with a wished-for trap and couldn't
stay in one place long enough again to successfully arm a trap object.
So there may be a nasty bug still present, perhaps now hidden by no longer
being able to create a new trap on that level.

boomerang path (trunk only)

     Thrown boomerangs travelled in a clockwise path, appropriate for
left-handed throwing.  But nethack heroes are treated as right-handed by
the weapon wielding and shield wearing code, so make boomerangs travel
counterclockwise instead.  Switching is straightforward, in case we ever
implement user-specified or random handedness.

enchant weapon fix (trunk only)

     Noticed while testing crysknives; a post-3.4.3 change (not present in
the branch code) introduced a bug that prevented scrolls of enchant weapon
from being used up properly when read.

final? multi-shot throwing (trunk only)

     Make worm teeth and crysknives be stackable.  Positively enchanting
a stack of multiple worm teeth produces a single crysknife, negatively
enchanting a stack of multiple crysknives produces a single worm tooth.
A dropped stack of N fixed crysknives has 90% of remaining N crysknives,
10% of becoming a stack of N worm teeth, rather than produce an average
of 0.9*N crysknives and 0.1*N worm teeth.  (The code which handles that
transformation operates on loose objects so cannot handle stack splitting
because it wouldn't have any idea of what to do with extra objects.)

     Terminate multi-shot volley throwing of boomerangs if one comes back
and isn't caught.  The sequence throw-catch-throw-catch is odd, but would
take a substantial amount of code and effort to be changed to the more
intuitive (for rapid volley throwing) throw-throw-catch-catch.  Even if
feasible, doing that for underused boomerangs would be a waste of effort.

multi-shot bug

     Reading the comments in the previous patch, I realized that keeping
the old behavior for monsters who are shooting multiple missiles was
leaving an obscure but potentially serious bug.  I haven't attempted to
trigger it but 3.4.3 is bound to be vulnerable.

multi-shot throwing for knives & spears (trunk only)

     Make all stackable weapons capable of multi-shot volleys when thrown.
Affects knives, spears & javelins, and boomerangs; requires advanced skill
assignment (skilled:  1-2 missiles per throw, expert:  1-3 missiles) or
role-specific bonus (ranger class's general +1 bonus is the only one that
applies to any of these weapon types).  For monsters, prince-caste get 1-3
missiles and lord-caste get 1-2, as before, with fake player monsters now
also getting 1-2; those counts apply to all stackable weapons regardless
of whether the species or role ordinarily uses whatever is being thrown.

     Related changes:  monks now get a role-based +1 count for shuriken,
throwing 1-2 instead of just one (they're only allowed to achieve basic
skill so won't reach any higher volley count).  Monster monks and ninjas
get that too; ninjas now get the same for darts and they're guaranteed
weapons in starting inventory.  Also, fake player rogues now sometimes
get orcish daggers instead of short sword, providing a decent chance to
occasionally have Grimtooth be randomly generated on the Astral level.

     Potentially controversial:  wizards can still become expert in dagger
skill and receive the to-hit and damage bonuses for that when throwing as
well as when wielding, but the number of missiles for them has now been
reduced to 1-2 (in other words, going from skilled to expert no longer
improves the max count for the volley amount for wizard role).  They're
supposed to be spellcasters; being able to throw up to three +7 daggers
at a pop was a big temptation for resorting to brute force, particularly
since they'll already want highest dagger skill for wielding Magicbane.

     To do:  throwing multiple boomerangs either needs to behave as if
they're all in flight before the first returns, or else the volley needs
to be cut short if one comes back and isn't successfully caught.  The
latter is a lot easier to do but the former fits better with what multi-
shot volley is supposed to represent.  Another alternative is to change
them to no longer be stackable, then this sequencing issue goes away.

     To do too:  make worm teeth and crysknives become stackable like the
other knife-skill weapons.

boiling oil (trunk only)

     A suggestion from the newsgroup:  when potions are hit by fire and
get the "boil and explode" result, potions of oil should burn instead of
boil.  Even though oil can be heated to boiling, nethack's potions of oil
are noticeably flammable [just (a)pply one...] so having them burn makes
sense.  It's just a message change; no actual explosion has been added.

     destroy_strings[] was implemented as an {N} x {3} array that used
manually computed indices into one-dimension.  This changes it into a two-
dimensional array instead.  However, it's still being indexed by a bunch
of magic numbers.

comment tidbit

#offer bit (trunk only)

     Refine a recent change:  Moloch should only have a chance to blast
you for offering the Amulet at an ordinary altar (instead of high altar)
when you're still in Gehennom (Orcus' Level or Valley of the Dead), not at
the unaligned altars in a couple of quests.

merge javelin and spear skills (trunk only)

     Part of "multi-shot throwing proposal" last January.  Unfortunately
some of the bits that I had implemented back then have vanished, so I'm
doing it over from scratch.  There were three main parts:
1) allow multi-shot volley throwing for all stackable weapons (affects
   knives, javelins, spears, and boomerangs; other weapons either don't
   stack or are already multi-shot);
2) make worm teeth and crysknives be stackable like ordinary knives;
3) merge spear and javelin skills, so that allocating skill points to
   their use becomes more attractive and they might get used more.
This patch only does #3.

     Since the monk skill set shrinks by more than any of the other roles,
I bumped max skill for escape spells (haste self, invisibility, jumping,
levitation, and teleport away) from basic to skilled; that's the only
skill adjustment included here.  For the couple of roles had different
max values for spear and javelin skill; this keeps the higher of the two.

engraving vs drawbridge

     From the newsgroup:  ``Something is engraved here on the water.''
An engraving written on a lowered drawbridge would be transfered to the
underlying terrain when the bridge was raised.  The coverse was also true;
if you plugged the moat and then engraved on the ground, that engraving
would remain visible--and touchable if blind--when the bridge was lowered
to cover its spot.  Rather than try to handle two different engravings at
the same coordinates (with one of those two changing locations when the
bridge is raised or lowered), this just wipes out any engraving at both
span and portcullis locations whenever the bridge state changes, like is
done for traps.

accessible()

     There's some discussion in the newsgroup about an engraving bug, and
while verifying that it's reproducible I've come across an unintentional
change between the current code and 3.4.3.  A recent change made engraving
use accessible(), and that routine wasn't yielding an appropriate value
when applied to a raised drawbridge if the terrain in front of it was ice
or floor (ie, moat or lava had been filled in).  Several places which used
the ACCESSIBLE() macro instead of the function suffer from same problem.

     This doesn't attempt to address the newsgroup bug (which is that an
engraving written on a lowered bridge transfers to the underlying terrain
if the bridge is raised, even when that terrain is water or lava; the
converse case applies too, an engraving on the ground gets transfered to
the bridge when it lowers).

build warning

..\src\invent.c(931) : warning C4554: '^' : check operator precedence
for possible error; use parentheses to clarify precedence

restore_menu for >52 saved games (trunk only)

     There's no need to restrict the menu of restoreable games to 52 in
order to stay within a-zA-Z for entries; just let add_menu() do its own
selector assignments (reusing letters on each page).

tty_askname() fix [#if UNIX || VMS]

     Typing a response at the "Who are you?" prompt didn't allow digits in
the character's name under Unix and VMS; something like "arc15" came out
as "arc__".  This allows them to be used anywhere except for the first
character.  "arc15" now works; "15arc" ends up as "_5arc" so that there
still won't be a leading digit abutting the uid value when they're joined
to form the save file name.

restore_menu (trunk only)

     Move the code to use a nethack menu for restoring a saved game.  It
was inline in tty_askname() but is now a separate routine, restore_menu()
in restore.c.  There was no port-specific code and only a small amount of
tty-specific code; it should be useable by anyone (but Qt doesn't have to
switch over if it doesn't want to).

     The original behaved strangely if there were exactly 26 saved chars;
the "start new game" menu entry ended up using "{" as selection character.
There wasn't any comparable problem at 52; it was limiting the menu to 51
games.  Now it will allow 52 (with "start a new game" bumped into "#" if
there are that many), and adds an explicit quit entry (unless there are
52 or more games so that # is already used by new-game, then quit remains
implicit rather than resort to some other none-of-the-above character).

SELECTSAVED in #version (trunk only)

      makedefs wasn't including this optional feature in dat/options for
display via ``#version''.  It doesn't affect save and bones files but it
is something that may be of interest to users.  This change won't work for
UNIX+QT_GRAPHICS because that config is defining SELECTSAVED in files.c
instead of in unixconf.h.

     I think there are some other new things which are missing here too.

saved-games menu for vms (3 of 2) (trunk only)

     A copy+paste error was being masked by some temporary code.

saved-games menu for vms (2 of 2) (trunk only)

     First cut at implementing SELECTSAVED for VMS.

saved-games menu for vms (1 of 2) (trunk only)

     First cut at implementing SELECTSAVED for VMS.  Unfortunately, it only
works by default if the player is using a [probably] shared account called
"games" or "nethack", and displaying a menu of games available to restore
will likely have the side-effect of encouraging other players sharing that
account to steal each others saved games.  To use it with a normal account,
the player has to include "-ugames" or "-unethack" on the command line
(or OPTIONS=name:games in config file) to force the program to reach the
"Who are you?" stage.

     I've added a flag argument to set_savefile_name() so regularization
can be suppressed, allowing it to be used to construct a wildcarded file
specification.  I'm using that for VMS and have attempted to put in place
for WIN32CON, but the latter is not tested.

     The current WIN32CON and UNIX+QT_GRAPHICS methods of collecting save
file names is bug-prone if used on a shared playground directory.  Counting
matching file names first, then allocating memory and retraversing the
directory to copy those names into the allocated memory has a window of
vulnerability where the number of matching files could increase between the
counting and the copying.

crossbow range and rate (trunk only)

     From a bug report:
crossbow shot range shouldn't depend upon strength.  Make it fire for a
distance of BOLT_LIM regardless of whether if would have gone shorter or
longer by using the normal ranged calucations.  However, strength is
necessary to load crossbows, so make characters with low strength be less
capable of launching multi-shot volleys.

sacrificing tune-up (trunk only)

     There was code to give feedback if you attempted to offer the Amulet
on a regular altar instead of the final high altar, but that code was
unreachable; getobj() yielded "that's a silly thing" whenever you picked
an amulet while not on the Astral (or recently changed, Sanctum) level.
This allows you to try to offer the real or fake Amulet of Yendor on any
altar, but they'll only be listed as likely candidates when on the Astral
level.  Conversely, it no longer lists carried corpses as likely candidates
at the Astral high altars; they're still acceptable but not what the hero
is supposed to be fiddling with there.  Also, allow corpses on the floor
to be offered on high altars, fixing a complaint we've gotten a few times
over the years.  (Unfortunately there's no way to suppress them as likely
candidates on the high altars while still allowing them to be sacrified.)

engraving in inaccessible locations

     Also from the newsgroup (2nd from "Three bugfixes for Xorns" [I got
the subject wrong on the previous spell of protection patch]):  when
phazing through walls or rock you could engrave as if it was ordinary
floor.  Again I didn't use the user's patch; it left closed doors, raised
drawbridge, and iron bars as locations where engraving was still feasible
and said "you can't write in solid rock" even if you were inside a tree.
[The 3rd of "3 xorn fixes" was for misleading feedback when attempting to
engrave while underwater; we've already fixed that one.]

     There was a suggestion that you should be able to engrave within solid
rock if you use a wand of digging, and that seems like a pretty good idea,
but the check for location comes before the check for writing instrument so
would be tricky to implement.

spell of protection feedback

     From the newsgroup (subject: "3 xorn fixes"):  casting spell of
protection would report "the air around you begins to shimmer" even when
you were embedded in rock or swallowed.  It included a pointer to a patch;
I looked at that but ended up not using it.

endgame: high altars, offering the Amulet to Moloch (trunk only)

Several small related changes that ended up being not quite so small:

     Allow the Amulet of Yendor to be offered on the altar in the temple
of Moloch's Sanctum level; doing so is fatal.  Fake ones can be offered
too, but that doesn't do anything special (they act the same as they do in
the temples on the Astral level).  Unlike in the endgame, the Amulet and
its fakes aren't listed as likely candidate for #offer's pick-an-object
prompt; like the endgame, corpses must be carried rather than being on
the altar in order to be sacrificed.

     Prevent non-chaotics from destroying the chaotic high altar on the
Astral level via same-race sacrifice.  From a bug report.  (Chaotics converting non-chaotic high altars
via same method was already handled.  I think the behavior for ordinary
altars if wrong here; why should a chaotic altar be destroyed this way?)

     Prevent demon princes and demon lords from being summoned in the
endgame.  Lesser demons answer instead.  Mostly prevents Yeenoghu from
being summoned by a chaotic who performs same-race sacrified on the
chaotic high altar, but might affect the Wizard and arch-liches too.

     Identify (via ':', ';', '/') altars in temples on the Astral and
Sanctum levels as "high altars" rather than just as "altars".  '/' and ';'
commands now work on those when you're adjacent, like they do when used on
adjacent high priests; from farther away, the altars' alignment is still
suppressed.

poly'd quantum mechanic feedback

     From a bug report:  if swallowed and blind
and in quantum mechanic form, hitting the engulfer would yield "the <mon>
disappears" even though you were still swallowed by <mon>.  The pre-teleport
criteria for whether you knew the target was there were different from the
post-teleport ones.  Make them match; swallower will remain sensed by touch
and won't be described as disappearing.

stone-to-flesh on corpse-wielding golem (trunk only)

     A couple of months ago Michael forwarded a thread from the newsgroup
about how wielding a cockatrice corpse without gloves while polymorphed
into something capable of that would leave you wielding that corpse
bare-handed if you changed form, turned to stone, then got life-saved.
That got fixed; the corpse becomes unwielded.  However, one of the
messages in that described a different bug:  if you were wielding such a
corpse as a stone golem and cast stone-to-flesh at yourself, you would
continue to wield it bare-handed as a flesh golem.  This makes you revert
back to stone golem once the first transformation has finished.

     This also fixes an attribute exercising bug in polymon().  It was
being done after the polymorph was completed, so the attempt to exercise
Con didn't do anything because exercise() of anything other than Wis has
no effect when the hero is polymorphed.

lava, slime, bones

      From a bug report:  entering lava cures sliming,
but if you got [re-]afflicted by green slime after becoming stuck in lava,
#sit failed to cure it.  Fix that, and have sinking farther into lava cure
it too (although not necessarily right away).

     Also, suppress leaving the corpse in a bones file for death caused by
being dissolved in lava.  Lastly, suppress the "you rise from the dead as
a <monster>" message during bones creation when the game ends due to being
turned into green slime since you transformed rather than died (and sliming
timeout gives "you have become green slime" just prior to that).

moveloop() vs lava

     Something's wrong with the way lava was being handled in moveloop().
If you were trapped in lava (ie, moved into some but didn't die on the
spot thanks to fire resistance), you could sink and ultimately die without
ever taking another actual turn (typing ``i<space>'' repeatedly is an easy
way to reproduce).  [`didmove' was only being checked for the sinking
deeper case and not for the decrement which ultimately leads to the fully
sunk case.]  On the other hand, if you could manage to start an occupation
and avoid being interrupted, you would never sink while it was in progress.
[Lava handling followed ``if (multi && occupation) { ...; continue; }''.]

     While testing some other code (lava vs slime, coming shortly) I ended
up with the cursor sitting on the status line while the game was waiting
for me to enter my next move.  I don't really understand what's going on
there, and moving the lava handling before bot() might have hidden that
particular problem now by changing the point at which Slime will get taken
off the status line, but this attempts to fix it anyway.

dipping and greasing (trunk only)

     From a bug report:  you
can dip a worn item such as shirt or suit into a potion of polymorph and
it will become unworn--but as of a couple of days ago, unworn only if the
transformed object's new form can't be worn in the same slot--even if it
is covered by a cursed worn item (suit or cloak).  It didn't seem like
trying to fix that special case would be very worthwhile; this fixes the
more general situation of "you could dip worn items even though they were
covered up by other worn items".

     In the same report:  you could apply grease to rings while wearing
cursed gloves.  The code already prevented greasing a suit when it was
covered by a cloak (regardless of whether that cloak was cursed), and a
shirt when it was covered by a suit or cloak or both.  This moves that
code into a separate routine which is used for dipping as well as for
applying grease, and now handles rings vs gloves.

     Since covered rings, shirt, or suit are no longer eligible to be
dipped or greased, this also makes "?" for the pick-an-item prompt leave
such things out of the list of likely candidates.

north-south drawbridge

     From a bug report:  zapping a wand of striking or locking or spell of
force bolt or wizard lock up or down when standing at an open drawbridge's
portcullis didn't affect the bridge if the portcullis was positioned north
of the open span.  One of the two drawbridges on the Valkyrie quest goal
level has that orientation.  is_drawbridge_wall()'s name is somewhat
misleading; it isn't boolean and returns -1 rather than 0 for "no".

polymorphing worn items (trunk only)

     From a bug report.  That's hard to fix in the general case because armor
and tools might not fit back into the same equipment slot, but most other
types of worn items can be re-worn after being transformed.  This makes
any transformed worn item stay worn if it is wearable in the same slot.

minimal_xname (trunk only)

     simple_typename and obj_typename operate on item types rather than
particular objects so have to assume that the item involved has been seen.
That means that simple_typename(obj->otyp) is not suitable; if obj->dknown
hasn't been set, it gives away information.  This adds mininal_xname(obj)
to be used for that purpose.  I'm not aware of any straightforward way to
actually expose the original problem; it's more than hypothetical but not
something anyone's likely to have come across.

     Not fixed:  test driver program reveals that obj_typename(GOLD_PIECE)
and simple_typename(GOLD_PIECE) yield "coin of gold piece".  But I don't
think there's any way to get nethack to show that to the user.

inappropriate resistances

     Noticed when examining resists_magm() while working on anti-magic
traps:  if you were polymorphed, you would be granted magic resistance by
keeping a cloak of same or gray dragon scales/mail in your quiver slot,
your alternate weapon slot, or main weapon slot (ie, by wielding it).  And
you obtained light-based blindness resistance regardless of whether you
were polymorphed if you carried a potion of blindness in any of those slots.

anti-magic trap (trunk only)

     Make anti-magic fields do something against targets which have magic
resistance, expanding the functionality of that trap type and giving a
minor drawback to the most valuable intrinsic in the game.  Make them work
against monsters too.

     Heroes who lack magic resistance lose spell energy as before, except
that if they drop below 0 they don't take as hard a hit against max spell
energy as they used to.  Monsters with spell or breath attack and lacking
magic resistance get their ability-last-used field bumped up a little bit,
so they can't cast or breathe for a few turns.  Heroes and monsters who
have magic resistance take HP damage instead.  I retained the concept of
feeling lethargic when being hit by something which normally drains enery,
and also tried to make it be the inverse of a "magical explosion":  the
message refers to torpor/lethargy/sluggishness and cause of death if the
damage happens to be fatal is "anti-magic implosion".  The latter suggests
some sort of compression, so creatures who can pass through walls (xorns
and ghosts) have been given partial resistance and take reduced damage.

more Riders (trunk only)

     If a Rider's corpse revival timer ends with failure (presumeably
because the level has become entirely filled with monsters), give it a big
chance to try again in a few turns instead of always rotting the corpse
away.  Also, if there is another monster standing on the corpse when it's
due to revive, try to bump that monster out of the way to let the Rider
revive in place instead of having it be diverted to some other location.

Rider strengthening

      High resistance made the Riders unlikely to be polymorphed, but
they were susceptible to being turned into green slime (and then never
reviving if killed in that state).  Now they'll be immune to both types
of transformation.

levitation timeout vs traps (trunk only)

<email deleted>:
> If you enter a magic trap on the same turn that you lose your levitation
> and "float gently to the floor", you are hit by the trap twice.

     I don't think this is actually a bug, but it does look fairly strange
if there aren't any monsters attacking (after you move on to the trap,
monsters get a chance to move too before timeouts are run, but if there
aren't any messages triggered by monster activity then it feels like the
timeout and second activation happens immediately).  To prevent this, if
levitation is due to time out on the same turn that a trap is being
entered, either extend the duration by an extra move or make it end
immediately instead of waiting until end of current turn.  Deferring
timeout is a lot easier but doing that unconditionally would allow player
to move back and forth between adjacent traps without ever descending.
The early timeout might lead to anomalous behavior in obscure cases; it
seems to be working ok so far though.

another petrification bit (trunk only)

     Noticed while tracking down the "you die..." situation.  Duplicating
instapetrify()'s resistance checks is useful here, but there's no need to
also duplicate its death handling.

petrification fixes

     Eliminate the somewhat redundant "You die..." following "You turned
to stone..." when becoming petrified by touching a cockatrice (reported
by <email deleted> for kicking, but occurs for weaponless hitting too).
Also, if a cockatrice killed you with normal damage, your tombstone would
erroneously report petrification and presumeably there'd be a statue
instead of a ghost in the resulting bones file.  This fixes both things.

#tipping shop containers (trunk only)

     Using #tip (post-3.4.3 code) on a container that's on a shop floor
didn't handle ownership correctly.  Bag of tricks could be emptied for
free, and contents of other containers were being sold to the shop even
when the shop already owned them.  This fixes bag of tricks and makes a
first cut at doing so for regular containers.

     Message handling when #tipping any bag of tricks was also suboptimal
since the decision about message delivery was made again as each charge
released something instead of waiting until the whole bag was emptied.
So you could get inappropriate "nothing seems to happen" before or after
a monster visibily popped up if something unseen was also produced.

"(contents, N zorkmids)" fix (trunk only)

     Some code I recently added was misusing count_unpaid() and would
traverse some or all of inventory instead of just container's contents
when looking for unpaid items.  Add mew routine `is_unpaid(obj)' to do
what I was intending to do with count_unpaid().

more shopkeeper feedback (trunk only)

     The earlier change involving "you sneaky cad!" got me wondering, so
I looked up cad in the dictionary:  "an ungentlemanly man".  I can see
that being extended to a male gnome, even to an orc, but not to a women.

shopkeeper feedback (trunk only)

     Use verbalize instead of pline for shop "thank you, scum" message
(From a bug report.  Suppress shop "you sneaky cad" message
when removing a hero-owned pick-axe from a container inside a shop if the
shk is unable to speak; also give it at most one time per move (taking
multiple pick-axes out of a bag at once was way too verbose).  Honor
addtobill's silent flag for the bill overflow message when/if that occurs.

     Also adds a safe_qbuf usage for the #tip command that I had pending
for pickup.c.

using unpaid horn of plenty (trunk only)

     Make objects created by applying or #tipping a horn of plenty which
is owned by a shop also start out being owned by the shop.  That's in
addition to the usage charge for using an unpaid item.

     I think wishes conferred by unpaid objects, or by entities released
from unpaid objects, should probably work that way too, but have left
that alone.

clearing no_charge bit for containers

[I can't get access to my mail at present, but `cvs update' shows
that there aren't any patch notification messages pending for me.]

     Extend a pre-3.4.3 fix--for objects picked up in an untended shop--
to container contents.  Without it, dropping a bag or box in a tended shop
and declining to sell it, then picking it back up after the shop has become
untended (shk killed or evicted) would leave the contents with no_charge
set.  After that it could be sold in another tended shop, picked back up
for free, then kept or sold a second time.  (Picking it back up in the
tended shop would clear the bit; afterwards it behaved normally.  And it's
not something prone to abuse; if you can make a tended shop become untended
you really don't need to sell stuff twice.  But it'd be noticeably wrong if
anyone ever stumbled across it.)

unpaid shop goods in inventory (trunk only)

     Inventory display adds "(unpaid, N zorkmids)" to carried unpaid
items, but it didn't show anything comparable for indirect unpaid ones
(hero-owned containers holding shop-owned objects).  Now it will include
"(contents, N zorkmids)" in such cases.

#adjust tweaks (trunk only)

     Allow '#' as a destination slot if you've given '#' as the source
and there aren't any available inventory letters, making it possible to
use doorganize()'s feature of merging compatible items into one slot even
when that slot is #.  ('#' won't work as a destination when the source is
from a regular letter.  If the player wants to swap something in letter
slot x with whatever is in the # slot, he'll have to use # -> x rather
than x -> #.)

     Also, a post-3.4.3 change made it possible to produce an inventory
that used duplicate letters.  Giving a count while specifying the source
slot splits the source object.  But the extra '?' choice added to show
inventory letters in use didn't undo the split if player hit ESC to quit
early instead of specifying a destination slot.

     Lastly, don't prompt forever if the user doesn't give a valid
destination letter; give up after 5 attempts.

more inventory overflow control

     Prevent getobj() from overflowing its inventory letter collection
buffer if someone figures out some new way to fill up their inventory with
a huge number of # entries.  Inventory manipulation might become crippled
at that stage but at least it shouldn't be able to trigger a crash.

     Also, the !fixinv configuration was never taught about # and did
strange things if you had more than 52 items, both for inventory display
and object selection with getobj.

     The reassign()/getobj() situation is definitely confused regarding
gold, using GOLD_SYM in some places and def_oc_syms[COIN_CLASS] in
others, and it's schizophrenic about whether the GOLDOBJ configuration
keeps gold in a letter slot or specially named $ slot.  I'm sure there
are some problems there but I'm not planning to try to figure them out.

inventory overflow control

     Prevent heroes in giant form from picking up boulders once they run
out of available inventory slots to avoid an uncontrolled number of '#'
entries.  There is an exception:  if not already carrying any boulders,
they can put one into the '#' slot.  Loadstones are treated the same way,
although since they stack and are rare to begin with, someone would have
to have gone far out of their way to have gotten many # entries with them.

     Assuming that you can get something other than a boulder or loadstone
into the # slot (which is definitely possible, I just can't remember how),
you could relatively easily get three total # entries by picking up a
loadstone and polying into a giant and picking up a boulder.  But I don't
think there's anything wrong with that.

inventory overflow prompting

     If someone manages to get three or more items with inventory "letter"
'#', compact inventory selection prompts to list "#-#" instead of showing
every #.  It isn't possible to selectively pick a particular one anyway,
so this doesn't affect player choices.

1 #:  Which item? [$#a-zA-Z]
2 #:  Which item? [$##a-zA-Z]
3 #:  Which item? [$#-#a-zA-Z]
4 or more #: same as 3.

     This doesn't address the fact that picking up enough boulders as a
giant might overflow the BUFSZ buffer getobj() uses to collect inventory
letters prior to calling compactify() on them.

shop fixes

[I accidentally left this out of the previous commit.]

Throwing didn't handle a container owned by the hero which contained
items owned by the shopkeeper.  I'm still not quite sure what's going on
there, but throwing the container out of the shop didn't give any feedback
but did add to shop charges which don't show up in ``I x'' (but do get
revealed by ``$'' or ``I $'').  Now there's some shop feedback for the
throw and the contents show up for ``I x''.

shop fixes

     Try to fix multiple container-in-shop bugs; it seemed as if every time
I tried to investigate one I stumbled into another.  billable() (post-3.4.3
code, but already present in branch as well as trunk) didn't handle
containers properly.  It sometimes gave the wrong answer and it didn't
clear the no_charge flag of contained items as the old code in addtobill()
it replaced did.  stolen_value() didn't use the actual bill price for an
item already on the shop bill; it generated a new price which might be
different if the object was unID'd (3.4.3 had this one).  Throwing didn't
handle a container owned by the hero which contained items owned by the
shopkeeper.  I'm still not quite sure what's going on there, but throwing
the container out of the shop didn't give any feedback but did add to shop
charges which don't show up in ``I x'' (but do get revealed by ``$'' or
``I $'').  (This was intertwined with some of the other stuff and I don't
know how 3.4.3 behaved in this regard.  Now there's some shop feedback for
the throw and the contents show up for ``I x''.)  An unpaid container which
contained another nonempty unpaid container showed a different price when
picked up and in inventory display [k - a bag (unpaid, NNN zorkmids)]
compared to what was on the bill and showed by ``I u'' because the first
two included double billing of the nested container (just it, not its own
contents).  [There where a few recursive calls of the form
    x += func(x)
which should have been either
    x = func(x)
or  x += func(0).]  Purchasing used the right amount, I think.  I'm not
sure whether 3.4.3 had this particular bug or whether fixes for some of its
other container bugs inadvertently caused this one.

     This patch also changes stolen_container() to work like the other
recursive shop routines:  it just handles the contents, leaving the outer
container itself to be handled by its caller.  It seemed inconsistent, and
changing it simplified the fix for using bill price on stolen unpaid items.

shop price quotes (trunk only)

     Add some extra container feedback when shop items are picked up or
browsed via #chat.  Dropping items (sell prompting) already has such.

shop bits

     Eliminate a couple of minor redundancies; no change in game play.

dropy() - only check about selling object if there is a shop on the level.
pick_obj() - leave it to addinv() clear object's no_charge bit.

shop queries (trunk only)

     This eliminates a whole bunch of the "Query truncated" entries in
the nethack.alt.org paniclog file by using safe_qbuf() where applicable.
It also makes selling queries and some other shop messages be less verbose
when shopkeepers are invisible (not uncommon after characters achieve see
invisible capability) by using shkname() to get "Manlobbi" instead of
Monnam()'s "Manlobbi the invisible shopkeeper" (something I had planned
to do even before seeing the truncations in that paniclog; repetition of
"the invisible shopkeeper" was very annoying when stepping through
multiple unpaid objects with itemized billing).

     This also simplifies several GOLDOBJ conditional sections which
happened to be near the other code I was modifying.

the colour of magic

     Add Terry Pratchett's "octarine" to the set of hallucinatory colors.

wchar follow-up (trunk only)

- ensure that wchar.h is included even if it is not included
from another system header file as it is on some platforms.

- attempt to make the NHWCHAR_P definition more appropriate
for more platforms.

safe_qbuf, short_oname (trunk only)

     Change safe_qbuf() so that instead of picking one of three strings
for sprintf() to plug into a prompt string, it actually constructs the
full prompt string itself.  Also pass in the unformatted object and a pair
of formatting functions instead of performing dual formatting in advance.
The actual formatting is done via new routine short_oname() which also
takes an object and a pair of formatting routines plus a target length.
It uses the first routine, typically xname() or doname(), and formats the
object, then if the result is too long it makes some transformations, and
tries again.  If truncating "called foo" and "named bar" down to 12 chars
and omitting "uncursed, rustproof, thoroughly corroded" attributes still
result in a string that's too long, it uses the other formatting routine.
The latter calls one of several jacket routines around simple_typename()
to produce a short result.

     This has been through about four incarnations now and has gotten a
bit less testing each time, but I need to get it in place before I end up
running out of gas and abandoning it.  I've got some changes to shk.c
(where safe_qbuf is needed but not currently used) that now need to be
redone and will come eventually.

comment bit (trunk only)

A comment needed updating following Pat's patch.

comment bit (trunk only)

comment bit (trunk only)

yn_function (trunk only)

     Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
[See cvs log for doc/window.doc for more details.]

yn_function (trunk only)

     Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
-----

     While trying to eliminate the "Query truncated" entries present in
nethack.alt.org's paniclog, I seem to keep going backwards.  Allowing
<win>_yn_function() to accept a full QBUFSZ worth of characters will
simplify the existing yn_function() in the core and greatly simplify the
revised safe_qbuf() I've been working on.

     Some interfaces don't seem to care how long the prompt string is; I've
left those along.  Several of the others already copied the prompt string
into a BUFSZ sized buffer instead of a QBUFSZ sized one, making them
unlikely to suffer from buffer overflows.  This changes the rest (just tty
and Amiga, I think) to do the same.  Also for all that have any size
constraint, it now truncates the prompt query to QBUFSZ-1 chars as it is
used rather than continue to rely on the caller doing so.  This assumes
that appending the set of acceptable choices and the default response won't
overflow, which is a safe assumption unless/until QBUFSZ gets enlarged til
it's too close to BUFSZ.

     Only tty's topl.c has been tested.  The others should work ok, but
might possibly be bitten by a typo or two.  Qt's implementation of the X11
"slow" method (reusing a persistant one-line window for prompts) has been
handled, but its C++ class-based variant is untouched; NetHackQtYnDialog::
Exec() is completely baffling to me but doesn't appear to have any length
issues.

unhiding during summoning

     According to a newsgroup followup, a hidden pet summoned via magic
whistle could produce the same effect as the level change case (where
sometimes the glyph for unseen monster would appear unexpectedly).  I was
unable to reproduce this one, but I don't see anything in the code to deal
with the situation, so I suspect that the monster is moving immediately
and being revealed before I have a chance to notice anything odd.

     I assume that other situations where hidden monsters get teleported
are being handled as attacks which expose them.  At least I hope so.

unhiding during level change

     From the newsgroup:  if a pet was hiding under an object next to you
when you changed levels, it could arrive hidden at the destination if there
was something available to hide under there too, and sometimes you'd start
the new level with a hidden monster glyph at its location.  I was able to
reproduce that once with current trunk code, but while trying to figure
out what is actually happening I've been unable to make it happen again.
However, it doesn't make sense for a monster to be able to remain in hiding
during the level change in the first place, so this patch prevents that.
(I'd still like to know how/why map_invisible() is sometimes getting called.
[The test character was a level 1 tourist without auto-search capability.]
I'm reasonably sure that it won't happen any more once this fix in place.)

     This also brings adjacent pets out of hiding when they accompany you
during ascension or dungeon escape, but it seems that that wasn't actually
necessary.  The end of game disclosure already lists such by name rather
than as "it", contrary to my expectations.  (I had forgotten that end-of-
game forces true names so that blindness and hallucination don't interfere
with disclosure; obviously that ends up handling hidden monsters too.)

Remove win32 mapi mail from distribution (trunk only)

more unicode follow up

Set the unicode restriction bit when loading a symset when appropriate,
and a win32 console refinement.

unicode follow up

attr value was only getting one byte allocated instead
of 1 * sizeof(nhwchar), so add required paranthesis.

botl.c follow up (trunk only)

add some unicode support (trunk only)

This patch attempts to add some levels of unicode support
to NetHack.

The master on/off switch for any Unicode support is
defining UNICODE_SUPPORT in config.h. Currently
there is code support for two subsets of unicode support:

UNICODE_DRAWING

If UNICODE_DRAWING is defined, then the data
structures used to house drawing symbols are expanded
to the size of wchar_t, big enough to hold unicode characters.
A typdef called `nhsym' is involved and if UNICODE_DRAWING
is defined, it is wchar_t, otherwise it is uchar.

UNICODE_WIDEWINPORT

If UNICODE_WIDEWINPORT is defined, then the data
structures inside the window port are expanded to the size of
wchar_t, big enough to hold unicode characters.  Both map
symbols and text within the window port are expanded, in order
for potential support for displaying multinational characters some
day, but this patch only provides viewing of map symbols.
A typdef called `nhwchar' is involved and if UNICODE_WIDEWINPORT
is defined, it is wchar_t, otherwise it is char.

The only window port with code support for UNICODE_WIDEWINPORT
currently is the TTY port.  Don't enable UNICODE_WIDEWINPORT
unless:
- it is a TTY port
- the underlying platform specific routines can
handle the larger data structures.

Don't enable UNICODE_SUPPORT unless:
- your compiler can handle wchar_t.
- your compiler can accept L'a' characters.
- your compiler can accept L"wide" strings.

Note that if your compiler can handle the above, you could
enable the larger data structures (currently if TTY) even if your
platform can't actually display unicode or UTF-8, by messing
with u_putch() in win/tty/wintty.c to only deal regular chars.
That should be the only function that actually pushes wide characters
out to the display.

If you enable UNICODE_SUPPORT, and your platform is capable
you will need to turn on the unicode run-time option to be able to
load unicode character sets from the symbol file, to be able to
push unicode characters to the display. You'll also want to load
a unicode symbol set once the unicode option is toggled on. In
a config file you would do that via these two lines:
OPTIONS=unicode
OPTIONS=symset:Unicode_non_US

The repository was stamped with NETHACK_PRE_UNICODE
prior to applying this patch, and stamped with
NETHACK_POST_UNICODE afterwards. The code differences
between those two tagged versions are this patch.

add some unicode support (trunk only)

This patch attempts to add some levels of unicode support
to NetHack.

The master on/off switch for any Unicode support is
defining UNICODE_SUPPORT in config.h. Currently
there is code support for two subsets of unicode support:

UNICODE_DRAWING

If UNICODE_DRAWING is defined, then the data
structures used to house drawing symbols are expanded
to the size of wchar_t, big enough to hold unicode characters.
A typdef called `nhsym' is involved and if UNICODE_DRAWING
is defined, it is wchar_t, otherwise it is uchar.

UNICODE_WIDEWINPORT

If UNICODE_WIDEWINPORT is defined, then the data
structures inside the window port are expanded to the size of
wchar_t, big enough to hold unicode characters.  Both map
symbols and text within the window port are expanded, in order
for potential support for displaying multinational characters some
day, but this patch only provides viewing of map symbols.
A typdef called `nhwchar' is involved and if UNICODE_WIDEWINPORT
is defined, it is wchar_t, otherwise it is char.

The only window port with code support for UNICODE_WIDEWINPORT
currently is the TTY port.  Don't enable UNICODE_WIDEWINPORT
unless:
- it is a TTY port
- the underlying platform specific routines can
handle the larger data structures.

Don't enable UNICODE_SUPPORT unless:
- your compiler can handle wchar_t.
- your compiler can accept L'a' characters.
- your compiler can accept L"wide" strings.

Note that if your compiler can handle the above, you could
enable the larger data structures (currently if TTY) even if your
platform can't actually display unicode or UTF-8, by messing
with u_putch() in win/tty/wintty.c to only deal regular chars.
That should be the only function that actually pushes wide characters
out to the display.

If you enable UNICODE_SUPPORT, and your platform is capable
you will need to turn on the unicode run-time option to be able to
load unicode character sets from the symbol file, to be able to
push unicode characters to the display. You'll also want to load
a unicode symbol set once the unicode option is toggled on. In
a config file you would do that via these two lines:
OPTIONS=unicode
OPTIONS=symset:Unicode_non_US

The repository was stamped with NETHACK_PRE_UNICODE
prior to applying this patch, and stamped with
NETHACK_POST_UNICODE afterwards. The code differences
between those two tagged versions are this patch.

botl.c follow up (trunk only)

window port change - putmixed()  (trunk only)

Add putmixed() to the window port. It allows map symbols to
be included in the string by encoding them in a unique fashion.
This was done because Unicode symbols, for instance, could be
longer than the size of a char.

The encoding of the map symbols in this patch is done by
prefixing a glyph value with \GXXXX, where XXXX is a
random value for the current game. The reason for the random
prefix is to minimize the possibility that a player can trigger
the escape sequence processing within text under their control
(dog names, etc.) the way they could if the sequence was fixed
in the source code. The random prefix remains the same throughout
the lifetime of a game because message window strings are
saved in the save file.

(There was actually a bug present because of the embedded
character even before the recent symbol changes, because if
someone was using a  different set of characters between games,
the saved messages would reflect the original characters, rather
than the current. That bug was introduced with the ability to
save messages to the savefile.)

A window port does not have to supply an XXX_putmixed() routine,
it can use genl_putmixed() which uses the old behavior of
embedding the sequence as a character within the string
and calling putstr(). genl_putmixed() takes care of the decoding
of the escape sequence.

This also #ifdef's out code in pager.c for converting a glyph
to a character, and uses mapglyph() to do that instead. Does
anyone see a problem with doing that through mapglyph instead
of repeating similar code within pager.c?

symset restrictions (trunk only)

The restricted bits could end up set on non-restricted sets.
This case needs to check that we're in a matching set.

surviving petrification (trunk only)

     From the newsgroup:  if you were wielding a cockatrice corpse without
gloves while polymorphed into something capable of doing that, then were
turned to stone when rehumanizing, you'd be left wielding the untouchable
corpse if life-saving kept the game going.  This causes it to stop being
wielded if you get that far.  Likewise for monsters.