A potion of acid could be destroyed and freed by dipping into a
fountain, then dereferenced after the fact -- both when checking its
type immediately after the water_damage() call (as was noticed by
hackemslashem and amateurhour on IRC), and also in the later switch/case
a few lines further down in dipfountain().
I basically reversed the original 'er != ER_DESTROYED' test here: as it
was before this, I think the only thing that could hit it was a greased
potion of acid, which would survive the initial dip due to the grease.
Such a potion would be silently deleted. Potions of acid which were
actually destroyed by water_damage, on the other hand, could be allowed
to continue down to the switch/case of further effects (and associated
dereferences). I think this makes more sense in reverse, with potions
that were protected by grease actually being protected and producing
normal dip effects, and potions of acid which exploded causing an early
return with no further effects. This effectively prevents the various
use-after-free scenarios that were possible, too.
This was totally silent, which -- at least for me -- has led to quite a
few cases of believing my bag or cloak is still greased when it actually
wore off the last time I took a dip. I think telling the player that
the grease has worn off would be helpful, and is consistent with other
types of water damage.
The message is printed even if you are blind, since that seems to be
true of all the other messages in water_damage(). I am not sure if that
makes complete sense (especially for ones like a scroll fading -- some
like water getting into a bag could be sensed by touch) but I didn't
change anything there.
Autodescribe was not updating during browse_map() when the cursor was
moved over a gold glyph that was actually a trap, causing the trap to
be described as the previous square that the cursor was on (probably
"unexplored area") instead of as gold pieces. This was especially
noticeable when using OPTIONS=whatis_coord:m, because the coordinate
was not updating when moving the cursor over the trap.
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
^ ^
It turns out that there are some objects marked unpaid that aren't
carried by the hero, so the recent sanity check for unpaid/no_charge
could complain. Unpaid items dropped on the shop boundary (gap in
shop wall, doorway, shk's free spot) stayed unpaid when dropped onto
the floor, similar to recent change for pushed shop-owned boulders.
Don't give sanity complaints for those. They could be all the way
inside a shop too, where unpaid items in a gap in the shop wall got
pushed into the shop when the wall was repaired. (Possibly those
should come off the bill instead of remaining unpaid.)
Teleporting items out of a shop was marking them unpaid instead of
treating that as robbery. That's a bug caught by the sanity check.
rloco() was also marking shop items which got teleported from one
spot inside the shop to another spot inside the same shop as unpaid.
Fix both of those things. Also, if an unpaid item on the boundary
gets teleported all the way inside, take it off the bill.
Change 'I u' to mention whether there are additional unpaid items on
the floor somewhere since they won't be part of unpaid inventory and
they're not on the used-up bill either. It might occasionally help
the player figure out why the shopkeeper won't let the hero out of
the shop.
Issue reported by AndrioCelos: bullwhip using monster was able to
snatch hero's weapon when hero was engulfed.
Fix is trivial: when a monster is choosing an item to use, don't
pick bullwhip if hero is engulfed. Regular attack attempts already
skip engulfed hero.
Fixes#935
Issue reported by Melon2007: when non-deaf hero heard an unseen
monster read a scroll, the monster's type was identified accurately
(unless distorted by hallucination). That was intentional but it
doesn't seem plausible for the hero's hearing to be that acute.
Change it to report the monster type accurately if not hallucinating
and monster is the same species as the hero (as the current form if
hero is poly'd), otherwise report it as "someone" when it's humanoid,
otherwise as "something".
Also, if the monster is heard at a spot that would be visible if
hero could see, draw a "remembered, unseen monster" glyph there.
Fixes#934
If paranoid_confirm settings include praying, don't put the answer
to "are you sure you want to pray?" into the do-again buffer where ^A
would use it to ignore confirmation if prayer is repeated. And for
wizard mode, when confirmation is 'y' then the answer to "force the
gods to be pleased?" has to be suppressed from the do-again buffer too
or it would be used by subsequent ^A to answer "are you sure?".
This is basically a band-aid just for #pray. There are probably other
confirmations that should be suppressed from do-again instead of being
reusable. The rest of the paranoid_confirm ones should be ok because
they require "yes" and that doesn't end up in the do-again buffer, but
there are bound to be other confirmations that shouldn't automatically
be re-used during repetition.
Issue reported by Meklon2007: typing arrow keys when a menu is open
can end up with hidden counts. That's a Windows thing and this
makes no attempt to address it. (That's also a user error since
menus don't support arrow key use.) It shows up more for throwing
that for other things because fetching an object from inventory for
throwing attempts to enforce a count limit during item selection
that other actions don't.
But feedback could also be odd if you explicitly specify a count
since the rejection wasn't attempting to distinguish throwing more
than one from throwing more than you have. This changes things so
that with invent of
|$ - 3 gold pieces
|a - a dagger
|b - 3 darts
t4$ now yields "You only have 3." instead of throwing all 3
t4a now yields "You only have 1." instead of "you can only throw one"
t2b still yields "You can only throw one at a time."
t4b now yields "You only have 2 and can only throw one at a time."
In each case, it will reprompt rather than terminate the throw.
"Only one at a time" was already in place when multi-shot throwing/
shooting was introduced and became iffy then, but the way to try to
throw a specific amount is via a repeat count before t rather than
by choosing a subset when selecting the inventory item for t. The
count prefix method also works for f which doesn't otherwise provide
an opportunity to specify count since inventory item is preselected
via quiver.
Someone might want to reopen the arrow behavior as a Windows issue
but I'm not sure how that would be fixed other than by eliminating
its attempt to be user-friendly in converting arrows into movement
direction keystrokes.
Closes#933
Although gcc specifies support for declaring a function as
noreturn after the function name and parameters, other compilers
do so via an attribute at the start of the declaration. Add some
macro support for the attribute-at-the-beginning method:
o MS Visual Studio compiler
o Upcoming C23 standard (untested at this point)
Handle items in gaps of a wall shared between adjacent shops.
Make handling of shop boundaries more explicit: walls, the door,
and the "free spot" by the door aren't classified as 'costly' but
obj->unpaid and obj->no_charge are valid there.
Move unpaid/no_charge checking into its own routine to unclutter
objlist_sanity().
Pushing a shop-owned boulder to the free spot or doorway or gap in
wall triggers the sanity check for the time being.
When dist2() got changed to use coordxy parameters, a macro that uses
it in its definition was overlooked and it had (int) casts in it.
That caused a warning about possible data loss when the int
then got converted to coordxy for the dist2() call.
Give online2() coordxy parameters instead of int, like its bretheren.
Avoid a couple of implicit conversion warnings where ints were being assigned
to smaller uchar or ints being assigned to smaller short.
A couple of signed vs unsigned warnings on some rumor processing.
Avoid some signed vs unsigned warnings in mdlib/makedefs where a signed int
param eventually got used in an external call that took size_t.
Eliminate all of it by just having the outer NetHack routine also take
a size_t.
Lastly, insert some default C99 alternative time-related code
in mdlib/makedefs since asctime() and ctime() are being flagged as
deprecated in the upcoming C23 standard and will now start to trigger
warnings for anyone using a C23-compliant compiler.
Shuffling gem appearances can cause mappings from object to
appearance that are not one-to-one. Copy any multiple mappings and
free any mappings that are left unused.
The getobj prompt for charging was presenting any chargeable tool in the
hero's inventory as a suggested charging target, even tools which were
unidentified and undistinguishable from their mundane counterparts
(e.g. bag of tricks, magic harp, horn of plenty...). This leaked
information about the identity of these items and made it possible to
determine whether a generic 'harp' was magic or not.
When suggesting chargeable tools, include only those which are actually
known to be chargeable (unidentified or unseen chargeable tools can
still be selected, they just won't be suggested targets). Basically the
same as what's done for a potion of oil in the apply prompt.
Pushing a shop-owned boulder out of the shop wouldn't charge the hero
anything. Remedy this (and remove the boulder from the bill if the hero
then pushes it back in). Also tried to handle a couple other uncharged
boulder "theft" scenarios: pushing a boulder into lava or water, into a
trapdoor or hole, or into a level teleporter (various other traps
already charged for the boulder -- it was pretty inconsistent).
I externified onbill() for this, since relying on otmp->unpaid by itself
impossibles if you push a boulder through a gap in a wall between two
adjoining shops.
Short for distu(mtmp->mx, mtmp->my) (i.e. the distance between the hero
and the specified monster), which is a very common use of distu(). The
idea is that this would be a convenient shorthand for it; I actually
thought it (or something very similar) existed already, but couldn't
find it when I tried to use it earlier. Based on the number of uses of
fully-spelled-out 'distu(mtmp->mx, mtmp->my)' replaced in this commit
I'm guessing I just imagined it.
"A dry rattle comes from its throat" would be printed whenever a
canceled monster tried to spit at you or another monster while not in
the hero's line of sight. That seemed weird to me: you can't see the
monster and don't know what it is, but you can tell the sound is
definitely coming from "its throat".
Change the message if the monster isn't visible, and make sure it's
printed it only if the monster is nearby (within reasonable hearing
range for a "dry rattle").
Instead of using a compile-time macro to suppress inclusion of the
menu entry to show UNIX command-line usage in the help menu, use a
sysconf setting instead.
Default is HIDEUSAGE=0, to include the entry for command-line usage.
Set HIDEUSAGE=1 to exclude that. Does not affect 'nethack --usage'
if player actually has access to the command-line.
Write up a description of how the command line works on UNIX and put
that in new file dat/usagehlp. Add support for
|nethack --usage | --help | -? | ?
to display it and exit.
Also add a menu entry for nethack's help command to show it during
play. That can be suppressed by uncommenting new '#define HIDE_USAGE'
in config.h since it won't be useful on servers that don't give
players access to command lines.
New genl_display_file() just writes to stdout. opt_usage(), which
calls it, might need some suid/sgid handling to make sure the output
is done as the player rather than as nethack.
doc/nethack.6 is already out of date again.
For nethack -s name1 [name2 [name3]]
allow any or all of the name arguments to be preceded by -u. Both
'-u name1' and '-uname2' forms are accepted same as when specifying
character name at start of play.
It has been accepting '-s<anything>' and ignoring the <anything>.
Treat such as a separate argument instead. That means it will accept
'-s-v' which is silly but if used intentionally, <anything> would most
likely be a name.
'nethack -s' without any character name(s) supplied and PERS_IS_UID
set to 0 now defaults to "all" instead of to "hackplayer". For Unix,
the default name will be in place, so that gets used instead of "all".
'nethack -s all' or 'nethack -s -u all' can be used to see all scores.
When no matches are found, feedback is a full sentence but terminating
punctuation was omitted except for the special case of "Cannot find
any entries for you." Add the final period all the time.
Condense the setup of PCHAR/PCHAR2 and OBJCLASS/OBJCLASS2 (last one
renamed from OBJCLASS7) so that it's easier to see the variations
at once on an ordinary size terminal/window. Revise some of the
indentation and other spacing, also to try to enhance readability
a little.
Unrelated: remove a trailing space that crept in with a recent pull
request.
As far as I know, there's no such thing as WIN32_GRAPHICS in the
current source tree. The Windows graphical port uses the preprocessor
macro MSWIN_GRAPHICS.
Some recent testing with a multi-platform compiler encountered difficulty
with the use of a variable 'near' (and presumably 'far', but we don't have
any of those in the source tree) due to reserved word extensions.
Avoid using that as a variable name.
Permit levelport by name to "delphi". That is what the Oracle calls the
level (or at least her room) in-game, so it seems like a natural guess
for the name of the level.
GCCs older than 3.1 understand __attribute__(printf(...)), but only
with functions; it doesn't work with function pointers. This change
uses PRINTF_F_PTR to remove the attribute from two function pointers.
This change establishes GCC 3.0 as the minimum version to build
NetHack. Older versions have trouble with the variadic macros and
variable declarations in mid-block.
Make the existing '#vanquished' command be available during regular
play, with M-V bound to it. 'm #vanquished' or 'm M-V' brings up
the sorting menu that you get when answering 'a' rather than 'y' at
the end-of-game "disclose vanquished creatures?" prompt.
The original #vanquished came from slash'em, where it was available
in normal play. When added to nethack, it was put in as wizard-mode-
only. I added the sorting capability several years ago.
The chosen sort is remembered and re-used if not reset but only for
the remainder of the current session. It probably ought of become
a run-time option so be settable in advance and across sessions but
I haven't done that.
This fixes the problem with reporting "the <foo> option may not
both have a value and be negated" to stdout if delivered before the
interface has been set up, so possibly not be seen. It has been
using pline_The() but that uses rawprint() during startup.
Unfortunately testing it has uncovered another config file error
reporting issue and this one won't be so easy to fix. For a logical
line that uses backslash+newline continuations to span multiple
physical lines, when there is a problem it reports the line number
and text of the last segment rather than of the first or of the
specific segment containing the problem. That isn't necessarily
wrong but is suboptimal.
The message for trying to (re)name an unnameable monster was weird when
the player entered a blank name (a name consisting of only spaces), in
an attempt to delete the monster's existing name rather than give it a
new one. Several of the normal messages looked incomplete due to using
the blank string as the "new name" (e.g., "I'm Feyfer, not ."), and the
one which didn't include the name still seemed a little off ("calling
names" is almost the opposite of what the player is doing). Add a new
message for attempting to erase the name of one of the special
unnameable monsters, e.g. "Juiblex would rather keep his existing name"
or "The Oracle would rather keep her existing title".
I also noticed that the message for trying to give an unrenameable
monster the name it already has (e.g. trying to name Death "Death") was
revealing the genders of the Riders with personal pronouns. This is
avoided elsewhere (e.g. using "the way" in mdisplacem, "its" baked
into the message in mhitm_ad_deth), so I also added a slightly rephrased
alternate message for Riders which avoids any pronouns. For the
unnaming message, on the other hand, I just used "its" for the Riders,
since I couldn't think of a way to phrase it that avoided pronouns
entirely.
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.
I made more things in dump_enums() static and/or const. In the
process I discovered both compile problems for NODUMPENUMS and when
fixed, link problems for NODUMPENUMS+ENHANCED_SYMBOLS.
The uft8map.c portion has no changes, just reformatting.
..\src\allmain.c(1061): warning C4221: nonstandard extension used: 'ed': cannot be initialized using address of automatic variable 'omdump'
..\src\allmain.c(1056): note: see declaration of 'omdump'
Resolves#916
