[DGD] From DGD to Hydra

[Felix A. Croes]

DGD 1.4.4 and Hydra 1.1.34 support the same statedump format, version 12.
But while DGD can restore much older format versions going back more than
a decade, Hydra will only be backward compatible with the current version.
That makes 1.4.4 the "crossover" version for DGD.  I certainly hope that
future versions will remain compatible with Hydra, but now that DGD is
open source, I am not the sole arbiter anymore :)

To safely use Hydra with a statedump that dates back to before DGD 1.4,
you should start DGD 1.4.4 with the statedump, recompile all objects, and
create a new statedump.  However, in some cases this may not be enough.
Over the years a number of kfuns have been removed from DGD, which could
still have some leftover presence in the statedump, shown as:

    Restored unknown kfun: 0.dump_state

or some similar message when booting with Hydra.  To properly scrub the
statedump, you should do the following:

 - start DGD 1.4.4 (with the statedump) in a debugger
 - recompile all objects
 - interrupt DGD, call kf_reclaim() from the debugger, and continue
 - recompile all objects, again
 - call kf_reclaim() from the debugger, again
 - create a new statedump

Statedumps originally created with DGD 1.4 (dumpfile format version 10)
or later will be converted automatically by DGD 1.4.4.  No recompiling
of objects or reclaiming of kfuns will be necessary.

Please note that although some nudging may be needed as noted above,
converting statedumps is a lossless process.  Provided that you have
adjusted your mudlib for the minor API changes made to DGD over the
years, it <is> possible to run Hydra on a statedump that originates
back in 1996 (format version 2).

Also note that statedumps created with a specific kfun extension in
effect, will require the the same kfun extension on restore.  With
some driver hacking, you can work around that:

    https://mail.dworkin.nl/pipermail/dgd/2008-August/006078.html
    https://mail.dworkin.nl/pipermail/dgd/2008-August/006079.html

It can be argued that DGD should handle these cases without hacks
and debugger interrupts, and I suggest this as an area for research
to my fellow DGD open-sourcers.

Regards,
Felix Croes