"When a room is created and passed down to a contents function in
Lua, the width and height properties of that room are computed by
subtracting lx from hx and ly from hy, which means e.g. a room
which is 8 floor squares wide and 5 tall appears to the contents
function as having a width of 7 and height of 4. This patch fixes
that off-by-one."
I don't understand the details here: should a room's dimensions
include its boundary walls or just the inner amount? This change
didn't seem to cause any problems so I've put it in.
Closes#345
Replace the blank placeholder icon with individual placeholders
for Stone, Slime, Strngl, Deaf, Lev, Fly, and Ride. They're just
40x40 tiles showing solid color (different for each) holding white
block letters spelling the condition. For the first four of those,
the text runs from upper-left to lower-right, for Lev and Fly the
text runs from lower-left towards upper-right, and for Ride it's
horizontal. Not particularly exciting but better than blank. We
still need real artwork to make them be similar to the older
conditions.
Also moves the two petmarks and the pilemark from qt_xpms.h to
qt_map.cpp. The marks and the assorted status icons are all
static arrays, and including that header in two source files
meant that they were all duplicated unless the compiler or linker
was smart enough to discard the unused ones.
For Qt, experience points weren't shown when enabling 'showexp'
option because they were conditional upon '#if EXP_ON_BOTL'. That
got eliminated prior to 3.6.0 so wasn't defined for qt_stat.cpp.
When displayed, show Exp as Level:Xp/Exp instead of as a separate
status field. This has the intentional side-effect of omitting it
when hero is polymorphed and status shows HD instead of Xp.
Label the six characteristics in mixed case instead of all upper
case: Str, Dex, and so forth.
As reported in https://github.com/NetHack/NetHack/issues/391
if make was invoked with -j, makedefs instances could end up running in
parallel and could trample on each other's grep.tmp tempory files.
Default to using mkstemp(); allow a port runtime library implementation
that lacks mkstemp() to define HAS_NO_MKSTEMP to revert to the old behaviour.
Provide a work-alike mkstemp() implementation for windows Visual Studio build
in mdlib.c so there is no requirement to define HAS_NO_MKSTEMP there.
Fixes#391
The code for peaceful monsters witnessing the hero attack another
peaceful monster and getting angry had a 20% of making them gasp in
surprise or exclaim "why?" in shock. It was only requiring them to
have humanoid shape rather than checking for speech capability, so
peaceful zruty or minotaur, possibly other animals, could exclaim
comprehensibly. Other things which shouldn't talk, like mummies,
would behave similarly.
This categorizes how a bunch of MS_foo types should react. It has
only been lightly tested.
Any key bindings in player's run-time config file will already be
in place by the time the Qt menus are constructed. Those menus
will use the new key assignments rather than the defaults, so not
a bug.
The previous teleport scroll fix was mislabeled with this pull
request number. Too late to fix that now; should have been
Closes#307
Now... Interaction between voluntarily busy hero (resting,
searching, and so on) with approaching monsters to decide whether
to stop had some inconsistencies.
Really closes#386
Since teleporation gives a "you matrialize" message even when
arriving close by, the old behavior of not learning a scroll of
teleportation when you land quite close to your original spot
no longer made sense. Always [almost] discover teleport scroll
when reading it.
Also adds one-shot teleport control when reading a blessed scroll
of teleportation. I changed that to be prevented when hero is
stunned, same as with full-fledged teleport control.
I reworded or reformatted several of the comments. And removed
the EDITLEVEL increment in patchlevel.h; save and bones file
contents are not affected.
I've also added an unrelated comment about reading mechanics to
doread().
Closes#386
The #enhance menu revealed a couple of menu problems for Qt.
Items flagged with "*" or "#" were showing tiny "..." instead of
the flag character. An existing problem rather than something
caused by yesterday's overhaul patch.
The "(Skills flagged by "*" may be enhanced when you're more
experienced.)" legend line was causing the regular entries to be
formatted strangely (their skill name column was much too wide).
That was caused by me dropping something (special case for header
lines during tab-separation handling) in yesterday's patch that
I mistakenly thought wasn't needed.
The save file selection widget was issuing a complaint to stderr:
|QLayout: Attempting to add QLayout "" to QDialog "", which already
| has a layout
This shuts that up, but doesn't fix the broken save file selection
so I haven't added a fixes37.0 entry.
handle preselected item in pick-one menu; picking it returns that
item rather than toggling it off and returning nothing, picking
something else only returns the other thing (was returning first
of the chosen item or the preselected item, foiling core's attempt
to deal with both and giving wrong result whenever the preselected
one came first--like pick-an-attribute for menu colors);
when handling typed input, check selector letters before menu
command keys so that special "letters" '-' (fingers, hands, self)
and ':' (look inside container) that are specified by a few menus
can be chosen by keyboard;
menus were using default line heights which are excessively tall,
effectively making them be double spaced and using more screen
space than should have been needed; reduce height to 60% of what
it was, still a bit taller than regular spacing; look at ^X--which
is rendered via menu--before and after to see the difference;
start with count column empty instead of 6 spaces; grow it as counts
get entered; reset to empty if [all], [none], or [invert] is used;
treat intermediate counts as long rather than int; right justify
formatted count values;
simplify creating menu return data (pick-one doesn't need separate
handling);
for pick-one menus,
enable [ok] button if there is one preselected item,
enable [all] button if there is only one item (may never happen),
enable [none] if there is a preselected item (menu remains active
if [none] is used to clear the preselection);
enable [invert] if there is one item (may never happen; should
allow two items if one of them is preselected--definitely does
happen--but that wouldn't work as intended without code changes);
honor pending count if an item is selected by clicking its checkbox
(already done for typing its letter or for clicking another part
of item's menu line);
accept <delete>/<rubout> in addition to <backspace> when backing out
a digit as a count is being typed;
accept ^[ as well as ESC key for cancelling count or entire menu;
honor 'menucolors'=false to ignore any defined menu color patterns.
Record a bunch of Qt stuff before I forget it all. It's probably
too late: I'll bet I've left some things out.
Doesn't include several menu problems that I've already fixed but
not checked in yet. (I don't have any other Qt changes pending.)
Qt's map hadn't been updated to draw unexplored locations with
the unexplored glyph so was still using solid stone instead.
Column 0 should be removed but I'll leave that for someone more
adventurous; I did it for curses and for X11 but am going to
pass here. It's very noticable after magic mapping but is only
"bad" (by wasting space) if clipping is being performed.
Qt's text window for 'history' was unexpectedly wide and it turned
out that that was to fit in one excessively wide line. tty has
been formatting it by splitting it into one normal sized line
followed by an excessively short line.
Similar to how the pick-an-attribute menu for menu colors and
status highlights shows the attribute names using the attribute
so that you can see how it looks (or whether it is supported),
have the pick-a-color menu show the color names in the
corresponding color. Does so by temporarily removing any
user-specified menu colors and setting up another list of such
for matching color names.
Forces the 'menucolors' option On while the pick-a-color menu is
in use, then restores the previous setting along with the user's
menu colorings. Might need some way to avoid setting that for a
configuration where colors don't work.
Avoid use of GNU make's 'override' feature by requiring
'make CCFLAGS=-O' to replace -g from the make command line instead
of 'make CFLAGS=-O'. Note the extra 'C' in the spelling.
Revert the previous umpteen MORECFLAGS+= back to normal CFLAGS+=.
In addition to 'true', 'yes', 'on' and 'false', 'no', 'off',
accept 1 and 0 for the value of a boolean option. Other numeric
values are rejected rather than treated as non-zero.
Relax the parsing for true, false, yes, no to accept one or more
letters instead of requiring at least three for true and false
and full word for yes and no. Full word is still required for
on and off.
Don't report two errors for the same mistake:
|% NETHACKOPTIONS='legacy:flase' ./nethack
| * Illegal parameter for a boolean.
| * Unknown option 'legacy:flase'.
|2 errors in NETHACKOPTIONS.
is changed to
| * 'legacy:flase' is not valid for a boolean.
|1 error in NETHACKOPTIONS.
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.
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 ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
