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.
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...
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).
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.
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.
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).
Test generation of every object, both via des.object and obj.new.
Expose FIRST_OBJECT and LAST_OBJECT numbers to lua.
Add lua nh.int_to_objname, a function to convert integer value to
object base name and class.
Allow creating new nethack lua object by specifying id and class.
Using extended #name for an object on the floor (for example)
wasn't updating the permanent inventory to reflect the updated
object type name if there was also one in inventory.
These are often an important part of a character's build. There's
no purpose in listing them in disclose because the player generally
already knows what spells and skills they had and doesn't need them
identified, but they're useful when looking at someone else's game
or reminiscing over a past game.
This adds a "reroll" option that lets players reroll their
character's attributes and starting inventory. Although I generally
think doing this makes the game worse, a) some players are going to
do it regardless and b) if a player is going for a challenge game,
rather than to win, it may be required. So in the absence of an
option like this, players repeatedly start and quit games instead,
creating a large number of junk logfile entries and generally
causing problems for other players on the same shared machine
(because repeatedly reloading the game is very CPU-intensive).
This should in theory be windowport-agnostic (although in practice
it may not be). Tested on tty, X11 and curses; on tty and X11 it
works fine (although X11 treats the change in attributes as
something that needs a status highlight), on curses it is slightly
jankier in terms of what other windows are drawn in the background
(but still plays correctly and I suspect this is a pre-existing
bug).
To form a complete implementation, we will need to consider the
following:
- Should there be a delay on a) starting the game and/or b)
rerolling? If so, what should it be (maybe configurable via
sysconf?)
- Should we take more steps to discourage players from rerolling?
It would be bad if players see the option exists and turn it on
just because it exists, or (worse) treat it as condoning the
particular style of play.
- Should we take steps to detect that players are rerolling
manually and a) tell them to use the option instead, b) tell them
that this is not an intended way to play (and may make the game
less enjoyable and/or prevent them getting the practice they need
to eventually win)?
Breaks save and bones files.
This doesn't implement inventory rerolling, just adds the
infrastructure: it's now possible to call u_init_inventory_attrs
multiple times and the starting inventory/attributes replace those
from the previous call rather than compounding.
This fixes a couple of bugs: a long-standing bug in which writing a
scroll by label could fail even if you've already seen a scroll with
that label (due to the game not tracking whether or not you've seen a
scroll if it doesn't have a name); and a somewhat newer bug in which
spellbooks auto-identified by Wizard knowledge were marked as having
been encountered (rather than as known but not encountered).
Breaks save file compatibility, but not bones files.
Issue reported by chappg: on arboreal levels, when an object was
located at a stone location treated as a tree location, examining
the object would report it as embedded in stone.
The Ranger quest has arboreal levels where STONE becomes TREE, and
items that would become embedded in stone will be in trees instead.
(Sometimes kicking a tree would drop fruit onto an adjacent tree,
effectively embedding it. For testing, it's easier just to poly
into a xorn, walk onto the tree spot, and drop something.) The item
description code for farlook and quicklook wasn't checking for that.
The fix also corrects another bug: an item located at a normal tree
location would just be described as itself with no mention of the
tree at all. Attempting to walk onto it would report the terrain
and not let you move there (assuming not in xorn form), like trying
to walk into a wall.
Fixes#1462
There was only one point in the code at which this caching was
being done, and it was incorrect: it's possible for the result of
near_capacity to change during a monster turn because monster
actions can change either inventory weight or carry capacity.
The bug was particularly relevant in cases where a character
polymorphed into a slow weak monster gets attacked by a monster
that moves at normal speed: due to the polyform being slow, the
normal-speed monster gets in a lot of attacks and causes a
rehumanization, but due to the polyform being weak, it was
burdened at the start of the monster turn, and so when that
penalty is (due to the bug) applied to the next turn it can
mean that the character misses the next turn too, and may end up
dying as a result.
Several window ports that support perm_invent were
using a call back to the core display_inventory()
function.
While calling from the window port back to core functions
is arguably not ideal in the first place, it was recently
brought to light that code NetHack-3.7 code changes to
display_inventory() actually caused it to stop repopulating
the perm_invent window as intended under certain circumstances.
For now, provide an alternative function, repopulate_perminvent(),
that hopefullshould still work the way it did previously.
There will likely be some additional changes after this to
further improve things, at some point.
For now though, this
Resolves#1454
Using 'i'+menu choice for suit+'T' to try to take off a suit that is
covered by a cloak (or shirt covered by suit and/or cloak) wouldn't
do anything. It should report that you need to take off the outer
garment first and then not take the chosen item off.
There is probably a simpler fix. It took me a long time to figure
where things were going wrong and them cobble this together.
A big chunk of the diff for invent.c is just identation, surrounding
a one-line change there.
In the context-sensitive menu when picking an item of armor from an
inventory listing, distinguish between wear-this-armor from could-
wear-this-armor-if-something-else-wasn't-already-worn-in-its-slot.
> Perhaps related: when a wand of sleep hits a disguised already-sleeping
> mimic (about which it is a separate question if they should go into
> disguise when sleeping, is it supposed to be automagic or conscious
> effort for them? but I digress), the mimic is not revealed (should it?)
> but the message says "hits a mimic".
Adjust restrap() so that a revealed mimic won't disguise itself while
sleeping. This seems to be in keeping with mimic lore.
Also, normal shop sounds (chime of register etc.) will wake a
mimic up from indeterminate sleep.
Closes#1441
More details in https://github.com/NetHack/NetHack/issues/1430
track photographed monsters using a distinct bit
also adds a pair of new context fields to track the total number of monsters seen up close,
and the total number of monsters photographed.
So, if somebody wants to add unique end-of-game disclosure statements for tourists that relate to
those, the groundwork should be there.
NOTE: This increments EDITLEVEL, so existing save and bones files will become outdated.
Fixes#1430
This is the third of a series of savefile-related changes.
This adds early-days experimental support for a completely optional
'sfctool' utility (savefile conversion tool), to be able to export
a savefile's contents into a more portable format. There are likely
to be bugs at this stage. In this initial first-attempt, the export
format is a very simple ascii output.
NetHack can be built entirely, without also building this tool.
NetHack has no dependencies on the tool.
Attempts were made to minimize duplication of existing NetHack code.
To achieve that, unfortunately, #ifdef SFCTOOL and #ifndef SFCTOOL
had to be sprinkled around through some of the existing NetHack
source code, so that it could be re-used for building the utility.
The process for building the sfctool typically recompiles the source
files with #define SFCTOOL and a distinct object file with SF- is
produced.
sfctool notes:
Universal ctags is used and required to produce the sfctool utility.
Some targets were added to the Unix and Windows Makefiles to
facilitate the build process.
make sfctool
That should build a copy in util.
Note: At present, the Unix Makefiles do not copy sfctool over to the
NetHack playground during 'make install' or 'make update'.
Until that gets resolved by someone, The tool will
have to be manually copied there by the builder/admin if
desired.
cp util/sfctool ~/nh/install/games/lib/nethackdir/sfctool
Also, a separate Visual Studio sfctool.sln solution was written and
placed in sys/windows/vs. That has has only very limited testing.
Usage:
i) To convert an existing savefile to an exportascii format
that co-resides with the savefile:
sfctool -c savefile
That *must* be executed on the same platform / architecture /
data model that produced the save file in the first place.
ii) To unconvert an existing exportascii format export file to a
historical format savefile that can then be used by NetHack:
sfctool -u savefile
That must be executed on the same target platform / architecture /
data model that was used to build the NetHack that will
utilize the save file that results.
A Windows example:
sfctool -c Fred.NetHack-saved-game
That should result in creation of Fred.NetHack-saved-game.exportascii
from existing savefile:
%USERPROFILE%\AppData\Local\NetHack\3.7\Fred.NetHack-saved-game
A Unix example:
sfctool -c 1000wizard
That should result in creation of 1000wizard.exportascii.gz
from existing savefile in the playground save directory:
1000wizard.gz
Current Mechanics:
1. Makefile recipe, or script uses universal ctags to produce
util/sf.tags.
2. util/sftags is built and executed to read util/sf.tags and
generate: include/sfproto.h and src/sfdata.c.
3. util/sfctool is built from the following:
generated file compiled with -DSFCTOOL:
src/sfdata.c -> sfdata.o
existing files compiled with -DSFCTOOL:
util/sfctool.c -> sfctool.o
util/sfexpasc.c -> sfexpasc.o
src/alloc.c -> sf-alloc.o
src/monst.c -> sf-monst.o
src/objects.c -> sf-objects.o
src/sfbase.c -> sfbase.o
src/sfstruct.c -> sfstruct.o
src/nhlua.c -> sf-nhlua.o
util/panic.c -> panic.o
src/date.c -> sf-date.o
src/decl.c -> sf-decl.o
src/artifact.c -> sf-artifact.o
src/dungeon.c -> sf-dungeon.o
src/end.c -> sf-end.o
src/engrave.c -> sf-engrave.o
src/cfgfiles.c -> sf-cfgfiles.o
src/files.c -> sf-files.o
src/light.c -> sf-light.o
src/mdlib.c -> sf-mdlib.o
src/mkmaze.c -> sf-mkmaze.o
src/mkroom.c -> sf-mkroom.o
src/o_init.c -> sf-o_init.o
src/region.c -> sf-region.o
src/restore.c -> sf-restore.o
src/rumors.c -> sf-rumors.o
src/sys.c -> sf-sys.o
src/timeout.c -> sf-timeout.o
src/track.c -> sf-track.o
src/version.c -> sf-version.o
src/worm.c -> sf-worm.o
src/strutil.c -> strutil.o
