Many damage handling routines were calling mhitm_mgc_atk_negated()
in advance so that the result could be used for u-vs-m and m-vs-u,
and m-vs-m variations of an attack. But the monster versus you case
called hitmsg() to deliver a "<mon> <bites, claws, &c> you" message
after that. When the negation checking routine recently began
issuing messages for some types of damage, they would be delivered
before that hit message when your armor/jewelry negated its damage.
|You avoid harm. [when MC is about to block the shock]
|The grid bug bites. [bite for electric damage]
or
|The fire ant bites. [for physical damage]
|You avoid harm. [when MC is about to block the fire]
|The fire ant bites. [second bite for fire damage]
This fixes the sequencing issue at cost of making the code become
even more complicated. It will probably require further refinement.
Be more consistent with the engulf attack feedback by creatures who
fold themselves around the victim (trapper, lurker above) rather than
swallow or directly engulf.
Replace an instance of a non-literal format string and the warnings
manipulation it needed with a literal one.
While watching a ttyrec, I noticed strange behaviour in
the cursor updates; it was moved to approximately middle
of the map window every so often, usually when doing ranged
attacks. This wasn't really noticeable in normal gameplay,
as it was moving the cursor there, and then almost immediately
to where it was supposed to be.
I managed to trace it down to the refresh() in curses_delay_output().
That call updates the terminal to match the ncurses stdscr window,
but the stdscr window cursor position wasn't updated by NetHack.
Adjust the message given when an attack knocks its target back. Say
|<defender> is knocked backward by <attacker>
if target will actually move or
|<defender> is knocked back by <attacker>
if there's something preventing the move. Most players probably won't
even notice the difference. (Possibly "rocked back" would be better
when not changing location but this hasn't gone that far.)
Also make the knock back distance be 1 step 2/3 of the time or 2 steps
1/3 instead of 50:50 chance for 1 or 2 steps.
I don't know when this behavior started, but a pet who was eating
something while standing on an item could pick that item while busy.
This would be wrong even for pets that didn't need to use their
mouth to do the picking up.
This fix may be overly simplistic. It prevents the pickup-while-
eating misbehavior but could possibly interfere with something else.
I happened to notice when looking at a ttyrec that farlooking
with automatic description would blink the cursor on hero for
one frame, and then back on the farlooked map location.
Some bits made when attempting and failing to figure out the curses
problem (which turned out to be an early return skipping reset of
input timeout and fixed by paxed).
Using #retravel when no destination was set up just silenty finished,
effectively a no-op. Could happen for the first travel attempt on
the current dungeon level, or after most recent #travel successfully
reached and cleared its destination.
Using #retravel when already at previously set but unreached--via
travel--destination, or explicitly picking your own spot as travel
destination using #travel, actually traveled from your current spot
to the same spot. Usually nothing interesting occurred and you got
no feedback. However, if you happened to be stuck in a trap at that
spot you tried to walk out of it and got trap feedback about that.
(Then probably right back into the trap if you succeeded in escaping
it. I didn't try to test that.)
parse_escape_sequence changed getch timeout, but when receiving
a certain escape sequence, it returned without changing the
timeout back. This caused all subsequent getch calls be
non-blocking, and getch returns ERR when there's no input
waiting in that mode.
NetHack interprets ERR as the terminal going away, so performs
an automatic save.
Extend "killed by the touch of death inflicted by <monster>" to buzz().
"Killed by a bolt of cold" becomes "killed by a bolt of cold zapped by
<monster>" or "killed by a blast of cold" becomes "killed by a blast
of cold exhaled by <monster>" and so forth.
More work than expected; the zap code isn't passed enough context.
BZ_M_WAND() was producing the wrong value for wands zapped by monsters.
Doors weren't getting added to the correct subrooms in certain cases.
Also fix one of the themerooms, because doors have to be added
after subrooms; there was a possibility of no door to the subroom(s)
in that themeroom, because the subrooms overwrote the doors in
the parent room.
Test case for the subroom doors:
Large room, with a medium subroom, with a tiny subroom inside that.
The doors go from outermost room <-> tiny innermost room <-> middle room.
des.room({ type = "ordinary", x = 1, y = 1, w = 10, h = 10,
contents = function()
des.room({ type = "ordinary", w = 6, h = 6, x = 2, y = 2,
contents = function()
des.room({ type = "ordinary", w = 2, h = 2, x = 0, y = 0,
contents = function()
des.door({ state="random", wall="south", pos = 1 });
end
});
des.door({ state="random", wall="north", pos = 1 });
end
});
end
});
Before this fix:
ROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:1, subrooms:0
after this fix:
ROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:2, subrooms:0
This is fairly ridiculous but it prevents the bogus complaints
when compiling eat.c with 'gcc -fanalyzer' about some fields in
gc.context.victual being used without having been initialized.
There's bound to be a better way to handle this and I'm curious
whether it will work with the 'onefile' testing.
Issue reported by vultur-cadens: cause of death reason for touch
of death and death due to loss of strength only showed the cause,
not the monster spellcaster who was responsible.
This changes
|Killed by a touch of death.
to
|Killed by the touch of death inflicted by the Wizard of Yendor.
and
|Killed by terminal fraility.
to
|Killed by strength loss inflicted by a chameleon imitating an arch-lich.
(The 'imitating' part doesn't fit on the tombstone but will be present
in logfile/xlogfile.)
Noticed while implemented this: touch of death was modifying u.uhpmax
and basing death vs damage on that even when hero was polymorphed.
It now rehumanizes the hero in that situation.
Closes#994
1. Add "engraved room floor" pchar sym (S_engroom). The symbol that
displays at the engraved part of a room (not a corridor though).
The default symbol is '`' which is currently never shown if people
have defined the boulder symbol to '0' and statues are displayed as
monster symbols. It is bright blue.
Add some stylized variations of the S_engroom symset to some of
the symsets.
2. Add "engraved corridor" pchar sym (S_engrcorr). The symbol that
displays at the engraved part of a corridor. The default symbol is
'#', and it matches the symbol for corridor from for whatever the
current symset uses. It is bright blue to match the color of the
S_engroom symbol. Using the normal corridor symbol for display
preserves the lines of the corridor so is not as visually-disruptive
as a smaller symbol would be. Explicit entries that match the S_corr
symbol have been added to the symset file.
Magic mapping and clairvoyance impacts yet to be determined.
The Guidebook updates will come later.
Pull request from entrez: when the curses interface was deciding
whether ">>" could fit on the bottom line of the message window, it
was off by two (based on the initial report) and ">>" clobbered the
last two characters.
Reported case was "Welcome to level " when that was appended to
another short message. It should have ended with "6. " but that had
been chopped off by ">> ". Reproducible by assigning a long name to
something, dropping an item, dropping the something, and dropping
just enough other stuff so that the named item will be reported on
the bottom message line during pickup-all, forcing --More-- before
continuing to the item below it. The item with the long name needs
to fit in the message window's width (when formatted with invent
letter prefix and trailing period) without being wrapped and not
leaving enough unused space to fix ">> ".
Closes#993
In some scenarios where a message prompted a 'more' (in curses shown as
'>>'), the '>>' could overwrite the last one or two characters of the
message.
This could happen if a single message on its own was the length of the
message space minus 2 (e.g. for an 80 character terminal, "h - a concave
amulet named this is an amulet name, it is very long, and so on."), or
if an addition to an existing line brought it to the length of the
message space minus 1 or 2 (e.g. "You materialize on a different level!
You remember this level as testlevlname."). The two scenarios had
slightly different causes.
I think this fixes both of those scenarios. I believe this is the
cause of the problem described in GitHub issue #990 but there isn't
enough detail to know that for a fact.
I felt it was strange that archeologist started out both
fast and stealthy, but didn't gain searching until level 10.
So, archeologists now start with searching, gain stealth at 5,
and fast at 10.
Similarly valkyries starting out stealthy felt odd, so now they'll
get it at level 3.
This leaves only the rogue starting out innately stealthy, which
feels appropriate.
> With sounds on, using #levelchange to drop more than one level only
> gave the level-loss sound effect once.
Fix the underlying issue within macsound.m by allowing the currently
playing sound to run to its completion prior to starting the next.
This also backs out the acknowledgment --More-- that was added after
the sound issue first materialized and puts it back to the way it was
the past several releases.
