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.
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.
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.)
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.
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.
