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.
Refine the code added by pull request #763 to check the quest nemesis
death message for reference to noxious fumes rather than having the
three relevant roles be hardcoded.
Pull request from matteverett: for generating starting equipment,
mark a wizard as having received a level 1 spellbook when getting
guaranteed force bolt so that the random second spellbook can be
level 1, 2, or 3 as intended rather than unintentionally be forced
to be level 1.
Closes#770
of vanquired monsters.
Pull request from janne-hmp: the test for how many spaces to insert
in front of "the <unique monster>" couldn't match prefix "the "
because it was specifying a length of 3 instead of the 4 required to
include the trailing space.
Despite that clear error, the code worked as intended because the
default value of 0 is the same as an explicit value of 0 it would
have gotten if it had matched "the ". So there is no change in the
resulting vanquished monsters display.
Closes#798
Make monsters being created in Sokoban that are given a random
defensive item be less likely to receive a wand of digging. Should
result in fewer extra holes needing to be plugged.
Resurrected from an old stash entry. I have no recollection of why
I didn't consider it to be ready for prime time way back then.
I forced a test compile to -std=c++20 mostly to see what we would
be up against. There was only a small number of things and they
are corrected in this commit.
c++20 has some issues with comparisons and bit twiddling between
different enums.
The vendor-supplied Qt5 header files triggered some of those issues as
well, so the qt_pre.h and qt_post.h NetHack header files were adjusted
to make those new warnings go away. I have not tested Qt6 under the
new compiler and c++ version yet.
Because there are multiple pragmas in qt_pre.h now, the conditional
ifdef structure in there was modified a little to make maintenance
simpler and have a single pragma push at the top. The pragma pop
comes after the Qt vendor-supplied header files, and is done
in qt_post.h.
The display.h macro cmap_to_glyph() was used in
a Qt c++ file and triggered a series of warnings because of that.
Rather than write c++20-friendly versions of those macros, the
simple fix is to provide a function on the C side of things
to front the cmap_to_glyph() macro, so fn_cmap_to_glyph()
was added.
Also thrown into this commit, PatR picked up on the fact that for
yesterday's new warning in qt_menu.cpp, the compiler had correctly
picked up on the fact that the format range of the variable 'cash'
had been correctly upper-capped at 999999999L in the warning message
because of an assignment prior. He suggested that perhaps by also adding
if (cash < 0)
cash = 0;
the warning might be eliminated altogether.
After a test, that was proven to be correct, so yesterday's
more-kludgy change is reverted and replaced with that variable
variable restriction ahead of the snprintf().
