Currently, options.c is the only file that #includes "optlist.h".
In theory, if a source file did want to include optlist.h (perhaps
for the struct allopt_t declaration so they could deal with a
pointer to such a struct), they wouldn't be able to include it
because of a static function prototype that it contains.
Add some protection to only include that static function
prototype when optlist.h is included from options.c.
As such, it shouldn't be affected by the heat of the ground in
Gehennom (which is hot enough to boil but not to burn). The oil
still heats but won't break its bottle.
In Gehennom and on the Plane of Fire, the ground is hot enough to
boil potions (although not hot enough to, e.g., burn scrolls).
The potions sometimes survive this (almost always if it's your
potion, it's blessed, and you have maxed Luck), but often don't.
In addition to making a lot of flavour sense, this serves a
gameplay purpose in that it reduces the number of potions that
are deathdropped by monsters in the late game. In Gehennom,
monsters often generate with potions to use defensively, but then
get killed before they have a chance to use them: this produces a
surfeit of potions that players tend to convert into holy water or
potions of full healing (and in general it doesn't make much sense
that the basic potion of healing primarily generates in Gehennom).
This commit approximately halves the number of useful potion
deathdrops, whilst still allowing monsters access to their
potions; when the monster dies, it drops the potion and this has a
chance of destroying it.
The previous commit makes things somewhat harder for vegetarian
characters. Normally, making a conduct harder isn't a huge issue,
but vegetarian Monk is an intended/encouraged combination. As such,
compensate by adding some additional food rations to Monk games
specifically; the Quest home level is early enough to provide the
extra food, and as the level is Monk-specific, it will provide the
food only to Monks specifically. (Although the Quest generally
requires level 14 to enter, the Quest home level specifically
doesn't.)
Playtesting has shown that there is too much permafood in the game
at present: in the late-game the only food-related problem is how
much to carry in order to avoid burdening yourself. In the early
game, food could previously have been a problem prior to
Minetown/Sokoban (thus the recent commit to add a guaranteed ration
in the upper dungeons), but past that point, there is easily enough
food generated on the ground. Additionally, the recent commits to
make healing sources more available in the early game reduce the
amount of time that needs to be spent waiting to heal, thus
further reducing food requirements.
The main purposes of food as a mechanic are to given an incentive
to press onwards and to discourage grinding. However, if monsters
are deathdropping non-corpse permafood, then beyond the very
early game, grinding actually generates more food than it uses up,
so the nutrition mechanic doesn't do its job properly.
Playtesting (including a full ascension!) has shown that there is
still plenty of food available even without deathdrops available
(my test game had 8 spare non-deathdrop food rations upon reaching
the Castle, at which point nutrition is no longer an issue due to
the Castle food stores and the huge numbers of C- and K-rations
dropped by the soldiers). I will address the potential problems
this causes for vegetarian Monks in a future commit.
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,
