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.
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.
../lib/pdcursesmod/dos/../common/dosutil.c:36:15: warning: comparison of integer expressions of different signedness: 'long int' and 'long unsigned int' [-Wsign-compare]
36 | while( ms > MAX_NAP_SPAN)
| ^
It isn't something that we can actually resolve within NetHack,
so just suppress the submodule build warning.
This commit will trigger the CI to carry out a test of the build.
There could be some follow-up after the results.
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.
Pull request from argrath: optfn_pickup_types checks 'opts' for
whether it is Null after having already used it without checking.
Remove the unnecessary test.
Closes#1132
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.
../win/tty/wintty.c: In function ‘set_item_state’:
../win/tty/wintty.c:1174:9: warning: implicit declaration of function
‘term_start_color’; did you mean ‘term_start_attr’?
[-Wimplicit-function-declaration]
1174 | term_start_color(item->color);
| ^~~~~~~~~~~~~~~~
| term_start_attr
../win/tty/wintty.c:1178:9: warning: implicit declaration
of function ‘term_end_color’; did you mean ‘term_end_attr’?
[-Wimplicit-function-declaration]
1178 | term_end_color();
| ^~~~~~~~~~~~~~
| term_end_attr
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
Pull request by entrez: have monsters and the hero use the same code
when deciding whether to destroy a missile that hits a monster after
being thrown or shot.
Closes#1129
There is a comment above the function indicating that it should be
aligned with hero ammo breakage, but this wasn't the case. One big
difference is that any monster-thrown or -shot object would be deleted
unconditionally if it hit another monster trapped in a pit. I don't
know why that was in there, but it's not present in hero ammo breakage
chances, and it meant that a monster could sling the Mines luckstone at
the hero, hit a monster in the pit, and permanently lock the hero out of
getting the luckstone (as just happened to a player during the current
tournament). This pulls the hero breakage rules out into their own
function and uses that for monster breakage as well, to make sure they
are aligned. I also refactored drop_throw a bit to reduce the number of
separate variables tracking whether the object was deleted (was create,
objgone, and retvalu), and changed its (and ohitmon's) type to boolean.
I used ^G to create a monster and specified "invisible owlbear". I
then got "An owlbear appears next to you." Except it didn't; it was
invisible and I lacked see-invisible. I imagine that newsym() was
called for the new-yet-invisible monster, but that remained buffered
and was gone overridden by the time pending map update got flushed
at some point after the monster was made invisible.
Add a new makemon() flag to turn a newly created monster invisible
during its creation, before "monster appears" message is delivered.
Since that message will now be suppressed in this situation, use the
cursor-flash hack that indicates where the new, unseen monster got
placed. Creating "1000 invisible <mon>" is something you probably
won't do twice.
Pull request from entrez: hero walking over a zombie's burial site
will only disturb it if meeting a minimum weight threshold.
Update several weight macros to be 'unsigned', matching mons[].cwt.
[I'm not sure about this one. 'unsigned short' promotes to 'signed
int' these days on most platforms.]
Closes#1125
These are meant to be 'cwt' values and directly comparable to a
particular pm->cwt, which is an unsigned short. My concern here was
signed/unsigned comparison warnings like the one fixed in 1538b40, but
I'm not sure if this is actually necessary: there is already a
comparison between cwt and WT_HUMAN in max_mon_load() which apparently
doesn't produce the warning...
