Add way to cycle through valid locations for polearm or jump target

Add whatis_filter option to filter eligible map locations for travel

Compound option whatis_filter, filters the eligible map locations
when getting a cursor location for targeting. Accepts 'n' (none),
'v' (map locations in view), or 'a' (map locations in the same area,
eg. room or corridor).

fix misplaced #if in sys/msdos/pckeys.c

Reported directly to devteam, so no #H number.  If SIMULATE_CURSOR
isn't defined, there would be no switch statement to attach the
subsequent cases to.

The suggested fix is obviously correct, but untested....

fix #H5781 - missing fprintf args in wc_trace.c

This compiles cleanly after the fixes, but is otherwise untested.

fix #H5780 - file pointer freed twice

win/share/tileset.c seems only to be used by the MSDOS port, but it
compiles cleanly on OSX after these changes.

A file pointer was passed to fclose() twice, second time potentially
causing problems.  There were cases of potentially null pointers
being passed to free() too.  That should be safe these days, but it's
something we've tried to hard to avoid and would probably trigger
complaints from our own MONITOR_HEAP code if that ever got applied
here.

util updates: lev_main.c and recover.c

Change lev_comp's add_opvars() to be like pline(), where there's a
single visible opening brace and a second one hidden in VA_DECL2
that introduces a nested block, plus a single visible closing brace
with a hidden one in VA_END() to close the nested block.  This
addresses the erroneous report (sent directly to devteam, so no #H
number, subject "missing '{' in util/lev_main.c:634") that the code
for !USE_STDARG/!USE_VARARGS in add_opvars() wouldn't compile.

Also, fix the part of "#H5778: file descriptor leaks" dealing with
util/recover.c -- an open file not being closed after various errors.
I didn't take responsibility for this entry in the bugzilla list
since the report includes similar problems in other code that's not
addressed here.

And a blast from the past:  some reformatting fixups in recover.c.
The most interesting bit is for a block of dead code....

mons[0]

Alex mentioned that loops over mons[] were starting at [0], which
should be [LOW_PM] instead.  I only found two, and the mvitals[] one
was benign.  The special level one might have been too, depending
upon spec_lev's thoroughness--I didn't attempt to check.

Once upon a time there was a possibility of moving 'playermon' from
a separate variable to mons[0], so LOW_PM became the index of the
first valid monster.  Instead, 'playermon' went away altogether.
LOW_PM (and NON_PM) could go away too, but I don't see how reverting
to hardcoded 0 and -1 would be an improvement.  We have enough
problems as it is with "giant ant" turning up in unexpected places
because someone used 0 instead of NON_PM to mean "none of the above".

health recovery

This started out as just an attempt to remove some duplicated code,
but mutated.  Move health recovery into a separate routine to
streamline moveloop().

Intentional changes:
1) when poly'd hero is at max u.mh (hit points as a monster), do
   not recover lost u.uhp (hit points when in normal form).  That
   was caused by a missing !Upolyd check in the long if..elseif..
   elseif..endif logic.  If we want to make it deliberate, I think
   some u.uhp recovery in rehumanize() would be the way to go.
2) regeneration for poly'd hero in sea monster form (ring worn on
   left or right pectoral fin) now counteracts the loss of hit
   points for turns spent out of water.  [Do eels even have fins?]
3) poly'd hero with moderate or worse encumbrance and lacking
   regeneration wouldn't recover any health.  Now he/she will do so
   if not moving [on the magic (moves%20 == 0) turn when u.mh
   recovery takes place].

If there are any other changes in behavior, they're unintentional.

Remove obsolete code allowing 1-indexing the monster list

Having selectable base indexes for the monster list doesn't seem
likely to be needed in the future any more, now that the code for
the monster list is stable. Additionally, the functionality in
question has bitrotted heavily (e.g. many "loops over all
permonsts" start at a hardcoded 0, which wouldn't work with a
1-indexed monster list). As a result, removing the relevant code
in makedefs makes it clearer what can and can't be assumed about
the code, reducing the risk of bugs in the future.

Thanks to FIQ for mentioning that this could be an issue.

some artifact.c formatting

I managed to separate these bits from the touch/retouch fix.
I almost threw then away, but one's a spelling fix in a comment.

fix commit ebd6bb62f58a : #H4383 - blasted twice

by Excalibur.  Noticed on Reddit by Alex, the attempt to fix being
blasted twice by wielded artifact weapon when changing alignment
ended up preventing wielding other role's quest weapons.  At the
moment I can't even see how it prevented the double-blast....

This backs out that change and fixes the double-blasting correctly.
When uwep and uswapwep are tested in advance of the rest of invent,
mark them as already processed before entering the loop that checks
all not-yet-processed inventory.

fix #H3013 - grammar bug with named fruit

Reported nearly four years ago for 3.4.3, original subject was
\#H3013: NetHack grammar bug when taking unpaid fruit from chest

Player used OPTIONS=fruit:Quorn and the capitalized value confuses
the() into thinking it's a proper name which shouldn't be preceded
by an article, resulting in "Quorn will cost you N zorkmids" when
removing it from a chest in a shop, followed by "X - a Quorn (unpaid)"
as it went into inventory.  It is a product name, but when used as a
fruit it shouldn't be treated as a proper name.  (Quorn is a meat
substitute rather than anything related to fruit.)  Teach the() about
named-fruits, so that we'll get "The Quorn will cost you N zorkmids."

Unfortunately, it means that someone who names their fruit after a
proper name used by the program, for example Mjollnir, can probably
induce other poorly worded messages (about the item rather than the
named-fruit).  the() is used all over the place and all it has to work
with is text, not the object whose formatted name produced that text.

I looked through a bunch of old cvs log messages last night, and
spotted one I wrote (in objnam.c) a dozen years ago where I suggested
forcing named-fruit values into lower case as they're being set up.
I don't remember that, but if we'd done it, this bug would have been
avoided.

releaseobuf() fix

The object name formatting routines operate using a pool of buffers to
hold intermediate and/or final result.  Some routines consume multiple
intermediate buffers, so use releaseobj() to try to reuse just one in
order to avoid churning through too many and maybe clobbering live
data.  It worked as intended for routines that use nextobuf() directly
but wouldn't haved worked right for xname(), also doname() and other
xname() callers.  This fixes that.

There have never been any reports of garbled messages which could be
traced to clobbering of formatted object names, so this fix is mostly
academic.

named-fruit manipulation

Add some new routines for dealing with fruit.  I had hoped they would
let the existing fruit handling be simplified quite a bit, but the
improvement wasn't great.  However, they're also groundwork for fixing
an old bug.

tribute typo

wishing for tins

A couple of days ago when verifying the report about being forced to
pay for a second tin when eating one from a stack on a shop's floor,
wishing for 'tins' (rather than 'tins of foo meat') was repeatedly
producing tin wands instead.  The name "tin" and the wand description
"tin" in objects[] were being given 50:50 chance for either one by
the 3.6.1 wishing code.  Wishing for "tins of spinach" also gave me
a tin wand on the first attempt.  Handle 'tin(s)' more explicitly.

This also does some reformatting.

more obj filtering

Add support for filtering by unpaid status for container-in and
container-out actions.  When taking out of a container, it works as
expected if you're carrying the container while in a shop, but won't
find any unpaid items if the container is on the floor.  That's
because they're only flagged as unpaid while in the hero's inventory.
(And when it doesn't find any unpaid items it won't list 'unpaid' as
a category of item to manipulate, so while that might be suboptimal
for taking items out of shop containers, it shouldn't be a problem.
Typically all the contents are shop-owned anyway, so using unpaid as
a filter wouldn't gain any advantage over just taking stuff out.)

fixes36.1 update: #H4725 - repeated shortcut keys

Mark an old 'unconfirmed' bug as 'fixed'.  The report was for win32gui
and I can't reproduce the problem or verify that it's gone, but I'm
sure enough about the cause and long-ago fix to put #H4725 to rest....

Report was that the menu for the name-from-discoveries-list command
was reusing a set of punctuation characters for each class of objects.
The key was that '!' was always first, and it is (' ' + 1) so the core
bug of erroneously specifying space for a selector on object class
header/separator lines was being used as the start of the selector
sequence.  (Report that led to the fix was that typing space on that
menu always made it finish instead of advance to the next page.)

tribute: The Amazing Maurice

and His Educated Rodents.  The last Discworld book with only one or
two passages to choose from when reading.

robustness of #timeout and #wizintrinsic

Remove the assumption of property index values from the list of
property names.  Move the properties that can't have timed values
in normal play to after those which can.  (Mainly only matters for
the #wizintrinsic command.)

Bug fix: #wizintrinsic variable 'any' wasn't initialized properly
if 'a_int' is smaller than a long or a pointer.  The separator line
I've added was ending up as a menu choice.

eating 1 of N floor tins in shop

Reported directly to devteam, eating 1 of 2 tins of spinach from a
shop's floor forced the hero to buy both.  (1 was gone, the other was
intact and now owned by the hero rather than the shop.  Tins of other
contents behaved similarly.)  The bug is easy to fix but not so easy
to explain:  eating split one from the stack but passed the remaining
stack to useupf(obj,1) which also split one off and treated that as
used up.  The second one was billed as used up and the first one was
added to the bill--as being subjected to a costly modification made by
the hero--and kept intact, now marked no-charge with hero obligated to
pay for it.

Eating 1 of N tins, for N greater than 2, billed for two, one gone and
the other now in a separate stack and marked no-charge.  The remaining
N-2 stayed as normal shop goods in their original stack.

The fix is communicate the splitobj() for costly modification up-call
so that the use_up_tin code operates on the one which was split off
the stack rather than on the remainder of the original stack.

set 'bouldersym' via 'O'

Reinstate the deprecated 'bouldersym' option for the 'O' command
instead of just showing the set-at-start-of-play value.  I leave
boulder with the default value except when attempting to solve
Sokoban, and it's a pain to have to save, edit config file or
reset NEHTACKOPTIONS, then restore in order to change the boulder
symbol, then do that all over again once leaving Sokoban.

If using the default symbols, a custom symbol set which just sets
boulder will work, but with {DEC|IBM}graphics that's no help
because the unspecified symbols revert to their default values.

Make #wizmakemap handle unpaid items and punishment

extend #timeout to cover all properties

Extend the wizard mode #timeout command:  show timeouts for all 67
intrinsics rather than just a handful.  Most won't appear because
they don't have any way to receive a timed value.  Except for...

Extend the wizard mode #wizintrinsic command:  allow setting a
brief (30 turn) timeout for any/every intrinsic, not just for
deafness.  It ought to prompt for duration, but that's more effort
than I'm willing to expend.  This might turn up lots of quirks that
the code isn't prepared to handle (like setting life-saving to
non-zero will break the assumption that it comes from worn amulet).
Perhaps some will warrant fixing, others just a shrug.

There are still some timed events that aren't listed by #timeout:
remaining duration to stay polymorphed in current form, number of
turns until it's safe to pray, luck decay, number of turns until
next attribute exercise/abuse check, probably others that I'm
overlooking.

Bug fix:  while testing, I observed
  Your limbs have turned to stone.
  You have turned to stone.
  You can hear again.
  You are a statue.
when deafness and petrification were timing out at the same time.
This modifies the stoning and sliming countdowns to extend deafness
duration a little if it's about to time out at the tail end of the
stoning or sliming sequence, so that "you can hear again" won't
happen until after life-saving.  There are probably other variations
of simultaneous or near simultaneous timeout that interact oddly.

update wizhelp for ^O and #wizwhere

I think ^O changed when the dynamic key-binding code was incorporated.
It's a shortcut for #overview in all modes.  To get the old wizard mode
behavior, use #wizwhere.

Add an entry for #terrain, expand several of the descriptions, and fix
up the formatting (remove periods in ^ section, align text in # section).

Show more properties in wizmode #timeout

BUCX filtering

The different menustyle settings have been offering different degrees
of support for BUCX filtering:
  Full       : multi-drop, container-in, container-out
  Trad, Combo: multi-drop
  Partial    : none (to be expected; it explicitly jumps past class
    filtering, where BUCX gets handled, to a menu of all objects)

This adds pickup, container-in, container-out, multi-unwear/unwield,
and object-ID for Trad and Combo, and multi-unwear/unwield for Full.
(Full behaves like Partial for pickup--not sure why--and for object-ID,
bypassing filters to go straight to a menu of all applicable items.)

There are probably several new bugs--this stuff is very convoluted....

address #H5426 - inventory category selections

Report #5426 was classified as not-a-bug, but the underlying issue
can be improved.

For item selection where BUCX (bless/curse state) filtering is
supported (mostly for menustyle:Full, but there are a few actions
where Traditional and Combination handle BUCX too), 3.4.3 took the
union of object class and bless/curse state (so ?!B gave all scrolls
and all potions and every blessed item from other classes) but 3.6.0
changed that to the intersection (so ?!B gives blessed scrolls and
blessed potions, period).  Since gold is inherently not blessed or
cursed it has been getting excluded during intersection handling
when that includes BUCX filtering.  Report #5426 was from a player
who was used to choosing $X when putting newly acquired loot into a
container asking to have the old behavior reinstated.

The ideal fix would be to support both union ($ | X) and intersection
(?! & B), but implementation would be bug prone and the interface,
especially when done for menus, would be cumbersome.  Instead, this
adds new boolean option, goldX, to allow the player to decide whether
gold is classified as uncursed--even though it is never described as
such--or unknown.  The new-loot-into-container issued can be solved
either via $abcX, where abc lists all classes that have any X items
(when gold is included as one of the classes, its BUCX state is now
ignored for the current selection), or by setting the goldX option
and then just picking X for the types of items to put into the
container (or drop or whatever other action supports BUCX filtering).

The situations where menustyle:Full allows BUCX filtering during
object class specification and styles Traditional and Combination
don't should to be fixed (by extending BUCX support to Traditional
and Combination rather than removing it from Full, obviously).

Add sanity checking for long worms

add missing fixes entry for #H4761 polyself msg

fix #H4761 - misleading polyself message

From end of last December:  turning into a "new man" or "new woman"
used the right gender if the hero was polymorphed at the time, but
always used "new man" if it happened when trying/failing to polymorph
while in original form.

options.c formatting

Fix a couple of things I noticed in options.c.  I didn't try to
make any comprehensive searches for misformatted stuff.

iflags fields

A small amount of comment formatting in flag.h, plus rearranging
some of the boolean fields into alphabetical order.  I only touched
one section of struct instance_flags.

dat/opthelp formatting (mostly)

Make the formatting of 'opthelp' be more consistent.  When entries
span multiple lines, sometimes the default value was shown on the
first line, sometimes on the last.  This puts it on the first line
which is more useful for quick looks with 'grep'.

This also adds an explanation for the value of 'disclose', adds
missing choice "full compass" to 'whatis_coord', and expands upon
the explanation for several other compound options.

As mentioned at least once before, menu_* is missing win32 in the
list of interfaces that support the various menu accelerators.

fixes36.1 fix

The extra entry about 'A' was intended to go into the "post-3.6.0
code exposed by git repository" section since that's where the
impossible: "cursed without otmp" was introduced.

yet another pass at 'A' bugs

I think this finally quashes the "cursed without otmp" issue.
Various ways of destroying wielded weapon used setnotworn() rather
than unwield(), so the previous change to have unwield() clear the
pending W_WEP bit from takeoff.mask wasn't sufficient to prevent
'A' moving on from another item (blindfold--it's the only thing
processed before primary weapon) to weapon which wasn't there any
more.  Also, if weapon was already set in takeoff.what to be
processed on the next move, clearing W_WEP from takeoff.mask wasn't
sufficient either.

Move the previous unwield() 'fix' to setworn() and setnotworn() and
extend it to include cancel_don() if the item being replaced or
removed is in progress or scheduled for next.  (Most of the time,
remove_worn_item() has already done that before setworn() or
setnotworn() is called.)

dynamic format strings vulnerable to user input

This adds new utility routine strNsubst(), a more versatile version
of the existing strsubst(), that can replace the Nth occurrence of
a substring rather than just the first, and replaces all occurrences
if N is 0.

When working on vampire shape-shifting messages a few days ago I
noticed that a constructed pline/sprintf format was vulnerable to
the player giving the vampire a name with '%' in it and included
a fix for that.  This fixes two other instances of the same
vulnerability:  a monster with reflection triggering a floating
eye's gaze and the hero using a silver weapon against a silver-
hating monster.

I didn't do a lot of experimenting with the failure, just assigned
the name "foo%s" to the floating eye or the weapon.  The resulting
feedback for the relevant messages was garbled due to parameters
being substituted in the wrong place.  When that caused there to be
too few arguments to satisfy the format, the final message included
"null" for the missing one rather than triggering a crash while
trying to format something arbitrary from the stack.

I don't think these bugs provided sufficient user control to be
vulnerable to stack manipulation that does something naughty.

I found the dynamic format strings by searching for "%%".  There
may be others scattered around the code which don't have that as
an indicator....

m_monnam() usage

m_monnam() overrides hallucination, which is appropriate in some
situations but not others.  This fixes one instance where it was
being misused:  discovering a hidden monster when another monster
attacks it was calling either m_monnam() or a_monnam(); one ignores
hallucination and the other doesn't, so accurate or inaccurate
monster type depended on the condition tested.

Figurine activation and egg hatching are using m_monnam(), which
seems suspect, but I left them as is.

'A' again - avoid stale takeoff.mask

The do_wear.c part just eliminates some redundant code but shouldn't
produce any change in behavior.

The steal.c part should fix problems with 'A' when outer items are
taken off during theft in order to steal an inner item, where the
outer item is next to be removed (call to cancel_don() wasn't being
made).  The wield.c part matches the X_off() behavior and is needed
to handle a weapon item that's slated for removal but isn't next (so
wouldn't pass the donning()/doffing() test to trigger cancel_don()).

If this seems a lot like trial and error, it is....

'A' interruption

Extend the 'A' blindfold fix from three weeks ago to cover weapons
too.  This might fix the problem being caught via curse(NULL) when
using 'A' to remove multiple items.  The blindfold bug was straight-
forward since it was requiring two turns but not checking for loss
of blindfold when interrupted by theft.  Weapon/alt-weapon/quiver
each only need one turn so I'm not sure what's really happening to
trigger problems for them.

vampshifting fog could vs door

Noticed while composing a reply to the #H5547 report about named
vampire shape-shift message.  The message when a vampire (possibly
in vampire bat form) turned into a fog cloud in order to pass under
a closed door was using a stale cached mon->data value when choosing
the verb.  So normal fog cloud or vampire already in fog cloud shape
would "flow" under the door, but newly shifted fog cloud would "ooze"
under the door.  I saw this while testing the previous patch but its
significance didn't register at the time.

fix #H5547 - named vampire shapeshifting message

Report was about "Pet vampire" but the relevant aspect was that the
vampire had been assigned a name, not that it was tame:
You observe a Hilda where a Hilda was.

Investigating this has uncovered two other bugs, one potentially
serious.  m_monnam() overrides hallucination but seems to be getting
used to some situations where hallucination should be honored (several
instances).  Dynamically constructed format strings are including
monster or object names in the format (rather than the usual use as
arguments), so player assigned names containing percent signs could
cause havoc (a few instances).  This fixes some of the former and one
of the latter, but doesn't deal with various other cases revealed by
grep.

explode.c bits

Update a comment prompted by '#H5459 - explosions and steeds'.
Also a couple of formatting changes.

This doesn't attempt to address the reported issue:  hero's and
steed's resistances are intermingled when exploding at the hero's
coordinates and influence the effect on both.  Inherited from the
behavior for an engulfed hero, and might not necessarily be a bug.

displaying detected tame monsters

This started out as a fix for '#H5460 - minor monster detection bug'
but that report turned out to be wrong.  It claimed that pets weren't
highlighted as pets if the only way to observe them was via extended
monster detection, but the code (both 3.6.0 and current) indicates
otherwise.  Detected monster highlighting is bypassed for pets.

Reorganize the code slightly to emphasize that this is intentional:
tameness trumps remote detection when choosing which highlight method.
For tty, if hilite_pet and use_inverse are both enabled or both
disabled, you can't see the difference anyway.  At least I can't....

That report also wanted the use_inverse option to be changed (I guess
it's overloaded for multiple things) so I haven't marked #H5460 as
closed.

fix #H5524 - green dragon breath

> Green dragons should probably not cough in their own breath.

They took no damage, but they did become blind.  Make creatures who
breath poison gas (adult green dragons, the Chromatic Dragon) be
immune to gas clouds like non-breathing creatures are.

There's no way to distinguish gas left behind by dragon breath from
that created by scroll of stinking cloud, so gas breathers are no
longer affected by the latter.

simplify vampshift message

Simlify the earlier revision for "the seemingly dead creature suddenly
transforms and turns into a vampire".  x_monnam() already handles "the"
the way we want here:  it's suppressed when the monster has a name
assigned and the "seemingly dead" phrase is omitted.

fix #H5507 - vampire death message bug

Fix a couple of weird messages issued when a shape-shifted vampire
is "killed" and reverts to regular vampire form instead of dying.
First weird one was when vampire has been given a name, as reported.
Second was noticed while fixing that:  when cause of death destroys
the creature so thoroughly that there'd be no corpse, the alternate
phrasing for noncorporeal or amorphous form should be used.

old:
 The Dracula suddenly transforms and rises as Dracula!
 The vampire bat is disintegrated.  The seemingly dead vampire bat
 suddenly transforms and rises as a vampire!
new:
 Dracula suddenly transforms and rises as a vampire!
 The vampire bat is disintegrated.  The seemingly dead vampire bat
 suddenly reconstitutes and rises as a vampire!

fix #H5486 - artifact naming vs illiterate

Attempting to name the relevant type of item with an artifact's name
(such as a runesword with "Stormbringer") fails with "your hand
slips" in order to prevent turning the item into an aritfact.  Since
that only happens when the name is valid, it indicates that the hero
is literate so violate illiterate conduct.

(Naming items in general doesn't affect [il]literacy so that player
can assign names to inventory or stash items to maintain notes.)

dumplog of map

When writing the known portion of the current level's map into
dumplog, discard any blank rows at the top (there will already be
one blank line separating it from the text that precedes) and keep
at most one blank row at the bottom (sometimes there won't be any).

high priest extinction

This issue has been around for a while but wasn't noticable to players
until some post-3.6.0 tweaking of end of game disclosure.  When testing
the DUMPLOG artifact_score fix, I level teleported to the Astral Plane
and performed a cheat ascension.  Final disclosure listed high priests
as extinct.  Same thing would happen after visiting Moloch's Sanctum
instead.  (The latter didn't interfere with creating the Astral high
priests if you got that far, just as creation of the first one there
didn't prevent the other two.)

I forget why high priests are flagged as unique (something I think
I'm responisble for...), but they shouldn't share unique's setting of
extinct during monster creation.  (They could be set that way after 4
are created, but this fix doesn't do that.  It just treats them like
ordinary monsters so you'd need 127 or 255 or some such to make them
become extinct.  Unlike other creatures with a special creation limit,
high priests can be produced when aligned priests gain experience--an
event that I don't recall ever noticing happen.)

dumplog revisions

I saw dumplog text in a newsgroup posting and the only way I could
recognize what version generated it was that "You entered the dungeon
N turns ago" included the missing-until-recently final period.  So,
put nethack's one-line version information as the very first dumplog
text and follow it with the dumped game's start and end date+time.
(That information is useful to know in its own right, but also should
prevent the build date+time shown with the version from confusing
anybody about when the dump was written.)

Along the way, I noticed that the 'counting' phase for artifact_score
was being repeated for '#if DUMPLOG' even though it doesn't generate
output.  That had a side-effect of adding points for artifacts twice
(applicable when final score was for an ascension or dungeon escape).

more movement prefix vs invalid direction

If user enters Fz when 'cmdassist' is off, respond with "Invalid
direction for 'F' prefix." instead of "Unknown command 'Fz'."

fix #H5462 - failed F-attack gives misleading msg

Report was for 'F' followed by '.' reporting "cmdassist: Invalid
direction key!" and then by a direction grid (which happened to
include '.' for self).  That behavior applied for all the movement
prefix keys ('m', 'G', &c).  When 'cmdassist' was off, "F." would
yield "Unknown command 'F.'." instead.

Now you'll get "You can't fight yourself.", either instead of the
"invalid direction key" part of cmdassist feedback (followed by a
direction grid which excludes up, down, and self since they aren't
applicable for prefix keys) or of the "unknown command" result.
Likewise, "You can't run upward." or "You can't rush downward."
for "G<" and "g>", respectively.

'A' vs blindfold

Fix an inconsistency with blindfold removal, eliminating possibility
of a panic (3.6.0) or an impossible (since mid-December, 2016).  The
'A' command treated blindfold removal as a multi-turn operation, the
rest of the wear/unwear code as single-turn operation so didn't try
to guard against it being disrupted.

fix #H5245 - levitation boots message sequencing

Report was for
  You finish taking off your boots.
  You float gently to the altar.  [destination was a red herring]
  [take some action to run through moveloop() for next turn]
  Your movements are slowed slightly because of your load.

Having float_down() do the next encumbrance check instead of
waiting for moveloop() to do so was straightforward.  However,
while testing I noticed the reverse situation (not due to the fix
for the above) when putting on levitation boots
  Your movements are now unencumbered.
  You finish your dressing maneuver.
  You start to float in the air!

Having float_up() do the encumbrance check isn't adequate to fix
this, because it takes multiple turns to put on boots but the
properties they confer are enabled immediately, so moveloop() runs
while hero is already levitating even though the game hasn't told
the player about it yet.  Fix is a hack to defer the effect of
levitation on encumbrance until the boots are fully worn, which
might lead to strangeness somewhere.  It's also boot-specific so
will need to be updated if some other multi-turn armor that confers
levitation ever gets added.

fix #H5416 - misleading attribute message

Report was for losing strength when sitting on a throne, but the
message issue was more general than that.  Character was wearing
gauntlets of power, so no visible change in strength took place,
but player was told "you're already as weak as you can get" (because
the attempt to reduce strength didn't change current strength;
however, it did change the hero's underlying strength, observable
once the gloves were removed).

There was a beta report last January that was related:  in that case
the player thought that gauntlets of power were preventing blessed
potion of gain ability from raising strength, but it was actually
giving a misleading message claiming that strength was already as
high as it could get.

Fix:  vary the message when something prevents an attribute change
from being noticeable.

^X/enlightenment tweaks

Noticed while working on something else:
  You entered the dungeon N turns ago
was missing the terminating period, and when polymorphed into a
1 hit die critter, plural "hit dice" is incorrect.  0 hit dice is
confusing even when fully spelled out, so include an explanatory
remark with it.

Don't include score (available if configured with SCORE_ON_BOTL)
unless player has the 'showscore' option enabled.  The value is
an approximation--accurate as far as it goes, but the value can
change depending upon how the game ends.  Someone who asks to have
it displayed on the status line will probably be used to that, but
others might start reporting bugs for it.

couple of formatting bits

timeout.c:  the luck timeout expression caused a bit of thought trying
to decide whether it was doing what was intended (it was).  Add some
parentheses so that thought is no longer required.  ;-)

worn.c:  fix up a macro where automated reformatting mistook a
bitwise-and operation for a cast applied to the address of something.

setmangry fixes

Some discussion in the newsgroup about nearby peaceful monsters becoming
hostile if they observed the hero attacking a peaceful monster made me
look at the code and I spotted a couple of problems.  An auto array was
being initialized in an inner block--some pre-ANSI compilers couldn't
handle that.  Worse, it was inside a loop and may or may not have
resulted in unnecessary setup each iteration.  Make it static.  Oddly,
the array had the same name as a function but `gcc -Wshadow' either
didn't notice or didn't care.

A more significant problem was that mon->mpeaceful was being set to 0
without checking whether mon->mtame was set, potentially resulting in
humanoid pets being both tame and hostile at the same time.  This change
prevents that but doesn't do anything interesting about pets who observe
attacks against peacefuls.  (I also wonder why chaotic peacefuls now get
upset by seeing other peacefuls be attacked; it seems out of character.)

There was also a check for non-humanoid peacefuls seeing another of the
same species be attacked, but it was checking for an exact match without
regard for littler or bigger incarnations of the same species.  I've
added the latter.

This also reformats a couple of block comments.

fix #H5333 - overview annotation for quest summons

The automatic annotations supplied for various special levels were
treating the quest leader's summons as being mutually exclusive with
the other things of interest.  It's not, so wasn't shown if the entry
portal was on either the bigroom level or the rogue level.  Handle it
differently from the rest so that it can stack with annotations for
those levels.  (The annotation for the portal itself, which doesn't
get added until traversed, was already handled differently and shown
correctly on those levels.)

autodescribe vs DUMPLOG

Keep getpos's autodescribe feedback out of the DUMPLOG message history.
Unfortunately it still gets put in interface-specific message history
and is liable to fill up the buffer there, forcing actual old messages
to be flushed away.

autodescribe vs detection

Temporary map views for detection or #terrain allow moving the cursor
around to get the brief location description provided by getpos's
autodescribe feature and were doing so by forcing the 'autodescribe'
option to True, then leaving it that way.  Save the option value prior
to such operations and restore it after instead of leaving it changed.

fix #H5264 fix

MSGTYPE handling was being suppressed, except during prompting when
it was intended to be suppressed.

partial fix for #H5216 - sortloot inconsistency

The tie-breaker for the qsort comparison routine used for 'sortloot'
had its logic backwards.  Instead of retaining the original relative
order for tied items, it inadvertently reversed them.  So a chest
containing
  club
  dagger named A
  dagger named B
  dagger named C
  long sword
would alternate between that order and
  club
  dagger named C
  dagger named B
  dagger named A
  long sword
each time the chest's contents were examined.  This fixes that, and
also simplifies the unnecessarily convoluted bless/curse state handling.

The other half of the report was a request that 'sortloot:n' not do
any sorting.  Right now, if the player has 'sortpack' set then
'sortloot:n' results in grouping into object classes within pack order
rather than not sorting at all.  (Also, armor and weapons are further
ordered within their groups:  armor by slot [helms, gloves, shields, &c]
and weapons by function [ammo, launchers, missiles, 'ordinary', pole-
arms].)  I think the proper fix is to add a new setting for 'sortpack'
which yields the current behavior before changing 'n' to leave things
in their unsorted order.

maybe fix #H5264 - screen clears on prompting

I couldn't reproduce the reported problem of the "In what direction?"
being issued after the screen was cleared, but bypassing pline() in
favor of putstr(WIN_MESSAGE) for tty prompts did also bypass
  if (vision_full_recalc) vision_recalc(0);
  if (u.ux) flush_screen(1);
done in pline().  Inadvertent loss of the latter could conceivably be
responsible for the problem.  If so, the escape code used by cl_end()
may be broken for somebody's termcap or terminfo setup since clearing
to the end of the line in the message window shouldn't erase the rest
of the screen.

Regardless, the prompting change also bypassed the ability to show
the prompt with raw_printf() if the display wasn't fully intialized
yet, so some change to the revised prompting was necessary anyway.

Switching back from putstr(WIN_MESSAGE) to pline() resulted in
duplicated entries in DUMPLOG message history, one with bare prompt
followed by another with response appended, so more tweaking was
needed.  The result is use of new custompline() instead of normal
pline().  custompline() accepts some message handling flags to give
more control over pline()'s behavior.  It's a more general variation
of Norep() but its caller needs to specify an extra argument.

tty prompting fix and DUMPLOG of prompts+answers

Update DUMPLOG's message history to include player responses to
most queries.  For tty, both getlin() and yn_function().  For other
interfaces, only yn_function() is covered.  (It's intercepted by a
core routine that can take care of the logging; getlin() isn't.)
Also includes saved messages from previous session(s), for the
interfaces which support that (tty), to fill out the logging when
a game ends shortly after a save/restore cycle.

The tty interface was using pline() to display prompt strings.
Having 'MSGTYPE=hide "#"' or 'MSGTYPE=hide "yn"' in .nethackrc
would suppress many prompt strings (in the two examples mentioned,
entering extended commands or the vast majority of yes/no questions,
respectively) and generally lead to substantial confusion even if
done intentionally, so switch to putstr(WIN_MESSAGE) instead.

fix Bell of Opening segfault

Noticed on nethack.alt.org; the Bell of Opening could trigger a
segfault if applied near a trap door or bear trap (and a few others)
that had no monster at the trap location.  Reproducible if done
while mounted; {open,close}{fall,hold}ingtrap() would try to access
monst->mx and monst->my of a Null monst pointer if given one when
u.usteed was non-Null.

fix #H5188 - getting an artifact break illiterate

To-be-3.6.1 bug, caused by a patch (of mine...) incorporated about
a week after 3.6.0 was released that was intended to be for naming
Sting or Orcist.  Any artifact creation ended up breaking illiterate
conduct whether user-assigned naming was involved or not (because
oname() is always used to apply the name, not just when do_name() is
executing).

This should be handled differently but I don't want to go through
the dozen and half or so calls to oname() to add an extra argument.

more control key formatting

The previous fix to use highc(UNCTRL(x)) worked for ^A through ^Z,
but not for NUL (yielded ^` instead of usual ^@) or ^[ through ^_
(yielded lowercase ^{ and so on).  The problem was UNCTRL(); it
shouldn't have been forcing on the lowercase bit to begin with.
Also, the code that used UNMETA() for formatting wouldn't work as
intended for M-control char since it stripped off the 8th bit but
didn't apply any fixup for control chars.

Just get rid of ISCTRL/ISMETA/UNCTRL/UNMETA and use the existing
visctrl() routine instead.  (Its 3.6.0 edition didn't handle
M-control char, but the to-be-3.6.1 branch has done so since a
week or two after the 3.6.0 release.)

Show control key combos with uppercase alpha

Instead of ^r, show ^R, as that one is used everywhere.

Document explicitly what m-prefix does to each command

dumplog message history groundwork

Separate the message logging out of pline so that other things (for
instance, one-line summary for quest block messages) can be logged.
The code that utilizes this isn't ready for prime time yet.

For FREE_ALL_MEMORY, release DUMPLOG message history when saving.
(Actually, this frees it unconditionally rather just doing so for
FREE_ALL_MEMORY.)  It was being freed when logged at end of game,
but not during save.  If dumplog message history and interface
message history get integrated, the existing message history
save/restore handling should become applicable instead.

vanquished monsters tidbit

Use the same terminology ("creatures" rather than "monsters") for
the two "no <foo> {have been, were} vanquished" messages as for the
"disclose vanquished <foo>" prompt and its "M <foo> vanquished"
summary.

dumplog fixes: genocide list, survivor's tombstone

The dumplog data was including a final tombstone unconditionally,
which looked awfully strange for characters who didn't die.  Make
it conditional, like actual end-of-game tombstone.  (One difference
though:  dumplog has a tombstone for hero who died from genocide,
end-of-game does not.  I think the latter should display one even
though no grave gets generated.)  [Potential for future enhancement:
add some alternate ascii art in place of tombstone for survivors.]

The list of genocided and/or extincted species was never shown
since caller passed 'a' to list_genocided() and it expected 'y'.
Also, once shown, the list entries were lacking indentation that
other sections of the dump generally have.

Both vanquished monsters and genocided/extinct monsters included
a blank line separator even when there was no feedback, making a
noticeable gap in the dumplog text.  Have them report "no creatures
vanquished" and "no species genocided", when applicable, so that
their separator lines always have something to separate.

When dumping, omit a couple of blank lines each from vanquished
creatures list, genocided species list, and tombstone so the
relevant sections of the dump are more compact.

more DUMPLOG lint

The recently added dumplog code assumed that 'time_t' is 'long int'
or at least will give sensible results when formatted with '%ld'.
This is more of a Band-Aid(tm) than a proper fix.

dumplog's saved_plines[]

Use a simple ring buffer instead of a flat array that needed to have
49 pointers shifted down a slot every time a pline message was issued.

'saved_plines[saved_pline_index]' is the oldest message in the buffer
and the next slot to use when adding a new one.

miscellaneous formatting

dumplog lint and formatting

Add end-of-game dumplogs

This is based on the "new" dumplog patch for 3.6.0, by Maxime Bacoux.

Define DUMPLOG to enable. By default only enabled for the TTY linux.

fix #H5082 - growing into opposite sex monster

When a female dwarf grows (via level gain) into a dwarf lord, it
changes sex as well as base monster form because all dwarf lords
are male.  The earlier fix for #H4276 (16-Mar-2016, to give an
alternate grow-up message acknowledging the change) used the wrong
monster form (monst's old one instead of new one).

some fixes36.1 fixes

Fix a couple of typos, change one entry which referenced internal
coding issues to a more general description for end-users, and remove
a duplicate about color handling for status hilites and menucolors.

(I've only skimmed through the first section.  There are likely more
inconsistencies in the file.)

fix rumors.tru typo

"They say that an ooze will bite your boots and a rockmole will eat them."

'rockmole' should be two words.  Also, rock moles won't eat leather
boots, so change 'will eat' to 'might eat'.

fix g.cubes eating green slime

Back when dead green slime left a corpse, gelatinous cubes wouldn't
eat that, but they would eat globs of green slime without being
affected.  Add the missing glob check so g.cubes will engulf globs
of green slime instead of eating those.

Fix #H5056/bz1086: Bug in Achievement Recording

Bug report was:

> "Completed sokoban" achievement was logged when picking up
> a randomly generated bag of holding in the gnomish mines.

The picking-up code was missing checks for the branches, so
you could get the achievements outside the correct branches.

Allow changing max name len via hints file

Fix complaint about uninitialized variable

Fix Valgrind complaint of uninitialized memory

Fix use of freed memory when snuffing a potion of oil

Document paranoid_confirm:all

tribute typos

Prevent a segfault with leashed vanished monster

It's apparently somehow possible to have a leash "attached" to
a monster not present on the current level. Complain instead of
segfaulting. (This is a post-3.6.0 bug)

Accessibility: option to prevent status line updates

Apparently some screen readers keep reading the status lines
at the bottom of the screen when parts of those change.
Add an option to prevent updates to those lines.

Show all statusline info in #attributes

Fix mnearto return value confusion

This caused appeased shopkeepers returning to their shops being killed.

Silence Yet Another Valgrind complaint

Silence some Valgrind errors

Need to have the allocated memory explicitly cleared for Valgrind
to know it.  We should probably start using calloc or something...

Modified player name list to include new team members.

Fix valgrind complaint in wizmode terrain

The code was writing characters into row[x-1] in the loop, but putting the
string terminator at row[x], leaving one character between uninitialized.

tty's compress_str(), core's dat/keyhelp

Rewrite 3.6.1's compress_str() to avoid peeking past the end of the
input string.  This should eliminate the reported valgrind complaint.
The problem was noticed for post-3.6.0 code introduced [by me...] last
June, but it looks like it was present in the old code too.

Also, fix the wording in the paragraph about NUL in the keyhelp text.

tty_putstr() always passes non-message window text through compress_str(),
clobbering usage of two spaces to separate sentences.  putstr()'s caller
ought to have more control over that (possibly via its hardly ever used
'attribute' arg?).

Fix wishing for tins of specific type

I believe this bug already existed, but was only exposed by
my wishing parser change post-3.6.0