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.
PatR [Fri, 30 Nov 2018 02:02:52 +0000 (18:02 -0800)]
more steed dismount
By creating a spot of lava, filling up the whole level, and creating
a lurker above, I managed to trigger the impossible "Dismount: can't
place former steed on map" that was added earlier today. I also was
told that my god was displeased even though the engulfer's attack was
responsible. This addresses both situations. I can't trigger that
impossible any more, and only voluntary dismount blames the hero if
it's killed because there's nowhere to place it. Hero is still blamed
for any dismount that kills the steed while flying or levitating over
dangerous terrain--hero took steed into jeopardy.
PatR [Thu, 29 Nov 2018 20:15:14 +0000 (12:15 -0800)]
steed vs "no monster to remove"
Noticed whlie testing the steed-in-pit fix. The EXTRA_SANITY_CHECKS
for remove_monster() are being tripped if riding hero has steed killed
out from under him because the steed is not on the map. This started
out simple but got a bit complicated. It seems to be sufficient but
I'm not very confident about it.
Being engulfed while mounted gave "placing monster over another?" due
to a change made along with EXTRA_SANITY_CHECKS but not conditional on
it. (The change was to issue a warning about an actual problem which
was previously undiagnosed.) I think bumping the engulfer off the map
in favor of the former steed only worked because some u.uswallow code
eventually used the hero's location to put the engulfer back. I didn't
pursue that to try to figure what really happened, just prevent it.
The DISMOUNT_BONES handling was being executed even if the steed was
dead. DISMOUNT_BONES only happens if the hero is dead. Since I don't
know whether it's possible for dead hero and dead steed to happen at
the same time, move it inside the steed-not-dead block just in case.