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.
Groundwork for a more versatile interface for using
sound libraries. A lot of sound libraries work across
multiple platforms.
The current NetHack sound stuff is quite limited.
Binaries can have a variety of window ports linked into
them, and it makes sense to have something similar for
sound.
This tries to set things up in a more soundlib-centric way,
rather than inserting things in a platform-centric way.
It establishes a new top-level directory sound (akin to win
for the window interface routines, or "window-port") where
sound-related additions and sndprocs and support files can be
added and used across platforms.
The default interface is nosound and the 'nosound' interface
is in src/sounds.c
The interface for 'windsound', which contains the same minimal
USER_SOUNDS support using built-in routines that has been in the
windows port for a long time is added to
sound/windsound/windsound.c.
For now, the sound interface support for 'qtsound' has been added
to the existing Qt files win/Qt/qt_bind.h and win/Qt/qt_bind.cpp,
and a note has been placed in sound/qtsound/README.md to avoid
confusion.
New header file added: include/sndprocs.h.
Also includes support by paxed for polearm targeting using the
frame color.
Also renames USE_TILES to TILES_IN_GLYPHMAP which is a more
accurate description.
Not all window interfaces have full support for the color framing
of the background square yet.
MS-DOS needs further work (to bring it to both VESA and VGA, with
and without tiles.
Windows GUI is missing support.
X11 and Qt have been started, but may require further refinement.
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.
Keep track of how a role|race|gender|alignment option got its value
so that role:!Tourist in .nethackrc and role:!Priest in NETHACKOPTIONS
yield 'role:!Priest' rather than merging into 'role:!Priest !Tourist'.
It also doesn't write the value into new config file for #saveoptions
if that value comes from environment or command line (not applicable
since the command line arguments for role,&c don't go through options
handling). Also, the old config file value takes precedence over
the current game's value file so that 'role:random' doesn't become
'role:Healer' or such in a new config after the random value gets
picked for play.
This only tracks the role, race, gender, and alignment options but the
concept could be extended to all options. The data would need to be
saved and restored if values set interactively need to be retained in
restore sessions (doesn't apply to role,&c since those don't change
during play).
Using role:!wizard to limit which roles would be candidates for
random selection didn't work as I expected. It required a separate
option setting for role to exclude. This implements how I thought
it worked:
|OPTIONS=role:!ranger !samurai !wizard
will exclude multiple roles with a space-separated list in a single
option setting. It also adds support for
|OPTIONS=!role:ranger samurai wizard
to do the same thing. (OPTIONS=!role:!ranger isn't allowed.)
I thought 'OPTIONS=role:barbarian caveman knight' could be used to
limit random selection to those choices, but that doesn't work and
I haven't attempted to implement it.
This also renames the 'align' option to 'alignment'. That made the
truncation to 'align' become ambiguous, so it got added back as an
alias for the full name.
Guidebook.tex is lagging; I'm burned out.
Option parsing rejected
|OPTIONS=!cond_X
for all valid X.
Using the menu to unselect all condition options treated that as not
having made any choice and didn't make any changes. That would be
reasonable if nothing was preselected, but things are so unselecting
all of them is a choice. (A bizarre one, but still should be viable.)
Mostly this deals with including cond_X options when #saveoptions is
used to write a new RC file. It now produces something like
|OPTIONS=!cond_barehanded,cond_blind,!cond_busy,cond_conf,!cond_deaf,\
| cond_iron,cond_fly,cond_foodPois,!cond_glowhands,cond_grab,\
| cond_hallucinat,!cond_held,!cond_ice,cond_lava,cond_levitate,\
| !cond_paralyzed,cond_ride,!cond_sleep,cond_slime,!cond_slip,\
| cond_stone,cond_strngl,cond_stun,!cond_submerged,cond_termIll,\
| !cond_tethered,!cond_trap,!cond_unconscious,!cond_woundedlegs,\
| !cond_holding
after the last alphabetical option and before the bound keys, menu
colors, and others which aren't simple OPTIONS=X settings. This only
happens if there is already one or more OPTIONS=cond_X entries in the
old file when it was read or if 'mO' gets used to make any changes.
Not fixed: after my RC had something similar to the above and before
I changed status conditions to accept negation, I was getting several
"the cond_ option may not both have a value and be negated" messages
written to stdout instead of the config file error handler. So they
vanished when the screen was initialized without providing a --More--
prompt to acknowledge that they have been seen.
Force windowtype to be the first option written to new RC file since
its value can affect how other options are processed. (Only saved if
comes from existing RC file, not command line.) doset() lists a few
compound options before the rest too. Combine the two sets of want-
to-be-first and move the handling for that to optlist.h where the only
cost is that the options are no longer in alphabetical order.
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.
'color' appears in the simplified O menu for curses, but was not
showing up for tty. That's because it is hidden when tiles are in
use, and tty has had a bogus value for iflags.wc_tiled_map.
Presence of USE_TILES is not a reliable way to tell whether tiles
are available in a multi-interface binary. Nor is the setting of
DEFAULT_WC_TILED_MAP from config.h.
Show and allow changing the debugging flags in options:
debug_fuzzer: turn on the fuzzer
debug_hunger: prevent hunger
debug_mongen: prevent monster generation
debug_overwrite_stairs: allow level generation overwrite stairs
These are wizard-mode only, cannot be set via config file,
and the fuzzer cannot change these either.
Reformat most of optlist.h. In the process, fix a couple of
conditionally included items which were mis-classified as set_in_game
when excluded. Add "permablind" as an alias for the "blind" option.
[I don't understand the size value of 70 for #if BACKWARD_COMPAT
{curses,DEC,IBM,Mac}_graphics but didn't alter that.]
Include 'pickup_types' in the behavior section; it's useful from
turn 1 and does get adjusted from time to time during play.
Include 'color' in the map section, but hide it for wc_tiled_map.
Include 'showscore' and 'statuslines=2|3' in the status section.
I didn't rebuild with SCORE_ON_BOTL enabled so the showscore part
hasn't been tested.
Make the default options menu only show the most important
options, split into categories. The full, traditional menu
can be accessed by using the m-prefix.
When the NHOPTP syntax was copied and pasted from cond_ a few lines
above, the opt_out/opt_in setting should have been changed to opt_out
to match the verbose boolean.
A new feature, enabled by default to maximize testing, but one which can
be disabled by commenting it out in config.h
With this, some additional information is added to the glyphmap entries
in a new optional substructure called u with these fields:
ucolor RGB color for use with truecolor terminals/platforms.
A ucolor value of zero means "not set." The actual
rgb value of 0 has the 0x1000000 bit set.
u256coloridx 256 color index value for use with 256 color
terminals, the closest color match to ucolor.
utf8str Custom representation via utf-8 string (can be null).
There is a new symset included in the symbols file, called enhanced1.
Some initial code has been added to parse individual
OPTIONS=glyph:glyphid/R-G-B entries in the config file.
The glyphid can, in theory, either be an individual glyph (G_* glyphid)
for a single glyph, or it can be an existing symbol S_ value
(monster, object, or cmap symbol) to store the custom representation for
all the glyphs that match that symbol.
Examples:
OPTIONS=glyph:G_fountain/U+03A8/0-150-255
(Your platform/terminal font needs to be able to include/display the
character, of course.)
The NetHack core code does parsing and storing the customized
entries, and adding them to the glyphmap data structure.
Any window port can utilize the additional information in the glyphinfo
that is passed to them, once code is added to do so.
Also, consolidate some symbol-related code into symbols.c, and remove it from
files.c and options.c
This gives the player more control over what autounlock does. It is
now a compound option rather than a boolean, and takes values of
autounlock:none
!autounlock or noautounlock (shortcuts for none)
autounlock:untrap + apply-key + kick + force (spaces are optional
or can be used instead of plus-signs, but can't mix "foo bar+quux")
autounlock (without a value, shortcut for autounlock:apply-key).
Default is autounlock:apply-key.
Untrap isn't implemented (feel free to jump in) so is suppressed from
the 'O' command's new sub-menu for autounlock. It's parsed and
accepted from .nethackrc but won't accomplish anything.
[Just musing: it should be feasible to kick in direction '.' to break
open a container or #force to an adjacent spot to break open a door.
If that was done, autounlock:kick+force (or more likely autounlock:
apply-key+kick+force when lacking a key) would resort to force if hero
couldn't kick due to wounded legs or riding.
This changes struct flags so increments EDITLEVEL again.
This includes pull requests #750 from entrez and #751 from FIQ but was
entered from scratch rather than using use their commits.
Closes#750Closes#751
Hide 'altkeyhandling' from the 'O' menu for !WIN32 builds. If
present in run-time config file it will be parsed and then ignored.
Instead of showing "unknown" for the value of the 'hilite_status'
compound option, show "none" if there are no highlighting rules, or
a pointer to other option "status highlight rules" when there are.
Deal with a few function parameters that are used for some
combination of build-time config settings and unused for others.
Change 'O's sub-menu for selecting new msg_window option setting to
work similar to the one for menustyle: show a description of what
the values mean with a two-line, two-column menu entry. Also make
its current value be pre-selected.
msg_window is a bit more complicated than menustyle because only
some interfaces support it and curses only supports two of the four
choices. It currently has one hard-coded reference to "^P" (in the
tty-specific 'combination' choice). Changing that is feasible but
seems like more trouble than it'd be worth.
Change the 'menuinvertmode' default from 0 to 1 so that it gets more
exercise. It can be changed back to 0 via option settings but it's
doubtful that anyone will care enough to bother.
Some pickup/take-off actions have been using it to avoid setting
their 'all' choice when bulk toggling for current-page or whole-menu
takes place; 'O' specifies it for its '?' help choice. This adds
the skipinvert flag to the 'all' choice of #wizidentify.
The comments describing it now state that menuinvertmode applies to
bulk set-on operations as well as to toggle-on/off operations but
that will only be true if/when interfaces call menuitem_invert_test()
for set as well as for invert. tty is about to start doing that.
I don't care for this very much at all, but making it shorter will
reduce its usefullness. It addresses one of the struggles exhibited
in the "a man and his cat" youtube video, where he was baffled when
selecting booleans didn't change their values and he later used Esc
instead of Enter after eventually finding number_pad.
This inserts some explanatory text (around three dozen lines,
unfortunately) at the start of 'O's menu. Some of it is general menu
stuff, some is specific options stuff, and some attempts to fend off
various bug reports about options that do or don't persist across
save and restore or RC revisions that seem to have no effect.
The new introductory text can be disabled by turning off cmdassist.
Players who already do that don't need to see this. Many who ignore
cmdassist and occasionally endure an outburst of compass directions
are likely to be goaded into turning it off. I hope we won't need a
new 'optassist' for players who want to skip this but leave cmdassist
in general on.
It doesn't attempt to address his attempt to use arrow keys (possibly
arrows overloaded on number pad keys, or perhaps just digits on the
number pad while numpad mode was off) to navigate the menu then having
the Windows port 'helpfully' change those into hjkl which resulted in
selecting and subsequently unintentionally toggling some options on
the first page. One was 'color' which he did notice and then re-run
'O' to successfully toggle it back on. There was at least one other
which he either didn't notice to didn't both to reverse.
It was possible to toggle ascii_map On (which toggles tiled_map Off)
and Off (so tiled_map On) during play, but tiled_map was marked as
config-file only so the converse pair of operations weren't allowed.
Allow tiled_map to be toggled On or Off during play.
When USE_TILES is disabled, don't let wc_tiled_map be the default.
Qt is capable of showing an (ugly) ascii map, and will do so if built
with NO_TILE_C after this fix (it defaults to tiles without this),
but it requires that a tiles file be loaded because it displays tiles
in other places besides the map, like role selection. So it can't
skip them when wc_ascii_map is set.
Incorporate the functionality of the loadable DLL's (nhraykey.dll,
nhdefkey.dll, and nh340key.dll) into the consoletty.c code and
remove the dll building
Allows the fire-command to autowield a launcher; it will now
do either swapweapon or wield an appropriate launcher, if you
have ammo quivered.
This assistance can be turned off with the fireassist boolean option.
Adds a rudimentary command queue, which allows the code to add keys
or extended commands into the queue, and they're executed as if
the user did them. Time passes normally when doing the queue,
and the queue will get cleared if hero is interrupted.
Change the default value of autopickup to off. Having it on is
harmful for new players, making them very easily burdened.
We can't expect new players to know how to configure
pickup_types, pickup_burden, and pickup exceptions.
Change the default value of color to on. We can safely assume
new users have a terminal that supports color, and most people
want color.
I accidentally toggled the 'altmeta' option On and got this
non sequitur result when trying to toggle it back Off:
|The altmeta option may not both have a value and be negated.
Add new '|' command, aka #perminv, which allows the player to
send menu scrolling keystrokes to the persistent inventory window.
Implemented for X11, where its usefulness is limited, and for
curses, where it is more needed and also more fully functional.
The interface can either prompt for one keystroke, act upon it,
and return to normal play, or it can loop for multiple keystrokes
until player types <return> or <escape>. X11 does the former if
the 'slow' application resource is False so that prompting uses
popups, and the latter when 'slow' is True where prompting is in
a fixed spot and doesn't end up causing the persistent inventory
window to be stacked behind the map window. curses always does
the loop-until-done approach. It also accepts up and down arrow
keys to scroll one line at a time.
Also adds two new menu scrolling commands, menu_shift_right (key
'}' by default) and menu_shift_left ('{') if wincap2 flags contain
WC2_MENU_SHIFT. Shifting allows different substrings of too-long
lines to be seen.
For X11, neither works because their handling requires a horizontal
scrollbar and for some reason that escapes me our menus don't have
one of those. If they did, shifts could work for all menus but a
shifted window would hide the selection letters. So shifting would
be most usefully done as: pan right, read more of any long lines,
immediately pan back to the left.
For curses, they only apply to the persistent inventory window.
Shift right redraws it with class headers and inventory letters
shown normally but the item descriptions omit their leftmost
portion, showing more text towards the end. Shift left reverses
that and does nothing if the beginning is already in view. Forward
and backward scrolling while shifted leave the shift in place.
OPTIONS=menu_previous_page:\mv
BINDINGS=M-v:menu_previous_page
both worked, but
OPTIONS=menu_previous_page:M-v
BINDINGS=\mv:menu_previous_page
both failed. Make all four variations work. Tiny change made large
by the need to move some things around.
The option definition for menu_first_page had a couple of its flag
bits swapped. I didn't try to figure out whether that had any impact.
"Demote" wizmgender from an obscure wizard mode extended command
to an obscure wizard mode boolean option. Behaves the same except
that no message is given when the value gets toggled.
I should have reenabled curses before committing an earlier change;
it broke compile.
Make all optfn_FOO() be static in options.c;
fix newly added prototype for optfn_cursesgraphics();
fix conditionals for optfn_palette(), both prototype and function.
Also, add missing prototype for a sound routine.
I stated out by changing dat/opthelp to stop shouting the boolean
defaults: [TRUE] -> [True], [FALSE] -> [False]. I ended up doing
a partical reconcilliation between ?g (dynamic list of options)
and ?h (dat/opthelp). There were several inapplicable options in
the dynamic list, so this changes option_help() to avoid those.
I barely glanced at the compound options so they may not sync up.
The pull request changed \ and ` output to unconditionally show
discoveries in alphabetical order. That's nearly useless except
when looking at prediscovered weapons and armor that fighter
types start out knowing.
This allows the player to choose sorting order via the new
'sortdiscoveries' option. In addition to setting it via
config file or 'O', it can be set via 'm' prefix for \ and `.
Choices are:
o - sort by class, by order of discovery in class (default);
s - sort by 'sortloot' classification which groups sub-class
items (so all helmets before any other armor, then all
gloves, then boots, and so on); within each sub-class, or
whole class for classes which don't subdivide so usefully,
partly-discovered types (where a name has been assigned)
come before fully ID'd types;
c - sort by class, alphabetically within class;
a - sort alphabetically across all classes.
Turned out to be a large amount of work for fairly little gain,
although I suspect that 'sortdiscoveries:s' will eventually be
more popular than the default.
Invalidates existing save files so that current sort setting can
persist across save/restore cycles.
Closes#334
"Name of your starting pet when it is a kitten" could be
construed as meaning that it will no longer apply once the
kitten grows into a housecat. Use "if" instead of "when".
The 'other settings' were in alphabetical order except for
"status condition fields" which presumably started out as
"condition fields". Move it into proper place for current
description.
Add a few missing options to dat/opthelp (without worrying about
"if FOO was set at compile time"). No doubt there are lots of
others still missing.
Reword a few options in dat/opthelp and also in the dynamic help
derived from optlist.h, particuarly catname, dogname, horsename
whose descriptions have always been confusing or maybe confused.
The revamped options handling was't doing dynamic help properly.
After listing the booleans, it listed them again amongest the
compound options. Since their description field is Null, that
could be a big problem. sprintf(buf,"%s",NULL) on OSX produces
"(null)" but most sprintf()'s would probably crash instead.
The 'other' options (autopickup exceptions, menucolors, &c) were
not listed at all. (I don't remember whether that was also the
case before the revamp.) Now they're listed but not explained.
The 'msg_window' description was unhelpful; this replaces it.
A couple of others were longer than necessary so they've been
shortened. The rest of optlist.h is reformatting wide lines.
Recently added 'safe_wait' option was included in the Guidebook
but not in dat/opthelp; add it.
Condense the Qt status slightly, moving Alignment field from the
Conditons line to the Characteristics line and the Time and Score
fields from their own possibly blank line to the HP,&c,Gold line.
That's for statuslines:2, which is the default. statuslines:3
restores the previous layout. I tried to make that become the
default for Qt but it got messy fast and I gave up.
I also tried to make changing 'statuslines' back and forth on the
fly work but failed. I left the code in as #if DYNAMIC_STATUSLINES
but that isn't defined anywhere. For the time being at least,
'statuslines' is config file or NETHACKOPTIONS only for Qt, not
changeable via 'O' like for curses and tty.
Change the option description for 'statuslines'. That depended
upon whether curses was compiled in when it should depend on which
interface is active. This moves the alternate info to Guidebook.
