Revert "transformation message when you apply a figurine"

This reverts commit e2b187f2f1e38987ece327f43ae6500ce5cd5567.

Revert "ensure BL_FLUSH always gets sent down to the window port whenever bot() is"

This reverts commit ee4c12b2388981926577d8095c314ab3490aff93.

ensure BL_FLUSH always gets sent down to the window port whenever bot() is
called with context.botlx set so that status updates work as
expected after full screen clear after a level change

Fixes #107

transformation message when you apply a figurine

make transformation message of a deliberate apply of a figurine seem a bit
less definite when blind. Put 'I' unseen monster marker at the spot you
expect it to be.

quiet a new visual studio compiler complaint from recent code change

..\src\hack.c(2553): warning C4113: 'int (__cdecl *)()' differs in parameter lists from 'int (__cdecl *)(void)'

Merge branch 'NetHack-3.6.2-beta01' of https://rodney.nethack.org:20040/git/NHsource into NetHack-3.6.2-beta01

reports on windows of partial status lines after level change

tty: turn off an optimization that is the suspected cause of Windows reported
partial status lines following level changes. It was turned on for
        non-unix platforms only

Split pickup checks out of dopickup

Fix pickup awful hack

If pickup has been bound to some other key than ',', the awful hack
did not work correctly. Testing, I couldn't notice the difference,
but probably just not doing the right thing...

adjust wizidentify title and prompt

wizidentify suppress unnecessary prompt; allow individual items for perm ID

Don't display the selection to identify all items if there are none.

Complete an item marked ToDo in cmd.c: allow selection of one or more
particular items to permanently identify rather than just all or nothing.

Guidebook update

I noticed that the description of ^O still referred to the 3.6.0
behavior (either #wizwhere or #overview depending upon play mode)
rather than the 3.6.1 behavior (unconditional #overview).

While updating that I changed a bunch of "Wizard-mode" references
to "Debug mode" which is the proper end-user name.

I slightly expanded the descriptions of #wizdetect, #wizgenesis,
\#wizintrinsic, WIZKIT, and Debug mode, and removed at least one
out of date reference to debug mode being a conditional feature.

And for most of the stuff I was looking at, I changed the nroff
source to honor the roff guideline of having each sentence start
on its own line (and also the latex source to use those same line
breaks even though they don't need it).

Not done:  a lot of quoted single characters use 'c' instead of `c'
(pair of ticks rather than back-tick and normal tick).  One form
or the other should be changed so that they're all consistent.
I'm pretty this was mentioned the last time it was formatted for
the web site.

Guidebook.mn has been tested, Guidebook.tex has not.

Use DEADMONSTER instead of checking mhp

fix wiz identify bugs

Fixes #124

Fix github pull request #124 which was also reported directly (but not
through the contact form so #Hxxx number).  Using ^I or #wizidentify
displays inventory with everything ID'd for that command only and adds
a menu entry "_ - use '^I' to identify" that can be chosen to make
those ID's persistent.  Picking underscore would work but picking the
alternate '^I' wouldn't work if the platform had unsigned characters
for plain 'char'.  Switch the return value from magic number -1 to
magic number ^I which isn't a valid inventory letter and isn't subject
to sign conversion.  Casting -1 to '(char) -1' would have worked too
despite some confusion expressed in discussion of the pull request.

If ^I has been bound to some other command and #wizidentify hasn't
been bound to any keystroke, temporary ID didn't disclose any extra
information (ie, acted like ordinary inventory display) and the extra
menu entry to make temporary ID become persistent wasn't available.
This fixes that too.

Document windowcolors option

Split string parsing and monster creation out of create_particular

Fix monsters not wielding digging implements

My change to unify the pet and monster digging weapon choosing
made monsters not actually wield the chosen weapon, even though
they could still dig as if they did. Pets behaved properly.

Also add an explicit check for IS_STWALL so they won't keep
switching away from their current weapon until needed.

fix #H7354 - incorrect material

for parchment and vellum spellbooks.  Parchment and vellum are made
from animal skin rather than from plants, so classifying spellbooks
with those descriptions as paper is inaccurate.  Changing them to be
made out of leather has a couple of side-effects:  eating them while
polymorphed will break vegetarian conduct and polymorphing them might
result in a leather golem rather than a paper one.

I left "leathery spell book" as paper since that directly refers to
the cover.  The composition shouldn't be changed--the pages of such
a book are still made out of paper--but the effect of eating one
possibly should.  (That description originally was "leather" and got
changed.  I don't remember the details and assumed it was due to odd
wishing behavior, but there's a commented-out routine in eat.c which
suggests it was related to eating instead.  Anyway, "leathery" is
still non-leather.)

Make it clear when a leprechaun dodges your attack

It was not obvious what was happening when a leprechaun dodged
your attack. Add a message to explicitly spell it out.
Code by aosdict.

Hallu YAFM for stumbling onto an undetected monster

Pokemon reference. Based on an idea by aosdict.

Make wish prompts not remember the input

With EDIT_GETLIN, the wish prompt remembered the previous input,
but this isn't actually useful.

another fix fox "killed, while helpless"

Augmented death reason with appended "while <helpless-reason>" was
broken in 3.6.0 and got fixed shortly after release (too late to
prevent high-score files from being corrupted).  Then within a
couple of weeks it got broken again, and doesn't work in 3.6.1
either (but in this case, it is omitted instead of being cloned
to all following score entries).  The problem is in both record
and logfile, but not xlogfile, so we could create a fix up routine
that would use the last to repair record (and perhaps logfile).
But having two fixup routines would probably lead to confusion.

The problem this time was bad logic in the fix for
|alter name of monster causing hero's death if name contains
|    characters that could cause confusion when using record,
|    logfile, or xlogfile later
killerformat() was going out of bounds of the input string and
using up all of 'siz' so that there was never room to append the
", while helpless" suffix.

shop damage repair

Fixes #121

Fix githib issue #121 - shopkeepers don't charge for consecutive
acts of vandalism on the same square.  pay_for_damage() keys its
action on the 'when' field of the damage structure, and when a
second type of damage gets added to existing damage, that wasn't
being updated.  Both bits of damage (broken door or dug wall plus
trap created at same spot) get repaired together but shopkeeper
wasn't challanging hero to pay for the second one (trap).

The repair process had issues too.  If you broke a shop door, paid
off the shopkeeper, then left the level before the repair took
place and came back after (or rather, catching up for lost time
repaired it when you returned to the level), it didn't actually
get fixed and remained a doorless doorway that was considered to
have been successfully repaired (record of damage discarded).
Unless there was also a trap there; then the door did get properly
fixed when the trap was removed.

Object scattering during wall repair was bypassed if trap removal
took place.

Also, trap removal while off level still gave messages when it took
place after you returned.  I didn't try to verify that; it's possible
that vision is in a state where you can't see the repair even if you
return to a spot where it would be visible.  But the return value
from the repair routine was one which wanted a message instead of
the one to suppress messages.

Not addressed:  digging a pit inside a shop (aside from in doorway
or breached wall) is not treated as damage which should be repaired.
This includes the case of digging up a grave which converts the spot
into ordinary floor (plus pit trap).

fix github issue #125 - grave gold not buried

Fixes #125

When a random grave included some gold among whatever treasure was
generated, that gold was left on top of the grave instead of being
buried inside it like other treasure.

I'm sure this was intentional but only because mkgold() puts the
gold on the ground and merges it with other gold if there is already
some present.  Keeping an existing stack of gold distinct from the
new one in order to bury the latter is feasible but clumsy.  Just
make a new gold object directly, bypassing mkgold(), and bury that.

git pull request #123 - wallification vs map edge

Fixes #123

Make sure wallification doesn't go out of bounds when operating
near the map edge.  The top and left edges were ok (although the
left edge could uselessly try to wallify unused column 0) but the
right and bottom ones weren't validating the map boundary.  None
of the 3.6.x levels were affected.

I've done this a little differently from the suggested commit in
the pull request.

fix #H7352 - panic when floodfilling large areas

Special levels with FLAGS:inaccessibles could trigger a panic if
a large enough area was subjected to floodfill handling.  The buffer
intended to be enough to hold an entire level wasn't big enough when
individual coordinates were being added multiple times.  I don't
really understand what this code is doing but the recommended fix
does work to prevent the panic.

None of the levels included with 3.6.x were affected.

quest message typo

Remove an extra space from Val 00021.

This does not address github issue #124 where the extra space shown
on the message line is the result of combining two separate plines
rather than coming from the data.

adjust wording on recent install.mw change

previous change bit

inconsistency going down a hole/trapdoor accidentally vs deliberately

Noted on rgrn, after being told that you don't fit upon discovery
of a hole or trap door you could then immediately use '>' to
proceed down.

The deliberate situation remains possible and has some
inherent risk.

fix github issue #122 - #turn takes 0 time

Fixes #122

When #turn won't work due to angry god or being in Gehennom, it
aggravates monsters instead.  But that was taking no time.

10.11 is out of date these days but it's the most recent version that
I can vouch for.

further OS X clarification

fix #H7342 - seduction sequencing

Interrupt seduction if the hero gets moved away from the seducer, or
if both of them move to another level.  Loss of levitation can drop
the hero onto a trap which sends him/her somewhere else, but seduction
was continuing as if nothing had happened.  In theory it could continue
despite level change because succubus and incubus are level followers,
but there's no way of knowing whether seducer and victim will arrive
next to each other until they get delivered and that doesn't happen
until long after the attack needs to finish.

I don't think theft has the same problem because it is a multi-turn
activity operating on one item at a time, but I didn't check it out.

suit_simple_name()

Unlike cloak_simple_name() and helm_simple_name(), suit_simple_name()
wasn't guarding against Null.  Current usage never trips up against
that, but when I added a new use in doseduce() [pending], it caused
a crash.

Merge branch 'NetHack-3.6.2-beta01' of https://rodney.nethack.org:20040/git/NHsource into NetHack-3.6.2-beta01

fix #H7334 - hearing seduction msgs while deaf

Various seduction messages with a verbal component were being given
to hero even when deaf.  This uses alternate messages if some cases
and bypasses the message in others.  In particular, if hero is deaf
then he or she will not be given the choice to decline removing a
piece of armor--or taking off or putting on a ring of adornment--
that can ordinarily occur (based on die roll against Charisma).

The seduction code was also using '!Blind' to test whether the hero
could see his/her seducer, ignoring the possibility that it might be
invisible.  I think the only ramification is that "It" would appear
in messages instead of the "She" or "He" that are explicitly used
when not seen due to blindness.

fix github issue #120 - quest message typo

Fixes #120

The one-line summary [for inclusion in message history] of the priest
quest's block message when bringing the quest artifact back to leader
misspelled "congratulations".

Makefile recognition of VS 15.7.5

github pull request #102 - Popeye vs Fixed_abil

Fixes #102

This is a simplified version of the code in pull request #102,
which replaces "You feel like Popeye!" with "You feel like {Olive
Oyl or Bluto}!" if eating spinach fails to provide a strength gain.
I think you should still feel like Popeye if the lack of gain is
due to already being at maximum, so I left out the change to make
gainstr() return a value which indicates whether a change took place.

Unfortunately, if you're both already at maximum and have attribute
changes suppressed by Fixed_abil, the latter overrides and you'll
feel like Olive Oyl or Bluto.  I think that situation is too obscure
to bother with the complexity of figuring out if you're at maximum
for the purpose of a silly message.

fix github issue #116 - farlook at corpse

Fixes #116

Farlook in 3.4.3 used xname() and just described any corpse as
"corpse" whether you knew the monster type or not.  3.6.x switched
to doname() and describes it as "<mon-type> corpse", but if it isn't
there anymore, the fake object contructed for it would have a random
corpse type.

For corpses and statues, the map glyph provides enough information
to give the fake object the same type as the original.  For other
items that have a monster component (figurines, tins, eggs) it does
not, nor for other doname attributes of objects in general (which
might be picked up by monsters rather than rot away).  So this fixes
the rotted-away-corpse-seems-to- become-random-corpse issue but not
the general case of the details for a remembered item which isn't
there anymore.

restore vs perm_invent

Redo how updates of permanent inventory window are suppressed during
restore.  Reverses part of e9f1e032717921cb7a51c0f2822628355a35ec36
which included a simpler attempt to deal with this.

It looks like we should have been getting impossible "unpaid_cost:
object wasn't on any bill" but segfault was reported; I haven't tried
to figure out why.  The band in xname() ought to be redundant now but
is included for bulletproofing.

github pull request #113 - shopkeeper placement

Fixes #113

Incorporate the contents of pull request #113 to fix shopkeeper setup
for irregularly shaped shop rooms.  Code intending to adjust the Y
coordinate was erroneously incrementing the X one instead.  (I'm not
sure whether we have any irregular shops at all but if so, they don't
have the necessary orientation to trigger this bug.)

And add a couple of formatting tweaks in the vicinity....

fix #H7256 - bug WRT eating rings

Wearing a negatively enchanted ring of increase <foo> would enhance
the bonus gained from eating another ring of the same type when you
got "the magic spreads through your body" effect so could be eploited.
Conversely, wearing a positively enchanted one would make you lose
that worn amount when gaining any bonus from eating one.

fix github pull request #114 - ant holes in *.des

Fixes #114

Report and contributed fix described lack of support for room type
"ant hole" in the code that loads special levels (and mentioned that
none of our des files attempted to use that room type so it isn't
noticeable in unmodified version of the game).  The fix overlooked
a couple of other missing room types (leprechaun hall and cockatrice
nest) so I didn't use the pull-request's commit (so not sure what
github's automated updating will make of 'Fixes #114').

fix github issue #111 - stone-to-flesh of statues

Fixes #111

Casting stone-to-flesh at a random statue animates it as a monster
(created via direct call to makemon()) at an adjacent or nearby spot
if there is already a monster at the statue's spot, but doing so on
a statue of a petrified monster (create attempt via montraits() which
called makemon() without the ADJACENTOK flag) turned it into a corpse
instead.  Pass an extra argument to montraits() so that it behaves
the same normal statue animation for stone-to-flesh without changing
how it behaves when reviving corpses for undead-turning.

hilite_status: score vs !SCORE_ON_BOTL reprise

Handle suppression of 'score' from the 'O' menu for viewing and
setting hilite_status rules differently so that the count of the
number of rules will always match the number of rules shown by the
'a - View all hilites in config format' choice.  If there are score
rules in the config file for a game running under !SCORE_ON_BOTL
configuration, list 'score' normally but if player picks that menu
entry, the followup menu will have the existing rule(s) and 'X -
remove selected hilites' but not 'Z - Add a new hilite'.  If there
aren't any score rules--or there were some but they've now all been
'X'd--then 'score' won't be listed as one of the status fields.

hilite_status: score vs !SCORE_ON_BOTL

When built without support for SCORE_ON_BOTL (the default), suppress
'score' field from 'O' menus for adding/removing hilite_status rules.

Also, add "encumbrance" as field name synonym for "carrying-capacity"
and "experience-points" for "experience".  Relevant for rules set in
config file or via NETHACKOPTIONS.

more hilite_status condition attributes

The formatted value for attributes of condition highlights was
reporting 'normal' (aka no attributes) even when the highlight
rule specified some other value.  It initialized a bitmap variable
to ATR_NONE, which is not 0, and then or'd other bits to that.
Then during formatting it checked whether the ATR_NONE bit was set
and returned 'normal' without examining the other bits.  Actual
highlighting wasn't affected, just the strings in the rule set
shown by the 'O' command.

This is a separate issue from the earlier 'bonus fix' where the
attributes of previous condition rules got clobbered if a
hilite_status:condition/any-color&normal rule was added.

hilite_status attributes

Take a step towards eliminating merging hilite_status rules during
highlighting by creating a single rule instead of multiple ones
when specifying multiple attributes for the same highlight via the
'O' command's menus.

Old:
 (pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&bold
 (pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&blink
New:
 (pick_one menu to pick a color) + (pick_any menu to pick attributes)
| hilite_status:title/always/red&bold+blink

At present, rule selection during highlighting still merges multiple
applicable rules instead of finding the best one first, with the
problems that entails.

Bonus fix:  a hilite_status rule for status conditions which specified
"no attributes" would clear attributes for all previous condition
rules rather than just the one(s) in that "no attributes" rule.

fix github issue #110 - sortloot segfault

Fixes #110

NetHack dumped core while qsort was executing for sortloot.  Fix a
logic error introduced by adding filtering capability to sortloot()
which could result in a sparsely populated array instead of having
the number of elements be less than the list size.

I don't know why this didn't show up sooner.

fix github issue #109 - healing spells

Fixes #109

Spells of healing and extra healing cast at monsters were handling
monster blindness differently from other forms of healing.  (Potions
also work differently when drunk by monsters but I haven't changed
that since it seems to be intentional.)

Hero:
   potion of healing cures blindness if blessed; spell of healing
      cast at skilled or better now behaves likewise;
   potion of extra healing cures blindness if not cursed; spell of
      extra healing is inherently not cursed and already behaved
      likewise;
   potion of full healing always cures blindness even if cursed.

Monsters quaffing potions:
   plain healing cures blindness if not cursed;
   extra healing and full healing always cure blindess.

Hero casting healing spell at monster:
   plain healing behaves like the hero plain healing case:  cures
      blindness as if blessed when cast at skilled or expert level;
      this is a change in hehavior--it used to cure timed blindness
      even if unskilled and not cure 'permanent' blindness at all;
   extra healing cast by hero is inherently not cursed so always
      cures blindness.

more glob wishing

Wishing for "<size> glob of black pudding" worked, and wishing for
"black pudding glob" worked, but wishing for "<size> black pudding
glob" didn't work.  Fix that.

Also, remove a bit of spaghetti introduced by the previous patch.
And once we know we're wishing for a glob, we can skip a big chunk
of wish parsing and special case handling.

fix githib issue #108 - wishing for mimic corpse

Fixes #108

"small"/"medium"/"large" prefix was being stripped off during wish
parsing so that it could be used to control glob size.  But those
are also prefixes for monster and/or object names.  Wishing for
"small mimic corpse" or "large mimic" corpse failed with "nothing
matching that description exists" when it tried to satisfy "mimic
corpse".  (Asking for "giant mimic corpse" worked as intended.)

Not mentioned in the report:  wishing for "large {dog, cat, kobold}
corpse" produced the corpse of corresponding normal sized critter
instead of that of a large one.

Noticed while testing the fix:  wishing for "glob" failed rather
than pick a random glob type.  Wishing for "glob of grey ooze"
failed even though "grey ooze" is recognized as a variant spelling
for the gray ooze monster.  Wishing for "<monster type> glob" also
failed even when the monster type was viable for globs.  This fixes
all of those even though no one will ever notice....

Wishing for "small box" (and "medium box") no longer yields a large
box, it fails with "nothing matching..." instead.  I was ambivalent
about the earlier change which had the unintended side-effect of
making them synonyms for "large box" so haven't tried to revive it.

more polymorph of worn item

The earlier change for 'fix github issue #106' could result in a
polymorphed weapon being worn in multiple weapon/alt-weapon/quiver
slots.  Reorganize the relevant code more thoroughly this time.

fix github issue #106 - polymorph panic

Fixes #106

If dipping a worn amulet into a potion of polymorph turns it into an
amulet of change, the game panics while trying to use up that amulet
when the new one hasn't replaced the old one in inventory yet.  Simply
reordering the relevant code isn't sufficient to fix things:  once it
is in inventory and can be successfully used up, later code would end
up deferencing a stale pointer because it was unaware of the deletion.

build fix, avoid use of 'class'

Build fix, avoid use of 'class'

include\hack.h(199): error C2236: unexpected token 'class'. Did you forget a ';'?
include\hack.h(199): error C2332: 'class': missing tag name
include\hack.h(199): error C2027: use of undefined type 'sortloot_item::<unnamed-tag>'

fix #H7226 - vault guard should have whistle

Implement the suggestion that since teleporting away from the vault
while being confronted by the guard results in a shrill whistling
sound, the vault guard ought to have a tin whistle in his inventory.

I also added a check that he does have the whistle and to give an
alternate message if not, but after half a dozen tries to have a
squad of beefed up monkeys steal the whistle, they never accomplished
that.  At least three times they took everything except the whistle
but I never succeeded in verifying the alternate message.

another sortloot tweak

The code that formats an object for use in alphabetic comparisons
during sorting is forcing off wizard mode to avoid any alternate
formatting that might produce.  Add a guarantee that doing this can't
be used as a backdoor to create a normal mode panic file if someone
figures out a way to make xname() panic.

sortloot - enhanced sorting [re-revamp anyone?]

When objects are in the same class, sortloot orders them by their
formatted name.  It was reformatting each object every time it got
compared to another object.  Change that to remember the formatted
name so that any given object is formatted at most once (during the
current sort; future sorts will need to format it again).

Armor and weapon classes are subdivided into smaller subclasses
and the formatting plus alpha compare is only done for items in
the same subclass, so helms come out before cloaks and don't get
their names compared, for instance.  [That was from my 'revamp'
rather than the original implementation.]  This adds a couple more
subclass sets:  food (named fruit, 'other' food, tins, eggs, corpses,
globs) and tools (containers, pseudo-containers [bag of tricks and
horn of plenty once those have become discovered; prior to discovery,
bag of tricks is classified as a container and horn of plenty as an
instrument], instruments, 'other' tools).

The main difference, aside from the formatting efficiency improvement,
is to change the previous sort order
| pink potion
| potion of enlightenment
| purple-red potion
to be
| pink potion
| purple-red potion
| potion of enlightenment
by grouping undiscovered items before discovered items when class and
subclass match.  So discovery state is essentially a sub-subclass and
formatting plus string comparison is only done for members of the
same sub-subclass.  There are actually four state values:  unseen
(which applies to particular objects rather than to their type),
unknown (not discovered and not named), named (not discovered but has
player-assigned type name), and discovered (either fully discovered
or considered not interesting to discover [no alternate description,
not nameable]).

My testing was primarily done with pickup ('m,' with menustyle:T)
and sortloot:Loot (the default) plus !sortpack (not the default and
not a setting I ordinarily use, but less verbose without the class
separators).  It won't astonish me if oddities crop up with other
usage combinations.

more sortloot - picking up cockatrice corpses

Yesterday's sortloot() overhaul didn't include some cockatrice corpse
handling for pickup.  If there's an object class filter in place and
pickup has been told to care about cockatrice corpses, have sortloot()
include them in the loot array even if food class isn't accepted by
the filter.  In the pre-sortloot days, and in 3.6.[01] which didn't
attempt to deliver a filtered subset of loot, the check for such
corpses was done before pickup checks the filter.  They need to be in
the loot array to retain the same behavior.

fix #H7205, #H7120, #H5216 - sortloot

H7205 - full-pack identify might skip items if perm_invent is on
        because updating the inventory window might reorder 'invent'
        while the identify code is in the midst of traversing it;
H7120 - pickup that doesn't pick anything up can change the glyph
        shown on the map because the pile might be reordered such
        that a different item is on top;
H5216 - performing a sortloot operation on a pile and then switching
        back to sortloot:none doesn't restore pile's original order.

The 'revamp' that changed the contributed sortloot feature to switch
to simpler usage (object list itself was sorted rather than having a
parallel array that needed to be constructed, sorted, traversed, and
discarded) turns out to have too many problems.  This reverts to a
hybrid solution that constructs an array for traversal, leaving the
linked list in its original order, but hides most of the details of
that from sortloot() callers.  The 'revamp' benefit of being able to
use normal list traversal is lost, as is the potential to skip
sorting when the list turns out to already be in the desired order.

This could stand to have a lot more testing than it's had so far.

makeknown()

Noticed while investigating the report about sortloot interacting
with persistent inventory window when identifying all of invent and
possibly skipping some items.  [This doesn't fix that.]

End of game disclosure was using makeknown() on inventory.  It is a
jacket around discover_object() which passes the flag to exercise
Wisdom.  That's useless at end of game [now; conceivably wrong if
disclosure of characteristics exercise ever got added], so call
discover_object() directly to suppress exercise of Wisdom.

discover_object() was also calling update_inventory() for every item
being discovered.  That's not useful when looping through inventory
at end of game.

Guidebook date for merge verification

expand on patch 2 so far in patchlevel.h

Guidebook

missed one

guidebk.txt over guideboo.txt

Merge branch 'msdos-build' of https://github.com/chasonr/NetHack into msdos

MS-DOS does not use getreturn_enabled

Work around quirky FreeDOS behavior

hilite_status title when polymorphed

Make a 'textmatch' rule for title that matches a specific monster type
while polymorphed take precedence over a "none of the above" one.

hilite_status, what else?

While deciding which highlights to apply, give 'percentage' and/or
'absolute' rules that match precedence over 'always' rules regardless
of order within the config settings.

When using 'O' to add 'up/down/changed' rule, don't include 'down'
as a choice for field 'time'.

When using 'O' to add rules, don't squeeze out spaces if adding a
'textmatch' rule for title (to support "field worker", "high priest",
"student of stones", and so forth).

While deciding which highlights to apply, ignore double quotes when
testing whether a 'textmatch' rule matches the current text of a
field.  This allows rules to specify string values as '"value"'
instead of just 'value'.  It not does validate them to ensure quotes
are paired at beginning and end, it just ignores them.  New rules
created via 'O' for rank title include them when displaying what the
new rule would look like as a config file option.  Other text fields
haven't been changed to show quotes but ignoring such applies to all
'textmatch' comparisons.

Expand the menu for adding 'textmatch' rules for title.  When a rank
has separate male and female titles, list three entries instead of
just one
  "male rank"
  "female rank"
  "male rank" or "female rank"
(the order of the first two entries and of the two titles in the
third entry is reversed if the current character is female).  If the
user picks the third entry, two rules are added instead of just one,
identical to each other except for the text to match.

Further expand that menu with
  "none of the above (polymorphed)"
at the end.  When deciding which highlights to apply, "none of the
above" and "(polymorphed)" and the full string are treated as
equivalent (with spaces, quotes, and parentheses ignored).  Rather
than comparing anything against the title text, it matches if the
hero is polymorphed (where title will be "<hero> the <monster-type>"
instead of "<hero> the <rank>").  Note that the user can have config
file 'textmatch' rules for title to match specific "<monster-type>"
values but the 'O' menu doesn't offer any opportunity for that.
(I've just realized that rules for specific monster types should be
given precedence over "none of the above" but at present that isn't
done; the order of the rules will determine which wins out.)

hilite_status string comparison

Simplify the string comparison done when checking 'textmatch' rules
to decide whether to highlight something.

Fix the menu titles when setting up a textmatch via 'O':  the title
for color referred to attribute and the one for attribute used the
default.  The two tiles are set up in advance; the one for color was
set correctly but then the one for attribute was written into the
wrong buffer.

When using 'O' to manipulate hilite_status rules, if there are any
when you're done and the 'statushilites' option (iflags.hilite_delta)
is 0, give a message reminding that it needs to be non-zero for
highlighting to be activated.

status_hilite: no more ANY_UINT

The fact that the index to the array of hunger strings is an unsigned
field in 'struct you' is unimportant as far as its usage for status
highlighting.  Since it is the only ANY_UINT field, change BL_HUNGER
to plain 'int' so that there'll be no need for ANY_UINT handling.

And some more validation when setting up highlight rules.  For 'O',
in the menu to choose a relationship after supplying a number N,
don't include "less than N" and "N or less" for percentage or
absolute--other than AC--unless N is greater than 0, and don't
include "N or more" and "more than N" for percentage unless N < 100.

Also, when 'O' prompted for a number, if you entered <X or =X (for X
not a sequence of digits), it remembered the '<' or '=' (or '>=', &c)
when reprompting for a valid number.  If the 'X' portion is invalid,
discard the relationship operator before asking for another number.

fix access violation in status_finish() if window port not initialized

Windows wouldn't compile without TTY_GRAPHICS defined

fix early crash during config file error processing

fixes update for previous static prototype move in rip.c

static prototype could be left orphaned depending on #defines

Merge branch 'NetHack-3.6.2' of https://rodney.nethack.org:20040/git/NHsource into NetHack-3.6.2

don't highlight the leading space before gold field on the status line

hilite_status support for <=, >=, explicit =

Add threshold relationships <= and >= so that the change to make <
and > perform their expected comparison can be resolved.  "Point
release shouldn't force players to update their config files" does
not carry sufficient weight given that they already had to do that
to turn on status highlighting when going from 3.6.0 to 3.6.1.  The
3.6.2 release notes can warn them about the need to update their
status highlight options if they're currently using '<' and/or '>'.

Entering new hilite rules via the 'O' command accepted '=' prefix
for numbers, but rules from config files did not.  Now they do.
The '=' prefix is optional in both situations.

With 'O', percent rules and absolute rules had separate menu entries
so picking one was already choosing the rule type, but entering a
numeric value without percent sign (for percent) or with one (for
absolute) would change the type on the fly.  If someone has already
picked percentage they shouldn't be required to append '%' to the
digits, so that is now optional.  If explicitly included with the
number after having picked absolute, the value is rejected.  It is
trivial to back up in those menus and choose the alternate type if
someone changes his/her mind part way through.

If a status field has both persistent (percent, absolute, always)
and temporary highlights (up, down, changed), give the temporary one
precedence when the value has changed.  To do that with 3.6.1, the
rules for temporary had to follow the ones for persistent highlights
since whichever matched last was the one used.  Now their order
relative to each other doesn't matter.  If a value increases and
there is both an 'up' rule and a 'changed' rule, the more specific
'up' takes precedence, regardless of their relative order; likewise
for decreases and 'down' vs 'changed'.

There were a couple more tweaks needed to support negative values;
I overlooked the 'O' menu handling before.  >-1% and <101% now work
for both the config file and interactive adding via 'O' methods of
defining highlight rules, although new >=0% and <=100% will be
clearer to anyone examining a rule set.

'enum relationship' was forcing LT_VALUE to be -1 but that fact was
never utilized anywhere, and the code was using magic number -2 to
mean "no relationship yet".  This adds NO_LTEQGT to replace the
latter and gives it value -1.  EQ_VALUE is still 0 so effectively
the default if a highlight hasn't been fully set up yet.  LT_VALUE
is now just another positive value along with GT_VALUE, LE_VALUE, &c.

The Guidebook hasn't caught up with the code yet.

The rule choosing code used when deciding how to highlight something
only supports 'int' fields and relies on 'long' having the same bits.
It needs to be extended to support 'long' properly.  Fixing should
be straightforward (except maybe for the initialization of min/max
best fit handling) but this doesn't address that.  Also, data type
for encumbrance/carrying-capacity should be changed from unsigned to
plain int so that no extra handling for just one field will be needed.

Merge branch 'NetHack-3.6.2' of https://rodney.nethack.org:20040/git/NHsource into NetHack-3.6.2

be consistent with the tex version

be consistant with the tex version

update note of appreciation in Guidebooks (dat/history to follow)

more status_hilite threshold handling

Negative AC needed one extra change to support >-N since there was
a place in the code that assumed 0 was the lowest possible value.
(My earlier testing was with <-N which didn't have that issue.)

Make '/<N/' work as 'val < N' instead of 'val <= N', and />N/ work
as 'val > N' instead of >=.  The <= and >= behavior might have been
intentional but the only support for that I could find was that
the 'O' menu used "N or less" for '<' and "N or more" for '>' when
setting up 'absolute' rules.  If we actually want <= and >= (and we
probably do...), we should add them as more relationship operators
instead of misusing < and >.

Simplify the is_ltgt_percentnumber() case when parsing options
since input has been fully validated by the point that that test
passes.  Among other things, /<-0/ and />-0' are now accepted (as
synonums for 0; -0 doesn't mean anything special) instead of being
silently rejected and then discarding the rest of the config file.
(That bad behavior is a separate issue not dealt with here.)

fix #H7155 - polearm can reveal hidden monster

The code to choose a likely target when applying a polearm was
basing its decision on visible spots which contained monsters,
so could expose the location of a hidden monster if there was
only one such spot within polearm range.  Not mentioned in the
report:  it also wouldn't pick remembered, unseen monster unless
there was a monster still at that spot.

I've changed it to choose candidate location based on the glyphs
shown rather than on the presence of monsters.

fix #H7159 - orc hero can start with lembas wafers

Orc heroes get an extra food item ("to compensate for generally
inferior equipment") and it could randomly be lembas wafers (or
cram rations), and Ranger heroes always started with cram rations
even when they're orcs.  Fixing the latter was simple, but the
normal race-based substitutions weren't applied to randomly
generated items, so the fix for the former required a bit of code
reorganization in ini_inv().

Elf heroes already get lembas instead of cram; do the reverse for
dwarves (although I don't think this case can happen--no role gets
lembas wafers and only orcs and always-human tourists get random
food); give orc heroes tripe instead of either lembas or cram.

fix some of #H7156 - perm_invent issues

> [1. perm_invent is kept in flags so persists across save/restore, but
>  perm_invent capability can change if player restores with a different
>  interface--or same one running on a different-sized display--so it
>  ought to be in iflags instead.]

Not addressed here.

> 2. perm_invent window does not get updated when charging a wand (or
> other chargeable item presumably), with a scroll of charging.

Most scrolls rely on useup() -> update_inventory(), but charging uses up
the scroll early so that it will be gone from inventory when choosing an
item to charge.  It needed an explicit update_inventory() after charging.

> 3. update_inventory(), is called from setworn(), which is called from
> dorestore(), when loading a save.  Segfaults have been observed in
> variants based on this code (though not yet in vanilla 3.6.1), so it's
> possible this may be unsafe.  The update_inventory() call in setworn()
> could be protected with "if (!restoring) ..."

tty doesn't support perm_invent, so this might be a win32 issue.
I've made the suggested change, but a better fix would be to turn off
perm_invent as soon as options processing (new game) or options restore
(old game unless/until #1 gets changed) has finished setting things up,
then turn it back on at the end of moveloop()'s prolog when play is
about to start.

 = =

Most of the read.c change is reordering prototypes to match the order
of the corresponding functions.  I did this when adding a new static
routine, then ended up discarding that routine.

more hilite_status threshold number parsing

In addition to leading '-' for negative values, accept explicit '+'
for positive values as a no-op.

Merge branch 'NetHack-3.6.2' of https://rodney.nethack.org:20040/git/NHsource into NetHack-3.6.2

preserve change from old branch

Unix Makefile changes

save Pat's change

commit test for renamed branch

Locally I've committed to NetHack-3.6.0 and haven't yet pulled from
upstream to get the branch rename.  I expect this commit to be
rejected but it could conceivably go through to the new name.

fix #H7160 - hilite thresholds reject negatives

There was a prior report about this but I can't find it; maybe it
didn't go through the web contact form.  Anyway, status_hilite
threshold numeric values wouldn't accept a minus sign before the
digits, preventing negative AC values from being tracked.

Merge branch 'NetHack-3.6.0' of https://rodney.nethack.org:20040/git/NHsource into NetHack-3.6.0

Guidebook.txt update