Issue reported by argrath: if getoptstr() executed its loop to
find the latest phase that set a role/race/gender/alignment option
value, the first iteration of the loop would use an index that's
out of bounds.
The code in question is wrong but happens to not be used, so the
out of bounds access doesn't occur. Fix the value for the first
iteration in case the offending code eventually gets used.
Fixes#960
Underwater vision was updated only once per turn, so if the hero had
more than one move per turn it could cause some spots to be left behind
on the map. For example, after moving around underwater while very fast
for a while:
}
}}}
}}}}
} }}@}
} }}}
Not only does the radius of vision appear to "smear" temporarily, but if
the hero moves fast enough, isolated spots can be left entirely behind
(since the normal underwater vision update only clears nearby spots, not
the entire map). Both these effects are visible in the example above.
The fix in this commit is to update the frequency of underwater vision
updates to "once-per-time-taken" rather than "once-per-turn", so that it
updates with every move. I'm not sure if it needs to happen more
frequently than that (i.e. in the "once-per-input" section) but I might
be overlooking something.
Also add missing punctuation to the message for applying a lamp
underwater.
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.
scan-build from llvm-14 (clang) doesn't complain about bite() or
maybe_finished_meal() so this is unlikely to fix those. But this
does fix one bogus complaint it has for doeat(). Testing whether
the result from touchfood() is Null was fooling it into thinking
that that was a possibility when it's not.
Also, use plain 1 and 0 instead of TRUE and FALSE when assigning
to the victual bit-fields. The analyzer doesn't care but the type
was mismatched due to the cast to (boolean) hidden in their macro
definitions.
This code was in three different places; pet eating,
monster eating metal, and monster eating other objects.
Other than very minor changes (eg. rustproofing completely
protects pets from bad effects, rustproof items are no longer
giving apport, and monsters eating corpses are healed), it
should behave the same as before... But I haven't exhaustively
gone through every iteration.
The brace added to dokick was misplaced - it should have included
the You_hear() as well.
The puts the code back the way it was, and relocates the Soundeffect().
The Soundeffect should play whether the hero is Blind or not, and the
Soundeffect() macro already includes a Deaf guard.
Cope with get_nh_lua_variable() possibly returning Null.
Either or both of the DISABLE_WARNING_UNREACHABLE_CODE and
RESTORE_WARNING_UNREACHABLE_CODE in the vicinity looked misplaced so
I took them out. They may need to be added back in.
Insert the calls to trigger a number of potential soundeffects
into the core.
If no additional soundlib support is integrated into the
build, then the Soundeffect macro (sndprocs.h) expands to nothing:
[#define Soundeffect(seid, vol)
]
If, however, at least one additional soundlib support is integrated
into the build, then the Soundeffect macro gets defined as this
in sndprocs.h:
[#define Soundeffect(seid, vol) \
do { \
if (!Deaf && soundprocs.sound_soundeffect \
&& ((soundprocs.sndcap & SNDCAP_SOUNDEFFECTS) != 0)) \
(*soundprocs.sound_soundeffect)(emptystr, (seid), (vol)); \
} while(0)
]
That macro definition checks for the hero not being Deaf; it checks
to ensure that the active soundlib interface has a non-null
sound_soundeffect() function pointer; and it checks to ensure
that the active soundlib interface has declared that it supports
soundeffects by setting the SNDCAP_SOUNDEFFECTS bit in its sndcap
entry. That just means that the interface routines are prepared to
accept and deal with the calls from the core, whether or not it
actually produces the desired soundeffect.
When using mouse to move to a location next to the hero,
the test_move result was reversed, causing the click to fall
in to the travel case instead of normal movement.
Groundwork for a more versatile interface for using
sound libraries. A lot of sound libraries work across
multiple platforms.
The current NetHack sound stuff is quite limited.
Binaries can have a variety of window ports linked into
them, and it makes sense to have something similar for
sound.
This tries to set things up in a more soundlib-centric way,
rather than inserting things in a platform-centric way.
It establishes a new top-level directory sound (akin to win
for the window interface routines, or "window-port") where
sound-related additions and sndprocs and support files can be
added and used across platforms.
The default interface is nosound and the 'nosound' interface
is in src/sounds.c
The interface for 'windsound', which contains the same minimal
USER_SOUNDS support using built-in routines that has been in the
windows port for a long time is added to
sound/windsound/windsound.c.
For now, the sound interface support for 'qtsound' has been added
to the existing Qt files win/Qt/qt_bind.h and win/Qt/qt_bind.cpp,
and a note has been placed in sound/qtsound/README.md to avoid
confusion.
New header file added: include/sndprocs.h.
The Gehennom changes broke the vibrating square, allowing hero to go
down into the Sanctum via stairs without performing the invocation.
Fix this by making the hellfill lua check for invocation level, and
placing down the vibrating square trap, instead of stairs.
When playing as a Samurai, add things like "osaku" to the discoveries
list even though they don't have separate descriptions to be used
when not yet discovered. Non-magic ones are pre-discovered and
players can now use the '\' command to figure out what things like
"tanko" mean without resorting to '/?'.
"wooden harp" has been getting changed to "koto (harp)"; make that be
| koto [wooden harp] (koto)
"magic harp" has been staying as "magic harp (harp)"; add it to the
list of Japanese item names. Since it's magic it isn't pre-discovered.
Once discovered it becomes
| magic koto [magic harp] (koto)
Those two needed special case handling, none of the other items did
aside from forcing them to be discoverable when lacking descriptions.
The discoveries list now has things like
| wakizashi [short sword]
| naginata [glaive] (single-edged polearm)
| gunyoki [food ration]
if--and only if--the hero is a Samurai.
Include some assertions to convince the analyzer that some pointers
can't be Null. They're Null if 'vis_func' is non-Null but only used
when that function pointer is Null and they have values.
If there's a macro that's defined when the analyzer is running and
undefined when not--or vice versa--it could be used to control NDEBUG
and avoid the assertion code when not analyzing. That's a bit like
using fake code to pacify 'lint'; however, since the assertions should
never fail, suppressing them isn't really switching to fake code.
I reordered a couple of macros so that the set of them matches the
comment which precedes them and refers to "the last three". It is
referring to the three within the block comment rather than the macro
defintions but putting those in the same order removes any ambiguity.
The complaint is that victual.canchoke might be used without having
been initialized. I'm fairly sure that that isn't correct but get
dizzy trying to trace through the eating code.
This might improve the situation, or maybe not.
This is similar to the earlier potential fix that I didn't like,
but I think think one is better.
The analyzer claimed that 'fptr' might be Null inside the switch
case for
|struct permonst *fptr = NULL;
|if (obj->otyp == CORPSE || ...) fptr = &mons[obj->corpsenm];
|switch (obj->otyp) { case CORPSE: ... /* dereference 'fptr' */ }
even though it will always have a non-Null value for otyp==CORPSE.
Make the assignment of 'fptr' unconditional. mons[NUMMONS] is
valid and won't match any actual monster. In this case it will
only be used when initializing fptr, never when fptr gets used.
Allow setting a per-level "temperature": hot, cold, or temperate
via special level flags. Currently it only affects some messages
in Gehennom, but it could be expanded to ice melting, water freezing,
or monster generation, for example.
Invalidates saves and bones.
Add a couple of redundant tests for 'shkp = shop_keeper()' yielding
Null to pacify the static analyzer.
Make the paired calls to shkp = shop_keeper() and inhishop(shkp) look
more consistent. Barring typos, the behavior hasn't been changed.
Remove some conditional code that isn't needed these days.
Use C99 fixed width integer types for all platforms, instead
of using it for some and Microsoft types for others.
