Issue reported by entrez: when getpos() is being used to have the
player pick a map location, if player types '$' (for some operations
like jumping or applying a polearm) then valid spots are highlighted
but the highlighting obscures what was shown on the map. I'm not
sure whether this 'fixes' the issue but it's probably good enough.
Allow typing another '$' to toggle the highlighting back off,
redisplaying the map in the process, without needing to move the
cursor or type ^R to accomplish that. Toggling seems more intuitive.
This is a lot more complicated than it needs to be because I assumed
that the background aspect of highlighting stayed visible when the
glyphs were reverted. It doesn't work that way but I haven't thrown
out the effort to make toggling the highlights work sanely. Prior
to this, typing '$' again just redrew the highlighting again, with
no visible effect.
Closes#983
CSTD can be manually set near the top of src/Makefile, util/Makefile
or by including c99=1 or C99=1 on the build make command line if
using the linux.370 or macOS.370 hints files.
Can't use gc.context.mon_moving to check if the ray was caused
by hero, as some rays can happen while hero is moving in response
to their action - for example a bolt of lightning from a god.
dobuzz() uses positive type values for magic rays caused by hero,
so just use that.
dobuzz() was modified in 677b32c2a7 to anger the target, but beams
handled by dobuzz() don't necessarily originate from the hero. Monsters
can zap wands that hit other monsters, dragons can use their breath
attacks, etc. Those things were causing the targets to become angry at
the hero.
The <x,y> params of dog_eat are the pet's starting position that turn,
not necessarily the position of the object being eaten. If the pet is
doing a combined move-and-eat action, <x,y> will be its original spot,
but it will have already moved to <mtmp->mx,mtmp->my>, where the food
object also is.
The attempt to check whether the eating was happening out-of-sight
underwater (to suppress the message in that case) was checking the pet's
starting location, not its new location/the location of the food object.
So if a pet moved from water to land to eat something, the chowing-down
message would be improperly suppressed (and presumably the message for a
pet moving from land to water to eat would be improperly left
_un_suppressed, though I didn't actually try to reproduce that).
isqrt adds some noticeable distortion artifacts to gradients (test case
I used is to draw a line from 10,10 to 20,15 with mindist = maxdist = 2
and see how the gradient is biased towards the upper right); changing
the distance calculations to use the square of the distance rather than
the raw distance avoids this. This makes radial gradients more radial,
and square gradients more square.
There still appears to be a bit of bias, but I think this is due to the
line algorithm not lining up perfectly with the tiles.
selection.gradient has some pretty unintuitive behavior, in that it
selects points that are NOT close to the defined center. I've used
gradient selections several times and so far all of them have had to be
negated, because I wanted to select points close to the center with a
decreasing probability further out.
This implements that behavior, and also fixes a bug in which the x,y
coordinates of the gradient center(s) were not converted properly when
used within a des.room or des.map. Also updated the lua documentation
for gradient.
I removed the "limited" argument, as it was previously used to control
whether the rest of the map outside the max given distance would be
included in the selection; now that the area beyond maxdist is naturally
never in the selection, it doesn't have much use. (And I can't think of
a reasonable use case for the inverse: wanting to select points close to
the center, with decreasing chance towards maxdist, but then select the
entire map beyond maxdist.)
Currently this does not affect any special levels or themed rooms
because none of them use selection.gradient.
This iteration:
Places the resulting bundle folder off the top of the tree, rather than as a subdirectory of src.
Leaves the Applescript files out for now.
Builds the Info.plist (for now) via hard-coded values in the Makefile.
Builds the bundle launch script on the fly at make-time.
I think this revision may be working, at lease on my test machine.
There are more improvements to be done.
Comparable to #vanquished, be able to view info normally available
during end of game disclosure while the game is still in progress.
The new #genocided command lists all genocided and extincted types
of monsters. Unlike #vanquished, there aren't any sorting choices.
Potential future enhancement: provide a way to view the genocided
list at the "what do you want to genocide?" prompt.
Have 'make clean' and 'make spotless' in 3.7 cleanup include/tile.h
from 3.6. Otherwise use of 'cc -I../include -I../win/share' in
util/Makefile will get 3.6's include/tile.h instead of 3.7's
win/share/tile.h; use of FDECL() causes the old header to break when
used in various tiles utilities.
I was looking at backporting an X11 build fix to 3.6 and decided
that the hangup handling wasn't correct if SAFERHANGUP is defined
(which it is by default). It didn't attempt to perform a hangup
save. Also, the handler might return when the X code calling it
expected it to not do so.
I don't know how to force a hangup within X11 so haven't tested
this properly. It works fine when there's no hangup. :-/
* 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).
