armorstatus, and terrainstatus
This adds three special status items to show at a glance what the hero
is wielding, wearing, and standing on.
Each of the three items has its own boolean option rather than try to
fix them in with the existing opttional status conditions. After a
lot of testing, I think the weapon and armor ones will prove useful
but the terrain one probably won't be.
Presently it is implemented for tty and curses. When I developed it
six years ago, it was also working for X11 but I'm not able to test
the resurrection of that part so have left it out.
Return a couple of variables that actually held a direction back
to int from coordxy.
bhit() takes int params instead of coordxy.
boomhit() takes int params instead of coordxy.
xytod() renamed to xytodir(), and takes int params (promotion will handle
coordxy params).
dtoxy(coord *, int) renamed to dirtocoord(coord *, int).
dmgval is also used for monster attacks; move the healer knife
bonus to actual hero-specific code, and make sure it only
applies to hand-to-hand combat.
Luck has a massive effect on the to-hit chance; maximum luck alone
(which almost everyone has past the midpoint of the game) gives
10 points to to-hit, so accounts for 50% chance alone, excluding all
other effects.
Multiple variants do something similar to this, so it is well tested.
This version comes from xNetHack by copperwater <aosdict@gmail.com>,
and allows the +1 or -1 luck adjustments of early game, such as full moon,
to have an effect.
This fixes a couple of bugs: a long-standing bug in which writing a
scroll by label could fail even if you've already seen a scroll with
that label (due to the game not tracking whether or not you've seen a
scroll if it doesn't have a name); and a somewhat newer bug in which
spellbooks auto-identified by Wizard knowledge were marked as having
been encountered (rather than as known but not encountered).
Breaks save file compatibility, but not bones files.
It makes sense that a vegetable would do less damage than a hard
object would, as they're generally fairly soft, so it seems like a
likely thing for players to try if they're *intentionally* trying
to hit for zero damage (which could be useful in certain niche
cases, e.g. to wake up a sleeping monster without damaging it).
Isssue reported by Tomsod: hero-as-target section of mhitm_ad_phys()
was not handling hero's Half_physical_damage attribute.
The issue was about cloning a pet from hero who is poly'd into a
pudding but it was more general than that. Half_physical_damage was
ignored for any hit by a monster-wielded weapon against poly'd hero.
It took a while to convince myself that Half_physical_damage wasn't
aleady being applied elsewhere but it doesn't seem to be.
Fixes#1447
Issue reported by Umbire: a gas spore that got swallowed and killed
didn't die but exploded anyway, with the explosion affecting the map
instead of being contained in the swallower.
There was code to handle that but it wasn't being executed. This fix
feels unclean but seems to work.
I couldn't reproduce the survival of the gas spore but since that
isn't wanted I won't worry about it.
Fixes#1434
From "Monsters trapped in pits cannot kick" two weeks ago. Avoid
uhitm.c:5505:9: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
Recent clang wants C23's [[fallthrough]] attribute rather than just
the lint '/*FALLTHRU*/' comment.
Stop attacking if target isn't there anymore. Already handled for
two-weapon in normal form, not for multi-attacks in poly'd form and
for multi-attack monster vs hero or monster vs other monster.
I didn't attempt to reproduce the reported problem. This fix is
based on code inspection.
Also prevent monsters that have hug or engulf attacks from knocking
target back with other attacks since that prohibits the grab/engulf
from being able to hit.
Noticed a strange oversight in knockback: Hero hitting a monster
did not cause knockback, unless polymorphed into a monster.
Add knockback chance if we're using a weapon, not twoweaponing,
and dealing some damage.
Weapons that can do knockback are lucern hammer, bec de corbin,
dwarvish mattock, (silver) mace, morning star, war hammer,
club, quarterstaff, aklys, flail, pick-axe, and grappling hook.
When I reworked amnesia to not forget levels or objects, I removed
the forgetting from the mind flayer attacks. I intended to add
something to replace it, but forgot ...
Grimtooth is now permanently poisoned, protects the wielder from
poison, and can be invoked to throw poison.
Permapoison code comes from xNetHack by copperwater <aosdict@gmail.com>.
Main problem was there was no condition applied to this message, so
anyone would hear it even if they were deaf. Even assuming a cry of pain
is something that could be seen, the message was still printed when the
hero couldn't see the gremlin.
This puts both a deafness check and a range check on that cry (if a
gremlin somehow takes light damage on the other side of the map behind
many walls, it doesn't make much sense to hear its cry), and provides an
alternate message if the hero can't hear it, but can see it. The
alternate message does rely on the hero being able to /see/, not just
spot, the gremlin and the light it's shying away from -- if you can only
sense it, there is no special message.
Previously, the code for monster healing was repeated every time it
was needed; this commit sends it all through a common function, which
will make it easier to make changes to how monster healing works in
the future.
This is just a code reorganisation and won't have any gameplay
effect unless I made a mistake.
The new EXTRA_SANITY_CHECK for a monster mimicking a monster. It
falsely triggered if the hero was hallucinating. Just add an
assertion that the monster index is within valid range.
The report (sent directly to devteam) stated that the bump-into-mimic
code might crash when bumping into a mimic that is masqueraing as
some other monster. Mimics don't actually do that, but the Wizard
of Yendor mimics another monster via Double Trouble. All I got from
it though is
|Wait! That's <other monster>!
which won't crash but is a fairly useless message.
This changes it to be
|Wait! That <other monster> is <the Wizard of Yendor>!
which seems a bit bland but provides useful information.
I couldn't reproduce the reported problem but the backtrace suggests
that defsyms[monst->mappearance] was probably out of bounds so that
nh_snprintf() got bad data. That might conceivably happen if the
glyph didn't match the mimic's mappearance, but I not sure how that
would occur.
This avoids using mappearance as an index into defsyms[] and should
give an impossible if that situation does come up.
Noticed when I summoned a quantum mechanic in wizard mode with a
starting character who should have no armor protection against their
teleport attack, but every touch resulted in "You are not affected". It
turns out the if statement checking for armor protection is backwards,
so you were never affected when you have no protection and were almost
always affected when you had good protection.
This appears to date back to when the all-purpose 'negated' variable was
removed and "You are not affected" moved to after the negation check;
the new conditional kept the ! by mistake.
Issue reported by loggersviii: attempting #untrap from an adjacent
doorway can move the hero diagonally out of the doorway.
A followup comment by elunna pointed out that a monster's attack that
results in knockback can produce similar result.
Fixes#1305
When a mimic in door form is hit by a wand of locking or wand of
opening or corresponding spell, bring it out of concealment like
was recently done for being zapped while in chest form. And give
some feedback rather than just changing the mimic's form to 'm'.
Give more detailed feedback when bumping into a mimic while moving.
gcc has recognized various "magic comments" for white-listing
occurrences of implicit fallthrough in switch statements for
a long time:
The range and shape of "falls through" comments accepted are
contingent upon the level of the warning. (The default level is =3.)
-Wimplicit-fallthrough=0 disables the warning altogether.
-Wimplicit-fallthrough=1 treats any kind of comment as a "falls through" comment.
-Wimplicit-fallthrough=2 essentially accepts any comment that contains something
that matches (case insensitively) "falls?[ \t-]*thr(ough|u)" regular expression.
-Wimplicit-fallthrough=3 case sensitively matches a wide range of regular
expressions, listed in the GCC manual. E.g., all of these are accepted:
/* Falls through. */
/* fall-thru */
/* Else falls through. */
/* FALLTHRU */
/* ... falls through ... */
etc.
-Wimplicit-fallthrough=4 also, case sensitively matches a range of regular
expressions but is much more strict than level =3.
-Wimplicit-fallthrough=5 doesn't recognize any comments.
Plenty of other compilers did not recognize the gcc comment convention,
and up until now the compiler warning for detecting unintended
fallthrough had to be suppressed on other compilers. That's because the code
in NetHack has been relying on the gcc approach, and only the gcc approach.
The C23 standard introduces an attribute [[fallthrough]] for the
functionality, when implicit fallthrough warnings have been enabled.
Several popular compilers already support that, or a very similar attribute
style approach, today, even ahead of their C23 support:
C compiler whitelist approach
--------------------------- -------------------------------------
C23 conforming compilers [[fallthrough]]
clang versions supporting
standards prior to
C23 __attribute__((__fallthrough__))
Microsoft Visual Studio
since VS 2022 17.4.
The warning C5262 controls
whether the implict
fallthrough is detected and
warned about with
/std:clatest. [[fallthrough]]
This adds support to NetHack for the attribute approach by inserting a
macro FALLTHROUGH to the existing cases that require white-listing, so
other compilers can analyze things too.
The definition of the FALLTHROUGH macro is controlled in include/tradstdc.h.
The gcc comment approach has also been left in place at this time.
Issue reported by elunna: sleeping mimics can grab the hero, and
zapping a concealed mimic with a wand of sleep describes the target
as a mimic but doesn't bring it out of concealment.
The grab-when-asleep case is reasonable. It's a reflexive counter-
attack by a magical creature. And the mimic wakes up in the process.
But the mimic wasn't being brought out of concealment. Do that.
Unconceal mimics hit by wand of sleep unless already sleeping.
Fixes#1299
I've been investigating issue #1252 (while the fuzzer was running,
sanity_check complained that hero's current health was greater
than maximum health) off and on for three months and haven't found
the cause.
I've checked all the places that lower maximum HP that I've managed
to find, but not spent much time looking for places that raise
current HP.
These changes might provide some more information. They don't rely
on sanity_check being enabled.
Issue #1252 is still open.
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
