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