* doc/Guidebook.mn: Remove workaround, in favor of...
* doc/tmac.n: ...setting automatic hyphenation mode appropriate to
hyphenation systems used by AT&T-descended troffs on the one hand
("suftab") and groff (TeX hyphenation patterns) on the other.
modify results of pull request #977 to target tmac.nh instead.
Guidebook update to trigger the process following pull request 977.
Pull request from entrez: combining just-picked-up (P) with explicit
accept without confirmation (A) for multi-drop (D) ignored the
just-picked-up part and dropped everything.
Affects menustyle:Full. For menustyle:Traditional, 'A' operates very
differently and combining 'a' with 'P' or vice versa already does the
right thing.
Closes#976
Selecting both 'P' (the just-picked-up items category) and 'A' (the
'auto-select relevant items' flag) when dropping items by type with 'D'
was automatically dropping every item in inventory instead of only items
that were marked as just having been picked up. Basically, it was
causing 'A' to act like it did before b65c93c amended its functionality.
This commit is more-or-less identical to 991e739, both in terms of the
problem and the fix, except that it applies to dropping items instead of
looting.
Pull request from entrez: mayby_unhide_at() operating on the hero
rather than on a monster was buggy because it was looking at the wrong
fields when checking for being hidden (recently fixed) and for being
trapped (fixed here) because those are tracked by fields in 'u' rather
than in 'youmonst'.
Closes#975
A monster may be unhidden if it's caught in a trap, but maybe_unhide_at
was checking mtmp->mtrapped across the board, which wouldn't work for
the hero. Use u.utrap instead under those circumstances. Also refactor
a bit so it shouldn't need the repeated guards against mtmp being null.
This creates a new target 'bundle' for make on macOS, when using
sys/hints/macOS.370.
The 'bundle' recipe:
- creates a subdirectory of src called 'bundle', and creates
a bundle (nethack.app/ etc) below that.
- the executable that is placed inside the bundle
(bundle/nethack.app/Contents/MacOS/nethack) will find resources
within the bundle, including the sounds, so a manual placement
of the sounds into your '~/Library/Sounds' is no longer
required when using the executable that's inside the bundle.
- the sounds are included in the bundle if a soundlib option is
chose at build time (for example 'make WANT_MACSOUND=1'), such
that the bundled executable supports sounds.
- the executable inside the bundle seems to find the resources
it needs, even if invoked through a symlink elsewhere that points
to the executable that's inside the bundle (only limited testing of that
has been done).
- at some point, its probably appropriate to add a
'mv bundle/nethack.app <proper location>', possibly under
a subsequent 'make install' step.
- right now, the bundle step has a dependency on 'update'. I don't
know if that's the right ordering or not, yet.
make WANT_MACSOUND=1 update
make WANT_MACSOUND=1 bundle
or, you can probably get away with:
make WANT_MACSOUND=1 bundle
if the nethack bundle is the goal anyway.
make clean
will clear the bundle subdirectory and everything below it.
Update and apply an old stashed commit: hide the casts in calls to
mread() made in restore.c. Some split lines get recombined and there
is less clutter when reading the code.
maybe_unhide_at tried to handle both a monster and hero, but
hero being hidden is in u.uundetected flag, and the code was
only checking the monster mundetected field.
The code should probably be changed, either to change all uses
of the u.uundetected to gy.youmonster.mundetected, or perhaps
use a macro ... but these changes are all too big for me
to tackle for now.
Give generic objects a name as well as a description to avoid some
potential object formatting problems. Also remove the 'unique' flag
from them to avoid confusion. Not exhaustively tested.
Neither my fix for #969 nor the followup by entrez dealt with this:
if you were in one shop and dug the wall it shared with another shop,
sometimes the shopkeeper for the room your were in would teleport to
you and demand payment--or attack if you lacked funds--other times the
one from the far room would do so. For the latter, if you maneuvered
to the gap in the wall (possibly declining to die if angry shopkeeper
managed to kill you) you would get "this shop is deserted" (which is
accurate) but if you subsequently died there, you could get "Welcome
to so-and-so's shop" when the shopkeeper who abandoned her shop was
returned to occupancy after one of them took possession of invent.
And the welcome message might come from the shop that hadn't been
deserted and that you had never left. (Perhaps always from that one;
I'm not sure.)
Possibly the shopkeeper for the room you're in should get priority
when demanding payment for repairs so that the other one won't
abandon the far shop, but I didn't attempt to tackle that. This
just suppresses room entry messages when returning the shopkeeper to
her shop if the game is ending.
Not fixed, but amusing: in one of the tests, the 'far' shopkeeper
who had teleported into the near shop to demand payment for the dug
wall picked up an item from the near shop (in the case I noticed, a
hardware store shk picked up a food ration; just an ordinary item
owned by the stop) while pursuing me to the wall gap. One shk was
stealing from the other. :-)
Pull request by entrez, following up issue by k2: when deciding
whether a shopkeeper should taken possession of dying heros invent,
check all rooms the hero is in rather than just the first. Deals
with dying in a gap of a wall shared by two shops.
Original issue was about "place_object: <item> off map <0,0>" but
an earlier commit fixed that (I hope). That commit had a typo in
the issue number and closed#965 (which was already closed) instead
of #969 (which this pull request reopened anyway).
Closes#969
inherits() only examined the first item in u.ushops, so some shopkeepers
that should have had first dibs were ignoring the hero, one of the
causes of #969. Examine the entire u.ushops array instead of just the
first item so that the hero's position within the shop will be correctly
identified (and do the same in set_repo_loc, though it's probably not
really necessary there).
sound_verbal(char *text, int32_t gender, int32_t tone, int32_t vol,
int32_t moreinfo);
-- NetHack will call this function when it wants to pass text of
spoken language by a character or creature within the game.
-- text is a transcript of what has been spoken.
-- gender indicates MALE or FEMALE sounding voice.
-- tone indicates the tone of the voice.
-- vol is the volume (1% - 100%) for the sound.
-- moreinfo is used to provide additional information to the soundlib.
-- there may be some accessibility uses for this function.
It may be useful for accessibility purposes too.
A preliminary implementation has been attempted for macsound to test
the interface on macOS. No tinkering of the voices has been done.
Use of the test implementation requires the following at build time with make.
WANT_SPEECH=1
That needs to be included on the make command line to enable the test code,
otherwise just the interface update is compiled in.
I don't know for certain when AVSpeechSynthesizer went into macOS, but older versions
likely don't support it, and would just leave off the WANT_SPEECH=1.
If built with WANT_SPEECH=1, the 'voices' NetHack option needs to be enabled.
It was a bit strange, when I first started up the test, to hear Asidonhopo,
the shopkeeper, talking to me as I entered his shop and interacted with him.
Reported by elunna: a monster trapped in a pit or web that was
adjacent to a polymorph trap could enter that trap to change shape.
It would remain flagged as trapped but there's no way to escape
from a polymorph trap so it would be stuck.
Fix supplied by entrez: when a monster is picking MUSE strategy,
don't allow it choose "enter polymorph trap" if it is currently
trapped.
I entered the changes from the diff manually and added a bunch of
minor formatting bits.
Fixes#972
Issue reported for a hardfought player by k2: dying in a shop wall
produced "place_object: <item> [0] off map <0,0>" when hero's invent
was dropped. It happened in Mine Town where multiple shopkeepers are
present and it is possible to have two shops share a wall.
I could not reprouce the problem, even after setting up--and dying
various times at a gap in--a wall shared by two shops.
paybill() -> inherits() -> set_repo_loc() sets up the destination
prior to disclosure and finish_paybill() -> drop_upon_death() later
places invent at the spot iff bones are going to he saved. inherits()
is convoluted and evidently took at least one path that failed to
call set_repo_loc(). Change it to always call set_repo_loc() when
returning 'True' so that the destination should always be set if
really_done() calls finish_paybill().
Some followups by entrez are probably still useful.
Closes#965
Add "walls of lava", basically lava which blocks vision and
require a bit more than just levitation or flight to move through.
No levels use this yet, as testing isn't thorough enough.
The intuitive behavior of des.levregion or des.teleport_region when
"exclude" is left unspecified is that there is no exclusion area.
However, this wasn't actually the case: since l_get_lregion defaulted
the exclusion area to (0,0,0,0) and exclude_islev to 0, this meant that
the 0,0 space on the map would always be excluded from regions. In cases
where a region was specified with its inclusion area constrained to the
0,0 space of the map, this would create a "Couldn't place lregion"
impossible message.
This fixes that issue by defaulting the exclusion area to (-1,-1,-1,-1),
and if the exclusion area is left unspecified, forces exclude_islev=1.
This means that the exclusion zone will be outside the walkable space of
the level where it can't cause any problems.
If a level designer puts negative coordinates in their inclusion or
exclusion parameters, this might not work correctly, but negative region
coordinates aren't currently used anywhere and probably shouldn't be
supported anyway.
With sounds on, using #levelchange to drop more than one level only
gave the level-loss sound effect once. Level-gain sound was better
because the more verbose messaging triggered --More-- before moving
on. Have both gain and loss use urgent_pline() in case messages
are being suppressed due to ESC, and have both request --More-- to
make the player acknowledge the message. That has a side-effect of
letting the sound play to conclusion.
cppregex.cpp recently had `#include "extern.h"' added as the last
quoted include. That gets set to "" while collecting dependencies,
then preceded by a space when output. So the unexpected trailing
space was new and wasn't caused by a change of awk versions as I
was suspecting. This removes it.
Requires rebuild of your Makefiles via hints file (for new stock wav additions).
If you've been testing by copying the wav files manually to
~/Library/Sounds, you'll need to copy them again to pick up
the additional wav files.
