Fixes#221
Routine unfixeable_trouble_count() is used for both applying a unicorn
horn (possibly internally via #monster if poly'd into a unicorn) and
drinking a blessed potion of restore ability. For the latter case, it
always gave the wrong answer (unless the hero happened to be all of
Sick and Stunned and Confused and Hallucinating and Vomiting and Deaf).
Since the actual count wasn't used to decide whether hero felt "great"
or just "good", having any of those conditions would hide the problem.
Have the 'menucolors' option control menu color pattern matching
(instead of curses-specific 'guicolor') for all menus, not just for
the persistent inventory window.
Subject was "display crash while in curses mode". Restoring with
perm_invent set in config file or NETHACKOPTIONS when the save was
made while swallowed (regardless of perm_invent at that time) resulted
in a crash when invalid u.ustuck was referenced before restoration had
done its pointer fixups.
init_nhwindows() is called with perm_invent On;
restgamestate() temporarily turns it Off (3.6.2 restore hack);
if/when update_inventory() gets called, curses notices that the
persistent window has been disabled so it tears down all its windows
in order to redraw the screen without that one;
docrt() sees non-Null u.ustuck and calls swallowed();
swallowed() tries to use the value of that pointer rather than just
Null/non-Null but the value is from the previous game session, not
valid for the current session;
crash.
Make yet another attempt to prevent update_inventory() from being
called during restore. curses won't try to redraw and the crash
won't happen. But the invalid pointer is still lurking (until an
eventual fixup later during restore).
An earlier fix for update_inventory() during restore actually handled
this problem (for the most common trigger, setworn(), but not in
general), so the 3.6.2 behavior is a regression.
Add the contributed code that checks for attempting to start a
duplicate timer. It's based on a comment which must have been there
at least 25 years and doesn't solve any known problems, but it is
conceptually similar to the large amount of sanity checking which has
gone into 3.6.x.
It didn't work as is because it was comparing two unions with '=='.
I don't know offhand whether C++ supports that but C doesn't (through
C11 at least; don't know about C17). The union ('anything') is simple
enough that two instances can be compared without jumping through hoops.
I've also added another check for timer 'kind' (level, object, monster,
or global).
phase_of_moon and friday_13th determined using rn2() instead of local
time if fuzzing. Don't reseed using init_random() if fuzzing. Allow
set_random to be called outside of hacklib. rn2_on_display_rng uses
rn2 if fuzzing so that we have a single source of random that we can
ensure is reproducible. Implement rul() that returns a random unsigned
long. Fix bug in fuzzer handling of ntposkey which would cause us to use
unitialized values for x and y. Added command line arguments to allow
auto starting and stopping of fuzzer. Add a logging facility for the
fuzzer to use to record activity. Added some scripts used to automate
fuzzer testing on windows.
_snprintf and snprintf have one very important semantic difference.
_snprintf does NOT add terminating null character when the buffer limit
is reached while snprintf guarantees a terminating null character. It
was a mistake to make this naming change hiding the fact that the
semantics don't match what the developer might expect.
For ^X and final disclosure, report external issues that affect game
play: midnight, other night, new or full moon, and Friday the 13th.
The 'new feature' entry in the fixes file rambles a bit but if it
heads off even one spurious bug report, it'll have been worth it.
Extend support for highlight rules that specify percentages from HP
and spell power to experience level and experience points. For both
of those, the percentage is based on progress from the start of the
current Xp level to the start of the next Xp level. 100% isn't
possible so is used to enable highlighting a special case: 1 point
shy of next level, most likely to occur after losing a level.
This is something I had in mind a long time ago and then forgot all
about until fiddling with the final disclosure of experience points
recently. It turned out to be trickier than expected because it needs
to check whether Xp should have a status update when it hasn't changed
but Exp has gone up. The latter might hit a percentage threshold that
switches to another highlight rule. Fortunately changes to Exp, at
least that aren't part of level gain or loss (which always trigger
status updating), are all funnelled through a single place (I hope).
