The important part of the "don't offer while impaired" change was to
prevent offering while confused. However, it was also extended to
other status conditions: stunning seems fine, but hallucination was
problematic (both because it makes a large number of messages
inaccessible, and because hallucination is more of a long-term status
effect than the other two and players may sometimes choose to play
with it for a large portion of the game). So make the change trigger
only on stunning and confusion, not hallucination.
This also updates the changelog for the change, because while
connected to the erinys changes, it's technically separate and is
relevant even in games where erinyes are never summoned.
For example, being hit by the bounce of a wand of fire means that
the main character could take damage twice in a turn, which would
kill even through saving grace; and scrolls and potions could burn
up after that and finish off the last HP, even if the wand only hit
once. This commit changes it to track all damage done during the
turn, and prevent HP dropping below 1 from damage until the next
player action or the next turn boundary, whichever comes first.
If you write the scroll by description, you obviously know what the
label is because you specified the label (even if you didn't know
what the scroll was). When writing an unidentified scroll by type,
though, and getting lucky, you don't necessarily know the label of
the resulting scroll.
This fixes a couple of bugs: a long-standing bug in which writing a
scroll by label could fail even if you've already seen a scroll with
that label (due to the game not tracking whether or not you've seen a
scroll if it doesn't have a name); and a somewhat newer bug in which
spellbooks auto-identified by Wizard knowledge were marked as having
been encountered (rather than as known but not encountered).
Breaks save file compatibility, but not bones files.
This is partially for the pun, and partially because the "wish for
scrolls of charging to identify them" strategy has been nerfed in
previous commits and this offers an opportunity to discover what
scrolls of charging are without randomly encountering one.
Issue reported by chappg: on arboreal levels, when an object was
located at a stone location treated as a tree location, examining
the object would report it as embedded in stone.
The Ranger quest has arboreal levels where STONE becomes TREE, and
items that would become embedded in stone will be in trees instead.
(Sometimes kicking a tree would drop fruit onto an adjacent tree,
effectively embedding it. For testing, it's easier just to poly
into a xorn, walk onto the tree spot, and drop something.) The item
description code for farlook and quicklook wasn't checking for that.
The fix also corrects another bug: an item located at a normal tree
location would just be described as itself with no mention of the
tree at all. Attempting to walk onto it would report the terrain
and not let you move there (assuming not in xorn form), like trying
to walk into a wall.
Fixes#1462
There was only one point in the code at which this caching was
being done, and it was incorrect: it's possible for the result of
near_capacity to change during a monster turn because monster
actions can change either inventory weight or carry capacity.
The bug was particularly relevant in cases where a character
polymorphed into a slow weak monster gets attacked by a monster
that moves at normal speed: due to the polyform being slow, the
normal-speed monster gets in a lot of attacks and causes a
rehumanization, but due to the polyform being weak, it was
burdened at the start of the monster turn, and so when that
penalty is (due to the bug) applied to the next turn it can
mean that the character misses the next turn too, and may end up
dying as a result.
windows/windsys.c:263:15: warning: format string is not a string literal
(potentially insecure) [-Wformat-security]
263 | msmsg(buf);
| ^~~
../sys/windows/windsys.c:263:15: note: treat the string as an argument to avoid this
263 | msmsg(buf);
| ^
| "%s",
../sys/windows/windsys.c:267:20: warning: format string is not a string literal
(potentially insecure) [-Wformat-security]
267 | raw_printf(buf);
| ^~~
Targeting '~' when vibrating square has been discovered would report
"Can't find dungeon feature '~'" if it was covered by an object or a
monster.
That's normal behavior for a trap but the vibrating square is only
one of those for display purposes.
Cross-compiling NetHack with Visual Studio from an x64 platform to an ARM64
target presents some new build challenges.
In the current nethack.sln solution, the build attempts to execute the
several just-built tools during the build of various subprojects.
For example, when cross-compiling on a typical Windows 11 x64 machine
to build a target ARM64 Windows 11 package, the build process tries to
run the following just-built target tools:
(under a Debug build)
"$(ToolsDir)\Debug\ARM64\uudecode.exe"
"$(ToolsDir)\Debug\ARM64\makedefs.exe"
"$(ToolsDir)\Debug\ARM64\tilemap.exe"
"$(ToolsDir)\Debug\ARM64\tile2bmp.exe"
"$(ToolsDir)\Debug\ARM64\dlb.exe"
(under a Release build)
"$(ToolsDir)\Release\ARM64\uudecode.exe"
"$(ToolsDir)\Release\ARM64\makedefs.exe"
"$(ToolsDir)\Release\ARM64\tilemap.exe"
"$(ToolsDir)\Release\ARM64\tile2bmp.exe"
"$(ToolsDir)\Release\ARM64\dlb.exe"
Those fail to execute successfully on Intel x64 (or x86) since they
are actually ARM64 executables, and the build attempts to execute
them on the host Intel x64 hardware.
The situation is a little different if the cross-compile is carried out
on a Windows 11 ARM64 machine (such as SnapDragon).
On an ARM64 machine, the cross-compile to build a target Intel x64
Windows 11 package, tries to execute the following:
(under a Debug build)
"$(ToolsDir)\Debug\x64\uudecode.exe"
"$(ToolsDir)\Debug\x64\makedefs.exe"
"$(ToolsDir)\Debug\x64\tilemap.exe"
"$(ToolsDir)\Debug\x64\tile2bmp.exe"
"$(ToolsDir)\Debug\x64\dlb.exe"
(under a Release build)
"$(ToolsDir)\Release\x64\uudecode.exe"
"$(ToolsDir)\Release\x64\makedefs.exe"
"$(ToolsDir)\Release\x64\tilemap.exe"
"$(ToolsDir)\Release\x64\tile2bmp.exe"
"$(ToolsDir)\Release\x64\dlb.exe"
Those actual do succeed in executing on ARM64, because of the
"prism emulation" that is available on Windows 11 ARM64 operating
systems to allow x64 and x86 executables to run.
The following change adds some detection to build environment, leading
to the definition of a "HostTools" macro that leads to the native host
tools for those steps.
There is a catch:
It means that the native build of the interim tools for Windows 11 must
be executed prior to attempting a cross-compile build to a non-native
target. That ensures that the native x64 interim uudecode, makedefs,
tilemap, tile2bmp and dlb tools are available on the disk for use by
a subsequent cross-compile.
This change consistently switches to the use of the host-native
interim tools for uudecode, makedefs, tilemap, tile2bmp and dlb tools.
Technically, this change would not be strictly necessary on an
ARM64-hosted build that was targeting x64 or x86, because of the
available prism-emulation that allows ARM64, x64, and x86 images to
execute, but this maintains consistency of the build process on
either platform. It is also likely that the native host versions execute
more quickly than versions requiring the prism emulation, although
that isn't really a concern for a NetHack build.
The use of native host uudecode, makedefs, tilemap, tile2bmp and
dlb tools is done with the Unix-hosted cross-compiles to other
target platforms as well (on Linux or macOS).
Issue reported by chappg: succubi could produce "it's on the house"
(quoted verbal message) when hero is deaf. The mail daemon could
produce a variety of verbal message when hero is deaf.
The succubus/incubus one is easy to fix. The mail daemon ones are
untested and a couple haven't been given non-verbal alternatives.
Fixes#1458
