Add a couple of non-zero permonst flags to the terminator at the end
of mons[] in case some code using a pointer to mons[NUMMONS] for "not
a monster" unexpectedly references them.
Also, eliminate some obsolete handling for conditional color support
from monst.c.
Commit 7a533a911c about three weeks
ago reordered a couple of timers. The list of timers in nhlua.c was
overlooked at the time.
The theme room "Ice room" was affected. I'm surprised that sanity
checking while running the fuzzer didn't notice and complain.
Monsters were using escape items when they couldn't move due to
being surrounded by other monsters. This was most evident in
Fort Ludios, where the alarm woke up all the monsters and they
would then read all the teleport scrolls.
Usually this doesn't matter, as special rooms full of monsters
are asleep.
Hardcode this fix for the Ludios only, otherwise you could trap
two monsters next to each other in a boulder fort, and they
would be happy to stay in there...
Pull request from entrez: change erinyes from lame devils named
after the Furies of Greek myth into those Furies.
Bumps EDITLEVEL because of changes to saved data. I augmented the
new data.base entry.
Closes#1150
I don't think this entirely gives the game away, but strongly suggests a
connection between bad deeds and how dangerous erinyes are (especially
combined with the new erinys encyclopedia entry).
When not on Astral, make it a roll based on alignment abuse whether an
erinys is summoned. Also make helm of opposite alignment use contribute
to alignment abuse, so that repeated uses to attempt to clear erinyes
before astral will make them stronger.
This makes sense to me, and further increases the challenge of erinyes
being summoned on astral after donning a helm of opposite alignment (if
the player has abused his alignment to the extent that erinyes have
teleport control), since they wouldn't be able to be banished across the
map simply by breaking a wand of teleport control.
This will increase the potential challenge involved in donning a helm of
opposite alignment on Astral, now that it confuses the hero -- it means
that you must spend at least a turn after putting on the helm clearing
the confusion. Since putting on the helm of opposite alignment may also
summon erinyes, this hopefully turns it from a situation where it's a
no-brainer to immediately ditch them by #offering the Amulet of Yendor
into one where the player must actually stop and think a little bit.
A helmet psychically reaching inside your head and twiddling knobs in
your brain must be a confusing experience. And the instant rejection of
your god (not to mention the vow that you made to find the amulet for
them), perhaps on the very cusp of their ascendance over the other gods,
is sort of the ultimate oathbreaking, so it interests the erinyes.
Consistent with their mythological role of punishing those who had
violated societal taboos -- oathbreakers, hosts who attacked their
guests, etc -- erinyes scale with the cumulative amount of alignment
abuse the hero has committed over the course of the game. This is
tracked separately from the alignment record, and cannot be cleared by
the hero improving her favor with her god via "good deeds" as the normal
alignment record can. Erinyes will gain abilities, levels, and attacks
as the hero's alignment abuse worsens. They will also aggravate
monsters when near the hero.
ACURR(A_STR) can yield a value as high as 125. Switch to acurrstr()-2
for a value of 1..19.
P_SKILL(skilltype) shouldn't be used unconditionally. It yields a
different value for restricted than for unskilled and those two skill
levels only differ for training, not effectiveness.
Allow weaponless forcefight againsta webs. The chance for success may
need to be tweaked.
on toss_up() when checking for touch_petrifies, add
a check for corpsenm >= LOW_PM as EGG can be without
corpse reference.
This prevents:
dothrow.c:1266:29: runtime error: index -1 out of bounds for type 'permonst [384]'
The 'tm' and 'croom' ?: tests introduced to this sprintf() a couple
of days ago will both always yield their else clause because execution
will only get into the block when they're Null (due to
if (!tm && !croom && ...) {}
that isn't visible in the diff's context).
While testing the wall crumbling message TODO yesterday, I saw a
case where the top line of the moat around the invocation area was
truncated even through there were 3 lines of map (on a cavernous
level rather than maze one) above where it cut off. This improves
things although it may not be 100% correct.
Picking the invocation position is unchanged, so there should be no
risk of it now being positioned too close to the map edge. It's
possible that it has been farther away from the edge than necessary
though; if so, it will still be.
When performing the invocation, you would get
|The floor shakes violently under you!
|The walls around you begin to bend and crumble!
even if all the nearby walls had been dug away or the level's maze was
made of lava pools instead of walls. Suppress the second message when
it isn't applicable.
Do isok check apriori to accessing the levl array to filter
out dx/dy that have grown too large.
This fixes:
trap.c:3455:19: runtime error: index 80 out of bounds for type 'rm [80][21]'
The old default allocation of space for 120 doors on a level seems
excessive. Reduce that to 20. Code for expanding the allocation
when needed is already in place.
Pull request from #1193 from mkuoppal was superseded by commits
132d642504 and
3786b2c1d0 so mark it closed.
Closes#1193
Pull request from entrez: add some rumors hinting at being able to
wash hands at a sink and about dropping rings down sinks.
There's already a major oracularity about sinks and rings but nobody
ever buys those. The sink rumor might actually be misleading because
"down the drain" suggests something bad rather than something useful.
Put it in anyway.
Closes#1159
These can hint at some of the changes that make it possible to dip
potions in sinks to potentially get a hint to their identity, and wash
your hands in sinks, pools, and fountains. I also mentioned rings in
the potion/sink rumor since there didn't seem to be a rumor about the
sink ring ID mechanic already (though there may be one in coded language
that my grepping didn't catch). The false rumor about hand-washing felt
to me like a good spot for a Macbeth reference.
Pull request from argrath: "These codes have been commented out
since 3.4.3, at least."
The two "#if 0 /* older method, fixed */" blocks were present in
3.2.0. wall_angle() itself wasn't present yet in 3.1.0 so the "older
method" couldn't have been in use for very long. I examined sources
hosted by nethackwiki.com, which doesn't offer 3.1.1 through 3.1.3.
git log only goes back far enough to include the second cvs repository,
so not far enough. I'm not sure but 3.1.x might not have even used
the first cvs repository.
Go ahead and get rid of this dead code now rather than wait for some
potential future purge.
Closes#1148
Pull request by mkuoppal: some objects which use the corpsenm field
to access the mons[] array can have a corpsenm value of NON_PM (-1)
and weren't avoiding array access in those cases.
In addition to a fixes entry for it, this makes some revisions to the
commited code, handling a few of the cases differently.
Closes#1175
Filter out unset (-1) corpsenm before calling touch_petrifies.
While here, cleanup the oselect by doing excluding loop
and use can_touch_safely for filtering (suggested by entrez).
corpsenm can be -1 (for EGGs and TINs) so touch_petrifies
using this as index would point to bad entry.
Fix this by making mstoning as helper function and bailing
out early if corpsenm <= LOW_PM (while keeping MEDUSA as is)
TIN or EGG can have the corpsenm not assigned into a
proper monster and instead have an value of -1.
Take this into account in assigning the monster (fptr)
pointer to only point into >= LOW_PM monste entries.
Issue reported by Umbire: an engulfing monster capable of passing
through iron bars (vortices and air elemental) could do so while
carrying the hero.
Prevent an engulfer from doing that unless the hero happens to be
polymorphed into a subset of the types of monsters that can move to
iron bar locations.
Fixes#1192
