Add support requested by a user for number_pad:3 to use a phone-style
keypad layout where 1,2,3 are on the top row and 7,8,9 on the bottom,
opposite of the adding machine layout adopted by computer keyboards. Also
number_pad:4 combines that with the number_pad:2 hack to give different
behavior for the 5 key (also meta-5 and meta-0). And number_pad:-1 is a
rather absurd way to support German keyboards which have y and z keys
swapped, avoiding the need to add a new option for that. With it, z moves
upper-left and y zaps wands, with corresponding swap of the upper case,
control, and meta variations of those two letters. (There is a "German
keyboard patch" for this floating around the net, but it implements a
compile time configuration setting which results in hard-coded behavior
for those keys. This implementation lets it be toggled on or off at will.)
There's more here, intended to ultimately simplify rhack() quite a
bit. Most of that isn't finished yet. However, the part that is done
should produce same run-time behavior as before. I hope....
iflags.num_pad and iflags.num_pad_mode should now be viewed as opaque
items used for communicating dynamically updated option settings to the
core only. Ports and/or interfaces which feel inclined to peek at them
should switch to Cmd.num_pad,&c instead. (I've made that switch for a
couple of places which would have stopped compiling due to sdir and ndir
going away, and for vms+tty where I could directly test the change(s),
possibly plus one or two places which got heldover over from my earlier
attempt that did try to update all of them. Ports which haven't made the
change yet ought to continue to work as-is though.)
Eventually ports/interfaces which implement alternate ways to invoke
commands (pull down menus or extra keyboard buttons or whatever) should be
able to scan Cmd.commands[] to figure out which input characters trigger
which nethack functions. The ones that currently use hardcoded key lists
will probably need to migrate before any dynamic key binding functionality
gets implemented. (Which may never happen; it's definitely not on my own
to-do list.) Cmd.serialno is intended to be the way for them figure out
when the commands have been changed (which right now only happens when 'O'
is used to alter the number_pad setting); perhaps a new interface callback
would be better suited for communicating this.
It may be necessary to rearrange header inclusion so that func_tab.h
gets included before flag.h (and/or struct cmd gets moved from the latter
to the former--but then func_tab.h would be needed in a bunch of places
which don't currently use it) to support some pre-ANSI compilers. And the
command initialization might need to be moved to somewhere earlier than
init_options() at some point if port/interface initialization starts caring
about it.
o Add support for zlib compression via ZLIB_COMP in config.h (ZLIB_COMP
and COMPRESS are mutually exclusive).
o rlecomp and zerocomp are run time options available if RLECOMP and
ZEROCOMP are defined, but not turned on by default if either COMPRESS
or ZLIB_COMP are defined.
o Add information to the save file about internal compression options
used when writing the save file, particularly rlecomp and zerocomp
support.
o Automatically adjust rlecomp and zerocomp (if support compiled in)
when reading in an existing savefile that was saved with those options
turned on. Still allows writing out of savefile in preferred format.
o In order to support zlib and not conflict with compress and uncompress
routines there, the NetHack internal functions were changed to
nh_uncompress and nh_compress as done in the zlib contribution received
in 1999 from <Someone>.
I tagged the sources NETHACK_3_5_0_PREZLIB prior to applying these
changes.
Fix the wizard mode crash From a bug report. Move the WIZKIT
message suppression to a lower level instead of trying to guard against
present and future pline() calls in the wishing code. The way that was
being handling wasn't suitable for dealing with quest feedback.
This also includes a couple of additional wishing synonyms.
on Sunday, April 4, 2004 at 20:27:06:
> On occassion when restoring a game where the
> character is wielding Sting, floor glyphs
> will show up before the --more-- prompt.
> These floor glyphs usually correspond to the
> location of monsters (sometimes they are just
> cavern features such as walls). Some of these
> floor glyphs are not in the character's line
> of sight upon restoring.
Also in this patch is a restore of Sting's ability
to glow blue.
This provides the core support needed for status field highlighting.
This patch doesn't actually perform status field highlighting for any port,
but provides the core hooks for doing so.
The syntax is:
OPTIONS=hilite_status:{fieldname}/{threshold}/{below}/{above}
where {fieldname} is the name of a status field.
{threshold} is the value used as the threshold to trigger a display
change. It can also be set to "updown" to trigger
a display change whenever it rises or whenever it falls.
If you end the threshold value with %, then it signifies
that you want to trigger the display change based on the
percentage of maximum.
{below}, {above}
are the color or display attribute that you want to use when
the field value is underneath the threshold. Supported display
fields are: normal, inverse, bold, black, red, green,
brown, blue, magenta, cyan, gray, orange,
bright-green, yellow, bright-blue, bright-magenta,
bright-cyan, or white.
Valid field names are:
alignment, armor-class, carrying-capacity,
charisma, condition, constitution, dexterity,
dungeon-level, experience-level, experience,
gold, HD, hitpoints-max, hitpoints, hunger,
intelligence, power-max, power, score,
strength, time, title, wisdom
Refer to window.doc for details. Guidebook updates to come later.
Introduction of a new set of window port status display
routines. The new routines are conditional on
STATUS_VIA_WINDOWPORT
being defined in config.h. See the experimental section,
where the #define resides for the time being.
An enhancement to the original to allow
two types of exceptions:
always pickup
never pickup
To specify "never pickup", begin the pattern string with '>'
which is NetHack's down direction symbol (for "leave it down")
To specify "always pickup", begin the pattern string with '<'
which is NetHack's up direction symbol.
For example, to pick up all arrows, regardless of the pickup_
types setting:
autopickup_exception = "<*arrows"
Add config.h experimental option AUTOPICKUP_EXCEPTIONS.
It's an interface-only change which allows you to add lines to your
config file to selectively avoid autopickup of items based on their
text description that is displayed when you pick them up. It does
it by matching a pattern against the xname singular return value.
For example:
autopickup_exception = "*corpse" will avoid picking up corpses, even if
food (%) is in your pickup_types.
autopickup_exception = "*brown*"
will avoid picking up any brown items (why, I do not know)
autopickup_exception = "*loadstone"
will NOT avoid picking up loadstones, unless they are already
identified, because the xname string will be "gray stone", so no
match there.
The matching has no knowledge of in-game objects, it is just
a text pattern match, thus it is an interface change, not a gameplay
change, and it is meant as a convenience for players.
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
> I'm working on a Nethack port, and one of the header files a
> library uses has a structure with a member named "red". Since
> includes/decl.h #defines red to something, this totally loses.
>
> Attached is a patch which fixes the color defines.
<Someone> wrote:
> Linux, Redhat 7.1 nethack 3.4.0
>
>Please see attached patch file.
>
>I'm attempting to move more stuff into the "read-only" area, in
>preparation for a port to another OS.
The NOCWD_ASSUMPTIONS conditional code allows readonly
parts of NetHack to be separated from areas that require write-access.
This allows the recent panic log needed a prefix.
Replace "feature_toggle" implementation with an easier-to-understand
boolean option called "lootabc".
Provide "showrace", an option to display the hero by race glyph rather
than by role glyph.
Document the above.
Remove some obsolete Mac options.
This adds a generic feature_toggle mechanism to
the game. Code that wants to offer two different
ways of doing something can add an entry to
feature_toggles[] (in decl.c), and create a
preprocessor macro for its array index in decl.h.
Then the code can test it using
if (feature_toggle(FEATURE_NAME))
..do_this..
else
..do_that..
The player can toggle the alternate code path
on using OPTIONS=feature_toggle:feature_name_1 feature_name_2 ...
This seems better than creating brand new options
for controlling features (ala prayconfirm, which
could switch to this single option feature_toggle
mechanism as well)
My first use of it is to allow toggling of the selectors
on the loot menu, which I'm hesitant to just change back
because now people are actively using the new selectors and
the complaints would be really loud if the interface were
to just switch back after they adjusted.
The default behaviour is the new behaviour "iob", but with an
OPTIONS=feature_toggle:loot_menu_selectors
in your config file, it will revert to using "abc" as it did
in 3.3.1. I'll add a Guidebook page of "features/behaviour
that can be toggled" later.
The toggles can only be done in defaults.nh, and are
not saved with the game.
The autodig code still requires lots of interaction, because of all the
digging messages. Make these messages behave more like boulder pushing
messages, where they only display if the previous move wasn't a push.
>
> I'd like the default for "Would you like to see your <whatever>"
> at the end of a game to be "y" instead of "n". I haven't asked
> for full disclosure in order to have it skipped if I press the
> space bar once too often by mistake.
This changes the way the flags.end_disclose array is used to
allow what this request is asking for. It should be backward
compatible with previous "disclose" options.
The order that the end_disclore options are stored:
inventory, attribs, vanquished, genocided, conduct
There is an array in flags:
end_disclose[NUM_DISCLOSURE_OPT];
with option settings for the each of the following:
iagvc [see disclosure_options in decl.c]:
Legal setting values in that array are:
DISCLOSE_PROMPT_DEFAULT_YES ask with default answer yes
DISCLOSE_PROMPT_DEFAULT_NO ask with default answer no
DISCLOSE_YES_WITHOUT_PROMPT always disclose and don't ask
DISCLOSE_NO_WITHOUT_PROMPT never disclose and don't ask
Those setting values can be used in the option
string as a prefix to each disclosure option
to get the desired behaviour for that option.
For backward compatibility, no prefix is actually required,
and the presence of a i,a,g,v, or c without a prefix sets
the corresponding value to DISCLOSE_YES_WITHOUT_PROMPT;
The actual prefixes used are controlled by the following in flag.h:
#define DISCLOSE_PROMPT_DEFAULT_YES 'y'
#define DISCLOSE_PROMPT_DEFAULT_NO 'n'
#define DISCLOSE_YES_WITHOUT_PROMPT '+'
#define DISCLOSE_NO_WITHOUT_PROMPT '-'
As far as the docs go, I don't know if I've got the *roff
stuff right. The TeX stuff looks okay when I converted it to .pdf.
This increments EDITLEVEL. If that is a problem, I can
add a routine to restore.c to perform a conversion of the old
values in flags. Let me know.
