A recent change was intended to allow specifying
make CFLAGS=-O
on the command line to override our default of -g, but it didn't
work as intended. foo=bar and foo+=bar don't work if foo has
been given a value on the command line. The first was expected
behavior but the second wasn't, at least for me. GNU make allows
'override foo+=bar' to cope with that. (We're already implicitly
requiring GNU make for the linux and OSX hints.)
Report described this as a panic triggered by the sanity_check
option, but that's because it was running under the fuzzer, which
escalates any impossible() to panic(), rather than because nethack
panicked.
I couldn't find anything wrong--which doesn't mean that there
isn't something wrong--with place_worm_tail_randomly() and
random_dir(). They use xchar for map coordinates which should be
fine as long as no negative values are generated and I couldn't
discover any such. The suggested fix of changing xchar to int
might indicate a compiler bug (although the odds of that are low).
The bogus coordinate of -15000 in the report suggests that
typedef short int schar;
(which changes xchar too) is being used in the configuration but
I don't recall having any problems attributable to that.
This switches from xchar to int as a side-effect of replacing the
offending code entirely. The new code might produce an 'ny' of -1
before goodpos() rejects it, so xchar would be inappropriate now.
The old code is commented out via #if 0 _after_ changing it from
xchar to int.
This also adds an extra sanity_check for worm tails, unrelated to
the current bug. I'm not aware of any instance where it fails.
EXTRA_SANITY_CHECKS needs to be defined for it to do anything.
Part of pull request #308: when using des.terrain to set terrain,
default for lit state becomes 'unchanged' rather than 'unlit'.
des.replace_terrain already operates that way. Replace lit state
magic numbers -1 and -2 with SET_LIT_RANDOM and SET_LIT_NOCHANGE.
Also change SET_TYPLIT() to not operate on map column 0 and move
it from rm.h to sp_lev.h. It never belonged there, is only used
in sp_lev.c, and now because of the SET_LIT_ macros it couldn't be
used anywhere else unless sp_lev.h gets included too.
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.
