Change the classification of new weaponstatus, armorstatus, and
terrainstatus from 'OptS_Status' to 'OptS_Advanced' to keep the menu
for the 'O' command shorter. Doesn't affect 'mO'.
Including them in 'O' might make more players notice them though.
armorstatus, and terrainstatus
This adds three special status items to show at a glance what the hero
is wielding, wearing, and standing on.
Each of the three items has its own boolean option rather than try to
fix them in with the existing opttional status conditions. After a
lot of testing, I think the weapon and armor ones will prove useful
but the terrain one probably won't be.
Presently it is implemented for tty and curses. When I developed it
six years ago, it was also working for X11 but I'm not able to test
the resurrection of that part so have left it out.
Any sort of iron footwear now protects from traps, and polymorph
traps change one sort of iron footwear into a different sort of
iron footwear (removing any incentive to try to farm them, because
you will see both options very quickly).
Because some optlist entries were ignored in the early pass,
some non OPTIONS= lines in the config file were having issues
due to those options not being set.
Extend what is being disregarded in the early config file pass
to include other config file statements.
remove the safeproc pseudo-windowport routines from
almost a decade ago.
A very early pass is made through the config file,
seeking out just the interface-related OPTIONS=windowport
and OPTIONS=soundlib and ignoring all other options in the
config file during that early pass, so the windowport
can be activated without the NetHack core initialization
in place that some of the other rcfile OPTIONS require.
Bundles the existing rcfile processing code into rcfile().
New functions to control which rcfile options will be
disregarded in the early config file pass, and which will be
processed:
set_all_options_disregarded();
set_all_options_heeded();
disregard_this_option(opt_xx);
heed_this_option(opt_xx);
Windows calls rcfile_interface_options(), which is
a bundling of a series of function calls to achieve
the desired result.
void
rcfile_interface_options(void)
{
allopt_array_init();
set_all_options_disregarded();
heed_this_option(opt_windowtype);
heed_this_option(opt_soundlib);
rcfile();
set_all_options_heeded();
disregard_this_option(opt_windowtype);
disregard_this_option(opt_soundlib);
}
remove the safeproc pseudo-windowport routines from
almost a decade ago.
A very early pass is made through the config file,
seeking out just the interface-related OPTIONS=windowport
and OPTIONS=soundlib and ignoring all other options in the
config file during that early pass, so the windowport
can be activated without the NetHack core initialization
in place that some of the other rcfile OPTIONS require.
Bundles the existing rcfile processing code into rcfile().
New functions to control which rcfile options will be
disregarded in the early config file pass, and which will be
processed:
set_all_options_disregarded();
set_all_options_heeded();
disregard_this_option(opt_xx);
heed_this_option(opt_xx);
Windows calls rcfile_interface_options(), which is
a bundling of a series of function calls to achieve
the desired result.
void
rcfile_interface_options(void)
{
allopt_array_init();
set_all_options_disregarded();
heed_this_option(opt_windowtype);
heed_this_option(opt_soundlib);
rcfile();
set_all_options_heeded();
disregard_this_option(opt_windowtype);
disregard_this_option(opt_soundlib);
}
Unix and Windows had diverged significantly for command line
options handling.
This:
1. uses the the Unix processing as a baseline.
2. consolidates the code in earlyarg.c, where it can
be a common copy to be shared.
3. start converting the Windows command line argument
processing to the Unix code that now resides in earlyarg.c.
Acolytes grow up to priests, apprentices to wizards, but they
did not cast spells after they grew up. Give the monster priests
and wizards the same spellcasting attack as all the other
priest and wizard -type monsters.
This lack of magical ability goes back at least to 3.3.1;
I didn't bother checking back further.
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.
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.
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.
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
Move the active Amiga source files back into their proper locations.
Legacy native build files (Makefile.ami, Build.ami, etc.) remain
in outdated/ as they are not used by the cross-compilation build.
The non-macro q_path() function wrappers in vision.c pass the first
two arguments in the wrong order to the _q*_path() functions, swapping
rows and columns. This causes the Bresenham line-of-sight code to use
column values as row indices into viz_clear_rows[ROWNO], producing
out-of-bounds access and infinite loops.
NO_MACRO_CPATH selects these broken function wrappers. It was only
defined for Amiga (in config1.h), so the bug never triggered on other
platforms. Remove the define to use the correct macro versions.
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.
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.
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.
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.
