Put the flag that parse() uses to tell readchar() that the next
keystroke is a command into the program_state structure instead of
having it be a static variable in cmd.c. Conceivably an interface
could make use of it, and even if none do, it is program state....
More #558
Setting the 'altmeta' option affects how ESC is handled. Normally it
is for terminals/emulators which transmit two character sequence ESC c
when the user types Meta+c, but it can also be used to construct meta
characters 'manually' by typing ESC c. Unfortunately setting this
option has a side-effect of requiring a second character after ESC
before our readchar() will return, so it is only honored when parse()
wants the next command, not for general input.
When readchar() was recently split into two parts, the use of static
variable 'alt_esc' by parse() and readchar() was removed. That
resulted in requiring the user to type a second character whenever
ESC was typed, instead of just when it was transmitted or typed as
the prefix of a command that uses a meta-character keystroke.
Instead of just putting 'alt_esc' back, do things differently by
adding static 'getting_cmd' flag instead.
Fixes#558
Add des.finalize_level() used for testing in conjunction with
des.reset_level().
Add nhc.DLB to return 0 or 1 if DLB was defined at compile-time.
Change the test_lev.lua to give more informative messages instead of
just lua error when required file doesn't exist.
Add bigrm-11 to the level tests.
The for loop which iterates through the list of movement keys in
movecmd(cmd.c) was updated in 5abf948116 to count down to 0 instead of
up to the end of the list. This commit inadvertently introduced an
off-by-one error which started the loop one past the actual end of the
array. On my system this made 'H' stop working as the 'run West' key.
Retravel travels to the previously selected destination.
Also changes the travel-via-mouse to execute the extended command
instead of faking a special key.
Put the rush and run movement keys into g.Cmd instead of bit twiddling
the normal walk keys in multiple places to get the run and rush keys.
Allow meta keys in getpos. Use the normal running keys to fast-move
in getpos, instead of explicit HJKL - I polled couple places online,
and number_pad users did not use the HJKL keys in getpos.
Make meta keys work even after a prefix key.
Allows the fire-command to autowield a launcher; it will now
do either swapweapon or wield an appropriate launcher, if you
have ammo quivered.
This assistance can be turned off with the fireassist boolean option.
Adds a rudimentary command queue, which allows the code to add keys
or extended commands into the queue, and they're executed as if
the user did them. Time passes normally when doing the queue,
and the queue will get cleared if hero is interrupted.
Have curses call the core get_count() routine instead rolling its
own so that backspace and delete are supported. That part was
trivial to accomplish. Unfortunately it brought the disappearing
menu phenomenon back so it became more complicated overall.
Quit is not a commmand you usually need very often, and generally
don't want to use by accident.
Apparently, on Spanish keyboard layout, n-with-tilde is interpreted
by the Windows NetHack as M-q, and the key is next to l. Loot also
asks for confirmation, just like quit.
Prevent stuff like this by not binding the quit command to any key.
When the fuzzer is running, don't allow a randomly generated M-X
keystroke to switch from debug mode to explore mode.
[Unintended side-effect of the combination of two earlier changes:
assigning M-X as default key for #exploremode and allowing someone
in debug mode to voluntarily downgrade to explore mode (which should
never impact normal play and makes some types of testing simpler).]
Fixes#512
The #twoweapon command was flagged as autocomplete back when using
an extended command was the only way to execute it. Take that off
since simple 'X' suffices. Do the same for wizard mode commands
that can be invoked with control characters. Probably ought to do
the same for #overview too but this change doesn't.
I started to add the autocomplete flag for #exploremode but that
would require an extra letter for #enhance so I decided not to.
There are some wizard mode commands that can't be executed under
X11 because they aren't flagged to autocomplete and its extended
command selection widget only offers autocomplete commands as
choices. I haven't attempted to change that.
Always require paranoid confirmation for #panic rather than just
when it has been enabled for #quit.
Report from roughly two and half years ago was about "<monster>
opens the door" without displaying <monster>.
Monster movement first decides whether a monster can pass closed
door. If so, the monster is placed at the door spot, a message
is given about that movement (unlock, open, smash down, &c), and
finally the map is updated.
Changing the sequence to update the map before issuing the door
message was not sufficient to fix this. In the corridor plus
closed door plus lit room map fragment shown here, when 'O' moved
to '+', you would see it there if the hero is at '1' or '2', but
not if at '3', '4', or '5'; open door was shown instead. But the
message described 'O' accurately rather than as "it" for all those
hero locations.
: -----
: #O+1...
: |2...
: |3...
: |4...
: |5...
: -----
For 3,4,5 the #vision command shows the closed door as 3 before
the O move, but blank (0) after. In other words, the closed door
is within line of sight but once opened, the doorway spot isn't.
It makes sense that the closed door behaves like a wall but I'm
not sure whether the behavior for an open door's breach does too.
I had an awful workaround that successfully displayed the monster,
but it wouldn't show the same thing if the door was already open,
so I've changed the situation to yield "You see a door open."
The pull request that fixed a couple of instances where it was
possible to have multiple entries for gold in inventory indirectly
pointed out that the error checking was clumsy. If you executed
the #adjust command while having two '$' items in inventory, you
were told twice that you had multiple stacks of gold in inventory.
Change how that's handled so that the warning appears at most once
for any given #adjust command. Also avoids having #adjust's use
of getobj() re-scan entire invent for every item in invent.
Also, if player did manage to get two or more '$' entries, #adjust
would allow moving any but the last to a letter entry. Once in a
letter, further #adjust with count specified could split the letter
gold entries into even more gold entries. Now, if the player picks
gold as the #adjust 'from' item (which is only possible when there
are wrong letter gold entries or multiple ones or both) then #adjust
will now force 'to' slot to be '$' (without asking player to pick).
Lastly, the inventory check for multiple and/or wrong slot gold is
now performed by wizard mode sanity_check() in addition to #adjust.
Add new '|' command, aka #perminv, which allows the player to
send menu scrolling keystrokes to the persistent inventory window.
Implemented for X11, where its usefulness is limited, and for
curses, where it is more needed and also more fully functional.
The interface can either prompt for one keystroke, act upon it,
and return to normal play, or it can loop for multiple keystrokes
until player types <return> or <escape>. X11 does the former if
the 'slow' application resource is False so that prompting uses
popups, and the latter when 'slow' is True where prompting is in
a fixed spot and doesn't end up causing the persistent inventory
window to be stacked behind the map window. curses always does
the loop-until-done approach. It also accepts up and down arrow
keys to scroll one line at a time.
Also adds two new menu scrolling commands, menu_shift_right (key
'}' by default) and menu_shift_left ('{') if wincap2 flags contain
WC2_MENU_SHIFT. Shifting allows different substrings of too-long
lines to be seen.
For X11, neither works because their handling requires a horizontal
scrollbar and for some reason that escapes me our menus don't have
one of those. If they did, shifts could work for all menus but a
shifted window would hide the selection letters. So shifting would
be most usefully done as: pan right, read more of any long lines,
immediately pan back to the left.
For curses, they only apply to the persistent inventory window.
Shift right redraws it with class headers and inventory letters
shown normally but the item descriptions omit their leftmost
portion, showing more text towards the end. Shift left reverses
that and does nothing if the beginning is already in view. Forward
and backward scrolling while shifted leave the shift in place.
OPTIONS=menu_previous_page:\mv
BINDINGS=M-v:menu_previous_page
both worked, but
OPTIONS=menu_previous_page:M-v
BINDINGS=\mv:menu_previous_page
both failed. Make all four variations work. Tiny change made large
by the need to move some things around.
The option definition for menu_first_page had a couple of its flag
bits swapped. I didn't try to figure out whether that had any impact.
"Demote" wizmgender from an obscure wizard mode extended command
to an obscure wizard mode boolean option. Behaves the same except
that no message is given when the value gets toggled.
Whitelist all the verified existing triggers:
makedefs.c: In function ‘name_file’
attrib.c: one compiler balks at a ? b : c for fmtstring
cmd.c: In function ‘extcmd_via_menu’
cmd.c: In function ‘wiz_levltyp_legend’
do.c: In function ‘goto_level’
do_name.c: In function ‘coord_desc’
dungeon.c: In function ‘overview_stats’
eat.c: one compiler balks at a ? b : c for fmtstring
end.c: one compiler balks at a ? b : c for fmtstring
engrave.c: In function ‘engr_stats’
hack:c one compiler balks at a ? b : c for fmtstring
hacklib.c: one compiler balks at a ? b : c for fmtstring
insight.c: one compiler balks at a ? b : c for fmtstring
invent.c: In function ‘let_to_name’
light.c: In function ‘light_stats’
mhitm.c: In function ‘missmm’
options.c: In function ‘handler_symset’
options.c: In function ‘basic_menu_colors’
options.c: In function ‘optfn_o_autopickup_exceptions’
options.c: In function ‘optfn_o_menu_colors’
options.c: In function ‘optfn_o_message_types’
options.c: In function ‘optfn_o_status_cond’
options.c: In function ‘optfn_o_status_hilites’
options.c: In function ‘doset’
options.c: In function ‘doset_add_menu’
options.c: In function ‘show_menu_controls’
options.c: In function ‘handle_add_list_remove’
pager.c: In function ‘do_supplemental_info’
pager.c: In function ‘dohelp’
region.c: In function ‘region_stats’
rumors.c: sscanf usage
sounds.c: In function ‘domonnoise’
spell.c: In function ‘dospellmenu’
timeout.c: In function ‘timer_stats’
topten.c: In function ‘outentry’, fscanf, sscanf, fprintf usage
windows.c: In function ‘genl_status_update’
zap.c: one compiler balks at a ? b : c for fmtstring
win/curses/cursstat.c: In function ‘curses_status_update’
win/tty/wintty.c: In function ‘tty_status_update’
win/win32/mswproc.c: In function ‘mswin_status_update’
It turns out that macOS barked when a POP was issued without
a prior PUSH, so since the DISABLE_WARNING_CONDEXPR_IS_CONSTANT
expanded to an empty macro on that platform.
Include a corresponding
RESTORE_WARNING_CONDEXPR_IS_CONSTANT macro for use with that
particular warning.
Microsoft and other non-GNU compilers don't recognize gcc tricks
like /*NOTREACHED*/ to suppress individual warnings. clang recognizes most
of them because it tries to be gcc-compatible. Because of that, a lot of
potentially useful warnings have had to be completely suppressed in the
past in all source files when using the non-gcc compatible compilers.
Now that the code is C99, take advantage of a way to suppress warnings for
individual functions, a big step up from suppressing the warnings
altogether.
Unfortunately, it does require a bit of ugliness caused by the
insertion of some macros in a few spots, but I'm not aware of
a cleaner alternative that still allows warnings to be enabled
in general, while suppressing a warning for known white-listed
instances.
Prior to the warning-tiggering function, place whichever one of
the following is needed to suppress the warning being encountered:
DISABLE_WARNING_UNREACHABLE_CODE
DISABLE_WARNING_CONDEXPR_IS_CONSTANT
After the warning-triggering function, place this:
RESTORE_WARNINGS
Under the hood, the compiler-appropriate warning-disabling
mechanics involve the use of C99 _Pragma, which can be used
in macros.
For unrecognized or inappropriate compilers, or if
DISABLE_WARNING_PRAGMAS is defined, the macros expand
to nothing.
Reformat the list of commands, making all of them take two lines
(except for a couple that need more) even if they fit on one.
Put "#wizmgender" into alphabetical order. I don't think we need
it anymore, but if we keep the functionality then it should be
demoted from a command to a wizard mode boolean option.
Also wrap a handful of lines wider than the formatting threshold.
Let users of #wizintrinsic set a specific amount by which they want to
increment each particular timeout, by entering a count/typing in
numerals before selecting the item in the list. I think doing it this
way should be pretty intuitive to players who are familiar with the
'enter count -> make selection' flow of normal inventory menus in
NetHack, and is simpler than using a separate prompt, as was mentioned
as a possibility in a comment.
When an intrinsic is selected without entering a count, the increment
will continue to default to the previous value of 30; this value is set
via the DEFAULT_TIMEOUT_INCR macro.
I also deleted a redundant declaration of wiz_intrinsic; the duplicate
seems to have been added by mistake in ff6139c6c5.
Gcc 9 has become more vocal with sprintf buffer overflow
checking. Remove these sprintf warnings by changing the
offending calls to a snprintf wrapper that will explicitly
check the result.
I noticed that the & command was claiming that ^A is an unknown
command. Unlike the old static version, or the replaced-before-
ever-released conditional version, the fully dynamic variation
of '&' didn't know about any of the special commands: prefix
letters, ESC, and ^A.
further adjustments to the window port interface to pass a pointer
to a glyph_info struct which describes not just the glyph number
itself, but also the ttychar, the color, the glyphflags, and the
symset index.
This affects two existing window port calls that get passed glyphs
and does the parameter consistently for both of them using the
glyph_info struct pointer:
print_glyph()
add_menu().
The recently added glyphmod parameter is now unnecessary and has been
removed.
remove unintentionally left M2_MALE flag on dwarf lord/lady/leader
provide a way to verify gender information relayed from the core
in debug mode on tty via #wizmgender debugging extended command
add MALE, FEMALE, and gender-neutral names for individual monster species
to the mons array. The gender-neutral name (NEUTRAL) is mandatory, the
MALE and FEMALE versions are not.
replace code uses of the mname field of permonst with one of the three
potentially-available gender-specific names.
consolidate some separate mons entries that differed only by species into a
single mons entry (caveman, cavewoman and priest,priestess etc.)
consolidate several "* lord" and "* queen/* king" monst entries into
their single species, and allow both genders on some where it makes some
sense (there is probably more work and cleanup to come out of this at some
point, and the chosen gender-neutral name variations are not cast in stone
if someone has better suggestions).
related function or macro additions:
pmname(pm, gender) to get the gender variation of the permonst name. It
guards against monsters that haven't got anything except NEUTRAL naming
and falls back to the NEUTRAL version if FEMALE and MALE versions are
missing.
Ugender to obtain the current hero gender.
Mgender(mtmp) to obtain the gender of a monster
While the code can safely refer directly to pmnames[NEUTRAL] safely in the
code because it always exists, the other two (pmnames[MALE] and
pmnames[FEMALE] may not exist so use:
pmname(ptr, gidx)
where -ptr is a permonst *
-gidx is an index into the pmnames array field of the
permonst struct
pmname() checks for a valid index and checks for null-pointers for
pmnames[MALE] and pmnames[FEMALE], and will fall back to pmnames[NEUTRAL] if
the pointer requested if the requested variation is unavailable, or if the
gidx is out-of-range.
Allow code to specify makemon flags to request female or male (via MM_MALE
and MM_FEMALE flags respectively)to makedefs, since the species alone doesn't
distinguish male/female anymore. Specifying MM_MALE or MM_FEMALE won't
override the pm M2_MALE and M2_FEMALE flags on a mons[] entry.
male and female tiles have been added to win/share/monsters.txt.
The majority are duplicated placeholders except for those that were
separate mons entries before. Perhaps someone will contribute artwork in the
future to make the male and female variations visually distinguishable.
tilemapping via has the MALE tile indexes in the glyph2tile[]
array produced at build time. If a window port has information that the
FEMALE tile is required, it just has to increment the index returned
from the glyph2tile[] array by 1.
statues already preserved gender of the monster through STATUE_FEMALE
and STATUE_MALE, so ensure that pmnames takes that into consideration.
I expect some refinement will be required after broad play-testing puts it to
the test.
consolidate caveman,cavewoman and priest,priestess monst.c entries etc
This commit will require a bump of editlevel in patchlevel.h because it alters
the index numbers of the monsters due to the consolidation of some. Those
index numbers are saved in some other structures, even though the mons[] array
itself is not part of the savefile.
Window Port Interface Change
Also add a parameter to print_glyph to convey additional information beyond
the glyph to the window ports. Every single window port was calling back to
mapglyph for the information anyway, so just included it in the interface and
produce the information right in the display core.
The mapglyph() function uses will be eliminated, although there are still some
in the code yet to be dealt with.
win32, tty, x11, Qt, msdos window ports have all had adjustments done to
utilize the new parameter instead of calling mapglyph, but some of those
window ports have not been thoroughly tested since the changes.
Interface change additional info:
print_glyph(window, x, y, glyph, bkglyph, *glyphmod)
-- Print the glyph at (x,y) on the given window. Glyphs are
integers at the interface, mapped to whatever the window-
port wants (symbol, font, color, attributes, ...there's
a 1-1 map between glyphs and distinct things on the map).
-- bkglyph is a background glyph for potential use by some
graphical or tiled environments to allow the depiction
to fall against a background consistent with the grid
around x,y. If bkglyph is NO_GLYPH, then the parameter
should be ignored (do nothing with it).
-- glyphmod provides extended information about the glyph
that window ports can use to enhance the display in
various ways.
unsigned int glyphmod[NUM_GLYPHMOD]
where:
glyphmod[GM_TTYCHAR] is the text characters associated
with the original NetHack display.
glyphmod[GM_FLAGS] are the special flags that denote
additional information that window
ports can use.
glyphmod[GM_COLOR] is the text character
color associated with the original
NetHack display.
Support for including the glyphmod info in the display glyph buffer
alongside the glyph itself was added and is the default operation.
That can be turned off by defining UNBUFFERED_GLYPHMOD at compile time.
With UNBUFFERED_GLYPHMOD operation, a call will be placed to map_glyphmod()
immediately prior to every print_glyph() call.
Make '?i' show special commands (primarily prefixes) without any
key assigned (^A and ^C are possible by undefining DOAGAIN and
defining NO_SIGNAL, respectively, not sure about any others) or
are blocked because another special command earlier in the list
is bound to the same key or player has tried to bind one to an
active movement command (ie, key used for movement by the current
number_pad setting).
Binding 'repeat' (DOAGAIN, or redo) to a different key than ^A
didn't work as intended because the code that used it was
checking for DOAGAIN (a key value from config.h) instead of
g.Cmd.spkeys[NHKF_DOAGAIN] (the key currently bound to repeat).
Contrary to the github issue, re-bound prefix keys worked ok for
me if followed by a direction. However, they behaved strangely
if followed by anything else. If the keystroke was stolen from
some other command and that command hadn't been bound to another
key, following the prefix with a non-direction could end up
executing the command that used to own the key. For example,
BIND=d:nopickup
to use 'd' to move without auto-pickup would work if you used
d<direction> but if you used d<something-else> if would execute
the drop command.
The NHKF_REQMENU prefix could be bound to some key other than
'm' but it only worked as intended if the new key was a movement
prefix.
This also makes DOAGAIN be unconditional. If it is deleted or
commented out in config.h, the default binding will be '\000' so
unusable (freeing up ^A for something), but still be available
to be bound to some key (perhaps even ^A).
This also includes an unrelated change to mdlib.c. The comments
added to config.h will force a full rebuild. Changing mdlib.c
now rather than separately will avoid forcing that twice.
Fixes#426
If you set COLNO larger than BUFSZ, few places cause a buffer overrun.
Add a new buffer size definition, COLBUFSZ, which is the larger of
COLNO and BUFSZ, used in places that care about a screen-wide string.
The pull request changed \ and ` output to unconditionally show
discoveries in alphabetical order. That's nearly useless except
when looking at prediscovered weapons and armor that fighter
types start out knowing.
This allows the player to choose sorting order via the new
'sortdiscoveries' option. In addition to setting it via
config file or 'O', it can be set via 'm' prefix for \ and `.
Choices are:
o - sort by class, by order of discovery in class (default);
s - sort by 'sortloot' classification which groups sub-class
items (so all helmets before any other armor, then all
gloves, then boots, and so on); within each sub-class, or
whole class for classes which don't subdivide so usefully,
partly-discovered types (where a name has been assigned)
come before fully ID'd types;
c - sort by class, alphabetically within class;
a - sort alphabetically across all classes.
Turned out to be a large amount of work for fairly little gain,
although I suspect that 'sortdiscoveries:s' will eventually be
more popular than the default.
Invalidates existing save files so that current sort setting can
persist across save/restore cycles.
Closes#334
Clicking on an adjacent location while 'herecmd_menu' is On
didn't run therecmd as intended. If it had, maybe somebody
would have noticed how broken it is. This reorganizes the mouse
click handling but leaves therecmd commented out since it hasn't
been fixed.
The #therecmdmenu command and tentative click handling for
adjacent spots should probably be removed. They've been in place
for slightly over three years and nobody has ever reported that
they don't work properly.
'? i' shows three keyless commands in the General section. This
makes M-X the key for #exploremode. #herecmdmenu and #therecmdmenu
are still keyless but now autocomplete.
A ridiculous amount of documentation for a three line code change.
Allow changing form debug mode to explore mode without resorting
to a debugger. The same caveat, "you won't be able to change back,"
applies as when in normal play.
Character's name will remain "wizard" rather than reverting to
whatever it would have been if not starting in wizard mode.
Make the key bindings help better able to decide whether a key
binding actually works. If you bind some command to a key that is
used by default for a prefix, the commands array will indicate that
it (the bound key) runs the bound command. But if you don't bind
some other key to the prefix action, typing that earlier key will
perform the prefix action instead. The code for displaying the
list of key bindings needs to know that for the case where no other
key runs the command.
BINDINGS=M:takeoffall
will still report 'A'==takeoffall, which continues to work, but it
would not show 'M'==takeoffall because 'M' is still used to run
without autopickup which takes precedence over ordinary commands.
BINDINGS=A:nothing
BINDINGS=M:takeoffall
would omit any mention of takeoffall in the '? i' output. Now it
will show #takeoffall as a keyless command at the end of the 'Game
commands' section.
Having recently noticed that using <del> aka <delete> aka <rubout>
could work as a command, assign it to #terrain. #terrain was the
only command in the "game" subset of commands as shown by '? i'
that didn't have any key assignment.
Since <delete> might be swapped with <backspace> on some terminals
and is a keypad key on the typical PC keyboard, it might not work
reliably depending on nethack's number_pad mode or the hardware
Num-Lock setting. Players in either of those situations haven't
lost anything; they can still use extended command #terrain.
