Pull request from entrez: when dipping gloved hands into pools or
fountains to wash them, subject those gloves to water damage. Also,
showing '-' as a likely candidate when picking an inventory item to
dip while at a pool or fountain location didn't work if player had
the 'force_invmenu' option set.
Closes#1141
This wasn't being provided as an option because apparently all actions
which allow hands needed to be explicitly added to the list in getobj().
Add a fallback default 'hands' entry for any action which permits hands,
which both allows #dipping your hands and means that future additions of
hands as a target to other actions will work with OPTIONS=force_invmenu
without needing to remember this.
I made it so that hands will only be presented in the pickinv menu if
they are actually one of the suggested/likely items, which was a little
tricky because pickinv was only looking at actual inventory to determine
whether some items were excluded and the "show everything" option should
be presented. I had to add a parameter to inform it that hands are
allowed so it would know to display that option if they were allowed but
no 'hands' entry was passed in xtra_choice. Not sure if there was a
better way to let it figure that out...
Make it so that washing your gloved hands in a fountain, pool, or sink
can still rust your gauntlets even if it successfully removes the grease
from your fingers. There wasn't much logic behind the two effects being
mutually exclusive, since the oily fingers of the Glib effect don't
normally protect against water damage like the item being 'greased'
does, and this introduces a possible tradeoff that could make whether or
not to clear Glib by washing your hands a more interesting tactical
decision.
Pull request from entrez: a 3.6 problem with mimics coming out of
hiding when they shouldn't was indirectly fixed by an earlier change.
Fix it directly.
Also, add a fixes entry since there didn't seem to be one.
Closes#1149
Some players of 3.6 recently noticed that sometimes, mimics in shops
seemed to have moved around even before the player had entered the shop
or done anything to uncloak them. I found that this was because
finish_meating was being called for all non-eating monsters when
restoring a level (monsters that weren't eating anything would have
meating == 0 so always pass the 'imv > meating' check). This would
uncloak mimics -- but not all the time, because the 'mappearance != 0'
test meant mimics disguised as strange objects weren't uncloaked. I
think that was meant to be an additional check to confirm the monster
really did have a disguise, but in reality it meant that M_AP_OBJECT
"strange object", M_AP_MONSTER "giant ant", etc disguises wouldn't be
removed by finish_meating.
As it turns out, this was mostly fixed by coincidence in 221e4a7, which
fixed the "exclude actual mimics" check in finish_meating. So at this
point in 3.7 it's largely a latent bug, but it still had the potential
to improperly uncloak non-mimics who can disguise themselves (like the
Wizard of Yendor, maybe?), and could cause other problems if
finish_meating were updated to have additional effects, or if some
monster types were made to disguise themselves as a strange object when
eating a mimic.
Issue reported by elunna: hero witnessing a wand of striking being
zapped by a monster didn't have that type of wand become discovered.
Monsters observing hero resisting--or failing to resist--the effect
on hero didn't learn about target's current resistance capability.
Barely tested.
Fixes#1157
For
|Autopickup what?
| a - amulets
...
| A - all classes
prevent invert all and set all from setting the 'A - all classes'
entry. For invert, toggling it is wrong. For set, suppressing it
from being set is academic since all other entries get set.
Simplify the notes about what happens when no classes are selected,
and when autopickup is On about how to not autopickup anything at all.
Add one when it's Off, about how to make the chosen classes matter.
I didn't like "your hands begin to glow red even more" very much (the
hero's hands aren't really 'beginning' to glow if they already have an
active confuse monster effect, and "glow red even more" was an awkward
turn of phrase on top of that). Rephrase it to "The red glow of your
hands intensifies."
Pull request from entrez: if breaking a wand of digging or playing
a drum of earthquake destroys an altar, provoke the god's wrath.
Likewise for shop damage, have the shopkeeper demand payment for
repairs.
Also revise the handling for some digging messages.
Closes#1137
Merge some nearly-duplicate code for the two trap types. Also include
alignment name when referring to an altar's destruction, since it
provides some context for the immediate follow-up by its god.
This is for completely destroying an altar with extra-powerful magical
digging -- the normal altar_wrath() punishment didn't seem sufficient
for such an outrage to me, so skip straight to slinging the lightning
bolts. Destroying an altar is unlikely to happen by accident (though
it's possible with poorly timed usage of a drum of earthquake).
drop_uswapwep() avoided calling makeplural() in a pline which also
had a call to Yobjname2(), with a comment about the possibility of
clobbering its static return buffer. uswapwep might be a stack that
results in Yobjname2 indirectly calling makeplural to produce a
plural description. But makeplural() has used xname's pool of obufs
since before uswapwep became a thing, so the code was evidently
cloned from some other out of date usage.
I was going to just move the makeplural() call into pline() but it
dawned on me that uswapwep must be one handed, so don't pluralize
hands at all. And since uswapwep might have the same description as
uwep, explicitly mention "left hand" to distinguish.
When a pet ate a mimic corpse and started mimicking a monster,
and the user then used #wizmakemap, the sanity checker complained
about "non-mimic posing as foo" - the code was clearing the
pet eating counter, but didn't clear the appearance.
Allow 'make USE_MANDOC=1 distrib' to be used for generating
the doc/*.txt files for systems that have mandoc and may not have groff.
(macOS Ventura doesn't include groff in the OS).
USE_MANDOC=1 is not restricted only to macOS.
Have hints/macOS.370 specify the /usr/share/man/man6 directory for the macOS
man pages, so that 'make manpages' will target the correct directory on
that platform.
add a 'distrib' target to the top level Makefile so that the
distribution doc/*.txt files can be created via 'make distrib'
from the top directory. It utilizes the existing 'distrib'
target in the doc/Makefile.
Have hints/linux.370 specify the correct directory for Linux
man pages of /usr/share/man/man6, so that 'sudo make manpages'
works on that platform,
Some changes to achieve the following MAN2TXT commands...
If groff version is 1.23 or greater:
nroff -man -Tascii -P -cbou
If groff version is less than 1.23:
nroff -man -Tascii -c | col -b
If non-groff nroff:
nroff -man | col -b
Closes#1153 again.
Following a commit for Issue #1153, g-branden-robinson commented:
> Mac OS X stayed on _groff_ 1.19.2 for over a decade (presumably due to
> _groff_ 1.20 adopting to GNU GPLv3), until finally dropping _groff_
> altogether for macOS Ventura (2022).
>
> There _has_ been an interface change in that time. The [`-P` option I
> advised about is new to _groff_ 1.23.0 (July 2023)]
> (https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n86).
> [...]
>
> There is a significant number of _groff_ users via Homebrew (enough that
> we hear from them occasionally via bug reports). Some of these have
> upgraded to 1.23.0 via that mechanism.
> [...]
>
> `nroff -` is not necessary with any _nroff_ known to me; like many other
> Bell Labs Unix programs, it reads from the standard input stream by default
> if not given any operands.
Action taken:
1. Remove the unnecessary ' -' from the nroff command in Makefile.doc.
2. In the misc.370 file containing make snippets to include, test whether
groff >= 1.23, and only insert the -P option for 1.23 or greater.
When testing 'm )' I noticed that weapon and alternate weapon weren't
offering the chance to toggle two-weapon mode. When already on,
providing it as a choice to toggle it off is simple, but when at is
off that isn't the case. There are lots of reasons why attempting
to toggle it on might fail and it is silly to offer as a choice if
failure is sure to occur. This tries to filter out the majority of
reasons why the player can't toggle it on when deciding whether to
include 'X' as a choice.
Make the various item-in-use commands put up a menu--which allows
choosing an item for context-sensitive item action--if/when preceded
by the 'm' prefix. Some of them do that even without the prefix ('*',
'[', or '=' when more than one ring is worn). By default '(' shows
primary weapon, then secondary one if dual-wielding. 'm (' shows a
menu of primary, alternate whether dual-wielding it or not, and quiver.
character_race() was going out of bounds when scanning the races[]
array, relying on a field value that the fencepost entry didn't set.
This incorporates the previous fix for UNDEFINED_RACE but also changes
character_race() to not care about that anymore.
rename hints/include/multiw-3.370 to hints/include/misc.370
keep the portable nroff options in sys/unix/Makefile.doc,
and relocate the non-portable bits to a variable defined
in sys/unix/hints/include/misc.370
This assumes that the groff options are compatible between
Linux and macOS implementations of groff.
If that turns out not to be the case, this bit:
ifneq "$(NROFFISGROFF)" "" # It's groff
# add the groff-specific plain text flags
MORE_MAN2TXT_FLAGS += -Tascii -P -cbou
endif
should relocate from sys/unix/hints/include/misc.370
to sys/unix/hints/linux.370 and sys/unix/hints/macOS.370,
immediately following the inclusion of misc.370, and the
appropriate platform-specific groff options can be
adjused in whichever of those appropriately needs it.
Closes#1153
If any items are in use and hero isn't wielding anything, include
| - bare hands
in the primary weapon slot of the display of used items as an alert.
More useful for perm_invent than for #seeall.
If no items at all are in use, continue to show "not using any items"
without any specific weaponless alert.
When sortloot() is called for inuse_only, pass a filter that screens
out items which aren't in use so they won't be needlessly sorted.
For '*' and for persistent inventory with perminv_mode==inuse, show
the items in a specific order and within four labelled groups rather
than within their object classes:
|Accessories
| amulet
| right ring
| left ring
| blindfold
|Wielded/Readied Weapons
| primary weapon
| alternate or secondary weapon
| quiver/ammo pouch
|Armor
| suit
| cloak
| shield
| helmet
| gloves
| boots
| shirt
|Miscellaneous
| lit candles and/or lamps
| attached leashes
The accessories come first due to the default 'packorder' position
for amulets; weapons before armor likewise. If you wield a potion or
quiver some gold, those non-')' items will appear in the weapons
section since the ordering is based on slot rather than object class.
Rebuild doc/*.txt (other than Guidebook) with 'nroff -man -c -Tascii'
rather than just 'nroff -man' to prevent it generating non-ASCII
characters for hyphen, aprostrophe, single and double quotes, long
dash, possibly others. Also preprocess with '--grep-define ALLDOCS'
so that a few parts of the text don't end up being specific to the
local configuration.
The next time they're rebuilt they'll probably be subject to the
ping-pong effect of inserting padding spaces for justification
(alternating right-to-left vs left-to-right as intended but starting
with different parity so lots of gratuitous changes) since my quite
old version of groff triggers that for Guidebook.txt.
