Move clearing of polearm context from migrate_to_lev() to lower
level relmon(). Add missing transfer of polearm context from
old mon to new mon in replmon(). These days it seems to only be
used for creating a monster from saved traits, so polearm context
in it should be moot.
Eliminate the feasibility of micro-managing ring hunger by swapping
back and forth between a pair of rings of slow digestion. Wearing
one at a time causes normal ring hunger (wearing both at once just
increases such hunger), but being able to put on the second ring
and take off the first just before the 1 out of 20 turns where it
affects hunger, then vice versa a few turns later, is an insanely
tedious way to avoid any hunger at all, made possible by the 'time'
option. Make the turns where extra hunger get imposed be randomized
so that that can't be done reliably.
Also closes githib issue #336: hunger caused by melee attacking
adds ring and amulet hunger a second time for that turn. That has
always been intentional behavior; now the amount varies for any
given attack due to the randomization, but on average is the same
as before.
Closes#336
Enable existing wc_popup_dialog option. Use it in yn_function()
instead using a mystery value which apparently used to live in Qt
Settings but isn't there anymore so couldn't be turned on or off.
Also replaces conditional USE_POPUPS which isn't defined anywhere
either so presumably came from CFLAGS and only supported "yn?",
"ynq?", and "rl?" with hardcoded Qt popups rather than using
NetHackQtYnDialog.
Doing that revealed that the popup dialog for ynaq was in pretty
bad shape. It's functional but still needs a lot of work, beyond
the limited Qt/C++ capability I possess. The KeyPress issue which
accepts <shift> as input, thereby preventing <shift>+<character>
from being typed during ynaq prompting, is particularly nasty.
Append the ynaq dialog's response to the message line containing
the corresponding prompt similar to what's now done for regular
yn_function().
Add getlin() prompt+response to the message window.
Core issue noticed while working on some Qt stuff. If hangup
occurred while prompting for "right or left?" ring finger, the
hangup yn_function() would return ESC and the accessory-on routine
would not see '\0', 'r', or 'l' so reprompt. Endlessly.
The Qt interface highlights the last message issued (using a
mechanism for selection, as if for copy+paste or similar operation)
but it was staying highlighted until another message was eventually
given. Having an old message seem to stick around is annoying and
is particularly bad when the message is a prompt. If the player's
answer doesn't cause a message to be shown then it seems as if the
prompt is still pending.
This removes the highlighting (by bulk unselecting) once the player
gives another input keystroke or mouse click.
It would be much better if the selecting/highlighting was for all
messages issued since last time highlighting was cleared. Figuring
out how to do that correctly is more effort than I want to expend.
Make ASCII control characters ^[, ^\, ^], ^^, and ^_ work on Qt,
at least partly. Mainly for ^[ to be treated as ESC, which works
if you're aborting a count on the map but doesn't cancel out of
menus [yet?]. I didn't attempt to make ^@ send NUL.
Also, fix the hardcoded macros (activated by F1: rest 100 turns,
F2: search 20 times, and Tab: ^A to do-again). The first two sent
'n' before the count so wouldn't work as intended with number_pad
off, and the third was executing twice as if Tab sent two ^A's
instead of just one. Resting and searching might have been getting
duplicated too; I don't know how to simulate the relevant keys.
(I temporarily swapped definitions for F2 and Tab to test the
number_pad fix but hadn't done that earlier when I discovered the
Tab bug.)
Menus have [ok], [cancel], [all], [none], [invert], and [search]
buttons across their top but the [all], [none], and [invert] choices
didn't redraw the menu after making changes to the pending selections
so it seemed as if they weren't doing anything. Subsequently picking
[ok] revealed otherwise.
[search] is broken (instead of accepting a search string, the letters
I type are being used to toggle individual entries as I type). This
doesn't attempt to address that.
The turn-to-slime countdown is one of the ones that uses turns/2
to stretch the sequence out longer and it was displaying the hero
as green slime when there was another turn before it happened.
(In theory anyway. I could not get my hero to be shown as slime
and still have one move left, even when hasted.)
Make the hero mimic green slime starting on the last turn before
being polymorphed instead of next to last.
Fixes#380
I was actually using fprintf(stderr,...) when testing and didn't
retry this bit after changing it to raw_printf(...). It's commented
out but needs fixing.
I've been trying to figure out how to make ^[ be treated as ESC but
so far have failed. That key combination just acts like a dead key.
But one bit of cp_key.cpp can be implemented instead of ignored.
No change in behavior because the keyboard-state value isn't being
used anywhere.
Infrastructure bits: Qt tombstone uses a short buffer; make sure that
the plname value fits instead of relying on snprintf() to truncate it.
A warning about gold, if any, was iffy but this should guarantee no
reason for future complaint. Year was safe but a compiler sensitive
to buffer overflows wouldn't know that.
Actual bugs: Qt used money in inventory for gold amount on tombstone;
that overlooks gold in containers and will be 0 by tombstone stage if
bones get saved. Year was recalculated from current date+time instead
of using the value that gets passed in--blindly flagging that variable
as UNUSED was a mistake.
../win/Qt/qt_menu.cpp: In member function ‘virtual void nethack_qt_::NetHackQtTextWindow::UseRIP(int, time_t)’:
../win/Qt/qt_menu.cpp:680:54: warning: ‘%s’ directive output may be truncated writing up to 31 bytes into a region of size 17 [-Wformat-truncation=]
680 | snprintf(rip_line[NAME_LINE], STONE_LINE_LEN+1, "%s", g.plname);
| ^~ ~~~~~~~~
In file included from /usr/include/stdio.h:867,
from ../include/global.h:9,
from ../include/config.h:608,
from ../include/hack.h:10,
from ../win/Qt/qt_menu.cpp:8:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:35: note: ‘__builtin_snprintf’ output between 1 and 32 bytes into a destination of size 17
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~../win/Qt/qt_menu.cpp: In member function ‘virtual void nethack_qt_::NetHackQtTextWindow::UseRIP(int, time_t)’:
../win/Qt/qt_menu.cpp:680:54: warning: ‘%s’ directive output may be truncated writing up to 31 bytes into a region of size 17 [-Wformat-truncation=]
680 | snprintf(rip_line[NAME_LINE], STONE_LINE_LEN+1, "%s", g.plname);
| ^~ ~~~~~~~~
In file included from /usr/include/stdio.h:867,
from ../include/global.h:9,
from ../include/config.h:608,
from ../include/hack.h:10,
from ../win/Qt/qt_menu.cpp:8:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:35: note: ‘__builtin_snprintf’ output between 1 and 32 bytes into a destination of size 17
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Qt is capable of using an ascii map, and does so on the rogue level.
So failing to load tiles doesn't need to quit; it can continue in
text mode.
Not extensively tested. This disables the paper doll when the ascii
map is forced (either via options settings or due to tiles loading
failure, but not when simply on the rogue level) rather than trying
to display it with object class characters.
