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().
User-contributed fix; bypassed the contact form so no #Hnnnn number.
On the Gnome King's Wine Cellar version of Mines' End, a couple of
wall stubs in the lower far right were diggable, unlike all other
walls on the level. One single-spot wall stub was leftmost of three
undiggable spots, wall+floor+stone. The floor spot wasn't noticeably
different from normal (not sure whether digging a pit was prohibited)
but the stone one was.
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.
Extracted from a larger patch: the only way to get silver damage
bonus from attacking with a shield of reflection (polished silver
shield) is to throw it or to wield it. Give different feedback when
hitting something while wielding a shield (or an iron ball; it seemed
appropriate despite having nothing to due with wanting to dish out
silver damage).
Regular two-weapon requires that both weapons actually be weapons or
at least weapon-tools. Simulation of that while polymorphed allowed
any one-handed object as the primary weapon.
If the message history contains a zero-length message line, skip it,
as trying to write a zero-length string will make bwrite panic.
Happened only on X11. This is post-3.6.1 bug.
Items on floor in the free spot one step inside a shop's doorway were
showing shop sell prices. Treat items on that spot as if they were
flagged no_charge as on the floor of other shop squares.
Report stated that sometimes they showed a 'for sale' price and
sometimes they didn't, but I didn't see any cases where they didn't.
This fixes the weapon related aspects of #H7980: having an alternate
weapon be used in cases where it shouldn't when polymorphed into a
monster form with multiple weapon attacks. The most egregious was
using an off-hand artifact, but it would also use off-hand two-handed
weapon, off-hand silver weapon when in silver-hating form, or any
reasonable off-hand weapon when wearing a shield. That last is iffy
whether or not to allow, since you'll still get the extra attacks
whether it switches to secondary weapon or stays with the primary.
I've made it re-use the primary since two-weapon mode doesn't allow
a shield. The other oddity was being able to use the secondary
weapon on the second swing even if the first swing was weaponless.
I went with ingoring the secondary weapon if there's no primary one
or if the primary is two-handed.
Report included "cursed secondary doesn't weld" but that has nothing
to do with polymorph attacking. I've changed that to drop the weapon
if you attack with it when it's cursed, similar to what happens when
secondary weapon becomes cursed while two-weaponing.
It also included "marilith's attacks beyond the second don't use any
weapon and can hit cockatrices without touching them". A marilith has
two weapon attacks and then four claw attacks. Claw attacks only use
the weapon if it hasn't been used yet, so marilith hits with primary,
secondary (or primary a second time if no secondary), claw, claw,
claw, claw and that's the intended behavior. It is able to hit
cockatrices if wielding anything at all, same as a monster with just
a single attack. Since it is impossible to wield six weapons or three
pairs of gloves, that has to be intended behavior too. Playability
trumps realism even if it is silly to hit without a 3rd through 6th
weapon and be safe from touching the target due to the 1st weapon or
one pair of gloves. [Situation is different from having no control
over unsafely biting something after making a safe weapon or claw
attack; perhaps a better solution would be to refrain from using the
four claw attacks when attacking something that is fatal to touch.]
Reported 14 months ago, a monster reading a scroll of earth which
dropped a boulder that killed another monster in an adjacent pit
was giving credit/blame to the hero and could also trigger a panic.
If the monster was killed, the pit would be filled and deleted via
m_detach and then when flooreffects tried to delete the same trap,
it accessed freed memory and deltrap could panic.
Noticed when looking at whether alchemy ought to remove user-assigned
name. Get rid of the potion being dipped into sooner so that it won't
still be present if a perm_invent update takes place.
The check I added to make sure that a monster was at the hero's
coordinates before deciding to move one or the other would have been
confused by a long worm's tail. Check that they're at that spot but
not by comparing monst.<mx,my> coordinates with <ux,uy>.
Also, don't have wiz_makemap() assume that each level of the Wizard's
Tower has the same boundary coordinates. Keep track of whether hero
is inside that tower before discarding the old level.
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().
The need for resetting lock picking when swapping in a new level made
me wonder whether other things should be reset too, and there were a
bunch: digging, travel destination, polearm target, being in water,
being swallowed or held, hiding. Hero placement was ignoring arrival
region. Also, it turned out to be pretty easy to fix the FIXME about
steed.
when level teleporting or digging. Level teleporting while levitation
was blocked due to being inside solid rock didn't notice that it should
be unblocked until you moved from whatever type of terrain you landed
on (room, for instance) to some other type (such as corridor). Digging
down to make a pit or hole while inside solid rock converts that spot
to floor so should also check whether to unblock levitation/flying, and
not fall if unblocking occurs.
Redo the Ft.Ludios entry hack to suppress the lit walls on the left
and top rather than to light the upper-right corner. Only noticeable
if carrying a lit candle. Usually, that is. This simpler hack could
be detected visually from the treasure room side of the walls involved
but normally won't be.
The entry chamber for the Fort Ludios level would be completely lit
except for one corner wall if you arrived carrying a lit candle. The
unlit spot turns out to be correct, it is beyond candle radius, but
spots further away than that were showing up lit. That's due to them
bordering a lit region on the opposite side and lit regions seem to
be bigger than their specified dimensions.
I tried to make the lit walls be unlit but it wasn't working. (Making
the lit region be smaller would probably work but might have unintended
consequences when populating the zoo room. I didn't try that.) This
makes the unlit corner show up if light hits the spot next to it, so
that it behaves like the other lit walls surrounding that entry area.
I haven't marked the bug report closed because I don't think this is
the proper way to fix this.
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.
melt_ice can delete the fire trap, in the case where the trap
is on ice, and a monster carrying a boulder triggers it, then drowns.
mintrap -> minliquid -> mondead -> ... -> mdrop_obj ->
flooreffects -> boulder_hits_pool -> delfloortrap
When SEDUCE is disabled, instead of swapping attacks in mons[] once,
do it on the fly in getmattk() whenever needed. That allows mons[]
to become readonly, although this doesn't declare it 'const' because
doing so will require a zillion 'struct permonst *' updates to match.
This seemed trickier than it should be, but that turned out to be
because the old behavior was broken. Setting SEDUCE=0 in sysconf or
user's own configuration file resulted in all succubus and incubus
attacks being described as monster smiles engagingly or seductively
rather than hitting (while dishing out physical damage). I didn't
try rebuilding 3.4.3 to see whether this was already broken before
being migrated to SYSCF.
A hero run by the fuzzer that has characteristics plummet to 3 and
then sometimes hang around there instead of being recovered by restore
ability is happening because loss that tries to reduce the base value
below 3 lowers the max (peak) value instead, and once that also gets
down to 3, restore ability is no longer able to do anything with it.
This changes an attempt to reduce a characteristic by N points below 3
to reduce it by rn2(N + 1) instead. That's N/2 on average and a 50%
chance to be 0 when N is 1, so the peak value reached doesn't plummet
to 3 quite to quickly. It can still drop to that though.
There is a pull request dealing with simplifying attribute handling
and part of it affects the code being changed here, but the bit of
simplification included in this patch doesn't use it.
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.
Some phrase substitution in getpos() or its helpers produced
``Pick a target interesting thing in view for travel''
for 'm _', which sounds pretty awkward. Change that to be
``Pick an interesting thing in view for travel destination''
leaving "target" implied.
For plain '_', typing '!' yielded
``Using a menu to show possible targets.''
but then nothing happened. Change that to be
``Using a menu to show possible targets for 'm|M', 'o|O', 'd|D',
and 'x|X'.''
to explain when a menu will actually appear.
'struct obj' contains a union of mutually exclusive pointers, but
removing an obj from a list wasn't clearing whichever one had been
in use. If something is removed from a monster's inventory, clear
the object's pointer back to that monster; if something is removed
from a container, clear the object's pointer back to that container;
and whenever something is removed from the floor, clear the pointer
to the object which followed it at that floor location.
