win/share/tileset.c seems only to be used by the MSDOS port, but it
compiles cleanly on OSX after these changes.
A file pointer was passed to fclose() twice, second time potentially
causing problems. There were cases of potentially null pointers
being passed to free() too. That should be safe these days, but it's
something we've tried to hard to avoid and would probably trigger
complaints from our own MONITOR_HEAP code if that ever got applied
here.
I couldn't reproduce the reported problem of the "In what direction?"
being issued after the screen was cleared, but bypassing pline() in
favor of putstr(WIN_MESSAGE) for tty prompts did also bypass
if (vision_full_recalc) vision_recalc(0);
if (u.ux) flush_screen(1);
done in pline(). Inadvertent loss of the latter could conceivably be
responsible for the problem. If so, the escape code used by cl_end()
may be broken for somebody's termcap or terminfo setup since clearing
to the end of the line in the message window shouldn't erase the rest
of the screen.
Regardless, the prompting change also bypassed the ability to show
the prompt with raw_printf() if the display wasn't fully intialized
yet, so some change to the revised prompting was necessary anyway.
Switching back from putstr(WIN_MESSAGE) to pline() resulted in
duplicated entries in DUMPLOG message history, one with bare prompt
followed by another with response appended, so more tweaking was
needed. The result is use of new custompline() instead of normal
pline(). custompline() accepts some message handling flags to give
more control over pline()'s behavior. It's a more general variation
of Norep() but its caller needs to specify an extra argument.
Update DUMPLOG's message history to include player responses to
most queries. For tty, both getlin() and yn_function(). For other
interfaces, only yn_function() is covered. (It's intercepted by a
core routine that can take care of the logging; getlin() isn't.)
Also includes saved messages from previous session(s), for the
interfaces which support that (tty), to fill out the logging when
a game ends shortly after a save/restore cycle.
The tty interface was using pline() to display prompt strings.
Having 'MSGTYPE=hide "#"' or 'MSGTYPE=hide "yn"' in .nethackrc
would suppress many prompt strings (in the two examples mentioned,
entering extended commands or the vast majority of yes/no questions,
respectively) and generally lead to substantial confusion even if
done intentionally, so switch to putstr(WIN_MESSAGE) instead.
Rewrite 3.6.1's compress_str() to avoid peeking past the end of the
input string. This should eliminate the reported valgrind complaint.
The problem was noticed for post-3.6.0 code introduced [by me...] last
June, but it looks like it was present in the old code too.
Also, fix the wording in the paragraph about NUL in the keyhelp text.
tty_putstr() always passes non-message window text through compress_str(),
clobbering usage of two spaces to separate sentences. putstr()'s caller
ought to have more control over that (possibly via its hardly ever used
'attribute' arg?).
This is a modified version of Jason Dorje Short's key rebinding
patch, and allows also binding special keys, such as the ones
used in getloc and getpos.
One of the ways to play NetHack on nethack.alt.org is via a HTML
terminal in browser. Unfortunately this means several ctrl-key
combinations cannot be entered, because the browser intercepts
those. Similar thing applies to some international keyboard layouts
on Windows. With this patch, the user can just rebind the command
to a key that works best for them.
I've tested this on Linux TTY, X11, and Windows TTY and GUI.
The value calculated for total_tiles_used never got adjusted for
displaying statues-as-monsters. The most common configuration(s)
using tiles don't care, but the combination of X11 plus USE_XPM
needs an accurate value there.
This is from the pull request for the assertion failure fix. It
did not mention how to reproduce the assertion failure, just added
casts to a bunch of isspace/isprint/tolower calls that didn't already
have such.
I removed an obsolete change for win/tty/topl.c and changed the
win/win32/mswproc.c code to avoid using an expression with side-effects
(*colorstring++) in calls to tolower() in case someone overrides that
with a macro which evaluates its argument more than once as some pre-
ANSI ones used to do. Not tested, might have typos....
sys/wince/*.c still needs similar casts.
Reported 11 months ago for 3.4.3, the tile for wrinkled spellbook
has a spurious brown spot on the far right. Several other books
have spots drawn outside the book proper for tile decoration, but
that doesn't seem to apply here. The report suggested changing
'K' to 'M', but that just changes it into a spurious white spot.
Change the stray 'K' to '.' to make the odd spot go away.
Reported directly to devteam last October, for 3.4.3 on NAO,
subject "UI flaw in message history":
"Applying the stethoscope at self informs:
"Status of Xxxxxxxx (piously neutral): Level 14 HP 138(138) AC -15, very
"fast, invisible.--More--
This is reproducible with shorter character name "wizard" by being
"nominally neutral" or "nominally chaotic". I had a 2 digit level
but didn't notice that my AC took up only 1 digit and ended up
using 125ish blessed potions of full healing to get 4 digits of hit
points in order to get the line to wrap between "very" and "fast".
"But the message history with Ctrl-P shows:
"Message History
"
"Status of Xxxxxxxx (piously neutral): Level 14 HP 138(138) AC -15, very
"invisible.
The key was "Message History", indicating msg_window:full or other
setting which causes ^P to bypass the top line message window and
use a general text window to deliver all history lines at once.
The original feedback splits the line by replacing the space
between "very" and "fast" with a newline, which topline handling
notices and processes as special, but then leaves in place.
msg_window:full results in tty_putstr() case NHW_TEXT, which treats
newline as an ordinary character since it doesn't expect to see
that in text. Squeezing out three doubled spaces made room for
"very\nfast," on the top line. process_text_window() attempted to
write it there, but putchar() wrote up through "very," on one line,
then output the newline which resulted in "fast," on the next line.
Then explicit cursor positioning set things up to put "invisible"
at the start of that line, overwriting "fast," so making it appear
to be missing.
FDECL(foo, (boolean)) ought to have been using (BOOLEAN_P), but
the tiles code isn't including the header which defines that, so
change the argument to int.
Just noticed that a change of mine to src/drawing.c 2.5 weeks ago
("zap beam symbol descriptions -- they aren't walls") triggered a
set of four complaints when processing tiles.
Add MG_BW_LAVA to mapglyph() instead of hijacking MG_DETECT. Used
to display lava in inverse video if color is disabled and lava is
using the same display character as water (which is the default).
(The use_inverse option must be enabled for tty to honor it. X11's
text mode doesn't care. Win32 does care but probably shouldn't--it's
not a case like tty where the hardware might not support it.)
This implements both MG_DETECT and MG_BW_LAVA for X11, but only if
the program is built with TEXTCOLOR enabled. Those should work even
when color is not supported, but I suspect that configuration is
unlikely to ever be used so didn't want to spend the time to figure
out how to do it. (The relevant data is overloaded on the color
data, so not available when TEXTCOLOR is disabled.)
The win32 revision is untested.
When --More-- was written to leftmost column of line 2 while the
hero was swallowed, after player acknowledged it and the top line
was cleared, the cursor ended up in the wrong place. I still
don't understand what in the world is going on here, but adding
'flush_screen(0)' after 'swallowed(1)' in docorner() makes the
problem go away. Why is the behavior different when --More-- is
in the first column than when it's anywhere else?
After that fix, I commented the whole thing out. The swallowed
optimization is just not significant enough to justify peeking at
core internals.
Core bit: prior to those two changes, I tried inserting 'bot()'
into swallowed(). It moved the mis-positioned cursor from the
end of the second status line to on the map just right of the
bottom right corner of the swallowed display. That didn't fix
anything, but I've left it in place. bot() to update status is
needed following cls(); now it happens before redrawing the map
instead of at some point after.
Quiting without ever examining inventory caused the Qt interface
to issue an impossible(), then crash due to deferencing a Null
pointer. The prior fix was to suppress the validation code that
was crashing. This changes things so that the inventory window
always gets at least one use, allowing the Qt validation code to
succeed. tty and X11 are ok with it; win32 needs to be verified.
Put in Ron Vaniwaarden's fix for crash occuring if player quits
right after choosing a character and declines to disclose anything.
Just a guess, but deleting the never-viewed inventory window might
be the cause. (3.4.3 didn't delete it.)
There's a small amount of reformatting, but cleaning that up
manually is a monumental task.
Start coloring after the space which follows the selection indicator
instead of on that space. The difference isn't noticeable when the
highlighting is just a color, but it is if that highlighting includes
inverse video or underline which visibly apply to spaces. So for
a - entry A
the old code produced
a -########
and this revised code produces
a - #######
where '#" indicates characters subject to menu coloring.
This reverts commit 2ff96797a8.
Since this pull request was made to the DevTeam, a commit has appeared
in the official repo's NetHack-3.6.0 branch which effectively does the
same thing: NetHack commit 98b5f58 (tty menu coloring) by PatR.
There was a report during beta testing that menu lines which were
displayed in color showed the whole line in color, unless/until an
item was selected or unselected, in which case the '-', '+', or '#'
was rendered in monochrome. The suggestion then was to redraw the
selection character in color, but I went the other way. Menu
entries will render the selector letter and selection indicator in
monochrome all the time, and only the text of the menu entry will
honor menucolors.
Umpteenth revision of the X11 extended command menu. Add a new
resource to NetHack.ad to control its initial size.
I still hope there's a better way to do this, but this is my last
shot at it.
Report states that using OSX Xcode IDE results in use of 'clang
Modules', whatever those are, and role.c's 'filter' struct ends up
conflicting with a function declared by <curses.h> (or possibly
<ncurses.h> since one includes the other). src/role.c does not
include <curses.h>, so this smacks of the problems caused by using
precompiled headers on pre-OSX Mac.
Instead of trying to import nethack into Xcode, I temporarily
inserted '#include <curses.h>' at the end of unixconf.h. gcc did
complain about 'filter' in role.c (but not in invent.c, despite
-Wshadow), and then complained about termcap.c using TRUE when it
wasn't defined (after in had been #undef'd, where there's a comment
stating that it won't be used in the rest of that file), and also
complained about static function winch() in wintty.c conflicting
with external winch() in curses.
This renames 'filter' and 'winch()' to things that won't conflict.
Also, our winch() is a signal handler but had the wrong signature
for one. And the troublesome use of TRUE was in code that was
supposed to be dealing with int rather than boolean.
When the extended command menu auto-scrolls as the player types in
characters, scroll so that all matching entries come into view rather
than just the first one. For example, it someone types 'w', instead
of just highlighting and showing "wipe", it will highlight "wipe"
(because that has become the default response when <return> is used)
but also show "wiz-this", "wiz-that", and "wmode". It actually shows
one extra entry beyond the last matching one--so you can see that
there aren't any more ambiguous choices--except for 'w' where "wmode"
is the very last extended command.
Previously, on subsequent popups of the extended command menu, the
scrollbar's slider was left drawn in the position it was in during
the previous time even though menu content wasn't scrolled. Now it's
forced back to the top (non-scrolled) position when that menu is
popped up.
When the extended command menu is big enough to need a scrollbar,
leave more elbow room when forcing its height to fit on screen.
The last entry was frequently obscured by OSX's "docking tray"
desktop decoration and the resize hotspot (bottom right corner of
the menu popup) could be hard to access.
I'm not particularly happy with this code. There really has to be
a better way to accomplish what's needed.
