[MUD-Dev] Re: Standard Mud Room Format?

T. Alexander Popiel popiel at snugharbor.com
Wed Aug 19 17:27:46 CEST 1998


In message:  <E0z9Hsk-0002NX-00 at mail.kanga.nu>
             plateau <plateau at mail.tcbi.com> writes:
>
>Anyway, I began to think of all the different MUD editors already 
>available, and started to wonder if there weren't some type of "standard 
>format" from which to import rooms, spells, mobs, etc.
>
>Sure, most muds are in some way "different" from the others, code-wise, 
>but they all share certain characteristics: most rooms have descriptions, 
>they are usually connected to each other by the 10 basic exits 
>(n/s/e/w/u/d/nw/se/ne/sw) as well as other links ('enter bushes'). Most 
>have titles for their areas, and some share similar flags such as 
>'nomob', 'safe', etc.

Methinks you've been dealing with Dikus a lot (they're the primary
ones to have the 10 basic exits concept in the driver; elsewhere
it's just convention or completely ignored), but that's beside
the point... ;-)

Anyway, the closest I've seen is something I wrote up a few years
ago, and still haven't managed to get into PennMUSH (though it should
actually make it into 1.7.3!).  The draft below is slightly out of
date, but should give you the general idea.

- Alex


PROPOSAL: DB Format #1

		Universal DB Format For MUSH/MUSE/MUX

Abstract

   The current systems for storing MUSH/MUSE/MUX databases have many
   problems with them, including inflexibility, mutual incompatibility,
   inefficiency, and general incomprehensibility.  I would like to
   generate a new format by which all flavors of MUSH, MUSE, and MUX
   (and any other MUD servers which share the paradigm of continually
   existing objects with locations, attributes, and the like) might
   store their databases, and read the databases of others.


Specific Goals (and Non-Goals)

   I would like to specify a syntax (and semantics) for database
   storage which is:

   (a) easily parsed by either machine or human,

   (b) usable even with missing information,

   (c) usable even with extra information (including unrecognized
       structures),

   (d) independent of in-server representation of objects, and

   (e) reasonably space-efficient.

   I do not intend this to be the format for the run-time database for
   disk-based servers, or even necessarily for the standard disk backup
   format of any server; it is intended primarily to address problems
   of database transportability between servers.  The fact that
   PennMUSH 1.7.0 will likely use it directly for database storage is
   of only minor relevance.


Basic Hierarchy

   A database in this format is made up of a set of nested data
   structures hereafter referred to as "groups".  Each group may
   contain an arbitrary amount of labeled data hereafter referred to as
   "fields".  Fields may in turn be groups in their own right.

   All data in this format shall be stored in fields.  All fields shall
   be composed of a label and an optional value, and (in the case of
   group fields) a list of group member fields.  The last member field
   of a group shall have a label lexically derivable from the label of
   the group as a whole (to enable servers to find the end of
   unrecognized groups); order requirements of the rest of the member
   fields is to be kept to a minimum (to reduce chances of mutual
   incompatibility).

   Field labels should indicate semantic content of the data in
   preference to how any particular server stores the information at
   run-time.


Lexical and Syntactic Structure

   A database shall consist of a set of logical lines of characters.
   Logical lines shall either be blank, begin with a '#' character
   (indicating that the rest of the line should not be interpreted), or
   contain a field.  A logical line shall contain exactly one newline
   (as the terminating character), discounting newlines within quoted
   strings.

   Each field shall be stored as one logical line in a  file.  This
   line shall begin with an arbitrary (possibly nonexistant) amount of
   whitespace, followed by a label, optionally some whitespace and a
   value, followed by a newline.  If there is a value in the field,
   then there shall be some whitespace separating it from the label.

   Labels shall consist of strings of alphanumeric characters and '_',
   '-', '!', or '.'; as a special case, labels of group fields (and only
   group fields) shall start with '>', and labels of the last members
   of groups shall be identical to the label of the group, with the '>'
   changed to '<' (thus, the terminating field of a group labeled
   ">object" would have a label of "<object").  Labels shall be case-
   insensitive.

   Values may take on several forms; numbers, labels, and quoted
   strings among them.  All forms other than quoted strings shall
   contain only those characters allowed in labels, with the addition
   of non-newline whitespace characters.  Quoted strings shall consist
   of an initial '"', the data, and a final '"'.  Any '\' or '"' within
   the string shall be preceded by an additional '\' character, thus
   enabling the representation of arbitrary data within the string.
   (Implementations should take care to allow the NULL character, all
   bits zero, within a string when reading a database in this form; it
   is a valid character in this context, despite problems that C
   library functions may have with it.)

   As an example, a lexically correct database might appear as
   follows:

      >database "Talek's Test"
      # This is a silly example
      version 1.0
                                  indented_label_without_value
      LaBeL_WiTh_STRanGE_CapItalIzaTion.

	 >object 1
            name "Talek"
            money too_little
            longstring "this
	                 string contains a newline and a lot of spaces"
      # Another useless comment ;-P
           <object ugly bag of mostly water
      <database


Semantics

   Fields should, as a rule, only appear in the database if their
   value is something other than the default.  If an implementation
   expects a value for a particular field, but does not encounter
   field in the database, then it should use a default value for
   that field.

   Unrecognized fields should not cause the implementation to abort;
   instead, the field should be discarded (including any subsidiary
   fields in the case of unrecognized groups), possibly generating
   a warning message.

   Fields containing derivable information should be avoided, since
   they bloat the database for little purpose.

   Garbage objects should not be stored in the database.  There should
   be no requirement on the order in which the objects in a database are
   stored.

   Fields with values incompatible with a server should produce
   warning messages when encountered.

   Defaults (unless specifically stated below) are left up to the
   server, and should be reasonable values.  A server may require
   that a field value be specified explicitly, but this is stongly
   discouraged.


Predefined Fields

   >database			top-level group
      This field contains the entire database.
      As an optional value, it may contain the name of the database.

   <database			member of >database
      This field has no value, and is used to terminate a database.

   generated_by			member of >database
      This field has, as a value, a string describing the entity
      (program?) that generated the database, such as "PennMUSH 1.7.0p0".

   num_objects			member of >database
      This field has an integral numeric value indicating the number
      of objects in the database, for purposes of memory preallocation.
      If present, it should occur before the first >object field.
      (Note: this field breaks the rule about derivable information.
      However, memory preallocation is useful enough, IMNSHO, to warrant
      it.)

   default_object_flags		member of >database
      This field indicates a set of flags commonly used by all objects.
      Default value should be no flags.  This field, if present, should
      preceed all >object fields.

   default_exit_flags		member of >database
      This field indicates a set of flags, in addition to those specified
      in default_object_flags, which are commonly used by exits.  If
      present, this field should preceed all >object fields, and succeed
      the default_object_flags field.
      Default: no additional flags.

   default_player_flags		member of >database
      This field indicates a set of flags, in addition to those specified
      in default_object_flags, which are commonly used by players.  If
      present, this field should preceed all >object fields, and succeed
      the default_object_flags field.
      Default: no additional flags.

   default_room_flags		member of >database
      This field indicates a set of flags, in addition to those specified
      in default_object_flags, which are commonly used by rooms.  If
      present, this field should preceed all >object fields, and succeed
      the default_object_flags field.
      Default: no additional flags.

   default_thing_flags		member of >database
      This field indicates a set of flags, in addition to those specified
      in default_object_flags, which are commonly used by things.  If
      present, this field should preceed all >object fields, and succeed
      the default_object_flags field.
      Default: no additional flags.

   >attr_info			member of >database
      This is a group containing permissions information about attributes
      in the database.  The value of this field is the name of the attribute
      so modified.

   <attr_info			member of >attr_info
      This is a valueless indicator of the end of an attribute permissions
      block.

   permissions			member of >attr_info
      This field contains a description of the permissions of an attribute.

   >object			member of >database
      This field has, as value, the dbref of the object it represents.

   <object			member of >object
      This field has no value, and indicates the end of an object.

   type				member of >object
      This field specifies the type of an object.  For current versions
      of MUSH, the type of an object may be EXIT, PLAYER, ROOM, or THING.
      This field must precede any type-dependant fields, such as flags
      or destination.
      Default: THING.

   flags			member of >object
      This field specifies a set of flags applied to the object.  Flags
      are specified by name (for ease of transport between servers),
      and may be preceded with an '!' to negate default flags.  Flags
      are separated by whitespace within the value.
      Default: as specified by the default_*_flags fields of the >database
      group.

   name				member of >object
      This field specifies the name of an object.
      Must be explicitly specified.

   contents			member of >object
      This field contains a space-separated list of dbrefs of objects
      contained within this object.  Note that the list is order-sensitive.
      Default: no contents.

   exits			member of >object
      This field contains a space-separated list of dbrefs of exits
      leading from this object.  Note that the list is order-sensitive.
      Default: no exits.

   parents			member of >object
      This field contains a space-separated list of dbrefs of OOP
      parents of this object.  Not all servers will allow multiple
      parents, but this format does.  Note that this includes only
      immediate parents, not all ancestors of an object.
      Default: no parents.

   zones			member of >object
      This field (yat again) contains a space-separated list of
      dbrefs, this time for zones (places checked for $-commands
      and the like) that the object is a member of.

   owner			member of >object
      This field contains the dbref of the owner object of this object.

   money			member of >object
      This is the amount of money held by the object.

   creation_time		member of >object
      This is the time (in seconds from the epoch) when the object was
      created.

   modification_time		member of >object
      This is the time (in seconds from the epoch) when the object was
      last modified.

   drop_to			member of >object
      This contains the drop_to for a room.

   destination			member of >object
      This is the destination object of an exit.

   powers			member of >object
      This is a space-separated list of powers (security permissions)
      granted to the object.

   home				member of >object
      This is the dbref of the "home" location of an object.
      Default: current location.

   warnings			member of >object
      This is a list of automated warnings that the object should be
      checked for.  (Who added this to PennMUSH?  Why?)

   channels			member of >object
      This is a space-separated list of names of channels that the
      object belongs to.

   >lock			member of >object
      This is the start of a lock on the object.  The name of the
      lock is given as value.  If the name is not present, then
      the lock generated by the bare "@lock" command is assumed.

   <lock			member of >lock
      This is the end of a lock.

   value			member of >lock
      This contains the unparsed text of the lock, as it would appear
      to a user of the server, with the exception that all objects are
      referred to by dbref instead of by name.

   flags			member of >lock
      This contains any flags that apply to the lock.

   >attr			member of >object
      This is the start of an attribute on an object.  The name of the
      attribute is the value of this field.

   <attr			member of >attr
      This is the end of the attribute.

   value			member of >attr
      This is the value of the attribute.

   flags			member of >attr
      This is a space-separated list of flags that apply to the attribute.

   owner			member of >attr
      This is the dbref of the owner of the attribute
      Default: the owner of the object with the attribute.


Example Database

   >database "Minimal"
   generated_by "T. Alexander Popiel"
   num_objects 3

   >object 1
    name "God"
    type PLAYER
    flags WIZARD
    >attr XYXXY
     value "XXUihVF6TimuY"
    <attr
   <object

   >object 2
    type ROOM
    name "Master Room"
    flags FLOATING
    >attr DESCRIBE
     value "This is the master room."
    <attr
   <object

   >object 0
    type ROOM
    >attr DESCRIBE
     value "This is Room Zero, the beginning of many things."
    <attr
    name "Room Zero"
    contents 1
   <object

   <database




More information about the mud-dev-archive mailing list