The widget is created with a label but not a pixmap, and then a pixmap
is set up for display. If the label is already realized and managed, it
will not resize when the pixmap is set up. This causes problems when
the inventory window is updated: unlike other menus, the parent Form
widget is already realized. The fix is to create the item widget in an
unmanaged state (XtCreateWidget), set up the pixmap (X11_wrap_widget
and X11_set_attrs), and then manage it (XtManageChild).
Unix command line handling treated an unknown command line parameter
as a maximum number of allowed concurrent players. This emitted
a complaint about expected MAXPLAYERS, and as it can be now set
in sysconf, remove this - most likely unused - functionality.
early_init() was already being called at pcmain.c line 70,
so the recently added call at line 132 was problematic
because it cleared program_state values that had been
intentionally set since the call at line 70.
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.
nhmall