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.
- Add a vision sanity checking routine
- Recalc block point when digging a door for temporary clouds
- Add recalc_block_point after cvt_sdoor_to_door, because doorways
on the Rogue level have no doors, and otherwise the sanity checking
would complain. This doesn't actually change how the Rogue level
vision works, as it uses a different vision system
- Monster using a trap in a secret corridor revealed the corridor,
but didn't unblock the vision unless you saw the location
Issue reported by elunna: the message given when zap_over_floor()
hits iron bars with lightning or acid was substituting a couple of
words or phrases in the wrong order, resulting in
|The {melt|dissolve} iron bars somewhat but remain intact.
when the iron bar location is flagged as non-diggable. It should be
|The iron bars {melt|dissolve} somewhat but remain intact.
Not mentioned: the corresponding message for locations that aren't
flagged as non-diggable used "melt" unconditionally. Change it to
keep "melt" for lightning but switch to "corrode away" for acid.
Fixes#1342
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
This is additional groundwork related to
https://github.com/NetHack/NetHack/issues/1320
This additional groundwork just puts some safeguards
in place to make it rather tough to end up with an
instant death from handling a cockatrice corpse in
your inventory without appropriate protection.
At this point, still no actual petrification will occur.
Wishing is powerful, so if you cannot safely handle a cockatrice
corpse, then have a wish for one result in the corpse materializing
on the floor rather than in your inventory.
Resolves#1320
GitHub issue #1315 points out that it is possible for
a downstream function to change an object's nobj field
to point to a completely different chain.
The cited example by @vultur-cadens was:
for (obj = gi.invent; obj; obj = obj->nobj)
if (obj->oclass != COIN_CLASS && !obj->cursed && !rn2(5)) {
curse(obj);
++buc_changed;
}
curse() drops the weapon with drop_uswapwep(),
which calls dropx(),
which calls dropy(),
which calls dropz(),
which calls place_object().
place_object alters the nobj pointer, to point to the floor chain:
otmp->nobj = fobj;
fobj = otmp;
The result was that the next loop iteration was then using floor
objects from the floor chain.
This alters several for-loops to use a more consistent approach,
particularly when the obj is being handed off to a function,
where a downstream function might, or might not, alter the nobj
field.
References:
https://github.com/NetHack/NetHack/issues/1315https://www.reddit.com/r/nethack/comments/1gkc9ub/even_if_you_drop_an_item_before_drinking_from_the/
A poison gas breath attack that hits a wall would leave a 1x1 gas
cloud region at that wall spot.
Not always noticeable due to other spots along the zap path leaving
regions that blocked vision.
Since wand of secret door detection now gives feedback even when it
fails to find anything, always discover it.
Some of the other zapnodir() wands had suspect discoveries.
Noticed when testing boulder pushing into/out of shops yesterday:
a shopkeeper can "mutter incantations" and fracture a boulder in the
shop, transforming it to rocks. If hero owed shk for the boulder
(happens when it has been further inside the shop and then gets pushed
to the shop's free spot), it would disappear from the shop's bill and
hero would then owe for the resulting rocks (which cost more than the
boulder!). That seemed confusing, especially since neither Iu nor Ix
would show the rocks (which are on the floor rather than in invent;
the $ command reported the amount owed, but not what the item was).
When such fracturing happens move the boulder from the unpaid section
of the shop bill to the used-up section before creating the rocks,
which are no longer interesting.
Testing the shopkeeper speed change, I noticed that zapping the shk
with speed monster made her angry. Since being hasted is beneficial
for the target, don't become angry.
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
Have magic mapping add special rooms to known overview data. Only
affects shops and temples because they're the only rooms tracked.
Most other special rooms revert to normal rooms as soon as they're
entered so there wasn't any point in tracking them. That might no
longer be the case.
Wand of probing zapped at or through a shop door or even at a shop
wall will add the shop annotation to the overview data. That works
differently for normal shops than for subrooms in the twin business
theme rooms. I'm not sure whether any fixing is needed there since
the shop type information gets suppressed as soon as more than one
shop becomes known on a level.
A monster zapped a wand of striking, hitting a burning potion
of oil, which destroyed items in the same square, and the ray was
checking destroyed item. Similar thing with a ray done by hero.
The code currently stops checking the objects in the location
if a next object in the chain was destroyed - an improvement
would be to gather all the objects into an array and iterate
over that instead of relying on the nexthere pointer.
Make object deletion work similarly to monster deletion:
it's marked for deletion (by setting the where-field to OBJ_DELETED
and moved to specific deleted-objects chain), but they're actually
freed at the beginning of turn.
This may need some more tweaking, especially in places that iterate
over object chains, but fuzzing did not find any obvious problems.
Fix a case of accessing freed memory: a monster breathed at hero,
destroying some items. The code stored the next item in the chain
(a cloak), but a ring of levitation was destroyed, causing hero to
plop down into lava, destroying the cloak. The item destruction
code then tried to access the destroyed cloak object.
Make the code check the object where-field - which will be different
if the object was marked for deletion. Also removed an extra loop
going through the whole object chain looking for the items to
destroy.
I still haven't found any explanation for the report by a hardfought
player recently that going down some stairs with a pair of leashed
pets got one into a confused state where it was flagged as leashed
but the corresponding leash was no longer in use.
This adds some new object and monster sanity checks regarding leashes,
and it changes o_unleash(obj) to clear obj->leashmon even if/when the
monster can't be found.
It also changes behavior for dipping an attached leash into a potion
of polymorph when that happens to yield another leash--now the new
one will end up being pre-attached.
underneath gets boiled away
Pull request by disperse: when a water walking hero zaps a wand of
fire downward and it boils away the water, hero should fall into the
resulting pit.
The PR commit didn't handle monsters (who don't zap wands downward
but could be on/in water that's boiled out from under them). And
while testing it I noticed that the existing code had message
sequencing issues (being enveloped in a cloud of steam before seeing
the water evaporate). This ended up redoing the fix rather than
using the commit.
Fixes#1238
Give a resistance animation if you #invoke Sunsword while it's
wielded and direct its blinding ray at yourself. Flashing a camera
at a monster who is wielding it will also produce the animation.
When a camera flash hit a mimic which was posing as something, the
feedback mentioned the mimic but didn't bring it out of hiding.
Change to make light pass over a mimic impersonating an object but
unhide one impersonating furniture. Ones impersonating some other
monster are woken up but wakeup doesn't force it back to mimic shape.
Trying to get the messages right brought on more code changes than
antipated. I changed one of the arguments to mhidden_description()
so had to change its callers; fortunately there aren't very many.
Support aiming at self (to become blinded) and aiming up/down (to
light the hero's current map spot only, persistently rather than
temporarily). Also, recognize cancel at the "direction?" prompt to
not leave the #invoke cooldown count set when aborted.
Aiming at self was a little trickier than expected to test because
you're blindness-resistant when wielding Sunsword. But it doesn't
have to be wielded to be invoked.
Pull request by elunna with assistance by entrez tried to fix up
wand of striking discovery when the wand is zapped by a monster.
The fix didn't match the intended behavior (which may or may not be
the desired behavior...), so this skips the code in the pull request.
[I can't post comments on github anymore since I declined to switch
to their 2-factor authentication. But I can still read submissions
without logging in.]
This also tries to fix a couple of inconsistencies between zapping
by the hero versus by a monster. If the zap "boinged" :-) due to
target's magic resistance, zap by hero didn't discover the wand but
zap by monster did. Conversely, a zap by the hero that reached a
target and missed did discover it but one by a monster did not.
Now a zap of not-yet-discovered wand of striking by the hero which
hits, whether or not the hit gets resisted, will become discovered
provided that the spot where target is hit can be seen (the target
itself need not be), and one which misses or which can't be seen
hitting something will no longer be.
Supersedes #1223Closes#1223
Recharge only handles items carried by hero.
I don't think it really matters that we just skip it, but leave
a FIXME in the code if anyone has enough energy to improve this later.
Fallout from the unified item destruction.
Note: Original change is from xNetHack by copperwater <aosdict@gmail.com>,
but this commit comes from HACKEM-MUCHE by Erik Lunna, with
some minor code formatting.
From xNetHack commit a0a6103bea:
'The original goal: nerf item destruction using a method I initially
proposed for SpliceHack, in which the number of items subject to
damage from any single source is limited by the amount of damage the
effect caused. The intent was to be more fair all around and prevent
aggravating situations where, for instance, a chest shock trap zaps
you for 4 damage and immediately ten of your rings and wands blow up.
Problem 1: no easy way to limit the items destroyed without biasing
heavily towards the start of the invent chain. The old code was able
to get away without bias by just indiscriminately destroying
everything eligible with a 1/3 chance. Here, I had to introduce
reservoir sampling in a somewhat more complex form than I've applied
it elsewhere, since there are a pool of potential items.
Problem 2: destroy_item no longer worked remotely like destroy_mitem,
which still destroyed 1/3 of items indiscriminately. Commence the
process of squishing them into one function that handles both the
player and monsters. (Which required making a lot of adjustments to
destroy_one_item, now named maybe_destroy_item, on nits such as
messaging and when to negate damage. An annoying consequence of the
merge is that in the player case, their HP is deducted and they can
be killed directly, but for monsters they need to add up the
destruction damage and return it.)
Unifying destroy_item and destroy_mitem has some advantages: in
addition to the obvious code duplication removal, it ensures monsters
now take the same damage as players for destruction (previously they
took a piddly 1 damage per destroyed item). Now when you hit
something with Mjollnir and their coveted wand of death breaks apart
and explodes, you at least get the satisfaction of knowing they took
the standard amount of damage from it. Monsters also now get
symmetry with players in having extrinsic elemental resistance
protect them from item destruction, and damage negation from item
destruction if they were appropriately resistant.
Problem 3: a lot of callers didn't preserve the "amount of incoming
damage" that this refactor relies on. E.g. if the defender resisted
that element, the local dmg variable would be set to 0. So I had to
do some wrangling with callers to save that original damage
value. The rule of thumb is: all *incoming* damage counts. So that
includes the player's spellcasting bonus if applicable, but not
things like half damage, negation due to resistance, or extra damage
due to being vulnerable to cold/fire.
Then I figured, while I'm here let's get rid of all those silly cases
where destroy_items is called multiple times for various different
object classes, and cut the object class parameter out of it. This
has a few minor effects:
- Places where different object classes previously rolled
independently for destruction to happen at all now roll
once. (Which, by my calculation, generally means less incidences of
destruction - a fire attack now won't have three separate chances
to hit your scrolls, potions, and spellbooks. On the flip side, a
lucky roll will no longer save an entire object class in your
inventory.)
- Callers can no longer specify different probabilities for
destroying different object classes. The only place this was really
used was to call destroy_item with a slightly lower probability on
SPBOOK_CLASS. With the nerf in this commit, less of them ought to
be destroyed anyway.
- A very edge case of where explosion-vs-monster damage was totted up
differently for golems, which could result in differences of a hit
point here or there.
- All object classes being processed in one go means that less items
are destroyed than would be if they were still processed
independently. This is not really visible compared to the old
baseline of just destroying 33% of everything, but would be a
marked difference versus a copy of the game that still called
destroy_items separately for different object classes. To
compensate, I adjusted my planned damage-to-destruction-limit
scaling factor down from 8 to 5.
Not done: merging in ignite_items(), though that would probably be
really easy now.'
Notes from porting from xNetHack:
- It might be necessary to reexamine at all the conditional checks for
calling destroy_items. Because item destruction is much more
restrained and uses the actual damage from an effect, we might now
need to check 'if (!rn2(3))' and similar in all the places item
destruction occurs.
Reported by elunna: a poison gas breath attack that was reflected
by the target still left that target enveloped in a poison gas cloud.
This makes the gas trail not extend to the target if the attack hits
and is reflected. But if the attack misses then the cloud does reach
the target, which seems weird to me. However, being in the cloud is
a separate event that isn't deterred by reflection.
Closes#1204
Update some potential weight issues. Eggs won't hatch when in
containers so they weren't affected but add some bulletproofing.
Corpse revival from inside containers was already ok too, so
effectively there's no change except for making container_weight() be
global instead of local to mkobj.c.
Have monster spells
| "shower of missiles" (AT_MAGC+AD_MAGM: Angels, Yeenoghu)
scuff an engraving at the hero's spot if there is one,
| "frost" (AT_MAGC+AD_COLD: only Asmodeus)
freeze water and lava terrain,
| "flames" (AT_MAGC+AD_FIRE: moot, no monster has this attack)
burn items on the floor at the hero's spot and melt ice terrain,
| "pillar of flame" (AT_MAGC+AD_CLRC+randomly chosen clerical spell)
which already burns floor items, melt ice too, and
| "lightning" (same casters as pillar of flame)
give a tiny chance of destroying iron bars. The chance to hit bars
is low and the hero has to be targeted while located on an iron bars
spot so probably won't happen before the sun burns out, but only
needed one extra line of code.
Only the first two have been thoroughly tested.
