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.
Ensure the standard C99 values are available to the NetHack code base, so that
code/macros to accomplish essentially the same thing are not necessary.
CHAR_BIT Defines the number of bits in a byte.
SCHAR_MIN Defines the minimum value for a signed char.
SCHAR_MAX Defines the maximum value for a signed char.
UCHAR_MAX Defines the maximum value for an unsigned char.
CHAR_MIN Defines the minimum value for type char and its value will be equal to SCHAR_MIN if char represents negative values, otherwise zero.
CHAR_MAX Defines the value for type char and its value will be equal to SCHAR_MAX if char represents negative values, otherwise UCHAR_MAX.
MB_LEN_MAX Defines the maximum number of bytes in a multi-byte character.
SHRT_MIN Defines the minimum value for a short int.
SHRT_MAX Defines the maximum value for a short int.
USHRT_MAX Defines the maximum value for an unsigned short int.
INT_MIN Defines the minimum value for an int.
INT_MAX Defines the maximum value for an int.
UINT_MAX Defines the maximum value for an unsigned int.
LONG_MIN Defines the minimum value for a long int.
LONG_MAX Defines the maximum value for a long int.
ULONG_MAX Defines the maximum value for an unsigned long int.
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.
The MSVC warning assumes that any attempt to write - followed by an
unsigned number is an attempt to create a negative number (which
produces the wrong data type if you type, e.g., -2147483648).
However, it's also warning when an explicit U is given, e.g. in -1UL,
which is clearly not an attempt to express a negative value.
Suppress the warning by rewriting the number in question as (0UL-1UL)
with a binary rather than unary minus.
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.
