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.
A check into github issue 364 confirmed that
ba6edbe5dc
had incorrectly updated the bwrite sizeof entry for sysflags.
The SYSFLAGS and MFLOPPY code is all in the outdated part of the tree, so just
remove it rather than re-correct it.
Closes#364Closes#207
fixes#361
Also, experminental introduction of vt_sounddata to enable tty to pass
a sound file index to the terminal side of things where perhaps someone
can add code to something like hterm to take the information relayed by
NetHack to trigger user_sounds locally even if playing on a server.
Compile time option TTY_SOUND_ESCCODES required to build that support in.
It should be independent of TTY_TILE_ESCCODES.
I added -Wmissing-prototypes to my CFLAGS and got a bunch of warnings.
This fixes the core ones (there are more for X11 that I haven't looked
at yet). While fixing these, I discovered a few option processing
issues: the non-Amiga 'altmeta' should be settable while the game is
in progress (not sure about the Amiga variation so left that as-is),
'altmeta' and 'menucolor' are booleans so shouldn't have had optfn_XXX
functions; 'MACgraphics' and 'subkeyvalue' were conditionally defined
differently in options.c than in optlist.h.
'use_inverse' used to be unconditionally present but conditionally
had default value True for WIN32 and False for others. The options
changes that moved things to optlist.h made it present for WIN32 and
absent for others. Put it back, and change the default value to be
unconditionally True.
../include/optlist.h:510:62: error: macro "NHOPTC" requires 10 arguments, but only 9 given
"color mappings for internal screen routines")
^
../include/optlist.h:562:52: error: macro "NHOPTP" requires 10 arguments, but only 9 given
"prefix for old micro IBM_ options")
^
combine boolean and compound options into a single allopt[] array for
processing in options.c.
move the definitions of the options into new include/optlist.h file which
uses a set of macros to define them appropriately.
during compile of options.c each option described in include/optlist.h:
1. automatically results in a function prototype for an optfn called
optfn_xxxx (xxxx is the option name).
2. automatically results in an opt_xxxx enum value for referencing
its index throughout options.c (xxxx is the option name).
3. is used to initialize an element of the allopt[] array at index
opt_xxxx (xxxx is the option name) based on the settings in the
NHOPTB, NHOPTC, NHOPTP macros. Those macros only live during the
compilation of include/optlist.h.
each optfn_xxxx() function can be called with a req id of: do_init, do_set,
get_val or do_handler.
req do_init is called from options_init, and if initialization or memory
allocation or other initialization for that particular option is needed,
it can be done in response to the init req.
req do_set is called from parseoptions() for each option it encounters
and the optfn_xxxx() function is expected to react and set the option
based on the string values that parseoptions() passes to it.
req get_val expects each optfn_xxxx() function to write the current
option value into the buffer it is passed.
req do_handler is called during doset() operations in response to player
selections most likely from the 'O' option-setting menu, but only if the
option is identified as having do_handler support in the allopts[]
'has_handler' boolean flag. Not every optfn_xxxx() does.
function special_handling() is eliminated. It's code has been redistributed
to individual handler functions for the option or purpose that they serve.
moved reglyph_darkroom() function from options.c to display.c
