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.
Instead of outright destroying the armor, the spell will instead
first erode the armor. The spell hits 2-4 times, so if it hits
the same armor 4 times, it will get destroyed. This does not
hit erodeproof armor.
Also change the scroll of destroy armor, so that blessed one will
destroy a cursed armor, if hero is only wearing that.
Give experience to the hero if opening Shroedinger's Box reveals a cat
corpse rather than releasing a live cat.
It feels a bit odd to assess a bonus rather than a penalty.
Reported via email direct to devteam.
If a monster killed by a drawbridge survives via life-saving and a
second monster also survives (in the reported case, it was a xorn
who will always survive bridge destruction), the second monster will
be placed at the same spot. That triggers an impossible
"placing <2nd mon> over <1st mon>, at <x,y>, mstates 0 0 at Dlvl N?".
If the first monster survives due to pass_walls rather than due to
life-saving and a second survives too, one of them should end up being
moved to a different spot and not trigger the impossible (not verified
via testing).
When a monster survives via life-saving, kill it again even if there
is no second monster involved.
Update vision affected by invisible mimics if polymorphing hero gains
or loses See_invisibls. Avoids triggering a sanity_check impossisble
if an invisible mimic is mimicking a boulder.
Bug report was that engulfer killed hero who was life-saved and expelled
onto a rolling boulder trap which resulted in the death of a bystanding
monster. That triggered an impossible about placing the engulfer onto
the map at an already occupied spot (containing the engulfer itself)
while dealing with the dead bystander.
This removes the code in mon_leaving_level() that was putting the
engulfer on the map. I'm no longer able to reproduce the problem it
was intended to solve, and if that problem (message delivery about the
swallow attack delivered with the engulfer missing from the map) exists,
it would be less severe than the impossible feedback. I didn't attempt
to reproduce the actual reported problem since the code removal should
make it moot.
Once again, the bug report via the web contact form got misclassified
as spam.
Give feedback if a visible monster drinks a potion of invisibility
that happens to be cursed so monster fails to become invisible, or if
hero hits a visible monster with a cursed potion of invisibility and
it fails to become invisible.
Show the invocation items in the unique items section of the
discoveries list even when they're only flagged as encountered rather
than fully discovered. The Amulet of Yendor is excluded; it has to
be fully discovered to be shown in that section.
The ` command already supports selecting 'u' for unique items as a
pseudo-class. Add support for 'r' as synonym to match the recent
addition of 'relics' to the Guidebook.
The unique item category includes the Amulet of Yendor in addition
to the three invocation items. 'r' shows it too, once it has been
fully IDed. I'm ambivalent as to whether the Guidebook's Relics
section should mention it.
In wizard mode, I used ^W to wish for the Amulet of Yendor and was
immediately prompted for another wish. It was baffling and took a
while to figure out. Give a message before initiating the wish.
This has been laying around for a few weeks. I meant to do more but
have forgotten what the rest would have been.
Don't mark generic objects as dknown.
Extend the recently changed behavior for cursed potion of invisibility.
Monsters won't drink potions of invisibility if already invisible so
can't accidentally or voluntarily make themselves visible again, but
let player make them become visible by hitting them with thrown or
wielded cursed potion of invisibility.
They don't have any concept of temporary invisibility that might let
them remain invisible while losing permanent invisibility, so they
just lose the latter and immediately become visible.
Return a couple of variables that actually held a direction back
to int from coordxy.
bhit() takes int params instead of coordxy.
boomhit() takes int params instead of coordxy.
xytod() renamed to xytodir(), and takes int params (promotion will handle
coordxy params).
dtoxy(coord *, int) renamed to dirtocoord(coord *, int).
dmgval is also used for monster attacks; move the healer knife
bonus to actual hero-specific code, and make sure it only
applies to hand-to-hand combat.
Styled as anatomy knowledge, a healer attacking a monster in melee
with a knife gets +1 damage per 6 dead monsters of that type,
capped at +3 damage.
Handwaving away the fact we're not keeping track who actually
killed the monsters...
Idea from aosdict.
