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.
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
- add nhl_pcall_handle() to wrap all nhl_pcall calls that didn't check
return value and either panic() or impossible()
- add --loglua (unix only) to dump Lua memory and steps info to livelog
- remove old logging
- set memory and step limits on all Lua VMs
Issue reported by AmyBSOD: several actions change the object type of
a potion rather than force creation of a replacement one, and if/when
the type was changed to oil, the age wasn't converted from absolute
to relative. Relative age is the amount available and/or the number
of turns it will burn if applied. The later in a game a potion got
converted into oil, the longer it would burn. Not mentioned: reverse
situation was also the case, although that didn't have any noticeable
effect since incorrect absolute age of former oil doesn't matter.
Not thoroughly tested. I got a potion of oil from a horn of plenty
and it burned for 400 turns, but it might have been created directly
rather than be a rejected magic potion that was converted into oil.
Closes#1191
Adds a new boolean option, accessiblemsg. If on, some game messages
are prefixed with direction or location information, for example:
(west): The newt bites!
(northwest): You find a hidden door.
I added the info to the most common messages, but several are
still missing it.
