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.
Allows the user to define arbitrarily named optional sections
in the config file, and select which of those sections are used.
For example:
OPTIONS=color
CHOOSE=char A,char B
[char A]
OPTIONS=role:arc,race:dwa,align:law,gender:fem
[char B]
OPTIONS=role:wiz,race:elf,align:cha,gender:mal
The previous version of this would lead to big warnings and
impossibles. This doesn't seem like a useful case, but it's still
better to have better warning messages just in case it does
happen.
The previous behaviour was to mention the missing file, but then to
try and fail to lock the nonexistent file 10 times, which rather
obscured the original cause of the error as it took up so much more
room on the screen.
This patch also changes the error message. Failure to lock a
nonexistent file is almost always the result of a mistake during
the install process (e.g. running from the wrong directory, or
running without an install). We should give the user a hint about
that.
Reported directly to the devteam. Set hilite_pile on, become
invisible, pick up all but one item from a pile on the floor,
the pile symbol was still there afterwards.
This is yet another case of evil hack, because the gbuf doesn't
distinguish between object piles and single items, see
commit 854fe40609
Reported directly to devteam, the starting inventory for rogue chars
specified that their lock pick be +9, but the 'spe' enchantment field
is meaningless for that type of item. A followup report indicated that
it had been this way since at least the 3.0 era.
It might have been a typo, since 9 and 0 are next to each other. Or
perhaps before lock picks were introduced, rogues started with a
skeleton key. That assumes spe==9 meant skeleton key back in the days
when each key and lock had a designated shape and a non-skeleton key
had to match the lock's shape to work. I don't know whether that was
how skeleton keys were flagged and don't care eough to delve deeper....
