If a monster fled from the hero by intentionally jumping into a vault
teleporter located in a niche which was still hidden and the hero
saw it happen, the trap would be mapped but the niche would remain as
a secret corridor spot. The hero couldn't move onto the trap until
searching or wall kicking or other map disclosing activity converted
the spot into regular corridor.
Trap doors in hidden niches did already change the secret corridor
into normal corridor to unhide the trap's spot, but only if the hero
saw it happen. Now the terrain change occurs even if hero doesn't
see it; only mapping the trap depends on that.
While testing the fix, I noticed that a monster jumping onto a vault
teleporter was teleporting randomly rather than being sent to the
vault, unlike when triggering such a trap by accident. The code has
changed for 3.7 but this bug was already present in earlier versions.
monmove.c: In function ‘postmov’:
monmove.c:1391:65: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
1391 | Soundeffect(se_door_unlock_and_open, 50);
| ^
monmove.c:1410:55: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
1410 | Soundeffect(se_door_open, 100);
| ^
monmove.c:1435:60: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
1435 | Soundeffect(se_door_crash_open, 50);
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.
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.
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.
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.
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."
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.
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.
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.
choose_classes_menu was declared extern. The only caller presently
was calling it was optfn_pickup_types() in options.c.
It could have had the extern declaration from include/extern.h and
declare it as static within options.c, if that was the only use
anticipated. Also, if the one existing caller were all there would
ever be, the argument passed to it that was the subject of pr #1146
could have just been removed along with the switch.
Checking the comments above the function, however, it was clearly
designed as a general-purpose function that could be called from
anywhere for the functionality desired, even though there's presently
just the one caller, passing just the one variation of the category
argument.
Relocate the general-purpose function over to src/windows.c, where
several interface-related / menu-related general-purpose functions
already reside.
options.c has gotten *huge* and this is a fitting opportunity to
reduce its size a little.
