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.
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.
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().
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
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).
new domove_core() assessment results
potentially smudge engravings
Proceed to wipe engraving after domove_core() now, but only under
all of the following conditions:
- you can reach the floor
- preceding domove_core() move attempt was marked as
having succeeded in domove_core()
- there is actually an engraving there to impact at
your original spot, or your new spot, or both
Since no one has come up with a better fix for has_colors() being
implicitly declared, add a hack for suppressing a compiler complaint
about has_colors() on linux and/or sco unix that use sufficiently old
<curses.h>.
Report was right after release of 3.6.0 but my fix at the time broke
compile when using more recent <curses.h>.
I did much of this quite some time ago, as prequisite for a different
bug report about monsters vs shades, then set it aside. It ended up
being more complicated than I anticipated.
When deciding whether various non-weapon attacks might hit a shade,
hmonas() was not checking for blessed or silver armor that should have
been applicable. It did check boots when kicking, but not gloves or
rings (when no gloves) when touching, or outermost of cloak/suit/shirt
when hugging, or helmet when head-butting. (The last one is actually
moot because nothing with a head-butt attack is able to wear a helm.)
The problem was more general than just whether attacks might hit and
hurt shades. Various undead and/or demons are also affected by blessed
and/or silver attack but weren't for non-weapon attacks by poly'd hero.
At least two unrelated bugs are fixed: a rope golem's AT_HUGS attack
gives feedback about choking but was fully effective against monsters
which fail the can_be_strangled() test. And it was possible to hug a
long worm's tail, rendering the entire worm immobile.
The report also suggested that all artifacts be able to hit shades for
full effect, but by the time shades are encountered everyone has an
artifact so that would nullify a shade's most interesting ability.
TODO: monster against hero and monster against other monster need to
have similar changes.
Both u_on_rndspot() and losedogs() might result in having a monster
and the hero be at the same location. Have wiz_makemap() use the
same fixup for that as goto_level().
Give the enum lists in several header files explicit values. Adding
or removing new entries will be more tedious, but doing that is rare
and being able to grep the headers for numeric values in addition to
names is very useful.
rm.h also has a bunch of tabs replaced with spaces.
Take a first step towards making the mons[] array be readonly.
The only other place that updates it is when changing succubus and
incubus AD_SSEX attacks to AD_SEDU ones and that can be handled
via existing getmattk(), but so far has proven to be trickier than
anticipated.
They're never modified. Minor complication: &zeroobj is used as
a special not-Null-but-not-an-object value in multiple places and
needs to have 'const' removed with a cast in that situation.
The recent attempt to have looking inside a container show shop
prices had multiple problems. Worst one was showing shop prices as
if the hero would be buying for items already owned by the hero.
Item handling inside containers on shop floor was inconsistent: if
shop was selling those items, they would include a price, but if not
selling--either already owned by hero or shopkeeper didn't care about
them--they were only marked "no charge" if hero owned the container.
This is definitely better but I won't be surprised if other obscure
issues crop up. Gold inside containers on shop floor is always owned
by the shop (credit is issued if it was owned by the hero) but is not
described as such.
Fixes#172
Casting teleport-away via ^T used different requirements for energy,
strength, and hunger than casting it via 'Z'. The strength and hunger
requirements were more stringent, the energy one more lenient. When
it rejected a cast attempt due to any of those, it used up the move,
but 'Z' didn't.
When testing my fix, I wanted an easier way than a debugger to control
how ^T interacts with wizard mode, so finally got around to a first
cut at being able to invoke it via wizard mode but not override those
energy/strength/hunger requirements. It uses the 'm' prefix to ask
for a menu. 'm^T' gives four options about how to teleport. (There
are other permutations which aren't handled.)
Also noticed while testing: ^T wouldn't attempt to cast teleport-away
if you didn't know the corresponding spellbook. 'Z' will attempt that
because it is possible to forget a book and still know its spell.
The 'O' handling for bouldersym was updating the display value for
boulder even if the value had been rejected, and if it still had the
default of '\0', the map would end up with <NUL> characters. (When
examined via '//' or ';', those matched dummy monster class #0 and
led to the impossible "Alphabet soup: 'an("")'" that was suppressed
yesterday.)
Attempting to set bouldersym to ^@ or \0 would also be rejected as
duplicating a monster symbol. That is now accepted and used to reset
the boulder symbol to default. However, other control characters are
also accepted--not due to this patch, they already are, and from a
config file in addition to via 'O'--so bouldersym can still disrupt
the map. But that's no different from putting control characters
into a symbol set or setting them from config file via S_foo:^C.
