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