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.)
Adds two new configurable keys to the cursor targeting: 'A' (getpos.menu)
and 'a' (getpos.menu.cansee). First one shows a menu of all interesting
glyphs on the map, second one shows only those in sight.
Travel command also now obeys the "request menu" -prefix, showing
the menu with interesting targets in sight, and then traveling there.
Idea via the NetHack accessibility research by Alexei Pepers.
This is a modified version of Jason Dorje Short's key rebinding
patch, and allows also binding special keys, such as the ones
used in getloc and getpos.
One of the ways to play NetHack on nethack.alt.org is via a HTML
terminal in browser. Unfortunately this means several ctrl-key
combinations cannot be entered, because the browser intercepts
those. Similar thing applies to some international keyboard layouts
on Windows. With this patch, the user can just rebind the command
to a key that works best for them.
I've tested this on Linux TTY, X11, and Windows TTY and GUI.
Yet another accessibility feature. When asked for a location
to travel, and autodescribe is on, the location description
has "(no travel path)" appended, if there is no known path
to that location.
Previous fix was 'me' to eat from inventory without checking current
location for edible items. The report describing the need for that
also mentioned that you could #loot while blind and without gloves
and not touch any objects except for the container you pick to loot.
This adds a corpse touch check, plus `m#loot' to skip floor containers
and go directly to using #loot for adjacent saddled creature. That,
as well as the open command, will reveal adjacent container in some
circumstances but I'm going to pretend that that doesn't matter.
doloot() has turned into spaghetti. We should probably add #unsaddle
or something of the sort and return #loot to container-access only.
Accept the 'm' prefix for eat, offer, and apply.
Allows 'me' to eat from inventory without checking for floor food.
Primarily for use after blind character used 'm<dir>' to move
somewhere without touching a suspected cockatrice corpse there.
'm#offer' and 'ma<let>' accomplish similar floor-object-skipping
when offering a sacrifice or applying a tinning-kit. (All three
commands share floorfood() to pick the item to use.)
Report suggested replacing pick-from-floor followed by pick-from-
invent with use of slash'em-style pick-from-invent with explicit
pick-from-floor choice in list of inventory letters "[abc or ,]"
(slash'em used period for 'here'; I've always liked comma better
since the action is to pick an item rather than a location). I
implemented that for nethack a long time ago, but it was mixed in
with other stuff that wasn't ready for prime time and vanished
when I lost access to the VMS system I used to use).
Using 'm' prefix to skip part of a multi-part operation is a lot
simpler to implement but doesn't include an in-game reminder that
it is available.
Revised Guidebook.mn is tested, Guidebook.tex is not.
