Adjust the Candelabrum of Invocation's weight when it has candles
attached. This has been a known issue ever since the candelabrum and
candles were introduced.
When the candelabrum burns out, update persistent inventory window to
show that it no longer has candles.
thitu() is mostly used for arrows and darts "thrown" by traps, but
scatter() uses it on items launched by a land mine explosion. Traps
had no need for potion handling, but scattering does. Changing thitu()
to call potionhit() required that more information be passed to the
latter in case killer reason was needed, and thitu()'s callers needed
to be updated since it now might use up its missile (only when that's
a potion, so scatter() is only caller which actually needed to care).
Quite a bit of work--especially the testing--for something which will
never be noticed in actual play. In hindsight, it would have been
much simpler just to make scatter destroy all potions rather than
allow the 1% chance of remaining intact (via obj_resists()), or else
leave any intact ones at the explosion spot instead of launching them.
Turning the boolean option force_invmenu makes all the commands
that ask for an inventory item pop up a menu instead of asking
a text query. This should be much more friendlier to new
players, and is very useful for window ports on systems
with touch screens and no physical keyboard, such as cell phones.
Reported directly to devteam, player threw a troll corpse into lava and
then later got messages about it reviving and burning to death. Items
thrown, kicked, or dropped into lava were being subjected to fire damage
(so scrolls burned up, potions boiled, non-fireproofed flammable weapons
and armor eroded), but corpses and a lot of other stuff not subject to
erosion remained unaffected. This makes things that are made out of
wood, cloth, flesh and other flammable stuff burn up (when in lava, not
when hit by fire).
The countdown for delayed vomiting gave message "you suddenly vomit!"
at T-2, allowing you to move some more, then vomit at T-0 with no
message, finally at T+2 get "you can move again", making it seem as
if the program was letting you move during a time it thought that you
couldn't move. Also, there was nothing "sudden" about it since it was
near the end of a 15 or so turn sequence where a few other messages
are given leading up to that.
Change it to
T-2: You are about to vomit. // different wording
T-0: You vomit! // new message
so that "you can move again" more clearly refers to the actual event.
It was once pointed out that
static long nulls[ sizeof (struct trap) + sizeof (struct fruit) ];
should have been
static long nulls[ max(sizeof (struct trap), sizeof (struct fruit)) ];
which is right, but using an array of longs to represent a null trap or
null fruit doesn't handle pointers properly so replace 'nulls' with
separate structs. This doesn't recover the previously wasted memory
(fairly trivial since these structs are small) but does guarantee that
null pointers in the relevant structs always have a valid value instead
of just all bits zero.
While doing some cleanup I found an old personal bug list with four
entries. Two have already been fixed, or at least I couldn't reproduce
them with current code, one is still pending (dungeon overview feedback
is inconsistent if you find an unlit temple and haven't seen its altar
yet), plus this one: a buffer overflow (triggering a crash for me) in
wizard mode if you turn on the 'extmenu' option and start an extended
command. The menu can't handle long line width for 'w' with all its
wizthis and wizthat entries; strcat() goes out of bounds writing into
a local array.
(This bug predates the keybinding patch that turned all commands into
extended commands.)
When entering a new menucolor via options, show regex error
immediately afterwards, instead of asking for color and attribute
before showing the error.
Also actually show config errors even if config error handler
hasn't been initialized.
Prevent using a leash while engulfed. If someone wants to supply a
better message, go ahead. I just tried to get the logic straight.
(The new swallowed part is easy; the previous lack of handling for
remembered unseen monsters wasn't quite so easy.)
Applying a leash was always using a move, even if player cancelled
at the prompt to pick an adjacent monster. Now some of the early
exits don't use a move.
For breath damage, the 'S' in NdS is ignored. 'N' for the number of
dice is used, but for number of sides of those dice, 6 is used for
most damage types. Add a comment to that effect to monst.c and change
a few Nd8 to Nd6 so that viewing the monster definitions matches what
they actually do.
The sequence
You feel the amulet draining your energy away.
You don't have enough energy to cast that spell.
didn't use any energy or cost any time so the player could try over
and over until the randomly chosen drain amount happened to be low
enough to succeed.
The old behavior was that the cost of the current cast attempt got
incresed by a random amount. Now, if hero already lacks sufficient
energy to cast the spell, the Amulet's effect won't take place, the
second message will be given, and no energy or time will be consumed.
When there is enough energy to cast the spell, the drain effect will
occur and some energy will be used up immediately (instead of
increasing the cost of this attempt). The energy drain might then
result in the second message, but if so, a turn will be used.
No longer increasing the energy cost of the current cast has a
side-effect on not increasing the hunger penalty for the current cast
(since that is based on the energy cost) but the energy drain message
doesn't actually imply any effect on hunger.
I started out just reformatting the function header for regularize()
but ended up doing miscellaneous other stuff, including some code
changes. I think the CHDIR code is a bit cleaner now, but shouldn't
have any differences in behavior.
Along the way I noticed that 'nethack -dpath' or 'nethack -d path'
modifies argv[] before PANICTRACE attempted to save argv[0], so would
break having nethack invoke gdb to get a backtrace. ('ARGV0' seems to
be unnecessary since 'hname' holds the same value, but I didn't get rid
of it....)
When polymorphed into a vampire, I saw an '@' in the distance, and
examining that with the cursor yielded "[seen: warned of shopkeepers]".
Fix that to be "warned of humans". (Vampires are warned of "humans
and elves" but this is a place where being more specific seems better.)
The function handles comments, empty lines, config sections,
CHOOSE, and line continuation, while calling another function
for other lines.
Currently used for config file, sysconf, and WIZKIT.
[Subject was actually "possible bug with shape-shifted vampires".]
The observation was that a pet vampire which took on fog cloud form
would just stay a fog cloud, rendering it nearly useless as a pet.
Fog clouds are too weak to attack dangerous monsters so are rarely
subject to damage from counter-attacks, so they wouldn't even get
killed to revert to vampire form.
Make a vampire in fog cloud form--hostile or tame--sometimes change
to bat form if not in view or out of missile range (the same criteria
used by vampires to change into alternate shape to begin with). Bats
are slightly more useful as pets and definitely more prone to revert
to vampire. The potential transformation from bat to cloud isn't
done randomly; that already occurs when encountering closed doors.
If a vampire, possibly in bat form, on the far side of a closed door
shifted shape to fog cloud in order to pass under the door, you were
told about the shape change if you could see it after being placed at
the door's location even if you couldn't see the vampire's pre-move
location. This is a bug introduced after 3.6.0....
Polymorph control gives the player a chance to accept or reject a form
change due to lycanthropy, but if it occurs during combat or movement
the player might type 'y' before realizing that the prompt is pending.
Provide a paranoid_confirmation setting for 'Were-change' to allow a
player to require "yes" instead of 'y' for that.
The existing setting 'wand' is renamed to 'wand-break' and now requires
at least two letters in the config file options instead of just 1. The
spelling of its synonym is changed from 'breakwand' to 'break-wand';
it can be shorted to as few as 2 letters (same as before) but if more
than 5 are present, the new dash is required.
Both 'wand-break' and 'Were-change' are placed before 'pray' in the 'O'
menu for paranoid_confirmation so that all the "yes" vs 'y' settings
are grouped together.
Bonus fixes:
Reverting from were-critter form to human (due to timeout) did not give
a player with polymorph control the option of remaining in creature
form; now it does.
The 'O' command's menu would not show "wand" (now "wand-break") in the
current value of paranoid_confirmation. (A post 3.6.0 issue, so no
fixes entry included.)
The revised Guidebook.mn has been tested; Guidebook.tex has not.
Reported directly to devteam, case WAN_TELEPORTATION in use_offensive()
is never used. Disable it, although this also adds other disabled code
which would make it become used if enabled.
Fix a typo/thinko that ended up being magnified by copy+paste.
I did test having the artifact be carried by a monster, but it was the
nemesis who accompanied me from the level above when I level teleported
back to his lair. He must have ended up as first monster in fmon chain
when he was placed on the level.
Some roles' quest message when returning the nemesis lair refer to
sensing the presence/aura/whatever of the quest artifact, but it might
not be there anymore. In reported case, the nemesis had picked it up
and later fled up the stairs to another level. Other situations are
possible; it's feasible for the hero to already have it. So provide
an alternate message, and some extra code to decide whether to use it.
Other anomalous messages, such as looking down on the dead body of a
nemesis who didn't leave a corpse, can still occur.
Fix a couple of warnings in options.c, and simplify feature_alert_opts()
in the process.
options.c:1126:30: warning: format string is not a string literal
(potentially insecure) [-Wformat-security]
config_error_add(buf);
^~~
options.c:1667:9: warning: unused variable 'i' [-Wunused-variable]
int i, c = NO_COLOR, a = ATR_NONE;
^
There are still a couple of warnings in files.c, but fixing them will
impinge open potential reversal of the CONFIG_ERROR_SECURE patch so
I've left them alone for the time being. The second one is because
VA_START() and/or VA_INIT() do more than just declare stuff; C99 doesn't
care, but for C90 (or pre-ANSI) the local variable should be declared
before them.
files.c:2816:12: warning: address of array 'buf' will always evaluate to
'true' [-Wpointer-bool-conversion]
(buf && buf[0]) ? buf : "Unknown error");
^~~ ~~
files.c:2799:10: warning: ISO C90 forbids mixing declarations and code
[-Wdeclaration-after-statement]
char buf[BUFSZ];
^
If user can make NETHACKOPTIONS point to a file, that user could then
get the file contents via the extended config file error reporting.
Add CONFIG_ERROR_SECURE compile-time option to make that case output
only the first error, no line number or error context.
Change the wording slightly if the hero simultaneously (in theory)
reverts to normal form and splahes acid on his/her attacker. Giving
the passive counterattack message first would be better, but several
types of counterattacks need to know in advance whether the hero has
reverted, producing a chicken-vs-egg seqeuncing situation.
I also took out 'register' directives from a bunch of declarations
since they'd been pretty much applied blindly rather than in
circumstances where someone evaluated the situation and decided that
they might matter.
Reported for nethack.alt.org where impossible events in to-be-3.6.1
trigger a panic instead of just a warning, being polymorphed into a
vampire and draining something to 0 HP (rather than killing it with
the bite attack) didn't properly kill off the victim unless it was
also being drained from level 0 to level -1, resulting in impossible
"dmonsfree: 1 removed doesn't match 0 pending". If the hero got
another move before dead monsters were purged, applying a stethscope
to the victim could trigger an actual crash rather than an impossible
escalated to a panic. Other actions such as attacking again probably
could too.
A followup included a diagnosis and one-line patch. I expanded the
adjacent comment when manually putting the patch into place.
Show the original line from the config file, followed by the line number and
a specific error message. Also show all errors from the config file before
waiting for key press.
