Make #untrap while carrying the non-cursed (for rogues) or blessed
(for non-rogues) Key work the same as #invoke has been doing (without
regard to its bless/curse state): when used on trapped door or chest,
that trap will always be found and disarming it will always succeed.
It should work when carried by monsters too: if they try to open a
trapped door while carrying the Key (must be blessed since they're
not rogues) the trap will be automatically disarmed. (Caveat: that
hasn't been adequately tested.)
TODO (maybe...): change the #invoke property to detect unseen/secret
door detection instead of #untrap. The latter isn't completely
redundant; it works when the Key is cursed. But quest artifacts
strongly resist becoming cursed so that isn't a particularly useful
distinction.
Also, trap hints when wielding the Key without gloves didn't notice
adjacent door and chest traps. Now it does. And the behavior is
slightly different: known traps covered by objects or monsters are
treated like unknown traps as far as the hot/cold hints go.
Originally by Ray Chason for 3.4.3, based on the Qt windowport by
Warwick Allison. The look and feel is mostly the same.
Some improvements over the Qt 3 interface are:
* Panes are resizable
* Full support for IBMgraphics, and walls and corridors are drawn with
graphical primitives for a continuous appearance no matter what the font
says
* Lots of irritating glitches fixed
* Menus support proportional fonts correctly
Adding this because the old Qt windowport cannot be compiled on Qt4,
even with Qt3 compatibility stuff.
TODO:
- background map glyphs
- status hilites
- menucolors
If the key is wielded and touching skin (that is, you're not
wearing gloves), it will give heat-related messages like
minesweeper, counting the undetected traps around player.
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).
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.
