save_currentstate() increments program_state.in_checkpoint and then
returns early without decrementing it when currentlevel_rewrite()
fails (full disk, quota, unwritable directory). The guard at the top
of the function suppresses every later checkpoint for the rest of the
game, leaving recover with nothing newer than the last checkpoint that
did get written, and nothing says so.
savestateinlock() returns early unless
program_state.something_worth_saving is set, but both call sites that
are meant to lay down the initial checkpoint run before that flag is
set: newgame() calls save_currentstate() two lines early, and
dorecover() calls savestateinlock() 73 lines before it, ahead of the
pass that writes out the level files.
Both calls are therefore no-ops, and the <uid><plname>.0 lock file
holds nothing but the pid written by getlock() until the hero first
changes dungeon level. A game that dies without a chance to save
during that window (SIGKILL, OOM killer, watchdog, host reboot)
cannot be rebuilt: recover has no save file name, no current level
number and no game state, and reports "Checkpointing was not in
effect", which is true of the outcome but misleading about the cause.
The window covers the whole of a long stay on one level, and in
particular the entire period right after a restore.
Set the flag before the call in newgame(). In dorecover(), drop the
ineffective call and checkpoint once the restore is complete instead;
at the original spot no level file for this session has been written
yet, so a checkpoint there would name a current level and save file
that are not on disk. The new call goes after program_state.restoring
is cleared, so that stairs and traps are written with the same
relative dlevel encoding a normal save uses, and it is
save_currentstate() rather than savestateinlock() so that
in_checkpoint is set while savegamestate() writes u.ustuck_mid and
u.usteed_mid.
This arrived with the something_worth_saving guard; 3.4.3, which has
no guard, is unaffected. Looks like this issue has been around since
version 3.6.0.
Reported directly to devteam, the code was using "Your little dog
devours the tripe ration" during the taming process, prior to the
pet becoming yours.
The startup had fallen behind NetHack 5.0 startup for other platforms,
and lacked support for some of the early command line options.
Following this, if PC_EARLY_OPTIONS is defined in pcconf.h, the
port will support those options, such as --version, --showpaths,
--dumpenums, etc.)
Currently, MSDOS #defines's PC_EARLY_OPTIONS, but AMIGA, ATARI,
and MAC68K do not.
If there are, say, two or more potions in the menu, and multiple
selections are allowed, then '!' should select all potions. Such keys
were selecting only the first matching item.
Renders to a Pixmap and then sets the Pixmap. This in itself does not
change the appearance, but provides a means to do percentage bars,
italics and more.
This was trying to retrieve the foreground color of the form created
in create_value(). Forms don't have colors, and so this was failing,
and update_color() didn't update the color.
Menu windows with lots of entries (such as #optionsfull) were taller
than the screen, making them awkward to use.
The widget needs to be realized before we can get the size.
Also, we need to set the size of the parent popup, not the
acting widget.
This is intended to resolve GitHub Issue #1650, which I was unable to directly reproduce
on my test system.
This fix assumes that the reported issue was related to cmdstr[BUFSZ] buffer not
getting initialized, thus containing random memory values.
1d3178a quieted the g++ build, but made the warnings even
worse with a clang build.
The addition of the -Wno-sfinae-incomplete caused an unrecognized
option warning using recent clang.
Recent clang build with Qt6.1 also caused several warnings
during the processing of the Qt6.1 header files related to
c++26-extensions.
This adds (under Linux) -Wnoc++-26-extensions to the clang++
command line to quiet those warnings and restricts the
-Wno-sfinae-incomplete command line option to the g++ build.