for <new form> portion of messages "<old form> turns into <new form>"
to avoid named vampires yielding "Dracula turns into Dracula".
Pull request from entrez: a couple of engulf messages used regular
monster naming for vamp-shifters transforming rather than dying.
3.6.1 had fixes for this for basic monster death but didn't handle
engulfing.
Fixes#978
Apply a similar fix as a791b4b and f441696 ended up settling on for
normal vampire transformation to the vampire transformation that happens
when their shapeshifted form is engulfed.
The Makefiles and some of the hints have already been updated to
specify that C99 is required in response to #K3863. The code was
evidently being compiled in the default mode of an old version of
gcc and that mode complained that C99 was required to specify a
declaration in the initializer clause of a
'for(initialize;test;update)statement'. Other C99 features used
by nethack were apparently accepted as extensions in the default
conformance mode.
There's only one such declaration in the core code so replace it
with a separate declaration and ordinary 'for' loop.
win/Qt/{lots}.cpp and win/win32/{few}.c have these declarations but
the core didn't.
At some point this may need to be commented out, but for the time
being report failure by wait() during the fork()+exec()+wait()
sequence when compressing or uncompressing a save file.
For the benefit of 'git log': uncompressing an old save file or
compressing a new one fails when running nethack under control of
gdb (GNU Project's debugger) on OSX. Noticed and reproducible on
OSX 10.11.6; no idea about more recent versions. wait() returns -1
and sets errno to 4, "interrupted system call", and leaves the
variable that receives the child process's exit status as is.
NetHack has been relying on that exit status variable without
checking whether wait() returns success or failure.
This changes nethack's behavior when wait() fails. It is now
intentionally failing compress/uncompress (by init'ing the status
to 1) after it was briefly treated as success (due to a recent
commit that set status to 0 before calling wait()), after a long
time of accidentally failing due to not setting varible 'i' (was 2
after being used for another purpose). In addition to initializing
to failure prior to calling wait(), replace use of 'i' with a new
variable that is only used for this, possibly making the code more
comprehensible.
By the way, the issue with compress and uncompress failure when
running under control of gdb on OSX is not new. I don't use gdb
a lot and have gotten tired of rediscovering this misbehavior.
Adds a more general way to handle gameplay tips, and adds
a boolean option "tips", which can be used to disable all
tips. Adds a helpful longer message when the game goes
into the "farlook" mode.
Also adds a lua binding to easily show multi-line text
in a menu window.
Breaks save compat.
I realized that I put opts[] inside a block that would go out of
scope while it was still needed. When I went to fix that, I
discovered that it is already present where it ought to be. My
'experimentation' should have defined COMPRESS_OPTIONS sooner so
that the outer scope would see it.
This doesn't revert the previous commit because a couple of comments
and a bit of reformatting from it are still useful.
In addition to C99=1 on the make command line, also allow
C89=1 or C11=1 or C23=1.
NOTE: Those won't all lead to a successful build of NetHack,
and the use of C23=1 (-std=c2x) will only be valid on recent
compiler versions (clang-15, for one, accepts it).
From a report 9 years ago, a pet pyrolisk was repeatedly gazing at a
grey-elf and nothing happened. It turned out that the elf was wearing
an elven cloak which was negating damage some of the time (most of the
time back then) but with no indication that that's what was happening.
This makes many types of damage that are negated by MC say so.
Probably other types of damage should do likewise.
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.
