Report #H9243 misinterpreted W_WEAPON as W_WEP and attributed a
hypothetical ball and chain sanity checking problem to that.
Rename the former to W_WEAPONS to emphasize that it includes
alternate/secondary weapon and quivered stack as well as wielded
weapon.
A couple of early returns could result in temporary windows getting
left around instead of being released for re-use, which in turn might
lead to a panic due to lack of available window slots. The first
one is accompanied by an 'impossible' warning which no one has ever
reported and the second one could only happen if data file 'keyhelp'
was missing, so panic due to either of these is hypothetical as far
as released versions go. Somebody making modifications could run
afoul of either of them though.
query_category() - switch from early return to 'goto' so that the
temporary window used for a menu will always be destroyed;
whatdoes_help() - defer creating the display window until after the
data file has been successfully opened so that early return won't
need any window cleanup.
The pull request #226 commentary follows:
One major limitation of the autopickup exception system is that you can't
define an exception from an exception, despite both menucolors and msgtypes
prioritizing rules based on the order they are defined in .nethackrc. This
is because the "always pickup" and "never pickup" exceptions are tracked in
different lists, and at runtime, when the player steps over an object, the
game checks these lists seperately, with "never pickup" taking precedence.
This means that if you want to pick up some but not all items matching a
given expression, you may need to write a long and kludgy list of regexes
to get the behavior you want.
I've edited the autopickup exception code to remove this necessity: now
the exceptions are stored in one list, and conflicts between them are
resolved based on their relative position in that list. Whether an
exception was inclusive or exclusive was already tracked individually;
I don't know why they were stored separately in the first place. This
edit makes the system both more convenient and more consistent with the
semantics of menucolors and msgtypes.
With these changes, the 33 autopickup exception rules in the wiki article
linked above may be replaced with the following 7 much simpler rules for
the exact same effect:
AUTOPICKUP_EXCEPTION=">.* corpse.*"
AUTOPICKUP_EXCEPTION="<.* newt corpse.*"
AUTOPICKUP_EXCEPTION="<.* lichen corpse.*"
AUTOPICKUP_EXCEPTION="<.* lizard corpse.*"
AUTOPICKUP_EXCEPTION="<.* floating eye corpse.*"
AUTOPICKUP_EXCEPTION="<.* wraith corpse.*
AUTOPICKUP_EXCEPTION=">.*\>.*"
closes#226
Fixes#202
When swallowed, you can take things from the engulfer's inventory, if
there are any, via pickup. Items might be worn by the engulfer and
when "picked up" those weren't being unworn before being added to
hero's inventory. Then they would be formatted as "(being worn)" and
could trigger warnings or worse.
Conceptually they should be worn on the outside and not be accessible
from the inside, so I've made attempts to pick up worn items fail
rather than fix up the unwearing.
Using ':' when swallowed to look at the engulfer's inventory describes
that inventory as "contents of <mon>'s stomach". That's weird for any
worn items, but the situation is so rare I haven't made any attempt to
deal with it.
Carried containers could have their contents-known state and/or
lock-known state changed without persistent inventory window being
updated to show the new information.
This also changes the behavior when player has hero zap self with
wand of locking or wizard lock spell. If it doesn't trigger a
holding trap then the effect will hit inventory, similar to how
opening/knock operates (releasing hero from holding trap or hiting
inventory when that doesn't happen).
Changing an inventory item's bknown flag wasn't followed by a call to
update_inventory() in many circumstances, so information which should
have appeared wasn't showing up until some other event triggered an
update.
Unfreed memory noticed after interrupting the fuzzer and quitting.
query_objlist() has an early return--for touching a cockatrice
corpse--that was skipping release of sortloot info (an array with
one element per object from whichever object list was being used).
Some formatting that's been sitting around for a while got mixed in
and I decided not to take that back out.
This is based on the multiple-RNGs code fron NetHack4, but using
only the parts relevant to the display RNG (and with substantial
changes, both because of post-3.4.3 changes, and because Nethack4's
display code is based on Slash'EM's rather than NetHack's).
Dropping an existing fragile item while levitating will usually
break it. Getting a new wished-for fragile item and dropping it
because of fumbling or overfull inventory never would.
Some callers of hold_another_object() held on to its return value,
others discarded that. That return value was unsafe if the item
was dropped and fell down a hole (or broke [after this change]).
Return Null if we can't be sure of the value, and make sure all
callers are prepared to deal with Null.
Fixes#163Fixes#153
Encumbrance calculations for taking things out of a bag of holding
where subject to rounding issues due to integer division. This may
improve things, although I think taking out a partial stack might not
be much better than before.
I simplified the contributed code, then decided that it wasn't an
improvement. In the process of switching back and forth I may have
introduced bugs which weren't present originally.
If hero was carrying Schroedinger's Box at end of game, disclosing
inventory converted it into an ordinary box. That interferred with
subsequent disclosure when writing DUMPLOG, which saw an empty box
if inventory had been shown or the special box with newly-determined
contents if not. I tried a couple of ways to fix it and decided
that redoing it was better in the long run.
Schroedinger's box is still flagged with box->spe = 1, but instead
of having that affect the box's weight, now there is always a cat
corpse in the box. When opened, that will already be in place for
a dead cat or be discarded for a live one, but the weight will be
standard for container+contents and when box->cknown is set it will
always be "containing 1 item" (which might turn out to be a monster).
Some temporary code fixes up old save/bones files to stay compatible.
TODO: food detection used to skip Schroedinger's Box; now it will
always find a corpse, so some fixup like the ridiculous probing code
is needed.
Followup to 'fix #148' patch: looting a container with menustyle:Full
wasn't offering a chance to remove everything in one go. That was due
to an error I introuduced 2.5 years ago with commit
529dad8ef1 when I changed how the flags
passed to query_category() were being set up. It accidentally switched
'A' from take-out to put-in but the only code to handle 'A' at that
time would take everything out (from container to inventory).
Prior to that, removing everything worked as intended and putting in
everything wasn't supported. Now 'A - autoselect all' is a viable
choice for both in and out.
Fixes#154
With menustyle:Full, picking 'A - autoselect all' when putting items
into a container ran code for taking things out and there wasn't any
corresponding code for putting things in.
Add some put-in-everything code. Taking things out doesn't offer
'A - autoselect all' as a choice so the code mentioned above may now
be dead. Taking everything out seems like something that's much more
likely to be desired than putting everything in.
