The change to Sokoban difficulty calculation introduced a balance
issue: previously the Sokoban prize was obtainable before item-
destruction attacks became common and would protect from them,
whereas now they commonly appear in Sokoban itself, before the
prize is accessible. This makes scrolls and potions much less
usable as escape items, and potions of healing less usable for
HP recovery, because they either get stashed or destroyed (and
in either case aren't usable by the character in time-critical
situations).
This commit attempts to alleviate the problem by adding a way to
protect items from cold and fire in the early game. It's a
little unreliable, and requires equipping an item that has bad
stats and generally isn't otherwise used, but which is generally
easy to find early on.
Not included in this commit, but probably necessary for a
"finished" version of the feature: some way of letting players
know the new mechanic. It shows up in enlightenment, but there
should probably be at least rumors (and maybe even a major Oracle
consultation) hinting at the mechanic. We might also want to
change the unIDed description of the dwarvish cloak as a hint,
although that would require, e.g., new database entries.
The tracks left by hero were cleared when player saved and
restored the game, or changed levels. Now the tracks are
saved in the dungeon level, so changing levels keeps the tracks
left by hero in that level.
Also increased the length of tracks from 50 to 100, and
simplify the tracking function.
Thing not done: fade out old tracks when returning to a level.
Breaks saves and bones.
For the accessories section of '*' and perminv_mode=InUse, show the
ring on main hand first (after amulet) and the one on off hand after
(before blindfold). Main hand ring is more significant due to the
potential of a one-handed weapon becoming cursed, preventing it from
being removed.
Report was that converting a novel into a blank spellbook via water
damage resulted in a spellbook of blank paper that increased weight
when put into a bag of holding.
Spellbooks weigh 50 units but novels were defined with a weight of 0;
when one was created, a non-zero weight of 1 got assigned. Blanking
it didn't update the weight; that stayed at 1. Putting it into a
container reset the weight to match the new type: spellbook of blank
paper, so its weight increased.
Do that when blanking rather than wait until a container might fix it
up. If it is already in a [possibly nested] container, update that
container's weight too along with any outer ones.
This also changes the base weight of novel from 0 to 10, so it still
gets magically heavier when turned into a spellbook of blank paper.
(The alternative seems to be to destroy it instead.)
The Book of the Dead weighed only 20 units which seemed odd to be so
much less than a spellbook. This changes that to 50 to match those.
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.
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.
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.
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.
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
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
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
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.
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.
Pull request from AndrioCelos: for feedback during pickup, add a
separate message from stressed instead of sharing the burdened one
and issue messages at higher encumbrance levels.
This 'tweak' will probably need more tweaking to reduce verbosity
when picking up multiple items in one operation.
Closes#1135
Issue reported by entrez: on tty, ^C while a menu was open followed
by 'yes' to "Really quit?" would lead to a bad window panic.
Brought on by screen erasure changes included with recent SIGWINCH
(window resize signal) changes.
Closes#1145
NetHack has historically had problems (both in terms of interface
and in terms of gameplay exploits) caused by unidentified items
not stacking with identified items. The 3.7 change to cause items
picked up by monsters to become unidentified has exacerbated this,
e.g. there's an undesirable strategy in which players give
ammunition to hostile monsters in order to unidentify it, allowing
it to stack with other unidentified ammunition so that the whole
stack can be enchanted with a single scroll.
This commit makes it possible to stack items with different
identification statuses (unles Blind), in effect causing the
unidentified items to be identified by comparing them to the
identified items (this is consistent with the mechanic via which
two stacks of unidentified items can be determined to be the same
as each other). The hope is that this will prevent any gain from
exploits involving intentionally unidentifying (or intentionally
failing to identify) items, that it will prevent interface clutter
caused by (e.g.) a Ranger's main projectiles becoming partially
unidentified as a nymph picks them up and subsequently failing to
stack, and that it will reduce the incentive to backtrack to an
altar to merge, e.g., a stack of formally-known-uncursed and a
stack of informally-known-uncursed food rations to stack.
'/ e' (or '/ `') lists nearby engravings (including headstones) that
the hero has read or felt (even if currently covered up) or can see
on the map;
'/ E' (or '/ |') lists all such on the level.
If the hero remembers an engraving and then monsters scuff it out of
existence, it will magically disappear from the list of remembered
engravings when deleted. I don't think that's worth bothering with.
[During testing, my pet seemed extremely reluctant to step on a
corridor engraving. That could have been coincidence but it seemed
to keep happening until I moved so close that it had no choice. I
wasn't carrying tripe.]
Report headstone engraving when using farlook to examine a grave:
| a grave (grave whose headstone reads: "foo")
or
| a grave (grave whose headstone you haven't read)
Make the farlook of ordinary engravings operate more like farlook of
other things:
| a boulder or a statue or an engraving (engraving with text: "bar")
rather than
| a boulder or a statue or an engraving with text: "bar"
The "or a statue" phrase will now be suppressed because statues aren't
shown as backtick anymore, so the parenthesized form isn't quite as
long as it would otherwise have been. If OPTIONS=boulder:symbol is in
use, the "a boulder" part will be gone too.
| an engraving (engraving with text: "bar")
or
| an engraving (engraving that you haven't read)
Make quicklook include engraving text. It's quick because it doesn't
ask the player to pick additional spots or whether to look up relevant
data.base quote, not because it skimps on useful information.
Autodescribe still does not include engraving text.
When using the 'm' prefix with #overview to get a menu of visited
levels and then picking one to annotate, replace the generic prompt
"what do you want to call this dungeon level?" with more specific
location information. Location details are visible while within the
menu but as soon as you choose something that goes away.
Pull request from entrez: when issuing the "welcome back" message
when restoring, print the current level's player-suppliedannotation
if there is one. Doesn't show automatically generated annotations
like "Oralce of Delphi" or "a sink" or "stairs to the Gnomish Mines".
Closes#1142
'm O' is a prime candidate for using ':' to select a menu item since
you can use that to avoid scrolling through many pages, but typing ':'
would immediately overwrite two or three lines of the menu with a
status refresh. curses doesn't suffer from this problem. X11 and Qt
show menus in separate windows do don't either. Not sure about WinGUI.
I think that this may have been reported in the past, but if so I don't
recall by whom, or why it wasn't addressed.
Remove menu_color support from the window port side of the interface.
The window port just has to honor the color parameter that was added
to the add_menu() interface definition in June 2022 commit
2770223d10, and let the core-side of
the interface handle things.
To that end, this does the following:
Removes the #define of add_menu() from include/winprocs.h and add a
real core-side add_menu() function to windows.c which acts as a
trampoline to the window port win_add_menu() function, while providing
a single location to adjust the parameters passed to the window port
function. get_menu_coloring() is now called in there.
Moves get_menu_coloring() from options.c into windows.c and makes it
static.
Removes all the calls to get_menu_coloring() from the tty, Qt, X11,
curses, and win32 interfaces and adjusts their code to simply honor
the color parameter in add_menu, similar to what the menu_headings
change from earlier today did.
Instead of just accepting an attribute, it's now possible to
use a color, or both color and attribute, for example:
OPTIONS=menu_headings:inverse
OPTIONS=menu_headings:red
OPTIONS=menu_headings:red&underline
Default is still just inverse.
This lets the player change the menu heading color without
needing to use menu colors for them.
Also makes it so the core uses NO_COLOR instead of 0, for all
the menu lines which don't have any prefedefined color.
Tested for tty, curses, x11, qt, and win32
Pull request by entrez: have monsters and the hero use the same code
when deciding whether to destroy a missile that hits a monster after
being thrown or shot.
Closes#1129
Suggestion from entrez: If dipping something in a sink while hands
are slippery happens to cause that sink to break, only remind player
about still being Glib if the item was '-' or uarmg.
Redo one of the fixes entries: dipping a potion into a sink does not
dilute it. The potion is used up and gives a hint about what it does
so player might discover it.
If hero has slippery hands, include '-' among likely candidates for
item to #dip when dipping at a pool, fountain, or sink location.
When dipping an item (including hands), have a modest chance for the
sink to be destroyed--which turns it into a fountain--each time so
that it can't be used to blank scrolls an unlimited number of items.
(Pools can already be used for that, but you need to obtain water
walking ability or else drop most of your stuff and enter the water;
sinks weren't imposing any such requirements or risks.)
Pull request from entrez: when at a fountain, pool, or sink location,
the #dip command will allow #dip to pick terrain and player to choose
pseudo-item '-' for hands. Also allow dipping actual items in sinks.
Closes#1112
Pull request from entrez: the mstate field in struct mon defines many
bits but didn't use some of them consistently.
Initially they were intended to be examined via debugger, where being
inconsistent might lead to confusion but not have a negative impact on
gameplay. However, some of them have morphed into affecting gameplay.
Closes#1116
One can observe the following problems when generating or viewing plain
text versions of the Guidebook. (There are three; "Guidebook" and
"Guidebook.txt" are identical, and are paginated; "Guidebook.dat" is not
paginated.)
1. The line "(Edited and expanded for NetHack 3.7.0 by Mike Stephenson
and others)" is overset.
2. So are Figures 1 and 2, by one character cell, when rendered with
groff 1.23.0 because of the way it handles boxed tables and those
with vertical rules at table boundaries.
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=8f066786ea3cb5e1dbade1149e7d50ae978da202
3. When viewing the Guidebook in an 80-column terminal, the left and
right margins are asymmetric; you get 10 columns on the left but
only 5 on the right.
So:
* doc/Guidebook.mn: In nroff mode, set page offset to 5n and increase
line and title line lengths by 5n to 70n.
Now, the margins are symmetric, there's ample room for the figures, and
the expansion credit fits.
(One diagnostic remains when formatting with groff 1.23.0.
troff:tmac.n:762: error: cannot load font 'S' for emboldening
This is a groff bug and will be fixed in the next release. The
diagnostic is spurious and can be ignored.
See <https://savannah.gnu.org/bugs/?64866>.)
