PatR [Sun, 3 Feb 2019 01:37:06 +0000 (17:37 -0800)]
fix #H7173 / github #101 - vault exit
Fixes #101
If you tell the vault guard your name, drop carried gold, wait one
turn, then pick up the gold again, the guard will move a step away
during the wait. If you teleport away, the guard will seal vault
walls and then park himself on the one-square (so far) temporary
corridor adjacent to the vault wall. Periodically he'll say "Move
along!" and the hero will hear it, regardless of location on the
level. Unless you dig a corridor to rescue him, or one or more of
the vault's walls get breached again, he will never move.
The report emphasized that you could use this to steal the vault's
gold, but it relies on being able to teleport beyond the gaurd's
reach and if you can do that, you might as well do so before the
guard comes. The stranded guard, and him saying "Move along!" when
no longer leading hero out of the vault, are more significant bugs.
Bonus fix: if the game ends and the guard seals up the vault while
the hero is in a spot that gets fixed up (vault wall or temporary
corridor) don't give the "You are encased in the rock" message if
game end was due to death rather than quit.
PatR [Sat, 2 Feb 2019 02:40:45 +0000 (18:40 -0800)]
object classes for wizard mode identify
When ^I was changed to allow picking more than one item to make
its temporary identification become persistent, group accelators got
left out. So to pick all potions, you needed to select them letter
by letter (or via '.' to select everything, then deselect non-potions
letter by letter). Now you can use '!' to select all potions.
PatR [Sat, 2 Feb 2019 02:24:23 +0000 (18:24 -0800)]
curing deafness
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.
Pasi Kallinen [Fri, 1 Feb 2019 16:19:00 +0000 (18:19 +0200)]
Fix making fake leash object with leashmon set
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.
PatR [Thu, 31 Jan 2019 23:50:12 +0000 (15:50 -0800)]
stale lock picking context
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.
PatR [Thu, 31 Jan 2019 12:22:04 +0000 (04:22 -0800)]
fix monstone() ... dealloc_obj() panic
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.
nhmall [Wed, 30 Jan 2019 01:29:56 +0000 (20:29 -0500)]
fix build
../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);
PatR [Tue, 29 Jan 2019 23:27:22 +0000 (15:27 -0800)]
last warning fix
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.
PatR [Tue, 29 Jan 2019 23:00:07 +0000 (15:00 -0800)]
warning fix
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.
nhmall [Tue, 29 Jan 2019 22:07:00 +0000 (17:07 -0500)]
try fix for Qt4 using a core macro
../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);
^
Alex Smith [Tue, 29 Jan 2019 03:37:08 +0000 (03:37 +0000)]
Consistently use rn2 in trap detection
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.
nhmall [Tue, 29 Jan 2019 00:43:55 +0000 (19:43 -0500)]
merge Alex's dual rng proposal with the isaac64 rng code and adjust
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().
PatR [Mon, 28 Jan 2019 17:10:52 +0000 (09:10 -0800)]
fix #H8072 - failing wish segfaults
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'.
nhmall [Tue, 15 Jan 2019 01:36:50 +0000 (20:36 -0500)]
define Rand() in isaac4 config
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.
Patric Mueller [Sat, 12 Jan 2019 20:36:08 +0000 (21:36 +0100)]
add file for the isaac64 random number generator
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
Patric Mueller [Fri, 11 Jan 2019 18:23:01 +0000 (19:23 +0100)]
reseed during level change to prevent deduction of rng state
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.
Alex Smith [Mon, 28 Jan 2019 04:45:26 +0000 (04:45 +0000)]
Don't advance the main RNG during hallucination
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).
PatR [Sun, 27 Jan 2019 23:28:31 +0000 (15:28 -0800)]
Wine Cellar tweak
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.
nhmall [Sun, 27 Jan 2019 16:55:23 +0000 (11:55 -0500)]
domove_core() out of domove(); assess domove_core() results
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
PatR [Thu, 24 Jan 2019 23:25:50 +0000 (15:25 -0800)]
band-aid for #H4041 - build warning: has_colors()
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>.
PatR [Wed, 23 Jan 2019 02:15:49 +0000 (18:15 -0800)]
fix #H6422 - hmonas against shades
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.
PatR [Tue, 22 Jan 2019 02:54:37 +0000 (18:54 -0800)]
shielding bashing
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).
PatR [Tue, 22 Jan 2019 02:49:44 +0000 (18:49 -0800)]
hmonas() simulated twoweap
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.
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.
PatR [Fri, 18 Jan 2019 21:22:43 +0000 (13:22 -0800)]
fix #H7980 - multiple weapon attacks when poly'd
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.]
PatR [Wed, 16 Jan 2019 23:08:11 +0000 (15:08 -0800)]
fix #H6285 - flooreffects and deltrap panic
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.
PatR [Tue, 15 Jan 2019 02:13:59 +0000 (18:13 -0800)]
potion mixing bit
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.
PatR [Tue, 15 Jan 2019 00:35:19 +0000 (16:35 -0800)]
level arrival
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.
PatR [Mon, 14 Jan 2019 17:28:10 +0000 (09:28 -0800)]
\#wizmakemap followup
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().
PatR [Sun, 13 Jan 2019 23:24:08 +0000 (15:24 -0800)]
\#wizmakemap update
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.
PatR [Sun, 13 Jan 2019 23:17:40 +0000 (15:17 -0800)]
blocking or unblocking levitation or flight
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.