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.
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.
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.
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.
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.
> [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.
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.
From Bart...
When we are creating the console font for testing character widths,
we were not specifying width. Because of this, the created font's
average width might be larger then what we expect and we might
falsely detect that the font was inappropriate for playing Nethack.
Fix provides the width that we are expecting when creating the font.
Noticed while testing the fix for the recently reported clairvoyance
bug. I saw a '1' move onto an 'I', then when it moved again the 'I'
reappeared. The remembered unseen monster couldn't be there anymore
if the warned-of monster was able to walk through that spot, so
remove any 'I' when showing a warning (digit) to stop remembering an
unseen monster at the warning spot.
Nobody has ever reported this so fixing it isn't urgent, but fixing
it is trivial so I'm doing it in now (without the clairvoyance fix).
