~name{~enUS{admin,administrator}}
~keywords{admin}
~desc{
  ~enUS{

You can get help on the various commands individually as well.  Many
require privilege on the caller's part to perform successfully.

%shutdown           Shut down the MUD
%reboot             Reboot the MUD
%swapout            Swap out MUD objects
%statedump          Dump the MUD's full state to a file
%save               Write the objectfiles (as if on shutdown)
%safesave           Write safe-backup copies of object files

%status             Give the status of the MUDLib & server

%who                Show those logged on, with IP addrs
%log                Writes events to the system log
%log_subscribe      Choose what log events get written to file

}}


~name{~enUS{%shutdown,shut down}}
~keywords{admin}
~desc{
  ~enUS{

The %shutdown command will save the state of the MUD including things
like rooms, exits and portables.  Then it will normally cause the MUD
to stop running and the driver process to exit on the host machine.

If an error occurs during the saving of objects, normally the MUD will
NOT continue shutting down -- you may correct this error and then shut
down the MUD again.  Since Phantasmal and DGD allow you to recompile
code so easily, such a small error is usually insufficient reason to
give up and die without saving your data.

However, if you really need to, you can type "%shutdown force" to shut
down the MUD *without* saving your data.

See also %reboot.

}}

~name{~enUS{%reboot,restart}}
~keywords{admin}
~desc{
  ~enUS{

The %reboot command will save the state of the MUD including rooms,
exits, portables, et cetera.  Then it will attempt to reboot the MUD
and have it reload the same files.  While this may be useful to do
occasionally, one goal of a persistent MUD is to *never* require this.
Please use the upgraded() method on objects and the %full_rebuild
command instead of %reboot wherever possible.

If an error occurs during the saving of objects, normally the MUD will
NOT continue shutting down -- you may correct this error and then shut
down the MUD again or you may manually kill the driver process on the
host machine.

See also %shutdown.

}}

~name{~enUS{%swapout,swap out}}
~keywords{admin}
~desc{
  ~enUS{

The %swapout command will swap out many or all of the objects
currently stored in memory.  Since DGD transparently swaps in objects
as they are used, this shouldn't be visible to users or developers
beyond a possible delay, nor is it especially useful to do in almost
any case.

Ordinarily you'd be better served by using the %statedump, %shutdown,
%save or %reboot command.

See also: %statedump, %save, %shutdown, %reboot

}}


~name{~enUS{%statedump,state dump}}
~keywords{admin}
~desc{
  ~enUS{

The %statedump command will dump the entire memory state of the MUD's
LPC environment (supplied by DGD) to a file for loading later.  This
is a far more complete and far less error-prone way to take the MUD up
and down than the %shutdown mechanism combined with object autoload.
However, it may exacerbate certain programming errors since it is a
persistent MUD model.  For details on persistent MUDs and their
characteristics see the DGD mailing list and/or MUD-Dev.  Such MUDs
have been discussed very extensively in both of those forums and
probably many others.

See also: %shutdown, %reboot, %save

}}


~name{~enUS{%datadump,data dump,%save}}
~keywords{admin}
~desc{
  ~enUS{

The %datadump command saves objects to a roomfile, a portablefile and
so on.  It uses the same mechanism as objects being saved on MUD
shutdown and will be broken in the same ways and at the same times.
The %statedump command is quite different and uses a different
mechanism -- see "%statedump".

See also: %shutdown, %reboot, %safesave, %statedump

}}


~name{~enUS{%safesave,safe save}}
~keywords{admin}
~desc{
  ~enUS{

The %safesave command saves objects to a roomfile, a portablefile and
so on.  It uses the same mechanism as objects being saved on MUD
shutdown and will be broken in the same ways and at the same times.
However, unlike the %save command (also called %datadump), this saves
to extra "safe" copies of the files and will not be automatically
loaded on startup.  This is to provide a backup, just in case
something bad happens to your primary copy of the data.  The
%statedump command is quite different and uses a different mechanism
-- see "%statedump".

See also: %shutdown, %reboot, %safesave, %statedump

}}


~name{~enUS{%status}}
~keywords{admin}
~desc{
  ~enUS{

The %status command gives low-level information about the DGD driver
process, including what version of DGD it is running, swap and memory
statistics, how many of its allowed objects, callouts and connections
it's using, and its start time and uptime.

}}


~name{~enUS{%who,%people}}
~keywords{admin}
~desc{
  ~enUS{

The %who command (synonyms: @who, %people, @people) lists who is
currently logged into the MUD, along with the IP address they are
currently logged in from.

}}

~name{~enUS{%write_log,%log, %log_write,%writelog}}
~keywords{admin}
~desc{
  ~enUS{

The @log (called %log and @write_log also, among others) command takes
a single string argument, much like "say".  However, it will log that
string along with your name to the system log.  In general, this is a
very poor way to send the equivalent of e-mail except on the most
excellently-run MUDs since most of the time the log gets briefly read
through (or not) and tossed out to make room for the next one.

See also:  %log_subscribe, logfile, log channel

}}

~name{~enUS{%log_subscribe,subscribe_log,
        subscribe, level, levels, subscription}}
~keywords{admin}
~desc{
  ~enUS{

The %log_subscribe command allows someone with full administrative
access to determine what gets written to the log file.  This is
determined by categories or channels, usually named after the
originating file/program.  The following will cause only warnings and
errors to be recorded from the object daemon:

   %log_subscribe /usr/System/sys/objectd 4

The levels of messages are:

     Fatal Error              6            fatal
     Error                    5            error
     Warning                  4            warning
     Debug Message            3            debug
     Normal operation         2            normal
     Verbose operation        1            verbose

You can type the text string on the right (normal, fatal, etc)
instead of the number to set the logging level.

}}

~name{~enUS{log file, file log, logfile, file}}
~keywords{admin}
~desc{
  ~enUS{

The log file keeps track of what's going on in the MUD.
Administrators can see entries as they are made on the log channel.
They can choose what goes into it with the %log_subscribe command.
Its current default location is /log/System.log in the Phantasmal
directory tree.

See also:  log channel, %log_subscribe

}}


~name{~enUS{log channel, channel log, logchannel}}
~keywords{admin}
~desc{
  ~enUS{

Administrators can subscribe to the log channel with the channels
command.  You can also subscribe at a particular level of severity
with the same command.  For instance:

channel log on verbose
channel log on error

You'll get all notifications at that level and above (so "verbose"
gives lots), even if the logfile isn't actually receiving them
because of its %log_subscribe settings.

See also:  logfile, %log_subscribe

}}


~name{~enUS{error channel, channel error, errorchannel}}
~keywords{admin}
~desc{
  ~enUS{

Administrators can subscribe to the error channel with the channels
command.  You can also subscribe at a particular level of severity
with the same command.  For instance:

channel error on verbose
channel error on error

Currently errors aren't divided by severity, so any subscription to
the channel will send you all uncaught errors that the ErrorD
receives.

See also:  logfile, %log_subscribe

}}