Using 'f', if hero is wielding a polearm, and a monster is in range,
don't switch away even if we do have ammo in quiver and a launcher
in the inventory.
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.
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
The prolog comment for hurtle() ends with
* dx and dy should be the direction of the hurtle, not of the original
* kick or throw and be only.
The clause "and be only" is incomplete and was added sometime between
3.3.0 and 3.4.0.
I suspect it was meant to say "and be only -1 or 0 or +1" but the code
enforces that with sgn(dx) and sgn(dy) so if that's the case, it isn't
necessary. Whether that guess is right or wrong, remove the clause
since as it stands now, it makes no sense.
on toss_up() when checking for touch_petrifies, add
a check for corpsenm >= LOW_PM as EGG can be without
corpse reference.
This prevents:
dothrow.c:1266:29: runtime error: index -1 out of bounds for type 'permonst [384]'
Checking the callers:
toss_up() would have segfaulted prior to use of stone_missile() if obj were NULL.
thitu() now has a guard prior to use of stone_missile()
ohitmon() would have crashed from earlier dereference otmp->dknown if it were NULL,
otmp arg is declared nonnull
thitm() now has a guard prior to use of stone_missile().
hmon_hitmon_do_hit() null obj takes a different code path than the code path
using stone_missile(); comment asserting that added
Add pickup_stolen option to autopick items stolen from you by a nymph or
monkey, even if they don't match your normal autopickup settings.
Replace was_dropped, was_thrown with a 2-bit bitfield that can contain
values LOST_DROPPED, LOST_THROWN, and LOST_STOLEN (or 0), since they
should all be mutually exclusive anyway as they track the most recent
way the item left the hero's inventory.
[Rebase/merge conflict fixed up. PR]
The same checks were being repeated for every damage type; this
sends them through two centralised functions (one for checking
whether an extrinsic blocks a specific instance of item destruction
and one for the enlightenment message), so that new mechanisms of
item destruction prevention will need to change only one point in
the code.
There is a comment above the function indicating that it should be
aligned with hero ammo breakage, but this wasn't the case. One big
difference is that any monster-thrown or -shot object would be deleted
unconditionally if it hit another monster trapped in a pit. I don't
know why that was in there, but it's not present in hero ammo breakage
chances, and it meant that a monster could sling the Mines luckstone at
the hero, hit a monster in the pit, and permanently lock the hero out of
getting the luckstone (as just happened to a player during the current
tournament). This pulls the hero breakage rules out into their own
function and uses that for monster breakage as well, to make sure they
are aligned. I also refactored drop_throw a bit to reduce the number of
separate variables tracking whether the object was deleted (was create,
objgone, and retvalu), and changed its (and ohitmon's) type to boolean.
Change 852f8e4 by requiring a minimum impact before a buried zombie
nearby will be disturbed: light, but still excluding things like
scrolls, if it's a violent impact (dropped while levitating, thrown, or
kicked), and fairly heavy if the hero is just placing the item on the
ground normally.
Moving the call out of flooreffects meant it no longer applied to
pushing boulders around, so have moverock disturb nearby zombies. I
additionally had wake_nearby do the same thing.
Finally, I renamed check_buried_zombies (which doesn't really reflect
what it does) to disturb_buried_zombies.
A hero hurtled into a wall of water while levitating, flying, or wearing
water-walking boots wouldn't be stopped by it unless it was on the Plane
of Water. Make it stop hurtling heroes immediately no matter the
location.
I also noticed that once I was hurtled safely into the wall of water, it
was described as a "pool" when I examined it with ':'. Fix that, too,
even though I think it shouldn't really be encountered in-game.
The other suggestion from Pat about potential extensions to bda0b3b. I
think it's interesting from a story perspective, and hopefully nobody
will run into this by mistake when they hoped to use the Candelabra as a
light source later! The specific language used by the leader could be
changed if someone has a better idea (as could the code itself, for that
matter).
If the hero throws an unidentified fake Amulet of Yendor at the quest
leader, the leader will identify it and toss it back, similar to the
behavior for the real Amulet.
This was one of Pat's suggestions for continuing in the same key as
bda0b3b; I think this makes a lot of sense, especially now that people
may be encouraged to throw things called "Amulet of Yendor" at the quest
leader. Arguable about whether a _known_ fake Amulet should still anger
the leader and quest helpers; as I have it in this commit, it will, but
I'm somewhat ambivalent about what makes more sense.
Pull request from entrez: if hero throws (or kicks) an invocation
item or the Amulet at the quest leader, identify it and give it back
instead of treating the throw (or kicked item) as an attack.
In addition to the fixes entry I've made several tweaks to related
code, mostly to refer to the leader as "Someone" rather than "It" if
unseen.
Closes#1093
It's been possible for a while to throw your quest artifact to your
quest leader, completing the quest (he will then throw the object back
to you). The quest leader will also react to being brought the Amulet
of Yendor (i.e. having it in inventory when you approach or #chat), but
tossing it over like the quest artifact was treated as a hostile act and
would cause the quest leader and guardians to become hostile and attack
the hero.
Make throwing the Amulet of Yendor at the quest leader work like
throwing the quest artifact, and treat the invocation items similarly
just in case people try throwing those (maybe because they are lost,
unsure what to do, and have already seen their quest leader catch and
react to the quest artifact -- regardless of the reason, throwing over
the Book of the Dead is almost certainly not intended to be an attack).
Doing so for invocation items will ID them but not do much more than
that. The Amulet of Yendor triggers the existing quest pager message.
Instead of a 5% chance for crystal plate mail or crystal helmet to
break each time it's subjected to breakage, switch to a 10% chance
but the damage is treated as erosion rather than break/don't-break.
'crystal foo' will need to go through four stages of damage before
breaking: cracked crystal foo, very cracked crystal foo, thoroughly
cracked crystal foo, then gone. Crackproof handling is included,
described as tempered crystal foo.
It mostly still applies to throwing and kicking the item. Having
some hits trigger damage might be worthwhile but isn't implemented.
Object creation within lua code probably needs to be updated, and
when the Mitre of Holiness is created in the priest/priestess quest
it should start out as tempered (erodeproof). Perhaps it ought to
be erodeproof regardless of where/how it's created.
Issue reported by vultur-cadens: changing helm of brilliance to
crystal made it stop being classified as "hard helmet" so it gave
less protection against things falling onto the hero's head.
Change the is_metallic() tests used on helmets to new hard_helmet().
Unlike when thrown, crystal helmets don't break when objects fall
on them.
Fixes#1060
I haven't forced a test case to verify this, but the logic for
calling mliquid() at the end of mhurtle() was clearly wrong.
Also, implement missing case of one monster causing another to
hurtle and hit the hero. Compiles but is otherwise untested.
Avoid impossible warning "breaking odd object?" when throwing a helm
of brilliance causes it to break. Presumably dropping one while
levitating or zapping one of the floor with striking/force bolt would
yield similar result.
While in there, reduce the chance of breakage from 99% to 5% for both
helm of brilliance and crystal plate mail.
I was working on this at the time 3.6.0 was released and set it aside
until later. Later has finally arrived. Redo the Blind, Blinded,
Blindfolded,&c macros to make more complete use of intrinsic property
handling. Blinded was being treated as a number which could be added
to or subtracted from; now that has to be done via TIMEOUT mask
because it has FROMOUTSIDE (OPTIONS:blind) and FROMFORM (poly'd into
!haseyes() form) bits included. Object definitions for blindfold and
towel now specify the BLINDED property; overriding blindness via the
Eyes of the Overworld is accomplished via props[BLINDED].blocked.
Code generated for the scores of Blind and !Blind tests throughout
the program should be smaller.
One bug that has been fixed is that putting on the Eyes of the
Overworld cured permanent blindness (from OPTIONS:blind). The
u.uroleplay.blind flag was cleared and stayed so after taking them
off. Putting the Eyes on still breaks blind-from-birth conduct but
now blindness will resume when they are removed.
This was untested at the time it was set aside and is only lightly
tested now. A large number of the changes here are just to switch
from Blinded to BlindedTimeout for current timed value and to call
set_itimeout() for setting a new value.
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.
Unless you kill the monster with one hit, it'll wake up
cranky and make noise - waking up other sleeping monsters.
This was a bit tricky with all the message sequencing; I tested
all the hit/throw/fire/zap combos I could think of, and it took
a while to get things looking right.
Reported directly to devteam: with one quivered boomerang and a
compatable stack of one or more boomerangs either wielded or in the
alternate weapon slot, throwing the quivered one, failing to hit any
target or obstacle, and catching the returning boomerang would empty
the quiver, merge the caught boomerang with the wielded weapon or
swap-weapon slot, then re-quiver and yield
|x - 2 boomerangs (wielded) (at the ready)
or
|y - 2 boomerangs (alternate weapon; not wielded) (at the ready)
If 'sanity_check' was On, complaints would ensue.
'autoquiver' may need to be On in addition to the thrown boomerang
being the last item in the quiver.
The unsplit portion of the fix feels unclean. There's bound to be a
better way.
Throwing while levitating or getting hit for knockback effect could
move hero carrying unpaid items out of a shop. If that happened,
sanity_check complained that unpaid items weren't in a tended shop.
Check for entering and leaving special rooms during recoil same as
gets done for ordinary movement. Leaving a shop via recoil or
knockback while owing a bill now gets treated as robbery immediately
rather than waiting until hero voluntarily moves to another spot
after recoil has finished.
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Give an extra +1 to potential multi-shot to rangers wielding the
Longbow of Diana and shooting any type of arrow. When an elf ranger
has been wielding an elven bow to shoot elvish arrows or an orc
ranger has been wielding an orcish bow to shoot orcish arrows, they
lose their racial bonus but won't lose any multi-shot capability by
switching to their quest artifact. Human and gnome rangers gain the
+1 bonus. (I have no idea how a gnome could wield a longbow. One
would need a step ladder to hold it vertically, and could only draw
the string back a stubby arm's length if they held if horizonally.)
That bonus gets applied before feeding the multi-shot counter to
rnd() so doesn't mean an extra arrow every time. And you have to
be wielding your own quest artifact--in addition to it being the
appropriate launcher for the ammo you're shooting--so doesn't provide
any multi-shot benefit to other types of characters who wish for it.
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
Specifying a count of 1 when throwing an object could leave you with two
stacks sharing one inventory letter. The second stack gets split off
when the player specifies a count (e.g. 't1o'), but keeps its original
invlet. Some early returns, like trying to throw at yourself with '.',
could fail to unsplit the stack. Theoretically, specifying multiple
items to multishot and then failing to throw them all could also leave a
partial stack; I don't think this is actually possible right now with
't' but I tried to make sure it won't become a problem if greater counts
than 1 are ever allowed.
The fix doesn't affect 'f', which can be a combined "create a quiver
stack and throw" action and doesn't have the issue with duping invlets.
Specifying a count to split off a new quiver stack with 'f' shouldn't be
reverted if the throwing fails or only part of the stack is thrown,
because the newly created stack may be intended for continued use as the
quiver in future turns. This slightly changes the behavior of the
existing unsplit when cancelling the throw (which previously unsplit the
newly created quiver and quivered the entire parent stack), but I think
this actually makes more sense -- the player only declined to throw the
new stack, not to create it (as if they canceled earlier in the action).
I routed a couple early returns through the stack unsplitting that
shouldn't actually need it (like Mjollnir and welded items) for
consistency's sake; I don't think it hurts anything.
Reported directly to devteam, mounted hero whose steed got hit
for knockback effect triggered impossible "no monster to remove".
In addition to fixing that, this makes a knockback attempt at a
hero who is stuck to a cursed saddle knock the hero and steed back
instead of knocking the hero out of the saddle.
mhurtle_step() should be able to use u.ux0,u.uy0 to update the
hero's old location after moving the hero in order to move the
steed, but the value was different from what was expected and the
map showed stale steed symbol when I used that. I'm not sure what
is going on there; saving u.ux,u.uy before moving the hero worked
as intended so I didn't pursue it.
