Noticed while testing an earlier fix - after your pet consumes a large mimic
corpse don't have it remain leashed once it begins to mimic something
that isn't leashable
Some variants were already using a similar approach
using a struct called 'ebones', so adopt the same naming
so NetHack-3.7, hardfought, and some variants are using
the same name.
As before there are fields in the struct that are not
currently used by NetHack-3.7, but the intent is that
hardfought save and bones files can be loaded by
NetHack-3.7 without code modification, for debugging
bug reports.
This invalidates existing save and bones files.
There are two hardfought code additions that render save and bones files incompatible
with the upstream NetHack-3.7, and that makes testing with hardfought
save and bones files more challenging than it needs to be, when
investigating and troubleshooting bug reports.
Add some unused fields to advance towards achieving save file parity with
hardfought, which is a significant source of play-testing for NetHack-3.7.
1) the elbereth field addition to u_conduct
This adds an unused placeholder field named 'hf_reserved1', at the appropriate
place in u_conduct to achieve struct field parity with the one in use on
hardfought.
2) hardfought adds a field to struct monst:
char former_rank[25]; /* for bones' ghost rank in their former life */
Instead of adding that to every monst, this adds a new mextra struct
named 'former', which currently contains the equivalent 25-character
field called 'rank' which can hold the content that was in the
former_rank[25] field. That way, the field will only be added when it
is needed.
A pull request https://github.com/k21971/NetHack37/pull/2 has been
done on hardfought to do it the same way (untested there as of yet).
Even though NetHack-3.7 does not utilize that information presently,
this will be a further step toward allowing hardfought-generated save
and bones files to be used for troubleshooting, without modification,
on a similar architecture running stock NetHack-3.7 code.
That savefile parity won't be achieved until the after the
hardfought pull-request mentioned above (or equivalent) is merged.
As this change will not be compatible with existing save and bones
files, it will be accompanied with an EDITLEVEL increment.
Commit 1acc2727 helped ensure that the which_armor(mtmp, W_SADDLE)
test at the top of put_saddle_on_mon() wouldn't lead to an obj
leak.
This commit covers off the adjacent can_saddle() test in
put_saddle_on_mon(), because if that failed, it could also lead
to a memory leak of the saddle obj passed by the caller.
- have put_saddle_on_mon() create and use its own saddle obj
if a NULL saddle obj is passed, instead of having to do that
in the caller.
- where an existing saddle obj needs to be passed from the caller,
ensure that the caller has done its own can_saddle(mon) check prior
to calling put_saddle_on_mon(), so that the can_saddle() test
in put_saddle_on_mon() won't fail.
- lastly, add an impossible() to put_saddle_on_mon() to catch
a failure when a saddle obj is passed from the caller and either
test has failed, just in case. That should not happen with any of
the existing cases now, but it will provide some bullet-proofing
for new code, new callers.
In file included from ../include/config.h:723:0,
from ../include/hack.h:10,
from files.c:8:
../include/global.h:519:24: error: expected ')' before '<=' token
#define unctrl(c) ((c) <= C('z') ? (0x60 | (c)) : (c))
^
../lib/pdcursesmod/curses.h:1686:16: note: in expansion of macro 'unctrl'
PDCEX char *unctrl(chtype);
^~~~~~
Define a macro NH_C to provide a shorter & simpler way to test for
which C standard the build is being carried out under (c99 or c23).
NH_C > 202300L Being compiled under C23 or greater
NH_C > 199900L Being compiled under C99 or greater
NH_C > 198900L Being compiled under C89 or greater,
or C std could not be determined.
While NetHack only requires c99, we've been taking advantage
of some c23 features (attributes), if they are available,
to allow the use of ATTRNORETURN/NORETURN and FALLTHROUGH on
compilers other than gcc.
Also add some comment documentation to tradstdc.h about NetHack's
use of c99.
The sys/unix/Makefile.top change overcomes a warning in the
Makefile-generated nhlua.h. That warning arises under some compilers
that rely on attribute [[noreturn]] ahead of a declaration
(NetHack macro ATTRNORETURN), rather than the trailing gcc
__attribute((noreturn)) (NetHack macro NORETURN). The sed command
is modified to include ATTRNORETURN at the start of the declaration
in addition to the NORETURN at the end of the declaration, in the
generated file. That's the same combination that's used for the
declaration of other functions that don't return.
Reported by paxed. A potion of oil, that was already in the midst of exploding,
got picked up through spot_effects(), which led to it merging with
another potion of oil and the freeing of the original obj.
The original obj pointer was still held by breakobj(), and breakobj()
proceeded to delete the obj (again).
Function nesting:
1 spelleffects()
2 -> weffects()
3 -> bhit()
4 -> bhitpile()
5 -> bhito(obj ...)
6 -> hero_breaks(obj ...)
7 -> breakobj(obj ...)
8 -> explode_oil(obj ...)
9 -> splatter_burning_oil()
10 -> explode()
11 -> zap_over_floor()
12 -> melt_ice()
13 -> spot_effects()
14 -> pickup()
15 -> pickup_object(obj ...)
16 -> pick_obj(obj ...)
17 -> addinv(obj ...)
18 -> addinv_core0(obj ...)
19 -> merged(obj ...)
20 -> obfree(obj ...)
21 -> dealloc_obj(obj ...)
8 -> delobj(obj ...)
9 -> delobj_core(obj ...)
10 -> obfree(obj ...)
11 -> dealloc_obj(obj ...)
12 -> impossible("obj already deleted)
This marks the exploding potion with LOST_EXPLODING, so that it won't
get picked up, or merged with another object during the long
sequence of functions, and that should take care of 15-21 above.
Apparently, restoring of saved games on Windows has been
broken since 1f36b98b, 'selectsaved' extension from Oct 10.
That change was altering the names of the files saved on disk
to a new format introduced at that time, but the game was not
opening a savefile with that same name, and the restore failed.
The code that renamed the savefile to match the internal name
was not part of 1f36b98b, it already existed prior to the new
internally-stored format.
To get things functional, this commit disables the code that
carries out the renaming of the on-disk savefile to match the
internal name in the savefile entirely, at least for now.
This relates to GitHub issue #1346 item 2.
Even though most of these are cast to void (but not all), the
mips cross-compiler seems determined to warn about them anyway.
Suppress that particular warning altogether to quiet the build.
That is not the ideal approach, but if the normal way of whitelisting
individual cases isn't working, I'm not sure of another course of
action.
A couple of option processing functions, one of which was called in file.c, were
recently added to sys/unix/unixmain.c, but the wasm build does not include unixmain.c,
it uses sys/libnh/libnhmain.c.
Transcribe the functions into sys/libnh/libnhmain.c.
Also, do not #include "wintty.h" for NOTTYGRAPHICS builds.
Remove start_screen() and end_screen() from the
Window-port interface.
They were only ever used by tty, and there was a comment
carried to several window-ports about how they "really
should go away. They are tty-specific"
term_start_screen() and term_end_screen() are part of
terminal/NO_TERMS supporting routines now.
Add a note about NO_TERMS to include/wintty.h for clarity.
Rename tty_startup and tty_shutdown to term_startup() and
term_shutdown(). They are found in termcap.c for !NO_TERMS
like most of the other term_ routines, as well as having
versions for several of the NO_TERMS platforms. They aren't
part of the tty_interface called from the core. The tty
implementation does call and rely on them.
Remove some conditional #ifdef's around term_shutdown()
(formerly tty_shutdown()) and just ensure that all the
tty platforms have an implementation that they can link
with, even if it is just a stub presently.
Put the protype for nethack_exit in extern.h to reduce
maintenance to a single spot, and remove it from other
locations. A warning in the msdos cross-compile led to
this change.
Options processing can be early, even before ttyDisplay is allocated.
If we find that TTY_PERM_INVENT initialization is happening too early,
just set a marker (iflags.perm_invent_pending) to try again a bit later.
The changes in win/share are just to be able to sucessfully
reproduce the original issue on Windows. It was easily reproduced
on Unix, just by building with TTY_PERM_INVENT in include/config.h
and setting OPTIONS=perm_invent in config file.
Instead of flat, have bin, lib and include folders for
the native DOS pieces.
If you have been cross-compiling for MSDOS, you will
need to carry out the following to bring things up-to-date:
sys/msdos/fetch-cross-compiler.sh
make CROSS_TO_MSDOS=1 WANT_DEBUG=1 package
If freedynamicdata() gets called twice, for whatever reason, a "double free" can occur.
warning: 44 ./nptl/pthread_kill.c: No such file or directory
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff7c8b26e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff7c6e8ff in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff7c6f7b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff7e148d7 "%s\n")
at ../sysdeps/posix/libc_fatal.c:132
#6 0x00007ffff7ceefe5 in malloc_printerr (str=str@entry=0x7ffff7e17bf0 "free(): double free detected in tcache 2")
at ./malloc/malloc.c:5772
#7 0x00007ffff7cf154f in _int_free (av=0x7ffff7e49ac0 <main_arena>, p=<optimized out>, have_lock=0)
at ./malloc/malloc.c:4541
#8 0x00007ffff7cf3d9e in __GI___libc_free (mem=0x555555ad82a0) at ./malloc/malloc.c:3398
#9 0x00005555557c12e9 in free_rect () at rect.c:48
#10 0x00005555557d77a2 in freedynamicdata () at save.c:1240
#11 0x0000555555682754 in nh_terminate (status=0) at end.c:1671
#12 0x000055555589af15 in opt_terminate () at ../sys/unix/unixmain.c:768
#13 0x000055555589af7a in after_opt_showpaths (dir=0x0) at ../sys/unix/unixmain.c:796
#14 0x0000555555693dd9 in do_deferred_showpaths (code=0) at files.c:4491
#15 0x0000555555778405 in initoptions () at options.c:6948
#16 0x0000555555899cd9 in main (argc=2, argv=0x7fffffffdad8) at ../sys/unix/unixmain.c:151
This helps avoid a potential chicken-and-egg scenario
with the system configuration file (sysconf).
If sysconf wasn't accessible at the expected location, it
caused an immediate exit, without relaying any helpful
information. That happened even when using:
'nethack --showpaths'
That's particularly unhelpful, because the --showpaths
output might have been useful towards understanding where
NetHack was looking for such things.
That left you without an easy recourse to identify where
the game is looking for the sysconf file. That might be
especially troublesome if you didn't build the game
yourself.
Be more consistent in the use of path separators.
Add a second version of Makefile variables that contain paths,
one with a trailing separator, and one without (prefixed with R_
for use in Makefile rules).
Also, in dat/luahelper,
Updates due to correspond to the Makefile.nmake changes.
Add Makefile variable AWK to use $(AWK) instead of hardcoded awk.
Use by:
make -f dat/luahelper [target]
Target examples:
Visual Studio nmake : make -f dat/luahelper devhelp-nmake >file.txt
msys2 GNUmakefile : make -f dat/luahelper devhelp-msys >file.txt
Xcode project.pbxproj: make -f dat/luahelper devhelp-xcode >file.txt
all: generate txt files for all the above
GitHub 1343 report by @ars3niy:
"When you are blind and see with telepathy a monster whom you then hear read
a scroll, said monster turns into an "I". While it reveals which one exactly
read the scroll, it is strange that you can no longer see it with telepathy
until it moves to another square."
Fixes#1343
There was a transcription error in the comments in cstd.h for
the standard list of header files, where only the description
remained for <stdlib.h>, not the name of the file itself.
Remove several extraneous inclusions of the standard C99 headers.
Tested on the following afterwards:
Linux (using hints/linux.370) including tty, curses, qt6, and X11
macOS (using hints/macOS.370) including tty, curses, qt5, and X11
Windows MSYS2 using sys/windows/GNUmakefile
Windows Visual Studio using sys/windows/Makefile.nmake
msdos cross-compile on Ubuntu using djgpp cross-compiler
Since EDITLEVEL is being incremented for the previous patch anyway,
add the "name_from" bit to the obj struct now, as groundwork for
the code change mentioned in a TODO comment in bones.c:
/* strip user-supplied names */
/* Statue and some corpse names are left intact,
presumably in case they came from score file.
[TODO: this ought to be done differently--names
which came from such a source or came from any
stoned or killed monster should be flagged in
some manner; then we could just check the flag
here and keep "real" names (dead pets, &c) while
discarding player notes attached to statues.] */
if (has_oname(otmp)
&& !(otmp->oartifact || otmp->otyp == STATUE
|| otmp->otyp == SPE_NOVEL
|| (otmp->otyp == CORPSE
&& otmp->corpsenm >= SPECIAL_PM))) {
free_oname(otmp);
}
Also, the bitfield per-byte groupings identified in the struct
weren't accurately reflected, so rearrange the Bitfields,
and correct the per-byte groupings.
This invalidates existing save files and bones.
GitHub issue reported by ars3niy:
https://github.com/NetHack/NetHack/issues/1303
@ars3niy commented on Oct 27:
Stepping on a square with a dust or "graffiti" engraving while blind
produces no message because presumably you can't read them by swiping
the floor with your hands, however the engraving glyph still shows up on
the map afterwards. While this helps zen players, it looks like a bug.
@ville-v commented 3 days ago:
Searching while blind also reveals the engravings. Here is a save file
demonstrating the issue.
[...]
This adds an erevealed bit to engravings, to accompany the the eread
bit that is already there.
eread: refers to the text of the engraving
erevealed: refers to the engraving map symbol
Hopefully, this resolves issue 1303 without creating additional bugs.
This invalidates existing save files and bones.
Fixes#1303
nhmall