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.
Start to add supporting code to windsound and macsound. The latter
remains commented out because I haven't had a chance to try
it on macOS yet.
In order to test it out, I added two more stock sounds:
sa2_xplevelup and sa2_xpleveldown.
A detected cave spider was hiding under a generic spellbook object;
farlooking at it produced a segfault. OBJ_NAME is null for the generic
objects, so don't try to strcmp it.