In earlier versions of NetHack, wands of digging generated fairly
often, allowing players to do a large amount of digging through the
maze walls in Gehennom and giving them a chance of an early escape
item.
In the current version, the need for both of these things has been
reduced: supply chests give a supply of early escape items
(including wands of digging), and Gehennom is no longer mostly made
of mazes with diggable walls. As such, there is no longer a reason
to generate wands of digging in such large numbers, even though it
was correct in the past.
This commit modifies some of the generation probabilities for wands
of digging in order to make them less abundant, in order to work
better with the code changes since the previous version.
Requested by Tomsod: change the break point for +2 damage bonus from
strength to be 18/50 instead of 18/51 so that gnome and orc heros can
achieve that 'naturally' by maxxing out Str.
Closes#1506
On macOS, the required underlying pieces are in there.
On Linux, we try to test for the presence of libuuid and
the uuid.h header files. If the tests are both successful,
we proceed to include NHUUID support.
On either macOS or Linux, NO_NHUUID=1 on the Make command
line will forcibly prevent the inclusion of the support for NHUUID.
Dungeoneers list updates
Ingo Paschke provided Amiga updates to get the port working
for the release to follow 3.6.7. He used the gcc-15.2 branch
of bebbo's Amiga toolchain on Linux.
G. Branden Robinson contributed several updates and suggestions to
help ensure that the *roff documentation production remains viable.
The traps don't disappear when stepped on any more; that should be
true even when monsters step on them.
(This bug was reported privately to me via IRC, rather than via the
devteam's email address, so there isn't a ticket number to close.)
New experimental option
This requires platform support to be useful. Currently an
implementation for Windows TTY console is included.
A Unix TTY implementation should be achievable I would think,
but I haven't pursued that, at least not yet (contributions welcome).
I'm not sure whether Qt or X11 interfaces offer a similar
timeout capability..
How it works:
When idlecheckpoint in on, if the wait for a new input is idle for
10 seconds (length of time to waite is controlled by
IDLECHECKPOINT_WAIT_TIME #define in hack.h), save_currentstate() is
called to bring everything up-to-date should a hangup or crash occur.
The input wait then continues/resumes.
The save_currentstate() call is only executed once per input request.
I have no idea whether this prevents the newly discovered impossible().
However, it does fix an obvious typo--in hindsight--that I made 6 years
ago (dealing with temporary lighting for camera flashes).
Issue reported by BartekCupial: segfault occurred and was tracked to
behavior of a rolling boulder trap. Suggested fix was included, but it
assumes that the destination spot is valid so is suspect.
A comment pointed out that the path is validated when a rolling boulder
trap is created so the segfault should be impossible. I didn't find an
explanation but am adding a fix based on the one in the issue report.
Closes#1490
nhmall