For the searching capability offered by '# ?', use ':' instead of 's'
to activate it. Otherwise, if the player typed ':', menu processing
would handle that and would search the few menu entries (for selectors
'a', 's'--now ':', and maybe 'z') when we're interested in searching
the data displayed via many separator lines.
I left 's' as the selector for "show all, clear search" once a search
has been performed, but perhaps that ought to be switched to ':' too.
Demote #monpolycontrol and #wizdebug_traveldisplay from commands to
simple boolean options. The former has the same name, the latter
is called travel_debug. Rename #wizdebug_bury to #wizbury; it
shouldn't matter that it goes away when compiled without DEBUG.
There are now five wizard-mode boolean options: monpolycontrol,
sanity_check, and wizweight are documented in the Guidebook;
menu_tab_sep and travel_debug are commented out there.
Guidebook.mn has been tested; Guidebook.tex has not.
Reorganize the logic for showing or suppressing an extended command
to avoid a slightly hairy 'foo || bar && quux' expression.
When searching and not finding anything, report "no matches" rather
just waiting for another menu selection.
Plus miscellaneous reformatting.
Get rid of bold/non-bold distinction in #wizidentify inventory menu
by only showing items which aren't yet fully identified instead of
full inventory with bold for unID'd. Support for bold text might
be lacking.
I was considering this even before the report that X11 menus ignore
attribute. The "_ - (use ^I for all)" menu entry is still present,
but it could be discarded in favor of '.' to pick everything via
ordinary menu selection.
Don't display the selection to identify all items if there are none.
Complete an item marked ToDo in cmd.c: allow selection of one or more
particular items to permanently identify rather than just all or nothing.
Fixes#124
Fix github pull request #124 which was also reported directly (but not
through the contact form so #Hxxx number). Using ^I or #wizidentify
displays inventory with everything ID'd for that command only and adds
a menu entry "_ - use '^I' to identify" that can be chosen to make
those ID's persistent. Picking underscore would work but picking the
alternate '^I' wouldn't work if the platform had unsigned characters
for plain 'char'. Switch the return value from magic number -1 to
magic number ^I which isn't a valid inventory letter and isn't subject
to sign conversion. Casting -1 to '(char) -1' would have worked too
despite some confusion expressed in discussion of the pull request.
If ^I has been bound to some other command and #wizidentify hasn't
been bound to any keystroke, temporary ID didn't disclose any extra
information (ie, acted like ordinary inventory display) and the extra
menu entry to make temporary ID become persistent wasn't available.
This fixes that too.
Allow the 'm' prefix for wizard mode level teleport command. Using
it skips the initial prompt for level destination and goes directly
to the menu of special level locations that you get when answering
'?' to that prompt.
It seems to me that the reaction to "you feel dead inside" when you're
polymorphed into an undead creature at the time would be "so what else
is new?". Vary the "dead" when current form is something which gets
reported as "destroyed" rather than "killed" when killed. That happens
for things flagged as non-living. Now undead "feel condemned inside"
and golems "feel empty inside". Neither of those are ideal but they're
more interesting than "feel dead inside".
After becoming dead inside, give a reminder about that during
enlightenment and if you restore a saved game in that condition. It
was the latter that set this in motion: I wanted to confirm that
restoring with u.uhp == -1 didn't give "you aren't healthy enough to
survive restoration" when polymorphed. (It doesn't; the game resumes
and you'll die if/when you rehumanize.)
Some windowports that are currently being written by third parties
need more information about the engine than they currently have.
Two specific reported problems: a) needing to know whether a
putstr() call relates to a count (so that it can be placed in a
different part of the user interface from the message area); b)
needing to know whether a request for a character relates to
command input (some hangup handling routines need this so that
they can determine what behaviour is potentially exploitable).
Knowing whether or not you're inside parse() fixes both of them.
This would be cleaner to do by changing the windowport API, but
that'd break existing windowports, which isn't really ideal.
Setting a globalish variable that the windowport can inspect, but
can ignore if it prefers, means that existing windowports will
continue to work fine, but new windowports will have more
information and thus more flexibility in how they handle command
entry.
The extended command added to test handling for adjacent mouse clicks
had a description which was too long. In the list from '#?', white
space for column alignment got squeezed out to make it fit (at least
for tty, where it ended up looking awful).
The new description isn't a complete sentence any more, but I don't
think anyone will care.
Fix several warnings about using 'void *' for a function pointer and
a couple of unused variables. Add a_nfunc for 'int NDECL((*func))'
alternative for union anything. Make the enum list of union anything
types actually match the alternatives (field a_uchar was missing from
enums, enum mask32 had no corresponding a_mask32 field).
Add another command, #therecmdmenu, so that the context menu for an
adjacent spot can be tested without mouse support. It revealed that
you could get an empty menu if nothing applicable was at target spot.
Add a few adjacent actions: lock/unlock door if carrying suitable
implement, search door for traps, examine known trap (door/ceiling,
not door), #untrap known trap, mount saddled critter, remove saddle.
Make "kick door" be the last choice for closed door instead of first.
Add one 'here' action: dismount.
Both #herecmdmenu and #therecmdmenu interact strangely with ^A, but
differently from each other. I didn't make any attempt to solve this.
There's no documentation for #therecmdmenu.
Add a new boolean option herecmd_menu. If this is on, and using
a windowport that supports mouse, clicking on your character pops
up a menu of actions doable in that location. Basically this is
nothing new, as almost all of the same actions were done before
on the mouse click.
You can also pop up the context menu with the #herecmdmenu
extended command
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
While doing some cleanup I found an old personal bug list with four
entries. Two have already been fixed, or at least I couldn't reproduce
them with current code, one is still pending (dungeon overview feedback
is inconsistent if you find an unlit temple and haven't seen its altar
yet), plus this one: a buffer overflow (triggering a crash for me) in
wizard mode if you turn on the 'extmenu' option and start an extended
command. The menu can't handle long line width for 'w' with all its
wizthis and wizthat entries; strcat() goes out of bounds writing into
a local array.
(This bug predates the keybinding patch that turned all commands into
extended commands.)
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.
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.
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).
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.
Report was for 'F' followed by '.' reporting "cmdassist: Invalid
direction key!" and then by a direction grid (which happened to
include '.' for self). That behavior applied for all the movement
prefix keys ('m', 'G', &c). When 'cmdassist' was off, "F." would
yield "Unknown command 'F.'." instead.
Now you'll get "You can't fight yourself.", either instead of the
"invalid direction key" part of cmdassist feedback (followed by a
direction grid which excludes up, down, and self since they aren't
applicable for prefix keys) or of the "unknown command" result.
Likewise, "You can't run upward." or "You can't rush downward."
for "G<" and "g>", respectively.
Report was for losing strength when sitting on a throne, but the
message issue was more general than that. Character was wearing
gauntlets of power, so no visible change in strength took place,
but player was told "you're already as weak as you can get" (because
the attempt to reduce strength didn't change current strength;
however, it did change the hero's underlying strength, observable
once the gloves were removed).
There was a beta report last January that was related: in that case
the player thought that gauntlets of power were preventing blessed
potion of gain ability from raising strength, but it was actually
giving a misleading message claiming that strength was already as
high as it could get.
Fix: vary the message when something prevents an attribute change
from being noticeable.
Noticed while working on something else:
You entered the dungeon N turns ago
was missing the terminating period, and when polymorphed into a
1 hit die critter, plural "hit dice" is incorrect. 0 hit dice is
confusing even when fully spelled out, so include an explanatory
remark with it.
Don't include score (available if configured with SCORE_ON_BOTL)
unless player has the 'showscore' option enabled. The value is
an approximation--accurate as far as it goes, but the value can
change depending upon how the game ends. Someone who asks to have
it displayed on the status line will probably be used to that, but
others might start reporting bugs for it.
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.
The previous fix to use highc(UNCTRL(x)) worked for ^A through ^Z,
but not for NUL (yielded ^` instead of usual ^@) or ^[ through ^_
(yielded lowercase ^{ and so on). The problem was UNCTRL(); it
shouldn't have been forcing on the lowercase bit to begin with.
Also, the code that used UNMETA() for formatting wouldn't work as
intended for M-control char since it stripped off the 8th bit but
didn't apply any fixup for control chars.
Just get rid of ISCTRL/ISMETA/UNCTRL/UNMETA and use the existing
visctrl() routine instead. (Its 3.6.0 edition didn't handle
M-control char, but the to-be-3.6.1 branch has done so since a
week or two after the 3.6.0 release.)
