Using
|OPTIONS=windowtype:Foo
|OPTIONS=perm_invent
or
|NETHACKOPTIONS='perm_invent,windowtype:Foo'
would enable perm_invent if interface "Foo" supported it, but using
|OPTIONS=perm_invent
|OPTIONS=windowtype:Foo
or
|NETHACKOPTIONS='windowtype:Foo,perm_invent'
or combined
|OPTIONS=perm_invent
|NETHACKOPTIONS='windowtype:Foo'
would only enable perm_invent if both "Foo" and the default interface
supported it.
Using '--windowtyp:Foo' on the command line didn't have this issue
because command line interface selection replaces the default one
before configuration file and environment options are processed.
creates new coloratt.c file
Also, this attempts to fulfill a wish-list item by paxed, to
allow naming colors in symbols file by name as an alternative
to using r-g-b values. The basic color names as well as html
color names are supported.
Calling sprintf with NULL string for a %s format identifier seems to be
undefined behavior. I got some semi persistent crashes while calling
the extend options menu with mO.
Any plain text symbol set specified in .nethackrc or NETHACKOPTIONS
didn't get loaded but did set the symset name.
Faulty 'if' logic excluded loading of symbol sets that used the
default handling type of H_UNK.
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.
Redo getpos() highlighting. If bgcolors is Off, '$' toggles between
no highlighting and showing dollar signs at valid spots. ^R removes
those if they're present. When bgcolors is On, '$' cycles among
three settings: highlighting via background color, no highlighting,
and highlighting by drawing dollar sign characters. ^R switches to
background color mode.
This doesn't directly solve the problem of background color causing
conflict with the foreground color of some objects or monsters, but
being able to get rid of the background with a keystroke should be an
improvement.
'bgcolors' defaults to On, which was a problem for tty when 'color'
was Off. Turn it Off (in the core) for text map if color is Off and
bgcolors hasn't been explicitly set. Conversely, Qt was leaving
color Off and then using color with abandon. Turn in On (in the core)
for tiled map if it hasn't been given an explicit value. Those two
changes should cope with most situations and still let the player
override.
end.c:177:16: warning: unused parameter 'why' [-Wunused-parameter]
177 | NH_abort(char *why)
| ~~~~~~^~~
end.c: At top level:
end.c:1191:1: warning: 'get_saved_pline' defined but not used [-Wunused-function]
1191 | get_saved_pline(int lineno){
| ^~~~~~~~~~~~~~~
options.c:1263:1: warning: 'optfn_crash_urlmax' defined but not used [-Wunused-function]
1263 | optfn_crash_urlmax(int optidx UNUSED, int req, boolean negated UNUSED, char *opts, char *op)
| ^~~~~~~~~~~~~~~~~~
options.c:1240:1: warning: 'optfn_crash_name' defined but not used [-Wunused-function]
1240 | optfn_crash_name(int optidx UNUSED, int req, boolean negated UNUSED, char *opts, char *op)
| ^~~~~~~~~~~~~~~~
options.c:1217:1: warning: 'optfn_crash_email' defined but not used [-Wunused-function]
1217 | optfn_crash_email(int optidx UNUSED, int req, boolean negated UNUSED, char *opts, char *op)
| ^~~~~~~~~~~~~~~~~
add CRASHREPORT for Windows
add ^P info to report (via DUMPLOG)
new options: crash_email, crash_name, crash_urlmax
new game command: #bugreport
new config option: CRASHREPORT_EXEC_NOSTDERR
new command line option: --bidshow
deleted helper scripts:
NetHackCrashReport.Javascript
nhcrashreport.lua
misc:
update CRASHREPORTURL (will need to be updated before release)
update bitrot in winchain
winchain for Windows
add missing synch_wait for NetHackW --showpaths
add PANICTRACE (and CRASHREPORT) in mdlib.c:build_opts
missing:
packaging (Windows needs the pdb file)
no testing with MSVC command line build
port status:
linux: working, but glibc's backtrace doesn't show static functions
Windows VS: working. pdb file is large - looking into options
MacOS: working
msdos: not supported
VMS: not supported
MSVC: planned, but not attempted
MSYS2: working, but libbacktrace not showing symbols (yet?)
My recent change to petattr caused a crash in curses when no
petattr was used in config file - because curses was setting
petattr to curses-specific value. Init the setting in core
instead.
src/options.c(711): warning: Reading invalid data from 'roleoptvals[roleoptindx]'.
Validate the roleoptvals[][] array indexes to appease the static
analyzer.
During very early startup, Windows may not have loaded
the tty window procs yet, and it is running with safeprocs.
It will eventually load the tty stuff. If the currently
operating window port fails in can_set_perm_invent(),
try the check for WC_PERM_INVENT again explicitly on
the tty windowport.
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 gets rid of a FIXME and K4056 internal bug report.
Allow the comma to be quoted as follows:
SYMBOLS=S_ice:\,
or
SYMBOLS=S_ice:','
Disclaimer:
The use of the comma on the map could conflict with future
use of that currently unused symbol for other intended purposes.
Currently, options.c is the only file that #includes "optlist.h".
In theory, if a source file did want to include optlist.h (perhaps
for the struct allopt_t declaration so they could deal with a
pointer to such a struct), they wouldn't be able to include it
because of a static function prototype that it contains.
Add some protection to only include that static function
prototype when optlist.h is included from options.c.
There's no need to process windowtype a second time after options
parsing. The sequence set windowtype, process options, set
windowtype again was intended to deal with the options setting it
to some other value, but there's a flag available to disable that
from happening.
choose_classes_menu was declared extern. The only caller presently
was calling it was optfn_pickup_types() in options.c.
It could have had the extern declaration from include/extern.h and
declare it as static within options.c, if that was the only use
anticipated. Also, if the one existing caller were all there would
ever be, the argument passed to it that was the subject of pr #1146
could have just been removed along with the switch.
Checking the comments above the function, however, it was clearly
designed as a general-purpose function that could be called from
anywhere for the functionality desired, even though there's presently
just the one caller, passing just the one variation of the category
argument.
Relocate the general-purpose function over to src/windows.c, where
several interface-related / menu-related general-purpose functions
already reside.
options.c has gotten *huge* and this is a fitting opportunity to
reduce its size a little.
Pull request from argrath would have made sure that an uninitialized
buffer wasn't used after choose_classes_menu() issued an impossible
warning, but there was no point in continuing if bad (or not yet
supported) arguments were passed, so panic instead. Bypass the pull
request's commit because it would have been immediately replaced.
Closes#1146
<color>
off: map, menu items, menu headings, menu prompt/title all, everything should have color suppressed.
<curses guicolor>
on: map, menu items, menu headings, menu prompt/title can all feature color, as can
menu borders, menu-selector letters.
off: map, menu headings, menu prompt and menu items (menucolors on) can still feature color,
but all other non-map features such as menu borders, menu-selector
letters will not have color.
<menucolors>
on: menu items can have colors if they match one of the regex in config
file; menu headings, menu prompt can also be in color (based on menu_headings option).
off: menu items won't have colors, but menu headings, menu prompt still
will feature colors (based on menu_headings option); those are not impacted by turning
off menucolors.
It was impossible to select entry 62 in the allopt[] array
from the 'm O' menu, apparently because of a collision with
the ascii value of a question mark.
Entry 62 was currently the guicolor option.
If the value is "no color&none" report it as "no-color&none" in 'm O'
and for #saveoptions.
Allow "OPTIONS=menu_headings" without any color or attribute value to
mean "no-color&inverse" as it once did before the player could choose
which attribute or color was supported, and matching the default used
when 'menu_headings' hasn't been specified at all.
Accept "OPTIONS=!menu_headings", meaning "no-color&none".
Explicitly reject "OPTIONS=!menu_headings:anything". It was rejecting
that due to blanket rejection of negated option, but reporting "can't
both have a value and be negated" whether there was any value present
or not.
For preselected menu entries when interactively choosing a new value
via the submenu of 'm O', use the current color and attribute rather
than NO_COLOR and ATR_NONE.
Simplify suppression of highlighting for menu header lines during end
of game disclosure. Didn't actually affect as many things as I was
expecting.
Plus a bit left out of the optfn_dogname() parsing commit.
Get rid of all the unnecessary 'if (!opts)' checks if the optfn_xx()
routines.
Replace the replicated contents of optfn_catname(), optfn_dogname(),
and optfn_horsename() with a common routine. optfn_dogname() was
different from the other two for no discernable reason. Player can
no longer assign the name "none" to an initial pet via RC file,
although there's nothing preventing doing so with C/#name command.
The submenu of 'm O' for recently added option 'perminv_mode' didn't
have color 0 changed to NO_COLOR. On tty the entries came out blue,
on X11 they were nearly invisible. Qt and curses didn't seem to care.
I checked all the add_menu() calls in src/*.c and managed to refrain
from the impulse to reformat, mostly.
Remove menu_color support from the window port side of the interface.
The window port just has to honor the color parameter that was added
to the add_menu() interface definition in June 2022 commit
2770223d10, and let the core-side of
the interface handle things.
To that end, this does the following:
Removes the #define of add_menu() from include/winprocs.h and add a
real core-side add_menu() function to windows.c which acts as a
trampoline to the window port win_add_menu() function, while providing
a single location to adjust the parameters passed to the window port
function. get_menu_coloring() is now called in there.
Moves get_menu_coloring() from options.c into windows.c and makes it
static.
Removes all the calls to get_menu_coloring() from the tty, Qt, X11,
curses, and win32 interfaces and adjusts their code to simply honor
the color parameter in add_menu, similar to what the menu_headings
change from earlier today did.
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
