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!
The previous fix prevents the crash from 'the()' when NO_GLYPH was
used as an index into the defsyms array, but it resulted in giving
feedback of "you attack thin air" regardless of what was at the
target location, reverting to the situation that the buggy code was
attempting to address in the first place. Handle that differently
by removing the unseen monster glyph sooner. Also, the underwater
handling wasn't working as intended.
I blamed Derek's pudding farming patch for introducing the problem,
but all that did was replace the offending line(s) with different
indentation. The older post-3.4.3 patch which produced the problem
was mine. Sorry, Derek.
Changes to be committed:
modified: src/hack.c
modified: src/pager.c
Don't use glyph_to_cmap as an array index into
the defsyms[] array unless it really is a cmap.
Recent situation: glyph_to_cmap will return
NO_GLYPH for the unknown monster glyph 'I', which
is not a valid index for the defsyms[] array.
Any monster with rusting or corrosion attack can eat through
the bars. This includes rust monsters, grey oozes, and black puddings.
Original patch by Malcolm Ryan
