This fixes a lot of problems where a menu or a text window was up
and the main window accepted input - for example you could move around,
making another window of the same type pop up ...
The 0x1000000 bit (NH_BASIC_COLOR bit) was used to mark
CLR_BLACK when storing it in u->ucolor. Now, all of the basic CLR_*
colors are stored that way.
The NH_BASIC_COLOR bit indicates that the value in u->ucolor is
not an rgb value, rather it is one of the 0-15 basic NetHack colors.
The window-ports need to strip the NH_BASIC_COLOR bit off before using
it for color changes.
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.
DUMPLOG requests the DUMPLOG feature as it does now
DUMPLOG_CORE requests the internal buffering only (used for CRASHREPORT)
This allows CRASHREPORT to access recent messages without performing
any file I/O.
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.
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
There was an error:
../win/Qt/qt_main.cpp:767:37: error: attempt to use a deleted function
action->setData(actchar);
^
/usr/include/x86_64-linux-gnu/qt6/QtCore/qvariant.h:199:5: note: 'QVariant<char *, false>' has been explicitly marked deleted here
QVariant(T) = delete;
^
1 error generated.
I'm hoping the fix applied is the correct one for the error.
A printf call was introduced in 20fb008012 that caused the terminal
window to be filled with repeated debugging messages as the window
containing the Qt windowport was resized. I removed it because I
assumed it was meant to be temporary and was left in the commit by
mistake, considering it isn't mentioned in the commit message; if it was
meant to be permanent it'd probably be good to block it out with #ifdef
DEBUG or something at least, because it produces a real deluge of
terminal output if the player spends any time resizing the window by
hand.
* qt_tilewidth and qt_tileheight are allocated with alloc() and need
to be freed with free().
* Don't use them after they're freed. Instead, retrieve the size from
the glyphs object.
Funnel all potential "<action> called before we know if Menu or Text"
warnings through a common routine. Aside from rephrasing a message
which no one should ever see, there's no change in behavior.
Neither X11 nor Qt would compile with TEXTCOLOR disabled. With this
they build and seem to work, but no promises, particularly for the
ENHANCED_SYMBOLS config.
Noticed when working on the add_menu() crash earlier, using a mouse
rather than the keyboard to pick an entry in the sub-sub menus for
'm O' -> 'disclose' -> {any disclosure category} didn't work properly.
The problem was in post-3.6.x menu code for the Qt interface.
I temporarily reverted the fix for end-of-game disclosure of overview
in order to trigger the add_menu() crash under Qt. It came down to
if (!actual) impossible("AddMenu called before we know if Menu or Text");
actual->AddMenu(glyph,identifier,ch,gch,attr,str,itemflags);
where 'actual' happens to be Null. impossible() gets called, goes
through pline() calling putmesg() and putstr(WIN_MESSAGE), then the
output never shows up anywhere. I haven't figured our what's going
on with that, but changing the above to
if (!actual)
impossible("AddMenu called before we know if Menu or Text");
else
actual->AddMenu(glyph, identifier, ch, gch, attr, str, itemflags);
at least prevents the crash. The main window ends up becoming
minimized/iconified but the final popups which occur after disclosure
appear and accept responses and then a clean exit takes place.
Presumably it used panic() rather than impossible() at some point,
otherwise that code makes no sense: test for Null then deference it
regardless of the result of the test?
to program_state.input_state
Rename program_state.getting_a_command and give it an int value
instead of treating it as boolean. Start using to it for Qt to
suppress commands initiated from the drop down menus in the title bar
if nethack isn't expecting to get a command from the user. Those menu
choices inject extended command text into the input stream and should
be avoided when entering text or waiting for a menu to be dismissed.
These menus would be better if they grayed out unavailable choices
when pulled down instead of accepting any choice and then treating
that no good. I'm not going to try to figure out to do that with Qt.
And this workaround for the menus doesn't have any affect on the
toolbar buttons below the title bar. Those execute core commands
directly and when I tried to use jacket routines instead, the tool bar
stopped showing up so I've given up.
This won't fix the reported problem of getting stuck in a loop.
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.
Switch to using the term "sound triggers" for things that
result in a call to one of the soundlib routines.
SNDCAP_* renamed to SOUND_TRIGGER_*
sndcap field in the sound_procs struct changed to sound_triggers
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.
A number of C compiler suites have a math.h library that includes a yn()
function name that conflicts with NetHack's yn() macro:
"The y0(), y1(), and yn() functions are Bessel functions of the second kind,
for orders 0, 1, and n, respectively. The argument x must be positive. The
argument n should be greater than or equal to zero. If n is less than zero,
there will be a negative exponent in the result."
At one point, isaac64.h included math.h, although that has since been removed.
Some libraries used in NetHack (Qt for one) do include math.h and that required
build work-arounds to avoid the conflict.
Rename the NetHack macro from yn() to y_n() and avoid the math.h conflict
altogether, eliminating the need for that particular work-around.
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
^ ^
The test system is Slackware 14.2, which uses Qt 4.8.7.
* WANT_WIN_QT4 is defined, and has the expected meaning. Qt 5 is still
the default.
* The QT_NO_SOUND macro now excludes all headers and declarations
relating to sound; the multimedia package is not needed to build
(on any Qt 4, 5 or 6).
* A new function, nh_qsprintf, replaces QString::asprintf, for Qt
older than 5.5. These versions do not have QString::asprintf.
* DYNAMIC_STATUSLINES is disabled for Qt older than 5.9. These versions
do not have QSplitter::replaceWidget.
Change Qt's 6x3 grid of worn/wielded equipment so that it is facing
the player: hero's right hand side is shown in the grid's left column
and left hand side is shown in its right column. Middle column is
unchanged.
The definition of enc_stat[] got changed by a pull request nearly a
year ago ('const char *enc_stat[]' -> 'const char *const enc_stat[]')
but the separate declarations for it weren't changed to match.
Make the same change for hu_stat[]. Not sure why the pull request
didn't include it since the old declaration and the usage are same.
The curses one is in code that isn't used.
This replaces the old pushq/saveq arrays (which were used to save
the keys pressed by the user for repeating a previous command)
with a new command queue. This means there's no hard-coded limit
to the saved keys, and it can repeat extended commands which are
not bound to any key.
