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).
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....)
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.
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.
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.
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.
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.
Reduce the chance of a player playing on a public server encountering
their own bones, by implementing separate bones pools. The pool a player
belongs to is determined at game start, and only bones in that pool
are used. The sysconf BONES_POOLS allows the sysadmin to define how
many pools there are.
Report was for a blinded horse which ate a carrot but remained blind.
This fixes that, and also lets blinded carnivorous pets eat carrots.
Gelatinous cubes now handle carrots too, but since they lack eyses
there won't be any noticeable effect for them.
Overriding clang-format was justified, but the result was too wide.
Make the lines less that 80 characters.
Also, WC_PERM_INVENT and WC_PLAYER_SELECTION had comments cloned from
the preceding line.
Previously the "fast-moving" when getting a target location
was always by 8 units. If this option is on, fast-moving
will instead skip the same map glyphs. This should be much more
useful for blind players.
Files modified:
include/extern.h
src/pline.c, priest.c, potion.c, mkobj.c
A bunch of calls to pline() in pline.c started triggering warnings
either as-is or possibly after the changes to tradstdc.h. Fixing
them in place would include intrusive VA_PASSx() like in lev_main.c.
Moving them to other files is much simpler (and they didn't
particularly belong in pline.c in the first place, although I didn't
actually find any better place for them....).
The probing/stethoscope feedback went to priest.c, where there's a
comment stating that it should move to wherever englightenment ends
up once that is moved out of its completely inappropriate current
home in cmd.c. (Holdover from when ^X was wizard-mode only but even
the other wizard mode commands don't really belong with the command
processing code.)
Files modified:
include/tradstdc.h, sp_lev.h, system.h
util/lev_main.c
Silence a bunch of warnings generated by recent gcc which weren't there
with whatever version I had when 3.6.0 was being readied for release.
For lev_main, there were two basic types: not enough arguments in calls
to lc_pline, lc_warning, and lc_error (since we weren't passing dummy
arguments as is done for add_opvars), and conversion from 'int' or
narrower to 'char *' (from -Wint-to-pointer-cast, which either wasn't
there yet in the older gcc, or wasn't included in -Wall back then).
[Note that for any configuration decrepit enough to actually need
USE_OLDARGS, such conversions will either work fine or else nethack
simply won't be viable.]
src/pline.c generates a bunch of warnings (for USE_OLDARGS). The fix
for that will be (2 of 2).
To test, instead of mucking about with CFLAGS or sys/unix/hints, I've
been temporarily adding unconditional
|#undef USE_STDARG
|#undef USE_VARARGS
|#define USE_OLDARGS
to the end of config1.h and then doing my normal build--which is why
-Wall (or possibly -W) is drawing -Wint-to-pointer-cast warnings.
Compound option whatis_filter, filters the eligible map locations
when getting a cursor location for targeting. Accepts 'n' (none),
'v' (map locations in view), or 'a' (map locations in the same area,
eg. room or corridor).
Having selectable base indexes for the monster list doesn't seem
likely to be needed in the future any more, now that the code for
the monster list is stable. Additionally, the functionality in
question has bitrotted heavily (e.g. many "loops over all
permonsts" start at a hardcoded 0, which wouldn't work with a
1-indexed monster list). As a result, removing the relevant code
in makedefs makes it clearer what can and can't be assumed about
the code, reducing the risk of bugs in the future.
Thanks to FIQ for mentioning that this could be an issue.
Add some new routines for dealing with fruit. I had hoped they would
let the existing fruit handling be simplified quite a bit, but the
improvement wasn't great. However, they're also groundwork for fixing
an old bug.
Remove the assumption of property index values from the list of
property names. Move the properties that can't have timed values
in normal play to after those which can. (Mainly only matters for
the #wizintrinsic command.)
Bug fix: #wizintrinsic variable 'any' wasn't initialized properly
if 'a_int' is smaller than a long or a pointer. The separator line
I've added was ending up as a menu choice.
Extend the wizard mode #timeout command: show timeouts for all 67
intrinsics rather than just a handful. Most won't appear because
they don't have any way to receive a timed value. Except for...
Extend the wizard mode #wizintrinsic command: allow setting a
brief (30 turn) timeout for any/every intrinsic, not just for
deafness. It ought to prompt for duration, but that's more effort
than I'm willing to expend. This might turn up lots of quirks that
the code isn't prepared to handle (like setting life-saving to
non-zero will break the assumption that it comes from worn amulet).
Perhaps some will warrant fixing, others just a shrug.
There are still some timed events that aren't listed by #timeout:
remaining duration to stay polymorphed in current form, number of
turns until it's safe to pray, luck decay, number of turns until
next attribute exercise/abuse check, probably others that I'm
overlooking.
Bug fix: while testing, I observed
Your limbs have turned to stone.
You have turned to stone.
You can hear again.
You are a statue.
when deafness and petrification were timing out at the same time.
This modifies the stoning and sliming countdowns to extend deafness
duration a little if it's about to time out at the tail end of the
stoning or sliming sequence, so that "you can hear again" won't
happen until after life-saving. There are probably other variations
of simultaneous or near simultaneous timeout that interact oddly.
The different menustyle settings have been offering different degrees
of support for BUCX filtering:
Full : multi-drop, container-in, container-out
Trad, Combo: multi-drop
Partial : none (to be expected; it explicitly jumps past class
filtering, where BUCX gets handled, to a menu of all objects)
This adds pickup, container-in, container-out, multi-unwear/unwield,
and object-ID for Trad and Combo, and multi-unwear/unwield for Full.
(Full behaves like Partial for pickup--not sure why--and for object-ID,
bypassing filters to go straight to a menu of all applicable items.)
There are probably several new bugs--this stuff is very convoluted....
Report #5426 was classified as not-a-bug, but the underlying issue
can be improved.
For item selection where BUCX (bless/curse state) filtering is
supported (mostly for menustyle:Full, but there are a few actions
where Traditional and Combination handle BUCX too), 3.4.3 took the
union of object class and bless/curse state (so ?!B gave all scrolls
and all potions and every blessed item from other classes) but 3.6.0
changed that to the intersection (so ?!B gives blessed scrolls and
blessed potions, period). Since gold is inherently not blessed or
cursed it has been getting excluded during intersection handling
when that includes BUCX filtering. Report #5426 was from a player
who was used to choosing $X when putting newly acquired loot into a
container asking to have the old behavior reinstated.
The ideal fix would be to support both union ($ | X) and intersection
(?! & B), but implementation would be bug prone and the interface,
especially when done for menus, would be cumbersome. Instead, this
adds new boolean option, goldX, to allow the player to decide whether
gold is classified as uncursed--even though it is never described as
such--or unknown. The new-loot-into-container issued can be solved
either via $abcX, where abc lists all classes that have any X items
(when gold is included as one of the classes, its BUCX state is now
ignored for the current selection), or by setting the goldX option
and then just picking X for the types of items to put into the
container (or drop or whatever other action supports BUCX filtering).
The situations where menustyle:Full allows BUCX filtering during
object class specification and styles Traditional and Combination
don't should to be fixed (by extending BUCX support to Traditional
and Combination rather than removing it from Full, obviously).
A small amount of comment formatting in flag.h, plus rearranging
some of the boolean fields into alphabetical order. I only touched
one section of struct instance_flags.
I think this finally quashes the "cursed without otmp" issue.
Various ways of destroying wielded weapon used setnotworn() rather
than unwield(), so the previous change to have unwield() clear the
pending W_WEP bit from takeoff.mask wasn't sufficient to prevent
'A' moving on from another item (blindfold--it's the only thing
processed before primary weapon) to weapon which wasn't there any
more. Also, if weapon was already set in takeoff.what to be
processed on the next move, clearing W_WEP from takeoff.mask wasn't
sufficient either.
Move the previous unwield() 'fix' to setworn() and setnotworn() and
extend it to include cancel_don() if the item being replaced or
removed is in progress or scheduled for next. (Most of the time,
remove_worn_item() has already done that before setworn() or
setnotworn() is called.)
This adds new utility routine strNsubst(), a more versatile version
of the existing strsubst(), that can replace the Nth occurrence of
a substring rather than just the first, and replaces all occurrences
if N is 0.
When working on vampire shape-shifting messages a few days ago I
noticed that a constructed pline/sprintf format was vulnerable to
the player giving the vampire a name with '%' in it and included
a fix for that. This fixes two other instances of the same
vulnerability: a monster with reflection triggering a floating
eye's gaze and the hero using a silver weapon against a silver-
hating monster.
I didn't do a lot of experimenting with the failure, just assigned
the name "foo%s" to the floating eye or the weapon. The resulting
feedback for the relevant messages was garbled due to parameters
being substituted in the wrong place. When that caused there to be
too few arguments to satisfy the format, the final message included
"null" for the missing one rather than triggering a crash while
trying to format something arbitrary from the stack.
I don't think these bugs provided sufficient user control to be
vulnerable to stack manipulation that does something naughty.
I found the dynamic format strings by searching for "%%". There
may be others scattered around the code which don't have that as
an indicator....
Report was about "Pet vampire" but the relevant aspect was that the
vampire had been assigned a name, not that it was tame:
You observe a Hilda where a Hilda was.
Investigating this has uncovered two other bugs, one potentially
serious. m_monnam() overrides hallucination but seems to be getting
used to some situations where hallucination should be honored (several
instances). Dynamically constructed format strings are including
monster or object names in the format (rather than the usual use as
arguments), so player assigned names containing percent signs could
cause havoc (a few instances). This fixes some of the former and one
of the latter, but doesn't deal with various other cases revealed by
grep.
When writing the known portion of the current level's map into
dumplog, discard any blank rows at the top (there will already be
one blank line separating it from the text that precedes) and keep
at most one blank row at the bottom (sometimes there won't be any).
Report was for
You finish taking off your boots.
You float gently to the altar. [destination was a red herring]
[take some action to run through moveloop() for next turn]
Your movements are slowed slightly because of your load.
Having float_down() do the next encumbrance check instead of
waiting for moveloop() to do so was straightforward. However,
while testing I noticed the reverse situation (not due to the fix
for the above) when putting on levitation boots
Your movements are now unencumbered.
You finish your dressing maneuver.
You start to float in the air!
Having float_up() do the encumbrance check isn't adequate to fix
this, because it takes multiple turns to put on boots but the
properties they confer are enabled immediately, so moveloop() runs
while hero is already levitating even though the game hasn't told
the player about it yet. Fix is a hack to defer the effect of
levitation on encumbrance until the boots are fully worn, which
might lead to strangeness somewhere. It's also boot-specific so
will need to be updated if some other multi-turn armor that confers
levitation ever gets added.
Some discussion in the newsgroup about nearby peaceful monsters becoming
hostile if they observed the hero attacking a peaceful monster made me
look at the code and I spotted a couple of problems. An auto array was
being initialized in an inner block--some pre-ANSI compilers couldn't
handle that. Worse, it was inside a loop and may or may not have
resulted in unnecessary setup each iteration. Make it static. Oddly,
the array had the same name as a function but `gcc -Wshadow' either
didn't notice or didn't care.
A more significant problem was that mon->mpeaceful was being set to 0
without checking whether mon->mtame was set, potentially resulting in
humanoid pets being both tame and hostile at the same time. This change
prevents that but doesn't do anything interesting about pets who observe
attacks against peacefuls. (I also wonder why chaotic peacefuls now get
upset by seeing other peacefuls be attacked; it seems out of character.)
There was also a check for non-humanoid peacefuls seeing another of the
same species be attacked, but it was checking for an exact match without
regard for littler or bigger incarnations of the same species. I've
added the latter.
This also reformats a couple of block comments.
I couldn't reproduce the reported problem of the "In what direction?"
being issued after the screen was cleared, but bypassing pline() in
favor of putstr(WIN_MESSAGE) for tty prompts did also bypass
if (vision_full_recalc) vision_recalc(0);
if (u.ux) flush_screen(1);
done in pline(). Inadvertent loss of the latter could conceivably be
responsible for the problem. If so, the escape code used by cl_end()
may be broken for somebody's termcap or terminfo setup since clearing
to the end of the line in the message window shouldn't erase the rest
of the screen.
Regardless, the prompting change also bypassed the ability to show
the prompt with raw_printf() if the display wasn't fully intialized
yet, so some change to the revised prompting was necessary anyway.
Switching back from putstr(WIN_MESSAGE) to pline() resulted in
duplicated entries in DUMPLOG message history, one with bare prompt
followed by another with response appended, so more tweaking was
needed. The result is use of new custompline() instead of normal
pline(). custompline() accepts some message handling flags to give
more control over pline()'s behavior. It's a more general variation
of Norep() but its caller needs to specify an extra argument.
Update DUMPLOG's message history to include player responses to
most queries. For tty, both getlin() and yn_function(). For other
interfaces, only yn_function() is covered. (It's intercepted by a
core routine that can take care of the logging; getlin() isn't.)
Also includes saved messages from previous session(s), for the
interfaces which support that (tty), to fill out the logging when
a game ends shortly after a save/restore cycle.
The tty interface was using pline() to display prompt strings.
Having 'MSGTYPE=hide "#"' or 'MSGTYPE=hide "yn"' in .nethackrc
would suppress many prompt strings (in the two examples mentioned,
entering extended commands or the vast majority of yes/no questions,
respectively) and generally lead to substantial confusion even if
done intentionally, so switch to putstr(WIN_MESSAGE) instead.
Separate the message logging out of pline so that other things (for
instance, one-line summary for quest block messages) can be logged.
The code that utilizes this isn't ready for prime time yet.
For FREE_ALL_MEMORY, release DUMPLOG message history when saving.
(Actually, this frees it unconditionally rather just doing so for
FREE_ALL_MEMORY.) It was being freed when logged at end of game,
but not during save. If dumplog message history and interface
message history get integrated, the existing message history
save/restore handling should become applicable instead.
Bug report was:
> "Completed sokoban" achievement was logged when picking up
> a randomly generated bag of holding in the gnomish mines.
The picking-up code was missing checks for the branches, so
you could get the achievements outside the correct branches.
Apparently some screen readers keep reading the status lines
at the bottom of the screen when parts of those change.
Add an option to prevent updates to those lines.
