87 lines
4.2 KiB
Plaintext
87 lines
4.2 KiB
Plaintext
RECOVER(6) Games Manual RECOVER(6)
|
|
|
|
|
|
|
|
NAME
|
|
recover - recover a NetHack game interrupted by disaster
|
|
|
|
SYNOPSIS
|
|
recover [ -d directory ] base1 base2 ...
|
|
|
|
DESCRIPTION
|
|
Occasionally, a NetHack game will be interrupted by disaster when the
|
|
game or the system crashes. Prior to NetHack v3.1, these games were
|
|
lost because various information like the player's inventory was kept
|
|
only in memory. Now, all pertinent information can be written out to
|
|
disk, so such games can be recovered at the point of the last level
|
|
change.
|
|
|
|
The base options tell recover which files to process. Each base option
|
|
specifies recovery of a separate game.
|
|
|
|
The -d option, which must be the first argument if it appears, supplies
|
|
a directory which is the NetHack playground. It overrides the value
|
|
from NETHACKDIR, HACKDIR, or the directory specified by the game admin-
|
|
istrator during compilation (usually /usr/games/lib/nethackdir).
|
|
|
|
For recovery to be possible, nethack must have been compiled with the
|
|
INSURANCE option, and the run-time option checkpoint must also have
|
|
been on. NetHack normally writes out files for levels as the player
|
|
leaves them, so they will be ready for return visits. When checkpoint-
|
|
ing, NetHack also writes out the level entered and the current game
|
|
state on every level change. This naturally slows level changes down
|
|
somewhat.
|
|
|
|
The level file names are of the form base.nn, where nn is an internal
|
|
bookkeeping number for the level. The file base.0 is used for game
|
|
identity, locking, and, when checkpointing, for the game state. Vari-
|
|
ous OSes use different strategies for constructing the base name.
|
|
Microcomputers use the character name, possibly truncated and modified
|
|
to be a legal filename on that system. Multi-user systems use the
|
|
(modified) character name prefixed by a user number to avoid conflicts,
|
|
or "xlock" if the number of concurrent players is being limited. It
|
|
may be necessary to look in the playground to find the correct base
|
|
name of the interrupted game. recover will transform these level files
|
|
into a save file of the same name as nethack would have used.
|
|
|
|
Since recover must be able to read and delete files from the playground
|
|
and create files in the save directory, it has interesting interactions
|
|
with game security. Giving ordinary players access to recover through
|
|
setuid or setgid is tantamount to leaving the playground world-
|
|
writable, with respect to both cheating and messing up other players.
|
|
For a single-user system, this of course does not change anything, so
|
|
some of the microcomputer ports install recover by default.
|
|
|
|
For a multi-user system, the game administrator may want to arrange for
|
|
all .0 files in the playground to be fed to recover when the host
|
|
machine boots, and handle game crashes individually. If the user popu-
|
|
lation is sufficiently trustworthy, recover can be installed with the
|
|
same permissions the nethack executable has. In either case, recover
|
|
is easily compiled from the distribution utility directory.
|
|
|
|
NOTES
|
|
Like nethack itself, recover will overwrite existing savefiles of the
|
|
same name. Savefiles created by recover are uncompressed; they may be
|
|
compressed afterwards if desired, but even a compression-using nethack
|
|
will find them in the uncompressed form.
|
|
|
|
SEE ALSO
|
|
nethack(6)
|
|
|
|
BUGS
|
|
recover makes no attempt to find out if a base name specifies a game in
|
|
progress. If multiple machines share a playground, this would be
|
|
impossible to determine.
|
|
|
|
recover should be taught to use the nethack playground locking mecha-
|
|
nism to avoid conflicts.
|
|
|
|
COPYRIGHT
|
|
This file is Copyright (C) Kenneth Lorber, 2024 for version
|
|
NetHack-3.7:1.12. NetHack may be freely redistributed. See license
|
|
for details.
|
|
|
|
|
|
|
|
NETHACK 25 December 2024 RECOVER(6)
|