With potions of healing becoming much more common, the multi-step
alchemy recipe from potion of healing to potion of extra healing to
potion of full healing is likely to become even more overpowered
(and it was somewhat unbalancing even beforehand).
This change restricts alchemy involving diluted dipped potions to
alchemize only two potions at a time. This means that potions of
healing can stil be alchemized into potions of extra healing as
efficiently as before this commit, and so can potions of extra
healing into potions of full healing; but the multi-step recipe
is now limited by requiring a lot of potions of gain level or gain
energy. As such, this is intended to make potions of healing into
an item primarily useful in the early game, and discourage hoarding
them for the late game.
At present, potions of healing generate primarily in Gehennom,
which causes significant balance issues (e.g. you don't have them
to heal in the early game, or even if you do, you can't identify
them in time to use them). In this series of commits, I'm aiming to
make potions of healing a more viable early-game healing source,
which means making them both (much) more likely to generate, and
easier to identify so that they are actually usable in the early
game.
This commit radically increases the generation chance of potions
of healing (reducing the chance of most other potions slightly to
compensate), and gives them a unique base price. This should make
them fairly easy to identify either by price-ID or quantity-ID
(and the unique base price is chosen to be fairly easy to figure
out even for unspoiled players).
These are primarily in chests (apart from one guaranteed good food
item on the Mines branch level), and are quite likely to be potions
of healing, although other items that are useful for early-game
survivability are also possibilities.
This is part of a series of commits that aim to make the early game
less about waiting to heal up and more about pressing forwards. In
particular, this means that characters need likely access to
healing sources other than waiting/backtracking/hiding in closets.
In a future commit, I plan to make permafood generate primarily
through exploration (rather than drops from monsters) in order to
deter waiting around or grinding; the early guaranteed food drop is
present to give the more nutrition-intensive characters (e.g. orc
wizard or vegetarian Monk) a fair chance to reach the more abundant
food sources in Minetown or Sokoban.
There's no need to process windowtype a second time after options
parsing. The sequence set windowtype, process options, set
windowtype again was intended to deal with the options setting it
to some other value, but there's a flag available to disable that
from happening.
In particular, Wizards now get a magic marker guaranteed (but with
fewer charges than magic markers naturally generate with). This is
intended to improve the game in two ways: it reduces the incentive
for startscumming, and it gives Wizards a method to gain an
additional low-level spell early if they wish (but the marker does
not have enough charges to get higher-level spells quickly using
this method).
Previously, Wizards got a boost to the chance of writing unknown
spellbooks based purely on being a Wizard (with the chance still
luck-based), leading to a very large power spike when the Wizard
gained access to a luckstone and the ability to max out luck.
This had two main issues: this power spike came *after* the major
early-game difficulty spike, often leaving Wizards forced to deal
with it without having appropriate spells; and it promotes
grinding (for Luck and for Magicbane) at an early point in the
game, meaning that the Wizard early game effectively followed a
sequence of extreme difficulty -> grinding -> minimal difficulty,
which isn't very good balance-wise.
With this commit, Wizards lose their advantage to writing unknown
spellbooks by guessing, and instead learn spellbook IDs based on
their spell skills (advancing a skill gives knowledge of higher-
level spellbooks). This means that writing unknown spellbooks
becomes guaranteed with sufficient skill, but has no advantage
over non-Wizards in schools where the Wixard does not have
sufficient skill.
Due to Wizards' skill caps, there are two spells which they can't
ever write guaranteed: create familiar and charm monster. Create
familiar is a fairly niche spell (that doesn't match the Wizard
playstyle that well) and being unable to write it is not a major
problem. The inability to easily write charm monster is
intentional.
Remove a stale comment and update one or two others.
Remove several trailing spaces.
Change the data type of a couple of variables from schar to int and a
couple others from int to coordxy.
Redo a nested 'if' sequence to un-nest; results in a bloated diff due
to reducing indentation for a big chunk of code.
Change monster movement to use u_on_newpos() when swallowed hero's
location moves along with engulfer so that a clipped map will be kept
up to date.
u_on_newpos() bit: player can't see the map while swallowed so hero
can't see objects on the map, hence shouldn't gain more info about
any generic objects if engulfer moves closer to some.
At the moment engulfer movement is manipulating <u.ux,u.uy> directly
rather than going through u_on_newpos(), but that's about to change.
Otherwise a clipped map doesn't get updated properly until the hero
is eventually expelled.
Pull request from argrath: reduce the size of m_move() and eliminate
several goto's by splitting off 'goto postmov' into a separate routine.
Some of the comments have ended up out of date, referring to 'above'
or 'below' for stuff that moved away. That can be fixed up later.
Closes#1139
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.
