<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: Standard Mud Room Format? -->
<!--X-From-R13: "F. Oyrknaqre Bbcvry" <cbcvryNfahtuneobe.pbz> -->
<!--X-Date: Wed, 19 Aug 1998 17:28:16 -0700 -->
<!--X-Message-Id: 199808200027.RAA08161#cashew,snugharbor.com.snugharbor.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: E0z9Hsk-0002NX-00#mail,kanga.nu -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: Standard Mud Room Format?</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:popiel#snugharbor,com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00779.html">Previous</a>
| <a href="msg00781.html">Next</a>
]
Thread:
[ <a href="msg00779.html">Previous</a>
| <a href="msg00781.html">Next</a>
]
Index:
[ <A HREF="author.html#00780">Author</A>
| <A HREF="#00780">Date</A>
| <A HREF="thread.html#00780">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: Standard Mud Room Format?</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: Standard Mud Room Format? </LI>
<LI><em>From</em>: "T. Alexander Popiel" <<A HREF="mailto:popiel#snugharbor,com">popiel#snugharbor,com</A>></LI>
<LI><em>Date</em>: Wed, 19 Aug 1998 17:27:46 -0600</LI>
<LI><em>cc</em>: <A HREF="mailto:popiel#snugharbor,com">popiel#snugharbor,com</A></LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
In message: <<A HREF="msg00779.html">E0z9Hsk-0002NX-00#mail,kanga.nu</A>>
plateau <plateau#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
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00779" HREF="msg00779.html">[MUD-Dev] Standard Mud Room Format?</A></STRONG>
<UL><LI><EM>From:</EM> plateau <plateau#mail,tcbi.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00779.html">[MUD-Dev] Standard Mud Room Format?</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00781.html">[MUD-Dev] Re: Standard Mud Room Format?</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00779.html">[MUD-Dev] Standard Mud Room Format?</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00781.html">[MUD-Dev] Re: Standard Mud Room Format?</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00780"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00780"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><strong><A NAME="00786" HREF="msg00786.html">[MUD-Dev] Re: Standard Mud Room Format?</A></strong>,
Michael.Willey <a href="mailto:Michael.Willey#abnamro,com">Michael.Willey#abnamro,com</a>, Thu 20 Aug 1998, 13:23 GMT
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00789" HREF="msg00789.html">[MUD-Dev] Re: Standard Mud Room Format?</A></strong>,
Scatter <a href="mailto:scatter#thevortex,com">scatter#thevortex,com</a>, Thu 20 Aug 1998, 16:49 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00785" HREF="msg00785.html">[MUD-Dev] [MUD-DEV] Tangent to the Tailor</A></strong>,
Marc Bowden <a href="mailto:ryumo#merit,edu">ryumo#merit,edu</a>, Thu 20 Aug 1998, 13:20 GMT
<LI><strong><A NAME="00779" HREF="msg00779.html">[MUD-Dev] Standard Mud Room Format?</A></strong>,
plateau <a href="mailto:plateau#mail,tcbi.com">plateau#mail,tcbi.com</a>, Wed 19 Aug 1998, 23:43 GMT
<UL>
<LI><strong><A NAME="00780" HREF="msg00780.html">[MUD-Dev] Re: Standard Mud Room Format?</A></strong>,
T. Alexander Popiel <a href="mailto:popiel#snugharbor,com">popiel#snugharbor,com</a>, Thu 20 Aug 1998, 00:28 GMT
</LI>
<LI><strong><A NAME="00781" HREF="msg00781.html">[MUD-Dev] Re: Standard Mud Room Format?</A></strong>,
Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Thu 20 Aug 1998, 01:42 GMT
</LI>
<LI><strong><A NAME="00782" HREF="msg00782.html">[MUD-Dev] Re: Standard Mud Room Format?</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 20 Aug 1998, 03:02 GMT
</LI>
<LI><strong><A NAME="00784" HREF="msg00784.html">[MUD-Dev] Re: Standard Mud Room Format?</A></strong>,
Hans-Henrik Staerfeldt <a href="mailto:hhs#cbs,dtu.dk">hhs#cbs,dtu.dk</a>, Thu 20 Aug 1998, 12:46 GMT
</LI>
<LI><strong><A NAME="00787" HREF="msg00787.html">[MUD-Dev] Re: Standard Mud Room Format?</A></strong>,
Holly Sommer <a href="mailto:hsommer#micro,ti.com">hsommer#micro,ti.com</a>, Thu 20 Aug 1998, 14:54 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>