Make healing magic which cures blindness also cure deafness. So,
drinking non-cursed potion of healing or any extra healing or full
healing; breathing fumes from blessed potion of healing or non-cursed
potion of extra healing or any potion of full healing; prayer reward
to cure blindness as a minor trouble. (Doesn't affect unicorn horns
which already treat deafness and blindness as two distinct troubles
that are eligible to be cured.)
More of a missing feature than a bug fix, so I listed it in the new
features section of the fixes file.
When farlooking at a leash glyph on a map, the fake object should never
have leashmon set. This happened when a mimic was on the same spot
and was mimicing a corpse or statue, due to leashmon and corpsenm
using the same field.
Lock context wasn't being cleared if it was for a container and that
container got destroyed. Case discovered was forcelock() ->
breakchestlock() -> delobj() (sometimes the container is destroyed
rather than just breaking its lock) followed by #wizmakemap (replace
current level) and maybe_reset_pick() trying to check whether
xlock.box was being carried. But being interrupted, destroying the
container or dropping it down a hole to ship it to another level, then
attempting to resume picking the lock would also find a stale pointer.
Fuzzer feebdack. When turning a monster into a statue, monstone()
builds a linked list of mon->minvent items to put into that statue.
It doesn't use obj_extract_self() to take them off again, leaving
obj->nobj non-Null. Not noticed for the normal case where each item
gets linked into the container's contents, but triggers panic if an
item merges with something already put inside so gets removed.
Suddenly, the dungeon collapses.
dealloc_obj with nobj
[2] 0x01000c4193 panic + 995
[3] 0x0100155427 dealloc_obj + 71
[4] 0x010021d4de obfree + 686
[5] 0x01000f2f92 merged + 834
[6] 0x010015356e add_to_container + 126
[7] 0x01001628ac monstone + 636
I don't know why the petrified monster's mergeable inventory wasn't
already merged while in inventory.
../sys/unix/unixmain.c: In function ‘sys_random_seed’:
../sys/unix/unixmain.c:779:29: error: expected expression before ‘long’
fread(&seed, sizeof long, 1, fptr);
Compiler gave four diagnostics about 'seed' being used uninitialized
if 'no_seed' were false, but two of those were alternate suggestions
for how to suppress them.
The new code provoked several warnings; this fixes one of them.
Moving the declaration of 'rolecount' would have been sufficient,
but I've gone another way.
../win/Qt4/qt4inv.cpp:41:26: error: macro "obj_to_glyph" requires 2 arguments, but only 1 given
glyph=obj_to_glyph(nhobj);
^
../win/Qt4/qt4inv.cpp: In member function ‘void nethack_qt4::NetHackQtInvUsageWindow::drawWorn(QPainter&, obj*, int, int, bool)’:
../win/Qt4/qt4inv.cpp:41:8: error: ‘obj_to_glyph’ was not declared in this scope
glyph=obj_to_glyph(nhobj);
^
Allow sys/share/random.c to be included in the build
always, even if USE_ISAAC64 is defined, by making most
of its contents conditional in that case.
That avoids Makefile tinkering when going back and
forth between USE_ISAAC64 and not during testing.
GCC doesn't set __STDC_VERSION__ for older versions. It is verified to
be set by default on 5.3.0.
Older versions set __INT64_MAX__ though (oldest version tested is
4.5.4).
If compilation with older GCC versions is required, set -std=c99. Even
3.4.6 is supported with this setting.
It's a gameplay-affecting action (it updates the character's
memory of the map), and there's no way to spam it without using
resources, so rn2 is safe.
This is branched from Alex's hallu-rng-stability branch,
with two build corrections (detect.c, zap.c), and merged
with the isaac64 branch that we have ready to go.
Alex's dual rng is supported by setting up the array
of multiple isaac64 contexts.
I stuck with Alex's approach of passing the rng function
name around as the parameter (rng or rn2_on_display_rng)
for the new additional parameter needed for
set_random(), init_random(), reseed_random(),
and init_isaac64().
Having an artifact wish be refused uses zeroobj and code which
followed was attempting to update its weight, triggering a segfault
now that zeroobj is 'const'.
Rand() was typically defined to random() or to rand().
gcc seems to provide a random() to link to on linux
when sys/share/random.c is linked in, but other platforms
such as Windows got an undefined refence to random()
when RANDOM wasn't defined.
The only direct use seems to be in get_rnd_txt() these
days, in rumors.c
Under the USE_ISAAC64 config, neither srandom()
nor srand() are being invoked to seed those routines,
and it really should be using isaac64 when USE_ISAAC64
is defined anyway.
move some system-specific seed-related stuff from hacklib.c to
a system-specific source file and #define SYS_RANDOM_SEED to
utilize it during build.
Windows changes for random seed generation using
crypto next gen (CNG) api routines.
Corresponding vms changes due to disentangling of VMS and
unix when the unix seed bits got moved (untested).
This is the version from the Comprehensive C Archive Network, licensed
under the CC0 "No Rights Reserved" Creative Common License.
http://ccodearchive.net/info/isaac.html
For platforms that read from the system's random number generator,
reseed during level change, before the map of a new level is created and
after level creation has finished.
Linux and BSD system have random number source devices that can be used
as source for a unguessable seed source.
Other platforms fall back to generate the seed with gettime().
This is based on the multiple-RNGs code fron NetHack4, but using
only the parts relevant to the display RNG (and with substantial
changes, both because of post-3.4.3 changes, and because Nethack4's
display code is based on Slash'EM's rather than NetHack's).
