The outer edge of a random dungeon level can have undiggable
walls. Phaseable monsters, such as earth elementals, could
hide deep inside that boundary. Turn the walls beyond the
first layer of non-diggable walls also non-phaseable.
Undead monsters created by the level creation routine do not grudge
other (zombifiable) monsters created during the level creation.
This of course doesn't prevent the grudge happening with monsters
created during gameplay.
Invalidates saves and bones.
Instead of using two separate functions with switch-cases for
wizard and clerical spell lists, define the spell lists
as arrays and use a single function to pick a spell
from the lists.
Adds levels to the monster spells, using the switch-case values,
with some minor fudging.
Give a little experience when releasing live housecat from Schroedinger's
Box, similar to recent change giving experience when opening the Box
produces a dead cat.
This defines the cut-off how many characters of the player's name
is shown in the bottom status line.
Also increase the limit from 10 characters to 16.
When access to the quest isn't available yet, describe the stairs down
as "blocked staircase down" instead of the usual "staircase down".
Applies to mimics posing as stairs too.
Does not apply to the stairs when standing on them and using lookhere.
I was going to use "locked staircase down" but that would imply that a
key or unlocking magic could be applicable.
Use the 'm' Prefix to make wizwish show the history menu.
Also entries wished via WIZKIT are added to the history.
While debugging, I often need to wish the same thing multiple
times, and typing or pasting it with mouse is annoying...
Move the monster spell definitions there, and use hackery
(similar to objects.h) to generate enum and data from
the header file.
I have not tested Windows, VMS, or Amiga builds.
In function 'create_monster',
inlined from 'lspo_monster' at sp_lev.c:3385:5:
sp_lev.c:2169:32: warning: 'tmpmons.m_lev_adj' may be used uninitialized [-Wmaybe-uninitialized]
2169 | if (mtmp->m_lev + m->m_lev_adj > 49)
| ~^~~~~~~~~~~
sp_lev.c: In function 'lspo_monster':
sp_lev.c:3217:13: note: 'tmpmons.m_lev_adj' was declared here
3217 | monster tmpmons;
| ^~~~~~~
Update the Amiga Intuition window port (AMII/AMIV) for the 3.7
window_procs API. Key changes:
- Update all window function signatures for 3.7
- Add assembly trampolines for AmigaOS register-based callbacks
- Convert all K&R function definitions to C99
- Add cross-compilation build system (cross-pre1/pre2/post.370)
using bebbo's m68k-amigaos-gcc with -noixemul -std=gnu17 -m68000
- Clipping fixes: viewport centering, simplified ScrollRaster,
duplicate Ctrl-R suppression, glyph buffer invalidation
- Add menucolor support in menu rendering
- Move native txt2iff.c and xpm2iff.c to outdated/
- Add nethack.cnf and README.amiga
cliparound() was called before rhack(), triggering a map redraw with
stale vision data followed by a second correct redraw. Move it after
vision_recalc() so the map is redrawn once with correct data.
Add a new parameter to des.monster, m_lev_adj, which is a level
adjustment for the monster. This only applies to the monster's
level, so basically only affects the spellcasting, it does not
change the monster's hit die or inventory.
Change one of the shamans in Orctown to be 3 levels higher.
Add a livelog/#chronicle message for quest leader opening the quest.
A similar message for being expelled doesn't seem possible to be
triggered.
Log the initial visit to each level in the quest branch. They record
when the hero actually visits the quest levels, beyond the new one
about permission to do the quest.
Change 'v' from #versionshort to #chronicle.
Change 'V' from #history to #versionshort.
History can still be accessed either directly with the extended command,
or via the help menu.
Versionshort now accepts the m-prefix, and then shows the longer version.
Normally energy regen is 1d2 or 1d3, so wearing the amulet increases
that to 1d4 or 1d5. The only way to get energy regeneration is via
The Eye of the Aethiopica, so you cannot have both at the same time.
Allows the user to configure a key binding to toggle any boolean
option, for example:
BIND=':toggle(price_quotes)
BIND=v:toggle(autodig)
The option must be settable in-game.
As of the change to allow for item probabilities that don't add up
to 1000, it's become a little difficult to figure out the exact
probabilities from the source code, which makes it hard to balance
item generation. Adding a tool to list the probabilities helps.
Part of the problem is that changing an item's probability without
balancing it elsewhere is usually wrong: doing that would in effect
take the probability equally from (or add the probability equally
to) all other items in the class, which might break the balancing
of those items due to the probability change.
As such, it is usually better to make an intentional decision about
which items should be less and which items should be more likely to
generate, then change them in a balancing way (meaning that the
probabilities of objects that weren't intentionally changed remain
unchanged). Doing a complex such change makes arithmetic errors
fairly likely, though, so it's useful to have a command that verifies
that it's been done correctly.
This command is primarily intended as a development aid, so it's
included only in debug builds and pre-release builds (the same as
other similar commands like #wizmondiff).
Armor is now slightly more likely to generate outside Gehennom (at
the expense of gems that generate via random generation rather than
mineralisation or level rules).
Basic nonmagical armor (especially body armor) has had its generation
probabilities reduced *relative to other armor*, but outside
Gehennom, it is no less likely to generate (because armor in general
is now more likely to generate outside Gehennom). It is slightly less
likely to generate in Gehennom (but isn't typically needed in
quantity there).
Armor that has extrinsics is more likely to generate, both due to
having increased probability relative to other armor, and due to the
increased proportion of generated items being armor: this is the
primary goal of this change.
The intention behind this change is to increase the chance that
players naturally find useful armor (especially armor that they might
not have been planning to use, but that they can adapt their strategy
to make use of), rather than needing to wish for it: the chance of
finding useful armor is higher both in the Dungeons (due to the
increased probability) and in Gehennom (because it is more biased
towards armor that might be useful at that stage of the game). In
practice, in 3.6.x (prior to this change and to wishing changes), it
was quite common for players to wish up an entire set of armor at the
Castle, ignoring almost everything they'd found so far that game; I'm
hoping this change encourages more wish variety rather than spending
the majority of wishes on armor.
Key bindings were stored as a fixed-size array, indexed by the input
character, pointing to the extended commands. This changes that into
a linked list of an intermediary struct Cmd_bind, storing the input key
and the pointer to the command.
This is just code cleanup for future enhancements, and should have
no effect on gameplay.
The old code had two main problems: a) it was very difficult for
unspoiled players to figure out how it worked (because donating too
much got you a bad result, and the exact amount you needed depended
on magic numbers that weren't stated in game, and because you had to
hide your visible gold to get a good result); b) for players who
knew the mechanics, it was somewhat exploitable and also somewhat
tedious to make use of (due to needing to hide visible gold before
donating).
This change preserves the spirit of the previous code whilst making
things more transparent for new players and less tedious for existing
players: the donation amounts for the various effects are still
roughly the same (but randomized), but the amounts you need to donate
for clairvoyance and for protection are explicitly stated (and as
before, the alignment reset is done by donating an unnecessarily
large amount and isn't explicitly stated as an option). If you have
a lot of visible gold, you still need to donate a sizeable proportion
of it to get a useful effect, but now you get a larger reward to
compensate for the larger donation (to the extent that doing this
gives comparable results to doing it as a series of small donations,
removing the incentive to hide your gold before donating).
There's also something here for those players who like to squeeze
every last point of optimality out of a game: the "obvious" donation
strategy gives decent results, but players who are really willing to
dig into the mechanics may be able to find a way to get slightly
better results on average (which if I've balanced this correctly,
will lead to a very long and complicated spoiler).
One other change is that this is now based on your peak rather than
current level, to fix an exploit in which the character was drained
down to level 1 to donate a very large amount of gold (improving by
20 AC points) and then immediately restored back to the previous
experience level using a blessed potion of restore ablity.
This breaks save compatibility, but is being pushed together with
other save-breaking changes to avoid the need for multiple bumps to
EDITLEVEL.
It takes time for an early-game monster to acclimatize itself to the
power of an attack wand: in much the same way as a nervous human may
quite possibly miss with their first attempt to use a gun in combat,
an early-game monster will always miss on its first use of an attack
wand (but from then on will understand how they work and get over
their nerves, and will hit as normal).
This is a balance change based on observed results from tournaments:
guarding against deaths to early-game attack wands requires an
unusually cautious playstyle which isn't much fun (and might not
always be possible even for the best players), so it is quite common
for them to be the cause of random deaths that it wasn't worth trying
to avoid. Although trying to dodge a monster who found an attack wand
is fun, you only actually get that fun if something makes you aware
of the danger: the monster missing with the wand is a clear way to
demonstrate the danger and let the player know that now is the right
time to take precautions.
This change could theoretically have broken saves, but probably
doesn't due to there having been a spare bit in struct monst. Just
in case, it is being pushed together with other save-breaking changes
to avoid the need for multiple bumps to EDITLEVEL.
A wand of stasis prevents teleportation (even in some cases where
it would normally not be prevented, e.g. the hero teleporting a
monster, or covetous monsters teleporting). This is intended to
provide an alternative tactic against covetous monsters (and their
AI has been adjusted to handle being under a stasis effect), but
might also be useful in other situations. It does not prevent
teleportation of objects, only the hero / monsters, and does not
at present prevent level teleportation (although I'm not sure about
this and it might well change in the future).
This breaks save compatibility, but is being pushed together with
other save-breaking changes to avoid the need for multiple bumps to
EDITLEVEL.
In previous versions of NetHack, this wasn't a problem because
teleport traps didn't *generate* on such levels, but more recent
changes have made this situation possible (e.g. a demon lord
migrates to a Gehennom filler level that already had a teleport
trap on it).
This change causes a "wrenching sensation", like stepping onto a
teleport trap with magic resistance does.
These are displayed in discoveries, and a new 'price_quotes' option
allows them to be displayed for un-IDed objects in other contexts
too (the idea is that you turn on the option while identifying
objects and off for general play).
Invalidates existing save files.
