When makedefs generates dat/options for #version, enhance the
formatting of the 'supported windowing systems' section with more
thorough word fill and also emphasize the actual window system names
so that user can tell what value to give to OPTIONS=window_system:%s
when picking one of them. Before and after
Supported windowing systems:
traditional tty-based graphics,
terminal-based graphics using curses libraries, and X11
with a default of tty.
Supported windowing systems:
"tty" (traditional text with optional line-drawing), "curses"
(terminal-based graphics), and "X11", with a default of "tty".
Clear up some NetHack warnings with updated PDCurses by using
-DCHTYPE_32
..\win\curses\cursinvt.c(98): warning C4244: 'function': conversion from 'attr_t' to 'int', possible loss of data
..\win\curses\cursinvt.c(101): warning C4244: 'function': conversion from 'attr_t' to 'int', possible loss of data
..\win\curses\cursinvt.c(105): warning C4244: 'function': conversion from 'attr_t' to 'int', possible loss of data
Leather jacket doesn't take multiple turns to wear, so wearing it
wasn't calling Armor_on() and recently moved 'uarm->known = 1' didn't
get executed. Not reported yet but had the same issue: fedora and
dented pot wouldn't call Helmet_on().
Do late message suppression in a different fashion. Also, there are
more messages than shk taking hero's possessions and guard taking
hero's gold that need to be suppressed if regular message delivery
is no longer possible: "do not pass Go", "you arise from the grave
as a foo", "the corridor disappears", "you are encased in the rock".
Those last two are from vault handling but take place in a convoluted
manner: paygd -> mongone -> grddead -> clear_fcorr.
Closing nethack's window sets 'program_state.stopprint' to inhibit
disclosure interaction, but shopkeeper claiming hero's stuff or vault
guard claiming hero's gold didn't honor that and just issued normal
pline messages. For win32, they got delivered in a popup even though
nethack's window had gone away.
Make those two end-of-game situations honor 'program_state.stopprint'.
[Fix not tested on win32...]
about the armor. Wearing armor sets obj->known, making its enchantment
be shown when it gets formatted, because the AC value on the status line
lets the player deduce what that is. It was being set at the beginning
of the wear operation. If the armor got stolen before it became fully
worn, the enchantment was still shown. Defer that until the end of the
operation. An attentive player can still deduce the enchantment if the
item is stolen (because its protection starts immediately) but the hero
won't learn that enchantment unless the donning completes.
This might be suboptimal but it isn't qualitatively different from
watching a pet walk/not-walk over items whose bless/curse state isn't
known or dropping unidentified items in a shop to check their price.
The player can deduce something that the hero doesn't know yet.
This takes care of a lot of the leaked memory in the curses interface.
It still needs to free memory allocated for status fields when the
status window is destroyed at game end; likewise for message history
when the message window is destroyed.
Support <delete> (aka <rubout>) during getline(). It doesn't actually
honor the current erase_char value set up for the terminal, just
treats DEL the same as ^H. (The previous lack of support had nothing
to do with terminfo specifying ^H; the handling is hard-coded.)
tty treats escape while there's already some input as kill_char (erase
the input but get more from scratch) and returns ESC if there isn't.
curses was doing the first half but not the second, so not providing
any way to communicate "cancel" back to the core. Fix is simple.
Other getline() bug fixes:
1] there was a wprintw("%*something") which was passing the value from
strlen (type 'size_t') to the "%*" argument (type 'int'). That's
always wrong (size_t is guaranteed to be unsigned) and could be severe
(if size_t is different width than int--as on current OSX systems--
depending upon the internals of argument passing).
2] strncpy() only supplies a terminating '\0' if the input is shorter
than the number of characters specified.
A lot of reformatting is warranted but I only did the getline routine
(manually, so might have missed stuff).
Three or four instances of one simple memory leak. Allocating a union
'anything' to pass to add_menu(), then not doing anything with it. The
value gets copied so there's no reason for the original to stick around.
[There are still lots of other memory leaks.]
