The two options are very similar but probably mutually exclusive
except when using look-here and look-into-container (both via ':')
with the default setting for 'sortloot', or with inventory when
'sortpack' has been toggled off.
This removes 'use_menu_glyphs' and changes 'menu_objsyms' from a
boolean to a compound taking six possible values:
| 0: no object symbols in menus,
| 1: append object class symbol to object header lines (same as old
|menu_objsyms boolean),
| 2: include object symbol in menu entry lines for objects (same as
|recently added use_menu_glyphs),
| 3: both 1 and 2,
| 4: display as #2 but only if the menu lacks class header lines,
| 5: if header lines are present, display as #1; if headers are not
|present, then display as #4 (which will implicitly be #2).
Default is #4.
Effectively replaces the options portion of pull request #1406 and
retains the functionality, but not as default for normal menus.
Guidebook.tex is only partially updated. Someone else will need to
finish that.
Provide a way to bypass a debugger when initiating fuzzing.
nethack -D --debug:fuzzer # run fuzzer in wizard mode
nethack --debug:fuzzer # run it in normal mode
nethack [-D] -@ --debug:fuzzer # skip role/race/&c selection
Options processing can be early, even before ttyDisplay is allocated.
If we find that TTY_PERM_INVENT initialization is happening too early,
just set a marker (iflags.perm_invent_pending) to try again a bit later.
The changes in win/share are just to be able to sucessfully
reproduce the original issue on Windows. It was easily reproduced
on Unix, just by building with TTY_PERM_INVENT in include/config.h
and setting OPTIONS=perm_invent in config file.
I don't always want to abort() on an impossible() when debug_fuzzing,
especially if the first impossible() encountered isn't related to the
bug I'm in the midst of trying to hunt down.
I often have breakpoints on impossible() anyway, and I'd like a simple
way to avoid the panic() call during a lengthy debug session.
Make iflags.debug_fuzzer an xint8 instead of a boolean.
Call abort() only if iflags.debug_fuzzer is set to 1.
That allows setting iflags.debug_fuzzer to 2 in order to bypass the
abort call, and make use of other breakpoints that have been set
to narrow down a particular issue.
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
For curses, behave like tty by keeping a count of messages issued via
raw_print, then if that is non-zero issue a prompt and require the
player to acknowledge them before it erases the screen. Mainly so
that complaints during RC file processing will be seen.
For tty, force getret() to be an unconditional routine instead of
sometimes a routine, sometimes a macro which calls another routine.
underneath gets boiled away
Pull request by disperse: when a water walking hero zaps a wand of
fire downward and it boils away the water, hero should fall into the
resulting pit.
The PR commit didn't handle monsters (who don't zap wands downward
but could be on/in water that's boiled out from under them). And
while testing it I noticed that the existing code had message
sequencing issues (being enveloped in a cloud of steam before seeing
the water evaporate). This ended up redoing the fix rather than
using the commit.
Fixes#1238
Make sure the windowcolors option can be specified more than
once without a config file warning.
Make the struct holding the details a little more extendable.
Add options 'showvers' (boolean) and 'versinfo' (numeric mask) to
show nethack's version on the status lines during play. It won't be
particularly interesting to ordinary players but should be useful
when making screenshots or video to be streamed, or for someone who
switches between git branches or between nethack and variants.
I worked on this several months back but it was combined with
unfinished changes to 'hitpointbar'. I've separated it out so that
it can be put into use. When enabled, one or more components of
"<name> <branch> <version>" will be shown right justified after
status conditions. At present the default is "<branch>" if that is
available and overall status isn't 'released', or "<version>" if
'released' or if branch isn't available. That might need some
refinement.
It works as intended for tty and curses, although some abbreviation
mechanism would be useful if/when the program resorts to abbreviating
status conditions to make things narrow enough to fit.
For X11, it works ok for fancy_status:True (the default, controlled
via NetHack.ad settings) but is messed up for tty-style status. The
text is positioned correctly but there are gaps in it, making it
appear garbled, similar to what I saw when I tried and failed to
implement statuslines:3 for X11. [It might be due to having empty
condition widgets be 1 pixel wide instead of being totally removed
but I don't think the situation is that simple.]
For Qt, if the text needs to be truncated in order to fit, the center
portion of the string will be shown, discarding parts from the left
and right. That ought to discard from left and retain rightmost
portion instead.
For win32|mswin|Win GUI, no attempt to support it has been included.
Things should be ok when 'showvers' is left as False (the default)
but I don't know what will happen if that gets toggled to True. At a
minimum, the version info won't be right justified. The information,
or at least some of it, is displayed in the game window's title bar
so there isn't any pressing need to add it to status, but toggling
the option will need to behave sensibly if it doesn't already.
Adds a new extended command #lookaround, which will describe
the map around the hero they can see or remember.
Adds a new boolean option mention_map, which will give a message
when an interesting map location in sight changes.
Add a new boolean option showdamage, if on, outputs a message
like "[HP -2, 14 left]" - several variants have something similar,
but I chose the message based on how eSpeak said it, while keeping
it short.
When a nymph or monkey successfully steals a worn item from hero,
first the item is unworn, side-effects of that take place (most
noticeably descending when losing levitation or flight) including
feedback about such side-effects, finally "<Mon> steals <item>" and
transfer from invent to thief's minvent. If the side-effects were
fatal (such as drowning or burning up in lava), the player wouldn't
see any explanation for why that happened.
When a thief removes a worn item, give a message to that effect:
"<Mon> takes off your <item>." That will usually be immediately
followed by "She stole <item>." When the thief isn't a nymph or if
any messages were delivered after the "takes off" one, the monster
will be described by name: "<Mon> stole <item>."
Adds a new boolean option, spot_monsters. If on, every time
the hero notices a monster which was out of sight before,
a message is given. Combine with accessiblemsg to get the
monster location:
(3north): You see a newt.
Breaks saves and bones.
Adds a new boolean option, accessiblemsg. If on, some game messages
are prefixed with direction or location information, for example:
(west): The newt bites!
(northwest): You find a hidden door.
I added the info to the most common messages, but several are
still missing it.
Add pickup_stolen option to autopick items stolen from you by a nymph or
monkey, even if they don't match your normal autopickup settings.
Replace was_dropped, was_thrown with a 2-bit bitfield that can contain
values LOST_DROPPED, LOST_THROWN, and LOST_STOLEN (or 0), since they
should all be mutually exclusive anyway as they track the most recent
way the item left the hero's inventory.
[Rebase/merge conflict fixed up. PR]
This is based on a feature in UnNetHack (and I think some other variants
as well). If the hero intentionally drops an item with 'pickup_dropped'
disabled, don't autopick it back up when walking over that square again.
Typically when the player drops an item, it's because she doesn't want
it in her inventory any more, and this option stops autopickup from
defeating that goal (especially useful for tasks like stash management
without a container). Players have come up with workarounds to this
problem like toggling autopickup when approaching their stash pile or
adding name-based autopickup exceptions to allow them to exclude
individual items from autopickup, but this behavior should reduce the
need for those things.
I think 'pickup_dropped' is a little unfortunate because it suggests
equivalence to 'pickup_thrown' (i.e. any dropped items will be
automatically picked up regardless of autopickup exceptions). Calling
it something like 'nopick_dropped' might be better, but as far as I can
tell options cannot start with the word 'no' because it's interpreted as
a negation of the rest of the option name.
This implements the mechanics to use the ctrl_nhwindow() interface
capability to pass down a setting change from the core to the active
window port, without resorting to accessing a core global variable
from within the window port, and without altering the interface..
The passed setting is honored in the tty and curses window ports.
X11 and mswin receive and store the values, but no implementation
to change the menu prompt style is there yet.
Qt does not store the values or have an implementation.
The setting change is done in allmain.c immediately after
creating the WIN_INVEN window.
Instead of just accepting an attribute, it's now possible to
use a color, or both color and attribute, for example:
OPTIONS=menu_headings:inverse
OPTIONS=menu_headings:red
OPTIONS=menu_headings:red&underline
Default is still just inverse.
This lets the player change the menu heading color without
needing to use menu colors for them.
Also makes it so the core uses NO_COLOR instead of 0, for all
the menu lines which don't have any prefedefined color.
Tested for tty, curses, x11, qt, and win32
I realized that failed explore-mode authorization on a special-mode
saved game cannot downgrade the game mode further down to a normal game,
because this would dump the player back into a state where she has
completed some part of the game in explore mode but is eligible for the
topten list. This is even more true when the game was formerly a
wizard-mode game. Unforunately, that was the state my previous commits
left the game in.
Instead, if restoring an explore-mode or wizard-mode savegame, and the
player is authorized via sysconf for neither of those modes, fail
restoration entirely and start a new game instead. That's sort of
clunky and there could probably be more explanation provided, but it
should be an exceedingly rare occurance and I'm not sure what
alternative exists that would still honor the EXPLORERS and WIZARDS
restrictions. This shouldn't affect the way they default 'down a mode'
in other circumstances, i.e. the overwhelming majority of situations in
which EXPLORERS authorization is needed/checked.
For the same reason, I realized that the player can't be prompted
whether or not to enter explore mode, if being downgraded from a
no-longer-authorized wizmode save while explore mode is authorized. The
change from wizard mode to explore mode must be mandatory. I have also
switched that up so that it will force the change -- unfortunately, this
has the side effect of allowing the preservation of the save, but it's
more important to make sure a wizard mode game doesn't get reverted to
normal mode. They won't be able to load the save into wizard mode
anyway.
Add a new option 'perminv_mode' to augment perm_invent. It handles
the same choices as the temporary TTYINV method: show all items other
than gold, show full inventory including gold, or only show in-use
items (similar to the '*' command).
For tty, both the all-except-gold and full-inventory modes can add
the poorly named 'sparse' variation which populates unused slots in
its fixed grid with the inventory letter that would go in each.
For others, the default has been changed from full-inventory to
all-except-gold. Note that gold is treated as part of 'all' or of
'in-use' if it is quivered because having the amount be shown on the
status line doesn't make that redundant.
Changing the default may mess up WinGUI if it assumes that perm_invent
is full inventory with gold.
Initially I was going to change perm_invent into a compound but this
leaves it as an on/off toggle and adds perminv_mode as a separate
option for how to show the inventory when the toggle is on. It may
make sense to combine them since dual controls is a little confusing,
but right now setting perm_invent On when perminv_mode is 'none'
changes that to 'all' and changing perminv_mode away from 'none' when
perm_invent is Off toggles it to On.
Guidebook.mn has been updated but as usual Guidebook.tex is lagging.
Classify nearby ice as "solid" (no melt timer), "sturdy" (more than
1000 turns left), "steady" (101 to 1000 turns left), "unsteady" (51
to 100 turns left), "thin" (15 to 50 turns left), or "slushy" (1 to
14 turns left, matching walking on ice with the Warning attribute).
[I'm not thrilled with "steady" and particularly "unsteady".]
I was originally going to do this just for probing downward, but ended
up also doing it for look-here and getpos's autodescribe. It nearly
got out of hand and touched more files than anticipated.
'mention_decor' ought to treat moving from ice firmer than thin to
thin or slushy, from thin to slushy, from slushy to any other, and
from thin to firmer as if moving onto different terrain but I haven't
attempted to tackle that.
The melt timer could work more like a candle's burn timer, triggering
at intermediate stages and resetting itself, so that ice which changes
to a weaker state under the hero could be reported to the player. But
this doesn't implement that.
From a comment w/ diff in the pull request by entrez, combine the
show-full-map flag (available in wizard mode and explore mode) with
the bitmask for map-only, map-and-traps, map-and-traps-and-objects
flags for #terrain mode (and getpos() help) instead of passing that
as a separate argument. No change in behavior unless I messed up.
Fairly old pull request from copperwater: add new paranoid_confirm
setting 'trap'.
The old commit suffered from bit rot and merging needed too much
fixing up despite there not being many bands of change in the commit's
diffs. I ultimately redid it from scratch, although the two biggest
chunks of code started with copy+paste of the pull request's commit.
It operates like paranoid:pray. Setting paranoid:trap adds a new
"Really step into <trap>?" y/n prompt when attempting to move
into/onto a known trap, even if an object covers it on the map.
Setting both 'paranoid:Confirm trap' turns that into a yes/no prompt.
(Adding 'Confirm' affects other paranoid confirmations; in addition
to requiring yes<return> rather than just y to accept, it also forces
no<return> to reject.)
However, moving into a known trap that is considered to be harmless
behaves as if no trap was present. Some of the trap classification
might be out of date; several types of traps have undergone changes
since implementation of the original pull request, notably anti-magic
field. When the hero is hallucinating, all known traps are considered
harmful since the map no longer reliably describes them.
Preceding a movement command with the 'm' prefix also behaves as if
no trap was present, bypassing confirmation for that move, similar to
how paranoid:swim currently behaves. Being stunned or confused also
behaves as if no trap was present, taking priority over hallucination.
This updates the documentation.
Supersedes #259Closes#259
Issue most recently reported by Xdminsy (previously reported by
others): it is too easy to accidentally pick choice 'A' in object
class selection menus for menustyle:Full. Previous change relevant
to this was to exclude choices 'A' and 'a' from being set by '.'
(choose all entries) and '~' (toggle all entries). That was an
improvement but doesn't help with pressing shift when meaning to
type 'a' by those who type faster than they cogitate.
This implements a suggestion by janne-hmp: add new choice for the
paranoid_confirmation option, 'Autoall' (synonym 'Autoselect-all').
If the player sets this and includes 'A' among the choices for
class selection, prompt to confirm whether to honor it. Like
confirmation for praying, it adds an extra y/n prompt rather than
change an existing y/n prompt into a yes/n or yes/no one. If the
player declines, then nothing is selected and the operation is
cancelled rather than putting the menu back up to choose again.
OPTIONS=paranoid_confirm:autoall requires at least two letters
('au') even if the 'a' is capitalized. paranoid_confirm:a means
confirm attacking peaceful monsters. And it should be
OPTIONS=paranoid_confirm:autoall pray swim
if someone just wants to add autoall to the default paranoid bits.
The Guidebook hasn't been updated to describe the new choice since
it seems likely that it might undergo adjustments.
Closes#1065
Reported by Umbire: if a statue of a hider-under was activated by
a statue trap, it would hide underneath its own statue. Also, the
hero saw a snake hide under unseen submerged kelp.
Both of those things were exposed by new "you see <monster> hide"
message rather than caused by it. It also led to the [re-]discovery
that an existing monster hiding under a statue that was a not-yet-
triggered trap prevented the trap from producing a monster.
This redoes yesterday's can't-hide-under-statue change: hiders can
hide under statues again, but they can't hide under anything at trap
locations. [Pits containing one or more objects are an exception,
although it seems silly that a hero is prevented from falling into
one by the presence of a tiny creepy-crawly hiding under a ring or
dart in there.] So, hider-underers won't be able to interfere with
statue traps by being present at the trap location. [Trappers and
lurkers-above probably need a similar restriction; I didn't look.
They avoid trap spots rather than get lured to such by objects.]
It also prevents newly created hider-underers from becoming hidden
as part of the their creation (except when that creation is part
of level creation) whether their creation uses up an object (statue
activation, egg hatching) or there are simply other items present.
That will prevent statue of a hider producing a monster that hides
under the activated statue (which was happening due to the sequence
create monster, transfer any statue contents to monster inventory,
destroy statue).
The can't-hide-under-statues code has been repurposed to prevent
hiding under gold pieces unless there are at least 10 (arbitrary
threshold) of those or they're in a pile with some other object(s).
Sea monsters hide in water regardless of the presence of objects.
Prevent other swimmers from hiding under objects at water locations.
Such creatures don't have gills and shouldn't be able to stay
submerged in hiding for an arbitrary length of time. [No exception
is made for non-breathers. The overlap between swimmers and hider-
underers is limited to small snakes, even though it is feasible for
a creature wearing an amulet of magical breathing to polymorph into
one. Heros don't spend enough time underwater to worry about snakes
hiding under kelp or thrown junk.]
Lastly, alter the "suddenly, you notice a <monster>" message if
monster-vs-monster activity causes one you've just seen going into
hiding comes back out again without any intervening messages. [I'm
not sure whether something similar is needed for the "Wait. There's
something there" message in the you-vs-monster case.]
Fixes#1062
Add a new debugging option, 'montelecontrol', that allows a wizard-
mode player to choose a teleporting monster's destination. If player
picks a bad spot, confirmation will be requested. If accepted, the
spot will be used even though the consequences could be bad; that's
on the player. If rejected, the destination will be assigned as if
no control had been attempted rather than try again.
The fuzzer isn't allowed to override a bad spot if it tries to pick
one. That would probably trigger a sanity_check warning; the fuzzer
causes impossible warnings to behave as if panic, so accepting a bad
spot would just be fuzzer suicide. It is allowed to randomly set the
option and maybe--though extremely unlikely--randomly pick a valid
controlled destination.
Reported by copperwater: entering the tutorial sets 'u.nofollowers',
changing to the tutorial level saves a copy of 'u', post-level change
from entering the tutorial level resets u.followers, but subsequently
changing levels to return to the original level 1 restores 'u' from
the saved copy with has 'u.nofollowers==True', overriding the reset.
Move the nofollowers flag from 'u' to 'iflags'. Invalides save and
bones files.
Fixes#1027
Adds a more general way to handle gameplay tips, and adds
a boolean option "tips", which can be used to disable all
tips. Adds a helpful longer message when the game goes
into the "farlook" mode.
Also adds a lua binding to easily show multi-line text
in a menu window.
Breaks save compat.
sound_verbal(char *text, int32_t gender, int32_t tone, int32_t vol,
int32_t moreinfo);
-- NetHack will call this function when it wants to pass text of
spoken language by a character or creature within the game.
-- text is a transcript of what has been spoken.
-- gender indicates MALE or FEMALE sounding voice.
-- tone indicates the tone of the voice.
-- vol is the volume (1% - 100%) for the sound.
-- moreinfo is used to provide additional information to the soundlib.
-- there may be some accessibility uses for this function.
It may be useful for accessibility purposes too.
A preliminary implementation has been attempted for macsound to test
the interface on macOS. No tinkering of the voices has been done.
Use of the test implementation requires the following at build time with make.
WANT_SPEECH=1
That needs to be included on the make command line to enable the test code,
otherwise just the interface update is compiled in.
I don't know for certain when AVSpeechSynthesizer went into macOS, but older versions
likely don't support it, and would just leave off the WANT_SPEECH=1.
If built with WANT_SPEECH=1, the 'voices' NetHack option needs to be enabled.
It was a bit strange, when I first started up the test, to hear Asidonhopo,
the shopkeeper, talking to me as I entered his shop and interacted with him.
sounds can be set in the config file or on the fly with the Options menu.
This also adds a mechanism for specifying a terminology preference
for a boolean option in the options menu.
The choices are: Term_False, Term_Off, Term_Disabled
Term_False, the default, will use the terms "false" and "true" in the
Options menu.
Term_Off will use the terms "off" and "on" in the Options menu.
Term_Disabled will use the terms "disabled" and "enabled" in the Options
menu.
I didn't review any of the existing options to see if one of the new
alternative terms might be a better fit. They were all left at the default.
Allow the preferred sort order for the vanquished monsters list to
be specified in the run-time config file
|OPTIONS=sortvanquished:X
where X is t, d, a, c, n, or z. It can also be set to 'A' or 'C'
but those aren't documented and aren't offered as choices when
setting the value interactively, which can be done via 'm O' or by
using 'm #vanquished'.
Guidebook.mn has been updated but Guidebook.tex is lagging again.
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Reported by entrez: using ^A instead of #retravel after interrupted
travel can pick wrong location if cursor was previously positioned
with movement commands rather than feature targeting because it
won't be starting from the original spot. Also, ^A after ';' will
just redescribe whatever was examined previously instead of having
the player pick a new spot.
This suppresses cursor positioning from the do-again queue so that
repeating travel or quick-look or other command that needs player
to choose a position will repeat the command but then need to have
a position chosen. For interrupted #travel, the cursor will already
be placed on the previous destination so that's relatively painless,
but also allows a different destination to be chosen.
It adds iflags.remember_getpos that callers of getpos() could set to
be able to restore the old behavior but none do so far.
Fixes#905
The pull request included some changes that were neither accidental nor
unintentional, so only a subset of the changes from pull request #869
submitted by klorpa were manually applied.
behaviour -> behavior
speach -> speech
knowlege -> knowledge
incrments -> increments
stethscope -> stethoscope
staiway -> stairway
arifact -> artifact
extracing -> extracting
The uses of "iff" were left alone.
Close#869
Instead of hardcoding mouse button actions, allow the user to
bind mouse buttons to extended commands. For example the new
defaults are:
BIND=mouse1:therecmdmenu
BIND=mouse2:clicklook
Currently a bit rudimentary; the defaults should be OK, but
documentation is bit lacking, and in-game binding and option
saving are missing.
Allowed commands to bind are "nothing", "therecmdmenu", "clicklook",
and "mouseaction". Clicklook replaces the "clicklook" boolean option,
and mouseaction does what mouse 1 button used to do - a context sensitive
action.
