Force trap to activate during failed untrap attempt if done while
already at the trap's location, to match the recent change in
behavior when failed attempt occurs while adjacent to the trap.
Most noticeable while flying over bear traps, but affects all
failed untrap attempts.
Make being trapped in/on/over floor block Levitation and Flying, the
way that being inside solid rock already does, and the way levitating
blocks flight.
Blocked levitation still provides enhanced carrying capacity since
magic is attempting to make the hero's body be bouyant. I think that
that is appropriate but am not completely convinced.
One thing that almost certainly needs fixing is digging a hole when
trapped in the floor or tethered to a buried iron ball, where the
first part of digactualhole() releases the hero from being trapped.
If being released re-enables blocked levitation, the further stages
of digging might not make sense in some circumstances.
I recently realized that being held by a grabbing monster is similar
to being trapped so should also interfere with levitation and flying.
Nothing here attempts to address that.
Save files change, but in a compatible fashion unless trapped at the
time of saving. If someone saves while trapped prior to this patch,
then applies it and restores, the game will behave as if the patch
wasn't in place--until escape from trap is achieved. (Not verified.)
Fix the situation of Flying hero failing to untrap a bear trap that
was resulting in the trap becoming hidden. Previous fix prevented
hero from moving onto the trap's location so that the reason for
hiding it didn't occur. This moves the hero and forces the trap,
so it will become unhidden again before there's any chance to notice
that it had been hidden.
Status 'Flying' conflicts with being trapped at floor level, but that
is a separate, known issue. I'll have to resurrect my unfinished fix
for that sooner rather than later.
Demote #monpolycontrol and #wizdebug_traveldisplay from commands to
simple boolean options. The former has the same name, the latter
is called travel_debug. Rename #wizdebug_bury to #wizbury; it
shouldn't matter that it goes away when compiled without DEBUG.
There are now five wizard-mode boolean options: monpolycontrol,
sanity_check, and wizweight are documented in the Guidebook;
menu_tab_sep and travel_debug are commented out there.
Guidebook.mn has been tested; Guidebook.tex has not.
Iron bars can be destroyed in some circumstances (hit by yellow
dragon breath or thrown potion of acid, being eaten by rust monser
or black pudding, or by poly'd hero in those forms) and should act
like walls for diggable/non-diggable purposes. But they aren't
walls, so the non-diggable flag was not being set for them by the
special level loader. Even once that was changed, they weren't
being handled consistently. Some places checked for non-diggable
directly (zap_over_floor of acid breath, potion of acid hitting bars)
and started working as intended, others used may_dig() to check
non-diggable (poly'd hero attempting to eat iron bars) but it doesn't
handle iron bars, and still others didn't check at all (bars-eating
monster who moved onto bars location in expectation of eating those
next).
If pickup has been bound to some other key than ',', the awful hack
did not work correctly. Testing, I couldn't notice the difference,
but probably just not doing the right thing...
When swapping places with a pet, the hero's coordinates are changed
before some tests which might disallow the swap, and if the pet was
a hidden mimic or was trapped and became untame, the attempt to draw
the revised pet or former pet would actually draw the hero and have
that mistake be visible during the message about not swapping. That
last bit only occurred when the pet couldn't move diagonally (due to
being a grid bug or to being unable to squeeze through a tight space).
Also, spoteffects for arriving at a new location took place even
though the hero hadn't changed position.
Poly'd into a giant with a full inventory that already contains at
least one boulder, moving onto a boulder (that can't be pushed due
to a wall or other obstacle) yielded
You try to move the boulder, but in vain.
However, you can easily pick it up.
You are carrying too much stuff to pick up another boulder.
You see here a boulder.
The second and third statements contradict each other. Make the
code that dishes out the second message smarter. If autopickup is
set for it and you will pick up the boulder:
However, you easily pick it up.
If autopickup is not set for it but would have worked if it was:
However, you could easily pick it up.
If your inventory is full and you have a boulder (or are in Sokoban)
However, you easily push it aside.
That last one is instead of "however, you can squeeze yourself into
a small opening" that you'd get if not a giant and not carrying much.
m_monnam() overrides hallucination, which is appropriate in some
situations but not others. This fixes one instance where it was
being misused: discovering a hidden monster when another monster
attacks it was calling either m_monnam() or a_monnam(); one ignores
hallucination and the other doesn't, so accurate or inaccurate
monster type depended on the condition tested.
Figurine activation and egg hatching are using m_monnam(), which
seems suspect, but I left them as is.
Report was for
You finish taking off your boots.
You float gently to the altar. [destination was a red herring]
[take some action to run through moveloop() for next turn]
Your movements are slowed slightly because of your load.
Having float_down() do the next encumbrance check instead of
waiting for moveloop() to do so was straightforward. However,
while testing I noticed the reverse situation (not due to the fix
for the above) when putting on levitation boots
Your movements are now unencumbered.
You finish your dressing maneuver.
You start to float in the air!
Having float_up() do the encumbrance check isn't adequate to fix
this, because it takes multiple turns to put on boots but the
properties they confer are enabled immediately, so moveloop() runs
while hero is already levitating even though the game hasn't told
the player about it yet. Fix is a hack to defer the effect of
levitation on encumbrance until the boots are fully worn, which
might lead to strangeness somewhere. It's also boot-specific so
will need to be updated if some other multi-turn armor that confers
levitation ever gets added.
Yet another accessibility feature. When asked for a location
to travel, and autodescribe is on, the location description
has "(no travel path)" appended, if there is no known path
to that location.
When underwater and an attempt to move onto adjacent land fails
because the destination is a wall or solid rock or closed door,
report that there's an obstacle instead of just silently failing
to make the move.
If the user has 'mention_walls' option set, give feedback for
failing to move diagonally into or out of a doorway instead of
just silently not moving.
Having 'mention_walls' set could yield "you cannot pass through
the bars" when travel was testing (not moving) for a path past
iron bars, and when it happened it tended to be delivered a whole
bunch of times.
Reported directly to devteam 7-Jan-2016, two issues with cursed
potion of levitation:
1) the go-up-stairs effect for cursed potion still let you choose
not to escape the dungeon if it occurred on level 1 stairs. I've
left that as-is; perhaps there's a gate across the entrance.
2) both the go-up-stairs and bonk-head-on-ceiling effects were
skipped if the hero was already levitating. I don't know whether
that was intentional but there was no comment explaining why, so
I've changed it to happen regardless of whether already levitating.
In the process, I changed the head-bonk case to do more damage when
a helmet is worn:
old: no helmet 1..10 hp, any helmet 1 hp damage;
new: no helmet 1..10 hp, soft hat 1..6 hp, hard helmet 1..3 hp.
Also, not in the report: when you aren't already levitating you
get the "you float up" message, but for cursed potion there was
never any corresponding "you float down" message because you ended
up not levitating. Now you'll levitate for 1 turn and float down
on the next, landing in a trap if one is present.
Triggered by a couple of mis-formatted block comments in spoteffects.
Much of the diff is adding braces to the 'if' portion of things like
if (test)
statement;
else {
block-of-statements;
}
After some permutation of commands which displayed items, the 'd'
command presented a prompt with the list of letters scrambled (in
loot order or pack order rather than invlet order), so explicitly
sort when getobj operates. Done for ggetobj too.
For menustyle:Traditional, ',' followed by 'm' presented a pickup
list in pile order even when sortloot was 'l' or 'f'. That was an
unintentional change during the 'revamp'.
This fixes a bug where hundreds of turns are wasted by the travel system
moving the player back and forth when the player targets an unreachable
space and sight-blocking obstacles occur in certain formations
in-between. The player will only be stopped if they're interrupted
externally, e.g. growing hungry or being hit by a monster. See the
comment in the code for full details.
Based on DynaHack commit 02da53e (Fix travel moving player back and
forth repeatedly) by me.
Test case: Bigroom, full of boulders, with a single
path from travel start to travel end. Boulders (and
doors) are added to the travelstep[xy] arrays multiple
times, and will overflow the arrays.
Original patch via Acehack by Alex Smith
Test case: U-shaped corridor, with a known trap in it.
Before this change, travel would try to move straight at
the target, bumping the wall or walking into a dead-end.
After this, travel will go along the corridor and then stop
right before the trap.
Original patch via AceHack by Alex Smith.
Same sort of stuff as before: some continuation lines with operator
followed by end of line comment (only a few files with those still to
go...), plus tab replaced by spaces in comments, excess parenthesis
removal for return statements, and force function name to be in column
one in function definitions:
type name(args) /* comment */
argtype args;
{
to
/* comment */
type
name(args)
argtype args;
{
I've been spotting those by eye rather than rexexp, so probably missed
some.
Relatively small number of continuation fixes needed for this subset.
Quite a bit of mangling to engrave.c unrelated to continuation lines,
with three or four coding changes.
Replace instances of strings split across lines which rely on C89/C90
implicit concatenation of string literals to splice them together
with single strings that are outdented relative to the code that uses
them. It's uglier but it won't break compile for pre-ANSI compilers.
This covers many files in src/ that only have one or two such split
strings. There are several more files which have three or more. Those
will eventually be '(2 of 2)'.
Noticed along the way: the fake mail message/subject
Report bugs to devteam@nethack.org.
wasn't using its format string of "Report bugs to %s.", so would have
just shown our email address. Doesn't anybody enable fake mail anymore?
I modified that format to enclose the address within angle brackets and
made a similar change for the 'contact' choice of the '?' command.
Reported by the keymasher: "stone at (48,8) is undiggable". Bigroom 4
has a tree at that spot and the whole level is flagged as undiggable.
Undiggable trees were supported on arboreal levels (where their terrain
type is STONE rather than TREE), but not elsewhere. Monster movement
uses IS_ROCK(), which is true for TREEs, but may_dig() uses IS_STWALL(),
which is false for TREEs so doesn't consider the location as being of
interest and fails to disallow digging. But mdig_tunnel() bypasses
may_dig() and tests the NONDIGGABLE bit directly, disallowing digging.
(If this sounds confusing, it's a stroll in the park compared to the
code itself. Apologies for the mixed metaphore.)
Digging away a secret corridor could leave rocks, which doesn't make
a whole lot of sense. Now a monster's dig attempt will reveal the
location as a corridor instead.
This also moves an assignment out of a macro invocation where it was
inviting trouble if that macro gets modified. And reorganizes an 'if'
to put cheaper tests sooner.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
