<!-- 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>