Add a non-string identifier to window_procs for use in runtime
identification of the current window port being used.
Use a macro WPID to add the identification at the top of the
various existing window_procs declarations. It expands to the
existing text string, as well as the newly added field wp_id
with a wp_ identifier.
For example, WPID(tty) expands to: "tty", wp_tty
The generated wp_tty must be present in the wp_ids enum at
the top of include/winprocs.h.
The WINDOWPORT(x) macro has been updated to expand to a simple
value comparison (port.wp_id == wp_x), instead of a
string comparison.
(user-side decisions really, but as it stands right now
user-side decisions/options are made and processed by the core)
add a parameter to add_menu so color can be passed
This starts the tty perm_invent just in time later in the
startup rather than initializing it with the other
game windows.
This also splits the duties:
The core will inquire from the window port about how many
inventory slots it can fill.
The core will handle figuring out the inventory text and
inventory letters, and will do the traversing of internal
data structures like obj chains, and passing customization
options on to the window port.
The window port will look after placing each inventory slot's
text at an appropriate location on the screen.
This, in theory, makes the core-portion available for
window ports other than tty to use, though none currently do.
The decision of what goes in an inventory slot is all left up
to the core with the update_invent_slot interface.
Documentation updates will come later, not at this time.
Modify the error message delivery when too-small so that it works for
both NETHACKOPTIONS or .nethackrc and for 'O'. "Early failure" isn't
very early; using pline() instead of raw_print() ends up writing to
the base window but also works normally when used for failed attempt
to set perm_invent with 'O'.
Fix the off by one error in height which required an extra line that
ended up going unused.
Fix an off by one error in the middle divider. Forcing the same item
from the left column to the right column, I was seeing
"f - an uncursed +0 pair of leather glove" ["s (being worn)" truncated]
"F - an uncursed +0 pair of leather gl"
After the fix I get
"f - an uncursed +0 pair of leather glov"
"F - an uncursed +0 pair of leather glo"
(When terminal width is even, the left side is one character wider
than the right.)
Split the invent window creation code out of tty_create_nhwwindow() to
new routine tty_create_invent(). I came across
if (r == 0 || (newwin->maxrow - 1)
in the process (note lack of 'r ==' in the second part). I'm not sure
what the initialization code is intended to accomplish but missing
that init for the bottom (boundary box) row didn't seem to be causing
any problem.
This forces the required size to be big enough to handle statuslines:3
regardless of what the setting for that is at the time the perm_invent
window is created. When the value is 2, there will be a blank line
between status and the boundary box of perm_invent. When it is 3, the
third line will use that line and the only separator will be the top
boundary box line. Toggling back and forth with 'O' works as expected.
I'm not sure what happened but something that worked when I tested
yesterday wouldn't work today. Have 'O' was pass TRUE rather than
FALSE to tty_perm_invent_toggled() when perm_invent is set to 'on'.
And skip that code for .nethackrc or NETHACKOPTIONS because it was
segfaulting.
Boolean switches: add an omitted 'break', plus a few 'default' cases
that would matter if someone turned on the warning about a switch
statement with 'enum' index that doesn't have cases for all possible
values of that enum. I haven't made any attempt to be exhaustive
about those; these few were just right in the same place.
The code for toggling perm_invent when windowtype=="tty" was inserted
into the middle of several switch cases that share 'need_redraw' so
was getting executed for various other options such as 'use_inverse'
that precede it in the list of cases. It was also continuing on to
general feedback for boolean options, reporting "'perm_invent option
toggled on" even if it failed and the option stayed off.
Add a rudimentary experimental always-up inventory display
capability to tty when the perm_invent option is in effect.
It requires an additional 28 rows available on the terminal
underneath the bottom status line.
It hasn't been optimized for performance as of yet.
Switch to using a macro invocation Verbos(n, s) in place of the
flags.verbose checks.
Provide the mechanics for individual suppression of any of the
existing messages that were considered verbose.
Mechanics only - this code update does not provide any means of
setting the suppression bits.
iflags.verbose = 0
is still a master suppression of all the verbose messages.
iflags.verbose = 1
turns on the verbose messages only for those whose suppression
bit is 0 (not set).
3.7 has a new size prefix for globs that 3.6 didn't. The code that
decides whether player is naming slime molds after an actual object
needs to know about it.
A new feature, enabled by default to maximize testing, but one which can
be disabled by commenting it out in config.h
With this, some additional information is added to the glyphmap entries
in a new optional substructure called u with these fields:
ucolor RGB color for use with truecolor terminals/platforms.
A ucolor value of zero means "not set." The actual
rgb value of 0 has the 0x1000000 bit set.
u256coloridx 256 color index value for use with 256 color
terminals, the closest color match to ucolor.
utf8str Custom representation via utf-8 string (can be null).
There is a new symset included in the symbols file, called enhanced1.
Some initial code has been added to parse individual
OPTIONS=glyph:glyphid/R-G-B entries in the config file.
The glyphid can, in theory, either be an individual glyph (G_* glyphid)
for a single glyph, or it can be an existing symbol S_ value
(monster, object, or cmap symbol) to store the custom representation for
all the glyphs that match that symbol.
Examples:
OPTIONS=glyph:G_fountain/U+03A8/0-150-255
(Your platform/terminal font needs to be able to include/display the
character, of course.)
The NetHack core code does parsing and storing the customized
entries, and adding them to the glyphmap data structure.
Any window port can utilize the additional information in the glyphinfo
that is passed to them, once code is added to do so.
Also, consolidate some symbol-related code into symbols.c, and remove it from
files.c and options.c
For char *next; don't compare (next = index(...)) != '\0'.
'\0' has value 0 and 0 used in a pointer context is a null pointer.
So the code worked as intended even though it wasn't written as
what was intended. Fix: take off the char decoration.
Implement 'untrap' as an 'autounlock' action. Quite a bit more work
than anticipated. The new documentation is rather clumsy; too many
if-this and if-not-that clauses have intruded.
I'll be astonished if all the return values are correct....
[A couple of places were checking for (rx != 0 && ry != 0) to decide
whether they were performating an autounlock action at <rx,ry> but
that erroneously excludes the top line of the map if the current
level extends that far. Just check rx for zero/non-zero.]
This gives the player more control over what autounlock does. It is
now a compound option rather than a boolean, and takes values of
autounlock:none
!autounlock or noautounlock (shortcuts for none)
autounlock:untrap + apply-key + kick + force (spaces are optional
or can be used instead of plus-signs, but can't mix "foo bar+quux")
autounlock (without a value, shortcut for autounlock:apply-key).
Default is autounlock:apply-key.
Untrap isn't implemented (feel free to jump in) so is suppressed from
the 'O' command's new sub-menu for autounlock. It's parsed and
accepted from .nethackrc but won't accomplish anything.
[Just musing: it should be feasible to kick in direction '.' to break
open a container or #force to an adjacent spot to break open a door.
If that was done, autounlock:kick+force (or more likely autounlock:
apply-key+kick+force when lacking a key) would resort to force if hero
couldn't kick due to wounded legs or riding.
This changes struct flags so increments EDITLEVEL again.
This includes pull requests #750 from entrez and #751 from FIQ but was
entered from scratch rather than using use their commits.
Closes#750Closes#751
mungspaces() returns its argument itself, so `newop` is assigned to `buf`, and always non-null.
`tfg` and `tbg` is assigned to (some addition of) `newop`, so these are also always non-null.
Hide 'altkeyhandling' from the 'O' menu for !WIN32 builds. If
present in run-time config file it will be parsed and then ignored.
Instead of showing "unknown" for the value of the 'hilite_status'
compound option, show "none" if there are no highlighting rules, or
a pointer to other option "status highlight rules" when there are.
Deal with a few function parameters that are used for some
combination of build-time config settings and unused for others.
Change 'O's sub-menu for selecting new msg_window option setting to
work similar to the one for menustyle: show a description of what
the values mean with a two-line, two-column menu entry. Also make
its current value be pre-selected.
msg_window is a bit more complicated than menustyle because only
some interfaces support it and curses only supports two of the four
choices. It currently has one hard-coded reference to "^P" (in the
tty-specific 'combination' choice). Changing that is feasible but
seems like more trouble than it'd be worth.
When using 'O' to set the menustyle option, include a description of
each of the styles. Makes the menu entries two lines of two columns
each: first line contains the setting value and the first half of
its description; second line has blank left column and second half
of description in the right one. Value on first line and single-line
description on second would have been simpler but this seems easier
to read--the four possible values don't have any clutter between them.
Also, mark the current value as pre-selected.
Change the 'menuinvertmode' default from 0 to 1 so that it gets more
exercise. It can be changed back to 0 via option settings but it's
doubtful that anyone will care enough to bother.
Some pickup/take-off actions have been using it to avoid setting
their 'all' choice when bulk toggling for current-page or whole-menu
takes place; 'O' specifies it for its '?' help choice. This adds
the skipinvert flag to the 'all' choice of #wizidentify.
The comments describing it now state that menuinvertmode applies to
bulk set-on operations as well as to toggle-on/off operations but
that will only be true if/when interfaces call menuitem_invert_test()
for set as well as for invert. tty is about to start doing that.
I've implemented 'nethack -nethackrc=filename' as an alternative to
'NETHACKOPTIONS='@filename' nethack' but at the moment it doesn't
work because the command line parsing comes after the run-time config
file has already been processed. But this part should work, or maybe
have problems spotted and fixed if it doesn't. The RC file part of
initoptions_finish() has been rewritten so that it won't need extra
replication of
| set_error_handling()
| process_file()
| reset_error_handling()
| if (NETHACKOPTIONS) {
| set_error_handling()
| process_options()
| reset_error_handling()
| }
I've tried to test all the combinations mentioned in the comment but
am not sure that I covered everything, particulary for repeating
earlier tests after making incremental changes.
In the name of accessibility: Prevent moving into dangerous liquids.
Now with themed rooms, water and lava are more common, and it's
unreasonable to expect blind players to check every step for those.
With paranoid:swim, just prevent normal walking into those liquids,
unless you prefix the movement with 'm', or if the liquid would not
harm you.
Doesn't completely prevent an accidental dunking - for example
if the hero is impaired or couldn't see the liquid.
This comes from xNetHack by copperwater <aosdict@gmail.com>
with some changes to the code.
I don't try to toggle 'number_pad' very often, but when I do I almost
always type '0' instead of 'a' for Off or '1' instead of 'b' for On
on the first attempt. The menu shows
| a - 0 (off)
| b - 1 (on)
| c - 2 (on, MSDOS compatible)
| d - 3 (on, phone-style digit layout)
| e - 4 (on, phone-style layout, MSDOS compatible)
| f - -1 (off, 'z' to move upper-left, 'y' to zap wands)
This change makes '0' through '4' be undocumented group accelerators
for 'a' through 'e' (and '5' for 'f') in the sub-menu put up by 'O'.
tty and X11 worked as-is for '0' and required what amounts to a pair
of one-line changes to handle the other digits.
It doesn't work for curses and Qt (no idea about Windows GUI) because
they insist on treating any typed digit as the start of a count even
if one or more menu entries include that digit as a group accelerator.
(They also fail to support '0' as the group accelerator for iron-ball
class in the menu for multiple-drop.)
error 28 in line 4090 of "invent.c": redeclaration of var <adjust_ok> with new storage-class
error 28 in line 4100 of "invent.c": redeclaration of var <adjust_gold_ok> with new storage-class
error 28 in line 610 of "mdlib.c": redeclaration of var <count_and_validate_winopts> with new storage-class
error 28 in line 3846 of "options.c": redeclaration of var <pfxfn_cond_> with new storage-class
error 28 in line 3886 of "options.c": redeclaration of var <pfxfn_font> with new storage-class
error 28 in line 5307 of "options.c": redeclaration of var <determine_ambiguities> with new storage-class
error 28 in line 5343 of "options.c": redeclaration of var <length_without_val> with new storage-class
error 28 in line 6853 of "options.c": redeclaration of var <illegal_menu_cmd_key> with new storage-class
error 28 in line 7708 of "options.c": redeclaration of var <count_apes> with new storage-class
error 28 in line 2686 of "pickup.c": redeclaration of var <stash_ok> with new storage-class
error 28 in line 1008 of "read.c": redeclaration of var <can_center_cloud> with new storage-class
error 28 in line 31 of "rnd.c": redeclaration of var <whichrng> with new storage-class
If you want to declare a pointer which the address pointed to is constant,
you should declare it as like `static const char *const var = "...";`.
This commit supplies missing `const` and prevents some programming
error in the future.
Make the code for setting up the 'O' menu's '?' entry more compact.
Also adds 'skipinvert' flag for that entry but it doesn't do anthing
here. I thought that it had been implemented, but aside from the
flag itself, it doesn't seem to exist.
When rest_on_space is On, assign same function as for #wait to the
<space> key. When Off, set that key to Null instead. Binding some
other command to <space> when rest_on_space is Off doesn't work but
I would classify that as something to be discouraged anyway.
When picking '?', showing help, and then re-executing the 'O' menu,
let doset() perform its normal cleanup after the first pass instead
of duplicating that prior to making the second pass.
When using the 'O' menu, if player picks '?' plus additional choices,
it shows help and then operates on the other choices as if normal.
But for the latter, it was re-using the '?' pick as an option to
change, attempting (and silently failing) to toggle the legacy option
because it happens to be allopts['?' - 1]. It was also relying on
the list of picks being sorted in menu order rather than in player's
selection order or some other arbitrary ordering, something not
specified by the windowing specs.
Instead of looking for '?' as the first selection, process the list
normally and show the options menu help if '?' is found as a choice.
If any interface doesn't return a set of multiple picks in menu
order, the help might not be seen before prompting for compounds,
but it would be very unusual to ask for help and also try to make
changes at the same time so this doesn't seem worth worrying about.
Move the help text for the 'O' command from the code into its own file
and allow that to be accessed from the '?' menu as well as by choosing
entry '?' in the 'O' menu.
sys/unix/Makefile.top has been updated to handle new 'optmenu', others
need to catch up. The game will still build and run without the file
but asking for options menu help won't work until they do.
