It's possible to get a rolling boulder trap which doesn't have any
boulder. That isn't invalid, but if/when it happens on a shallow
level it shouldn't be covered by the corpse of a fake adventurer
since such a trap won't kill anyone.
One-line fix is much shorter than attempting to describe the problem.
^A could misuse previous input if 'f'<direction> needed to fill the
quiver and there was nothing suitable, so that the sequence became
'f'<what to throw>. If previous <direction> was an inventory letter
that was occupied, and the item it that slot wasn't already worn in
some other slot, it would be put in quiver slot. Then player would
be asked for direction rather than immediately throwing it since the
what-to-throw prompt had just used up the last of the ^A queue.
Miscellaneous formatting included....
The fuzzer likes to set options randomly; the combination of
DECgraphics symbol set (on a display capable of rendering it) plus
eight_bit_tty produces a bizarre map display. Make DECgraphics
override eight_bit_tty rather than the other way around.
We aren't defining BSD for OSX but we probably should be. This doesn't
go that far, just changes a couple of __APPLE__ for MACOSX (set up in
config1.h) and defines DEV_RANDOM as "/dev/random".
Noticed while fixing the 'monster intrinsics from worn gear' bug(s):
set_uasmon() calls set_mon_data(&youmonst,...) which updates movement
when the monster polymorphs into something slower, then it did the
same thing to youmonst.movement itself, hitting the hero with a double
dose of reduction for any movement points not yet spent on current
turn. Remove the set_uasmon() side of that, and change set_mon_data()
side to add a redundant non-zero test to prevent static analysis from
warning that it might be dividing by 0.
Fixes#177
The monst struct has 'mintrinsics' field which attempts to handle
both mon->data->mresists and extrinsics supplied by worn armor, but
polymorph/shape-change was clobbering the extrinsics side of things.
Potentially fixing that by changing newcham() to use set_mon_data(...,1)
instead of (...,0) solved that but exposed two other bugs. Intrinsics
from the old form carried over to the new form along with extrinsics
from worn armor, and update_mon_intrinsics() for armor being destroyed
or dropped only worked as intended if the armor->owornmask was cleared
beforehand--some places were clearing it after, so extrinsics from worn
gear could persist even after that gear was gone.
So, fixing the set_mon_data() call in newcham() was a no go. This
fixes update_mon_intrinsics() and adopts the suggested code from
github pull request #177 to have mon->mintrinsics only handle worn
gear instead of trying to overload innate intrinsics with that. This
is a superset of that; the flag argument to set_mon_data() is gone
and mon->mintrinsics has been renamed mon->mextrinsics. (The routine
update_mon_intrinsics() ought to be renamed too, but I didn't do that.)
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.]
