PatR [Wed, 12 Dec 2018 09:54:33 +0000 (01:54 -0800)]
fix #H7677 - guard placed twice at <0,0>
"Placing monster over another?" warning was triggered for vault guard
by an earlier change which made m_detach() stop removing monsters at
<0,*> from level.monsters[][]. So one guard would replace another at
<0,0> for however many guards were created, and memory for all but
the last one would be lost.
This involved a lot of flailing about and the patch includes various
things would could have been discarded. One or two extended monster
sanity checks are included, plus a couple of debugpline()'s for
tracking guard movement.
PatR [Tue, 11 Dec 2018 01:34:18 +0000 (17:34 -0800)]
fix 'a X'
The fruit name fix a couple of days ago revealed that an() didn't
pick the right article for single letters. If you set named fruit to
"X" and wished for "fruit", you'd have 'k - a X' added to inventory.
This changes an() and also doname() which bypasses an().
PatR [Mon, 10 Dec 2018 11:52:00 +0000 (03:52 -0800)]
fix #H7707 - terrain change leaving stale flags
struct rm.flags in overloaded for a bunch of rm.typ -dependent things
(doormask, altarmask, throne/fountain/sink looted, a few others) and
wasn't being reset for various cases where rm.typ gets changed.
I've changed a lot, some no doubt unnecessarily, and probably missed
plenty. This compiles but has not been thoroughly tested.
PatR [Mon, 10 Dec 2018 10:21:31 +0000 (02:21 -0800)]
fix #H7704 - clairvoyance: objects vs pools
When clairvoyance revealed an underwater object and the player wasn't
being given a chance to browse for some other reason, the map didn't
get refreshed and the object stayed displayed with the water hidden
under it. Force a chance to browse when revealing underwater objects
despite that being intrusive when clairvoyance kicks in while walking
around.
nhmall [Mon, 10 Dec 2018 05:44:18 +0000 (00:44 -0500)]
allow a deferred windowport init during options processing
When options processing encountered OPTIONS=windowtype:X,
the code would immediately attempt to switch over to that
windowtype right in the midst of options processing.
This stores the chosen option into
chosen_window[WINTYPELEN]
thus allowing the startup code to choose it after
options processing has been completed.
PatR [Mon, 10 Dec 2018 00:22:27 +0000 (16:22 -0800)]
fix #H7708 - change in terrain not noticed
Jumping or teleporting while levitating in xorn form wouldn't toggle
blocking of levitation when moving from open spots to wall/stone and
unblocking of same when moving the opposite way.
This handles those cases but there are no doubt others. The only
other one I checked was when failed #untrap moves hero onto trap.
That case works correctly--at least after this fix is in place.
Noticed while working on it: change of terrain didn't always update
the status line. When levitation became blocked, it still said Lev
and when unblocked, didn't say that. Next status update got status
condition back in sync.
PatR [Sun, 9 Dec 2018 23:03:13 +0000 (15:03 -0800)]
fix #H7702 - named fruit warning: singular of null
Some code added for 3.6.1 tries to find the longest matching prefix
when comparing a user-supplied with previously set up fruit names.
It does so by temporarily replacing space with NUL then passing that
to makesingular(). After already having named a fruit (resulting in
something to try to compare with), attempting to assign a name
beginning with two or more spaces would yield an impossible "singular
of null?" warning.
After the warning, the name minus its leading spaces got successfully
assigned. I'm not sure why a single leading space didn't trigger it
too, nor where the leading (and trailing, if any) spaces are going
away when the name is assigned.
Fix by removing all leading and trailing spaces from a new fruit name,
and combine consecutive internal spaces to one, before any other
manipulations. (This can result in names that used to work as-is now
being simplified a bit--when consecutive internal spaces have been
given--but that shouldn't be a problem.)
Also, don't complain about "missing parameter for 'fruit:'" if user
hits <return> when prompted for fruit name by 'O'. An empty fruit
name at that stage is just a no-op.
Bart House [Sun, 9 Dec 2018 19:57:50 +0000 (11:57 -0800)]
Three fixes to NetHackW font handling.
Check that player level is valid before checking if it is rogue.
Prevent attempting to pick a font that is too small.
Don't leak fonts when trying to find a font that fits.
copperwater [Sun, 9 Dec 2018 14:51:47 +0000 (09:51 -0500)]
Fix resurfacing of "foxen" pluralization bug
Inadvertently reintroduced in f9f1236. It was just the conditional
that was bad: due to resolving the possible buffer underflow when
comparing to "muskox", the pluralizer now only adds -es when the length
of the string is greater than 5. So for "box" and "fox" the pluralizer
will never add the -es ending, since they are greater than 5.
This commit checks for "does not end in muskox" correctly.
nhmall [Sun, 9 Dec 2018 04:04:53 +0000 (23:04 -0500)]
clean up some tear-down
Windows continued to use function pointers belonging
to particular window ports that were still assigned
even after that port (tty) had gone through its
shutdown procedures when requested by the core.
Fix that and return to the minimal function pointers
that are not part of any of the actual WindowPorts.
nhmall [Sat, 8 Dec 2018 22:56:20 +0000 (17:56 -0500)]
Windows startup modifications
Changes to be committed:
modified: include/winprocs.h
modified: src/options.c
modified: sys/share/pcmain.c
new file: sys/share/safeproc.c
modified: sys/winnt/Makefile.msc
modified: sys/winnt/stubs.c
new file: sys/winnt/windmain.c
modified: sys/winnt/winnt.c
modified: win/win32/vs2017/NetHack.vcxproj
modified: win/win32/vs2017/NetHackW.vcxproj
modified: win/win32/winhack.c
Because multiple window ports are supported on Windows
now, even in the same executable and selectable via
config file in some cases, some adjustments became
necessary. There will likely be some further refining
of this over the next day or two.
List of changes:
Move Windows startup from sys/share/pcmain.c and
into its own sys/winnt/windmain.c so that it can
be modified to fix some current breakage, and
allow altering the order of some things.
There is startup processing code that is common to
all of the Windows WindowPorts, but that startup
processing code needs to have no dependency on
any one of those WindowPorts.
Yet, during startup processing, some of the initialization
routines can end up calling NetHack functions that
expect an active Window port underneath, and if there
isn't one, routines like pline, impossible, panic can
end up invoking null function pointers.
Place a new file sys/share/safeproc.c, in which a complete
window port is available for early startup processing
purposes. It's WindowPort name field is set to
"safe-startup" just for reference. The prototypes in
include/winprocs.h require that SAFEPROCS be
Usage:
windowprocs = get_safe_procs(0);
initializes a set of winprocs function pointers that ensure
none of the function pointers are left null, but that's all it does.
windowprocs = get_safe_procs(1);
initializes a set of winprocs functions pointers that ensure
none of the function pointers are left null, but also
provides some basic output and input functionality using nothing
other than C stdio routines (no platform or OS specific code).
The conditional code related to WIN32 has been removed from
sys/share/pcmain.c
The code common to all of the Windows WindowPorts calls
get_safe_procs() almost immediately to ensure that
there is a set of WindowPort winprocs available.
PatR [Sat, 8 Dec 2018 00:51:18 +0000 (16:51 -0800)]
recursive destroy_item()
Make the sequence:
be zapped by lightning,
have worn ring of levitation be destroyed,
fall onto fire trap
work better. The fire trap handling will mark everything in inventory
as already processed; anything vulnerable to lightning past the destroyed
ring would not be checked. So delay destroying such a ring until after
all of inventory has been subjected to lightning.
nhmall [Sat, 8 Dec 2018 00:12:56 +0000 (19:12 -0500)]
back out some spider changes
After consultation with the original committer, this
is being pulled out, possibly revisited later. There was
originally meant to be a follow-up piece to this that he
never had a chance to integrate for various reasons.
nhmall [Fri, 7 Dec 2018 14:29:01 +0000 (09:29 -0500)]
add MM_NOGRP makemon() flag
add MM_NOGRP makemon() flag as a means of suppressing groups of monsters in
a couple places that warrant it when a specific monster type isn't
specified on the call to makemon()
PatR [Fri, 7 Dec 2018 09:20:20 +0000 (01:20 -0800)]
menucolors
In the 'special options' section at the end of 'O's menu, change the
spelling for the menucolors entry to "menu colors" so that it isn't
spelled exactly the same as the 'menucolors' boolean option. Only
affects what the player sees when reading that menu.
If player uses 'O' to add any menu colors and 'menucolors' boolean is
Off at the time, give a reminder to toggle it to On in order to have
those menu colorings become active. (Adding hilite_status entries has
a similar reminder for 'statushilites' if done while that is 0.)
PatR [Fri, 7 Dec 2018 08:36:38 +0000 (00:36 -0800)]
fix #H7655 - highlighting gold
With options along the line of
OPTIONS=statushilites:4
HILITE_STATUS=gold/always/yellow
gold started out unhighlighted (unhighlit?). I didn't try to figure
out why, just changed things to force a full status update when gold
requires internal changes (different \G encoding or different glyph)
which is something that happens when session first enters moveloop().
PatR [Fri, 7 Dec 2018 01:27:36 +0000 (17:27 -0800)]
fix #H7686 - destroy_item()'s inventory traversal
Inventory traversal can be disrupted when items being traversed are
able to change inventory. I've lost track of how many times this
sort of thing has been discovered.
Report claimed that boiled potion of polymorph caused transformation
which resulted in dropped weapon and dropped or destroyed worn armor.
That was evidently a guess; potionbreathe() for that potion only
abuses constitution. The traceback showed 'you_were()' was involved.
Boiled potion of unholy water triggers human-to-beast transformation
of hero inflicted with lycanthropy, yielding similar situation.
I didn't notice anything unusual when reproducing this but inventory
was definitely vulnerable. My 'one line' fixes entries are steadily
getting to be more verbose; I may have to go back to 'fix bug'. :-}
PatR [Wed, 5 Dec 2018 22:56:03 +0000 (14:56 -0800)]
more green slime
When a hero dies due to turning into green slime, actually polymorph
him into a green slime monster before killing him off. That way he'll
show as a green 'P' on the map instead of white '@' during final
disclosure. Also, armor that gets destroyed by polymorphing into that
form will be absent from resulting bones file.
PatR [Wed, 5 Dec 2018 09:45:16 +0000 (01:45 -0800)]
fix #H6292 - green slime & genocide
Report suggested that if hero is turning into green slime, genociding
green slime should cure it. I went another direction: if life-saved
while dying due to turning into green slime, you survive polymorphed
into green slime form. If green slimes have been genocided (probably
after becoming infected with slime or hero wouldn't have faced any
slimes to cause infection, but that could be from eating a glob of
green slime created prior to genocide, or from #wizintrinsic), you'll
immediately die again, this time from genocide.
PatR [Wed, 5 Dec 2018 01:10:15 +0000 (17:10 -0800)]
fix #H7667 - maybe_reset_pick(), other bad context
When deciding whether to discard interrupted lock/unlock context while
changing levels, maybe_reset_pick() checks whether xlock.box is being
carried. But it was doing so after the old level had been saved and
memory for non-carried container there had been freed.
That led to a couple of other issues. context.travelcc was using -1
for 'no cached value', but the fields of travelcc have type 'xchar' and
shouldn't be given negative values. 0 should be fine for 'no cache'.
Failed partial restore which occurred after old game's context had been
loaded would begin a new game with old game's stale context. Restoring
goes out of its way to avoid that for 'flags' but didn't for 'context'.
PatR [Tue, 4 Dec 2018 02:57:01 +0000 (18:57 -0800)]
fix #H7659 - accessing freed memory by cutworm()
hmon() can destroy the weapon being used, and known_hitum() would
still pass the pointer to the freed object to cutworm(). Remember the
relevant weapon attribute before using and maybe freeing the object,
then pass that attribute instead of the whole weapon. Also pass
'more-likely-to-cut' for axes in addition to blades.
thimonst() behaved similarly, although due to much different code
paths none of the objects that might get to hmon() were then passed to
cutworm(), so it wasn't vulnerable. But pass 'more-likely-to-cut'
for axes instead of for blades when thrown.
PatR [Mon, 3 Dec 2018 09:46:01 +0000 (01:46 -0800)]
more !SHELL, !SUSPEND
Update tty command completion to ignore #shell and #suspend when
they're disabled. (Since they aren't flagged for command completion,
this should be unnoticeable.)
Update X11 extended command selection to not show shell and suspend
in the menu when they're disabled. (Trickier than I expected.)
X11 currently rejects #suspend (at run time, not compile time) but
allows #shell. If it was launched syncronously from a terminal
window, shell escape behaves sanely. Otherwise, that seems like
asking for trouble.
PatR [Mon, 3 Dec 2018 00:43:53 +0000 (16:43 -0800)]
command handling for !SHELL and !SUSPEND
Change the command list to always include #shell and #suspend so that
a user's preferred key bindings can span platforms without worrying
about whether those exist or not. They're still effectively no-ops
when compiled out.
'#?' suppresses them from the list of displayed commands. Interface-
specific extended command handling may want to check new extcmd.flag
value CMD_NOT_AVAILABLE to do the same, but failing to do so shouldn't
pose a problem. They behave sanely if executed when not supported.
nhmall [Sun, 2 Dec 2018 23:47:23 +0000 (18:47 -0500)]
'curses_display_nhmenu' should return a value
Caught by automated build test
../win/curses/cursdial.c:598:9: error: non-void function 'curses_display_nhmenu' should return a value [-Wreturn-type]
return;
^
../win/curses/cursdial.c:605:9: error: non-void function 'curses_display_nhmenu' should return a value [-Wreturn-type]
return;
PatR [Sun, 2 Dec 2018 10:09:22 +0000 (02:09 -0800)]
Sting revisited
Replace recent "(light blue aura)" with
"(flickering light blue)" if there are 1..4 orcs,
"(glimmering light blue)" if 5..12, or
"(gleaming light blue)" if there are 13 or more, and move its place
in the formatted name.
_3.6.1_: Sting (weapon in hand) (glowing light blue)
_recent: Sting (weapon in hand) (light blue aura)
_now___: Sting (weapon in hand, flickering light blue)
The thresholds for intensity may need to be tweaked. The start
message has been changed from "glows" to "flickers/glimmers/gleams"
and is given when the intensity changes (up or down) as well as when
first glowing. Stop message will usually be "stops flickering" but
some form of mass kill (genocide for sure, maybe explosion, probably
not wand zap) might result in stopping directly from higher intensity.
It still "quivers" if hero is blind when there are orcs on the level,
but no name augmentation shows in inventory for that situation;
describing it as "(weapon in hand, quivering)" would be too silly.
Also, the quiver or glow intermediate message if blindness is toggled
while Sting is active only worked for make_blinded(), not for putting
on and taking off a blindfold. Now fixed. I think becoming blind due
to polymorphing into an eyeless form is still not handled, but there
are no eyeless creatures capable of wielding weapons so that can wait.
Polymorphing from eyeless to sighted is handled but moot for Sting.
PatR [Sun, 2 Dec 2018 00:43:13 +0000 (16:43 -0800)]
debug_fuzzer vs '!' and ^Z
My sysconf allows shell escape, and the fuzzer seems fond of that.
Suppress '!' and also '^Z', although I didn't notice it execute the
latter. Without this hack, the sequence '!', sub-shell exit, '&'
causes nethack to be killed via SIGTTOU while fiddling with terminal
settings for introff().
PatR [Sat, 1 Dec 2018 00:02:55 +0000 (16:02 -0800)]
X11 text popup fix
Text popups on OSX could be dismissed with <space> or <return> or
<esc> if user's X resources had 'NetHack*autofocus' set to True, but
for the default of False they ignored all keystrokes even if you
clicked inside the popup window to set focus explicitly. Clicking
on the Close Window button of the popup's title bar was the only way
to get the popup to go away. Fix suggested by Pasi.
nhmall [Fri, 30 Nov 2018 21:00:24 +0000 (16:00 -0500)]
curses follow-up bits
Move the curses global variable defininitions to cursmain.c.
Make the references to those global variables extern in
include/wincurs.h
Get rid of a warning:
../win/curses/cursmesg.c:379:9: warning: declaration shadows a
variable in the global scope [-Wshadow] int orig_cursor = curs_set(0);
Kludge for Visual Studio compiler: Add a stub- file for use
in Windows curses port builds to ensure that a needed #pragma
is invoked prior to compiling the file pdcscrn.c in the
PDCurses source distribution. All command line options and
compile of the file. It is unreasonable to expect a NetHack
builder to have to tinker with the PDCurses source files in
order to build NetHack. This kludge means the NetHack builder
doesn't have to.
The file stub-pdcscrn.c contains only two lines:
#pragma warning(disable : 4996)
#include "pdcscrn.c"
Some day, if the PDCurses sources corrects the issue, this
can go away.