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

another beta bit

sync date between two Guidebook files (.mn, .tex)

beta bit

Display the word beta in a better spot on the line

more bump of version ID

bump version ID values

tty/wintty.c w/o TEXTCOLOR

With TEXTCOLOR disabled, compiler warnings about term_start_color()
and term_end_color() not being declared were followed by link failure
because they weren't available.

This tries to simplify color handling in the tty status code without
resorting to #if TEXTCOLOR (the proper fix, but somewhat intrusive).
For the usual case where TEXTCOLOR is defined, there were instances
of
  if (color != NO_COLOR && color != CLR_MAX)
    term_start_color();
  ...
  if (color != NO_COLOR)
    term_end_color();
and also of
  if (color != NO_COLOR)
    term_start_color();
  ...
  if (color != NO_COLOR)
    term_end_color();
I've changed both types to be
  if (color != NO_COLOR && color != CLR_MAX)
    term_start_color();
  ...
  if (color != NO_COLOR && color != CLR_MAX)
    term_end_color();
so that start/end pairing will always be consistent.

Also, ((color_and_attr & 0xFF00) >> 8) might not work as intended if
using 16-bit int and color_and_attr happened to have its sign bit set.
Change to ((color_and_attr >> 8) & 0x00FF) to ensure just the desired
bits.

Also also, a couple more formatting bits.

X11/winX.c w/o TEXTCOLOR

Avoid warnings when TEXTCOLOR isn't enabled.

mapglyph.c w/o TEXTCOLOR

Avoid warnings when TEXTCOLOR isn't enabled.

fixes36.2 catch-up for previous commit

fix access violation when --debug:xxxx has no other args after it

fix spaces in hilite_status option text field not working H7107 (GitHub #88)

Fixes #88

H7107: FWD: spaces in hilite_status option text field not working

fix H7138: sys/unix/setup.sh fails with no arguments
Sanity check was in the wrong place.

fix a couple of status items, gold highlighting and a boundary check

typo
gold highlighting
boundary check on tty_curs()

tty status

Started by removing two or three unused variables, ended up cleaning
up a lot of formatting (tabs, trailing spaces, indentation, a few
wide lines, 'if (test) return' on same line).  Marked some static
functions as static in their definitions instead of leaving it hidden
in their prototypes.  Moved a pair of short-circuit checks to skip
several initializations.

debug logging

Remove unused variables.

integrate aklys feature introduced in 3.6.1 into 3.6.x display

add prototype

(cherry picked from commit 438cfd3815420aab1b7a8bbaf06f3ba2c9b3fe59)

integrate aklys feature introduced in 3.6.1 into display

(cherry picked from commit 3fe8325f14481f450058c0b7b4abba0bbe25a6ef)

Merge branch 'win-minor' into NetHack-3.6.0

boundary bit

catch up on fixes36.2 updates

Merge branch 'win-minor' into NetHack-3.6.0

Merge branch 'win-tty-status' into win-minor

a few cut-and-paste errors

some tty per field rendering and optimization

put back the functionality of commandline --debug:immediateflips overwritten recently

Additional changes to xputc_core() and early_raw_print() to manage
the cursor position correctly.  This is needed to handle raw printing
correctly.  Added check for when we might be running off the bottom
of the screen when handling msmsg().  Added runtime checks to keep
cursor always within bounds.

Changes to xputc_core to handle cursor correctly.

testing build with STATUS_HILITES

missing stubs for NetHackW.exe

Removing temporary debugging code and fixing compiler warnings.

Fixing typo.

Merge branch 'tty-status' into win-tty-status

more status updates

- prevent an overflow
- add make_things_fit()

Fix memory leak.  See bug 1169.

fix #H7140 - list MSGTYPE values shows empty strings

The 'O' menu's 'list' for MSGTYPE settings showed truncated versions
of really long message strings but didn't show anything except the
hide/stop/norep setting for ordinary length ones.  3.6.0 showed the
latter correctly but suffered buffer overflow for the former; the
fix for that had a typo/thinko in it.

fix "a Vlad the Impaler"

Killing Vlad while he was in bat/fog cloud/wolf form gave poorly
worded feedback when he reverted to vampire form.

Fix for bug 324 (aka H4216).  We now will use nhraykey by default if the
players keyboard layout is non-english.  nhraykey properly handles
non-english input.  We also now support changing altkeyhandler in game.

Some nttty.c clean-up.

Added ntassert() mechanism for Windows based port use.

Merge branch 'tty-status' into win-tty-status

empty field suppression caught condition values unintentionally

more status handling updates

Suppress unneeded spaces from a couple of fields
BL_LEVELDESC - trailing spaces.
BL_CAP - it only contains a space

some build fixes for compile issues reported

condition shrinkage when required

remove some debug code

missing return value

more tty-status updates

update files.c with testinglog

add some logging to debug

provide some debug developer controls - part 1

Revert "some cross platform testing"

This reverts commit 3d1e086648fa5657ee6181c8ae169af769d0e2c5.

cross platform testing

some cross platform testing

Merge branch 'barthouse-bugH7132' into NetHack-3.6.0

remove a commented out code line

tty status updates

some status code cleanup

It should be ready to merge tty-status changes into NetHack-3.6.0.

Fix for bug H7132.
In nethackw, there can be conflicts between menu accelerators and an extra
choice accelerator.  For example, when engraving the using fingers options
conflicts with the unselect all menu accelerator.  The extra choice
accelerator should take precedence.