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.
The permanent inventory will be automatically shown if the terminal size
allows.
But only output an error message if the player requested it via
perm_invent option.
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.
specifies duplicate accelerator keystrokes
Reported and diagnosed nine and half years ago but never fixed.
In the WinGUI-specific help menu (under the titlebar, not nethack's
'?' command), both "&Long description of the game" and "&Longer list
of game options" use &L as accelerator. Typing 'L' or 'l' highlights
one of the entries, then <enter> is needed to execute it or typing
another 'L' or 'l' unhighlights it and highlights the other. Other
accelerators in that menu execute their entries immediately, without
the need for <enter>.
Change the first one to "Long description of the &game" so that 'G'
or 'g' becomes its accelerator.
That menu is missing several things that have been added to the menu
for '?'. I put in placeholder comments for them but won't pursue
them further.
Untested.
If is mon not sensed or seen and you use #wizkill to kill it, report
"You kill an unseen mon." rather than just "You kill the mon." Also,
override hallucination when identifying the victim.
Something which occurred to me when looking at the magic whistle code.
It's behavior can vary depending upon whether pline()/You()/&c has
been called and that is detected by checking whether pline() has reset
iflags.last_msg. Change the debugpline() mechanism to prevent it from
interfering with that.
apply.c:495:22: warning: variable 'optr' set but not used [-Wunused-but-set-variable]
struct permonst *optr;
^
1 warning generated.
cmd.c:4577:26: warning: variable 'how' set but not used [-Wunused-but-set-variable]
const char *dothat, *how;
^
cmd.c:4578:29: warning: variable 'viawindow' set but not used [-Wunused-but-set-variable]
boolean prefixhandling, viawindow;
^
2 warnings generated.
Allow the hints file to apply a correct timestamp to
the Guidebooks prior to use.
Detect the NH_DATESUB in the Guidebook.mn or Guidebook.tex
files and replace the datestamping line that follows.
If git is available, it determines the hash of the last commit
applied to doc/Guidebook.mn, and then determines the date of
that commit. The interim Guidebook.dated.mn (or
Guidebook.dated.tex) gets the datestamp applied.
If git isn't available or doesn't correctly provide the hash
for doc/Guidebook.mn, it should just continue to use whatever
hard-coded date in the Guidebook.mn source file (it uses it
instead of the interim file).
The old code to supply a list of directions if a prefix was followed
by a non-direction didn't work as intended anymore. Add some more
precise feedback for gGF mis-use and comment out some code that never
gets executed.
A number_pad user can get a complaint about 'G' when using '5' followed
by a non-directional command. Too bad for them.
Supersedes pull request #803
Reported by entrez: if magic whistle summoned a pet onto a trap, the
messages produced could be in the wrong sequence or contradictory.
The code was collecting counts and name-of-first for shift (was seen
before whistling, seen at different spot after), for appear (wasn't
seen before, now is), and for disappear (was seen before, now isn't)
before dealing with a trap at arrival location. The trap could issue
a message (including pet killed, pet sent away--teleport trap, hole,
&c--or pet changed shape--which occurred after its name/old shape was
saved for use when it was the only one in its category), and finally
the summary message was issued.
Change the code to handle arriving in a trap before the collection
into the three categories that provide feedback, and skip the latter
if any message was given during mintrap(). That handles the most
glaring anomalies like killed followed by shifted location or takes
on new shape followed by old shape shifted or appeared. But it no
longer gives specific shift/appear/disappear feedback for those cases.
Pets that don't land on traps or who land on ones that don't issue
any feedback aren't affected.
The accessibility aspect of this--message feedback in order to avoid
tedious screen reading of the map--will need to be satisfied by the
trap feedback unless/until someone comes up with a better solution.
One possibility is an option to allow player to have rloc() always
issue its vanish and appear messages. Right now it does so when magic
whistle hasn't been discovered yet, then avoids that hyper-verbosity
(if hero has multiple pets) once it has. Or the whistle code could
count the number of pets first, then behave as if such an option is in
effect when the count is small and only resort to the current summary
method if the count is larger than some threshold.
Incorporate the diff from entrez describing the travel_debug wizard
mode option and removing obsolete M prefix from the Guidebook. That
missed a reference to it in the description of '_'.
I put M back in case someone who has used it with earlier versions
tries to use it and gets a no-such-command complaint so goes looking
for it.
Also, make the mention of ^X at the end of the discussion of status
stand out a bit. The indentation of its paragraph made it line up
with the preceding text instead of making it be distinct from that.
The TeX changes are untested and given the amount of punctuation
characters used, it will be surprising if they all have been quoted
properly.
The nomakedefs stuff for cross-compiling support broke the code to
treat enabling or disabling some optional features as not breaking
save and bones file compatibility. It was relying on a macro whose
definition was local to mdlib.c rather than propagated among files.
makedefs still constructs date.h with a value indicating the ignored
features but the actual compatability check doesn't use that anymore.
Toggling SCORE_ON_BOTL shouldn't have caused existing files to be
rejected but they were.
On a machine with both homebrew and macports, the presence of
macports was causing the homebrew Qt settings to be overwritten
right after they were set. Check to see if QTDIR is already
defined before proceeding with QT macports.
if macports is detected:
- check for ncurses from macports
- adjust the library search path to include /opt/local/lib
- adjust the C compiler include search path to include /opt/local/include
via -I/opt/local/include.
- if libncursesw* is in /opt/local/lib, link with it.
Also, USEMACPORTS=1 will use macports if you have both homebrew and macports.
It isn't required, but the ordering in the Makefile will use homebrew first
otherwise.
Reported by entrez: buying an unpaid item using itemized billing used
to result in the price information for unpaid items disappearing when
they get shown by perm_invent. (Their status as unpaid didn't change;
persistent inventory just got redrawn without cost information.) The
fix for that didn't handle buying a used-up item. There's no invent
update for the gone-item item but there is one for moving gold out of
hero's inventory to add to shopkeeper's inventory. The vanishing
price phenomenon applied to that situation too.
I can't think of any situation where persistent inventory would want
to hide unpaid status and/or cost, so always prevent those from being
excluded during perm_invent update.
The #therecmdmenu command calls getdir() which issues an "in what
direction?" prompt. This allows you to answer with "_" instead of a
regular direction, then it will call getpos() to allow you to move
the cursor and type "," (or ";") to behave as if a left-click had
been done or type "." (or ":") to behave as right-click.
Ordinarily I would think of the 'normal' getpos() response of "."
as suitable for left-click, then one of the other getpos finishers
for right-click, but comma is left of period on a standard keyboard
and that seems useful for remembering which is used for which click.
Left clicking on a spot farther than one step away offers travel,
throw iff lined up, and also click-look as choices. If you right
click farther than one step away, it will only offer click-look.
The look choice for either left or right click isn't inhibited by
having the clicklook option set to False. After all, player is
explicitly choosing the menu entry to look at something.
New getdir.mouse can be bound to some other key than "_" and the
getpos.pick* responses could already be re-bound, but there's no
separate getdir.left/right that could be used to bind different keys
from those used for the four getpos responses.
Still more PR #777. Commit c4c6c3d73a broke #therecmdmenu travel,
throw, and far-look. It was restricting dx and dy unnecessarily
and that resulted in not specifying the correct location when the
destination was farther than one step away.
Testing those properly requires a mouse. I've implemented a way
to simulate a left or right click at getdir()'s prompt (only useful
for #therecmdmenu). That will be committed separately.
More PR #777: there's no need for there_cmd_menu() to pass absolute
<x,y> instead of <dx,dy> for a couple of actions. Those actions can
reconstruct <x,y> by adding <dx,dy> to <u.ux,u.uy>.
For the description of what a keystroke does, augment 'm' (or whatever
key has been bound to #reqmenu) to replace the default description
|m prefix: request menu or modify command (#reqmenu).
with
|m movement prefix: move without autopickup and without attacking
|m non-movement prefix: request menu or modify command (#reqmenu).
The text is delivered by pline so tty will issue --More-- between the
two lines.
Refine the code from pull request #777 by changing act_on_act() to
take 3 arguments instead of 6. x,y and dx,dy are mutually exclusive
so it doesn't need both pairs provided that the caller is adjusted
to pass the ones appropriate for the action, and dir is easily
derived from dx,dy for the couple of cases that use it.
