Casting to (void) to discard a function return value doesn't satisfy
gcc's -Wunused-result (which we aren't enabling but is apparently
being activated for particular functions by glibc header files). Turn
it into a no-op to suppress three dozen warnings from Travis builds.
I don't know why we have two different functions which do exactly
the same thing (checking whether an item is unpaid or is a container
that holds at least one unpaid item), but switch the #H2504 fix to
use 'the other one' and reverse one of the changes made when using
the inventory one.
I thought that the earlier fix for #H2504 was too easy for anything
shop related. It didn't deal sensibly with containers owned by hero
but holding unpaid shop goods.
That #H number isn't a typo. This finally fixes--at least improves--
something reported eight years ago. The monster types chosen by
mkclass() could be way off in some circumstances. Cited example was
repeated same-race sacrifice by chaotic hero on dungeon level 20; it
produced about twice as many incubi as succubi even though they're
the same as far as difficulty goes. (No changes in the intervening
years had any discernable effect; that was still reproducible.)
The report also mentioned that ndemon() threw away the result from
mkclass() and retried quite often and suggested that mkclass() be
taught to filter by alignment when caller cared about that.
This seems to even things out, although it also made harder monsters
chosen more often. A test program generated these numbers when
picking a chaotic demon 10000 times (level 1 hero on dungeon level 20,
so not realistic; actually probably level 0 hero since the program
didn't initialize struct u.) Third column is the number of times the
monster type was chosen with the old mkclass(), fourth is same for
the new one.
mkclass() calls 27315 10000
286 succubus 2800 3309
288 incubus 5552 3262
291 marilith 973 780
292 vrock 477 1617
293 hezrou 150 626
294 bone devil 46 247
295 ice devil 2 107
296 nalfeshnee 0 23
297 pit fiend 0 15
298 sandestin 0 4
299 balrog 0 10
Note that vrock has generation frequency 2 and marilith only 1, so
getting twice as many vrocks as mariliths should be expected.
I temporarily changed ndemon() to ask for lawful demons instead of
chaotic ones and got this.
mkclass() calls 15762 10000
287 horned devil 3197 3375
289 erinys 4991 3339
290 barbed devil 1812 3286
I also ran it for dragons with any alignment (so the outcome was
never thrown away; 10000 calls were needed for 10000 picks) instead
of demons of specific alignment and am suspicious of the outcome.
mkclass() calls 10000 10000
140 baby yellow dragon 1124 0
141 gray dragon 1096 1096
142 silver dragon 1073 1099
143 red dragon 1061 1126
144 white dragon 1077 1128
145 orange dragon 1141 1118
146 black dragon 1154 1049
147 blue dragon 1137 1123
148 green dragon 1137 1154
149 yellow dragon 0 1107
There may be a flaw in the test program. Or else old mkclass() was
not very good at picking dragons.
The relatively recent change to lev_comp do deal with apparent junk
in some places in its generated data has triggered a bunch of
"cast to 'vA' (aka 'const char *') from smaller integer type 'int'
[-Wint-to-pointer-cast]"
from clang when building with USE_OLDARGS. Probably should have
added a zillion explicit casts to long and 'L' suffix for 0 rather
than trying to handle both int and long. Or maybe just turned off
that particular warning, which must be coming from -Wall or -Wextra.
This modification has no effect for USE_STDARG or USE_VARARGS configs.
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.
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.
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.
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()
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.
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.
Some bits from another feature by Tangles had
slipped into our merge of curses a while back.
Remove the partial bits as feature bits should
be complete or not at all, unless foundational
for something to come.
