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.
Theoretically we still support implementations which don't have %p.
Even if we didn't, it requires a 'void *' argument rather than an
arbitrary pointer, so casts would have been needed.
