<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<title>Scripting in CoffeeMud 5.9</title><link rel="StyleSheet" href="style.css" type="text/css" media="screen" /><!-- Modified by Josh Mueller, 2006-05-05, fix validation problems, add index, and fix spelling errors --><!-- Modified by Josh Mueller, 2006-05-06, add close_prog, lock_prog, unlock_prog, open_prog --></head>
<body>
<center>
<table style="width: 90%;" border="1" cellpadding="10" cellspacing="0">
<tbody>
<tr>
<td colspan="2" align="left" bgcolor="#dfdfdf" width="100%">
<h1>Random Generation in CoffeeMud 5.9</h1>
</td>
</tr>
<tr>
<td align="left" valign="top" width="20%">
<ul>
<li><a href="#introduction">Introduction to
Random Generation</a></li>
<li><a href="#structure">Overview of XML Tags</a></li>
<li><a href="RandomAreas.html#using">Using
the Random Generator</a></li>
<li> <a href="#glossary">Glossary of XML
Tags</a>
<ul>
<li><a href="#areatag">Area</a></li>
<li><a href="#roomtag">Room</a></li>
<li><a href="#mobtag">Mob</a></li>
<li><a href="#itemtag">Item</a></li>
<li><a href="#affecttag">Affect</a></li>
<li><a href="#abilitytag">Ability</a></li>
<li><a href="#culturalability">Culturalability</a></li>
<li><a href="#behaviortag">Behavior</a></li>
<li><a href="#contenttag">Content</a></li>
<li><a href="exittag">Exit</a></li>
<li><a href="#racetag">Race</a></li>
<li><a href="#factiontag">Faction</a><span style="text-decoration: underline;"><br />
</span></li>
</ul>
</li>
</ul>
</td>
<td style="text-align: left;">
<p class="center"><img src="images/mug.jpg" alt="coffeemud logo" /></p>
<h2><a name="introduction">Introduction to
Random Generation</a></h2>
<p>Random generation in the realm of mud areas, rooms,
items, mobs, and so forth is a strange proposition. In the
end, it always boils down to selecting among known, fixed, and constant
alternatives that make sense in a particular context. For
example, a mob that might be named "George" or "A path in the forest"
is certainly random, but doesn't make much sense, so we tend to
restrict our alternatives in some way. Also, selecting evenly
among alternatives, while certainly the most common thing you will do,
also sometimes doesn't make sense. A random Moon description
might include words like "full", "new", "crescent", "half", and "BLUE".
However, just because you want the "BLUE" alternative to be
available, doesn't mean you want it to have an equal chance of
describing your moon as the other choices. Lastly, sometimes
the context in which an alternative makes sense can be extremely
narrow. Having "a rat" as a random monster in your dungeon
almost always makes sense, except in the "cat room". Again,
judgement must come into play.</p>
<p>All of these considerations and more have gone into the
devising of a random mud engine, and particularly to the format of the
input data it uses. This engine receives a series of sets of
alternatives which may include a relative weight for each alternative,
and potentially the context in which each alternative applies or
doesn't apply, and then makes selections and instantiates real
mud objects based on those selections. The input to the
engine is a very specifically built XML file, and the output is actual
mud objects (mobs, items, areas, rooms, or all the above) in your game.<span style="font-weight: bold;"></span></p>
<h2><a name="structure">Overview of
XML Tags</a></h2>
<a name="structure">The random generator works by reading a specially-written XML document
that contains tags describing the object or objects to generate.
For example, area generation looks for tags named
<AREA />, mobs for <MOB />, items for
<ITEM />, rooms for <ROOM />, and so forth.
<br />
<br />
The embedding of tags can also be significant. For
example, to generate a mob from a given <MOB /> tag, the
tag must either contain a NAME attribute, or a <NAME />
tag embedded inside the <MOB /> tag. Another
example would be that<br />
room tags may contain mob and item tags.<br />
<br />
Generation sometimes requires that a specific starting object be named
by ID, in which case an ID attribute may be found on the tag, allowing
it to be referenced globally, no matter where it is embedded.<br />
<br />
The basic tag types are AREA, ROOM, MOB, ITEM, and STRING.
Any tag that contains other tags of the same tag type is a
Container tag, and usually has rules in the form of special attributes
for how to select among the alternatives in the container. In
cases where one of something is called for, but multiple options are
available, and no rules are found for how to select among them, a
random roll will be made. In cases where one or more of
something is allowed, and multiple options are available, all the
alternatives found will be selected.<br />
<br />
Each basic tag type is used to build an object of that type.
For
instance, the MOB tag is used to build a MOB. Therefore, each
basic
object type must have other tags or attributes to "fill in the
details", such as name, level, and so forth. These Details
may be
defined as variables on the command line using GENERATE or by the
"define" attribute, or may be given as an attribute of the basic tag,
or as other tags inside the parent tag. A Detail given as an
attribute
always supersedes any detail given as internal tags, no matter
what. A
detail found as an defined variable identifier, supersedes both tags and<br />
attributes. See the glossary for more tails on each major tag
type.<br />
<br />
Basic
tags may also have special pre-defined variables to help give some
context to help with their parsing, and will often cause variables to
be defined as their details are filled in. Basic tags also
have
certain required details which must be resolved for the<br />
object to be created, and other optional details which may or may not
be given, and which are extremely object-specific. Again, the
glossary entry for each basic tag type will have more information about
this.<br />
<br />
Tags are always evaluated recursively, from first to last.
Any tag may contain zero or more of the following
meta-attributes:<br />
<br />
</a><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2">
<tbody>
<tr>
<td>id</td>
<td>exposes the tag to either the Generate command,
or to the "insert" or "like" attributes.</td>
</tr>
<tr>
<td>load</td>
<td>the xml inside the file named is inserted into
the tag</td>
</tr>
<tr>
<td>like</td>
<td>a comma separated list of other tag "id"s of the
SAME TYPE. These may NOT be container tags. This will allow
the current tag to be parsed as if it contained the same tags
and attributes as the listed tags. This is useful for making
one-off variations on existing tag structures.</td>
</tr>
<tr>
<td>insert</td>
<td>a comma separated list of other tag ids. The
targeted tags may be of any type, and may be containers. It
will cause the tags to be parsed and the resulting tags added as
contents of the host tag as if they were already inside it.
Remember, the listed tags will be parsed first, so any "condition",
"select" or other operations will occur.</td>
</tr>
<tr>
<td>copyof</td>
<td>a tag "id" or standard class id. This will cause
the stats and attributes and other details of the listed items
into the current object.</td>
</tr>
<tr>
<td>validate</td>
<td>a boolean expression which must evaluate to true
for the tag to be finally built into an object. Check
"condition" below for more information....</td>
</tr>
<tr>
<td>condition</td>
<td> the value is a boolean expression which must
evaluate to true for the tag to be included in its parent.
This is similar to "validate" except that "condition" determines
whether a tag is among the allowed choices, whereas "validate"
determines whether, after being chosen, it is finally built into a
final thing (whether string, mob, item, whatever). These
expressions may use boolean operators like AND and OR and NOT (or
!), string constants are always single-quoted 'string', string
comparison operators include = , !=, and IN to check to see if
the lhs string is a substring of the rhs string. Numeric
comparisons may be made as well, and numeric comparison
operators include > < >= <= != =.
Parenthesis may be used to group sub-expressions. Defined
variables may be included, but only if preceded by a $
character. For instance, to check if the variable "bob" is
equal to "bobvalue", you would enter $bob='bobvalue'.
Undefined string ids are treated as ''. Remember
that in XML, a < and > characters can not appear
in attribute values, which is why they must be written as &lt;
and &gt; in your xml.</td>
</tr>
<tr>
<td>define</td>
<td>this attribute is only used if its "condition" is
met, and it is "selected" by its parent tag, if applicable.
It is a comma separated list of any combination of the
following:<br />
<ul>
<li>"id": either a new or existing identifier, in
which case the value that this tag resolves to will be set to
that identifier, allowing it to be used in "condition", tag values, or
other places.</li>
<li>"id=value": will set the new or existing
identifier "id" to the given constant "value".</li>
<li>"id+=number": see below</li>
<li>"id*=number": see below</li>
<li>"id-=number": see below</li>
<li>"id/=number": Will attempt to evaluate the
existing value of the identifier"id" as a number, and perform the given
operation upon it with the "number" given. For instance "bob+=3" will
add the number 3 to the current value of the identifier
"bob". Any undefined "id" will be treated as if it were 0.
When dealing with areas, there is an extra feature of defined
identifiers. An identifier whose name starts with "_" will
persist for every tag and object in the room's "room
group". An identifier whose name starts with "__"
will persist throughout the entire area. Otherwise, any
variables defined using this command will persist only for one room.</li>
</ul>
</td>
</tr>
<tr>
<td>predefine</td>
<td>identical to "define", but always evaluated when
encountered.</td>
</tr>
<tr>
<td>select</td>
<td>used mostly by container tags, this attribute
allows you to specify how multiple choices are resolved by this
tag. More than one selection may be made, which makes sense
when selecting MOB tags for a ROOM. However,
sometimes it does not, such as when selecting a NAME for a
MOB. In those cases, any remaining multiple-choices are
always selected randomly from. Possible values are:<br />
<ul>
<li>"all": always selects every choice.</li>
<li>"any-X": selects any X** of the choices,
without repeating. Make
sure you have another choices to cover the possible value of X!</li>
<li>"pick-X": same as "any-X", but the tag choices
will be checked for the </li>
<ul>
<li>"pickweight" is container-entry attribute,
and is used only when the parent tag is using 'select="pick-X" ' as a
relative weight when selecting among the choices.</li>
</ul>
<li>"limit-x": selects up to X** random choices,
but less is OK too if no more.</li>
<li>"repeat-X": always selects every choice, and
treats the choices as
if enough of them actually existed to select X** of them,
even if not
enough choices were given.</li>
<li>"none": always selects none of the choices (why
would anyone use this?!)</li>
<li>"first": selects the first choice (another
stupid one)</li>
<li>"last": you guessed it, select the last choice</li>
<li>"first-X": selects the first X** choices.</li>
<li>"last-X": selects the last X** choices.</li>
</ul>
** Where you see X above, this may be a number, or a math formula or
math expression. (see mud help on math formulas/math expressions)</td>
</tr>
<tr>
<td>merge</td>
<td>must be "true" if two tags with the same ID are
included in the same xml document. It permits some of the tag
parameters, and all of the content tags, to be merged together into a
single referenced tag. In this circumstance, child tags of
parent tags which are being merged may optionally include "merge=false"
to prevent duplicates from being formed.</td>
</tr>
<tr>
<td>pickweight</td>
<td>a helper attribute for the "select"
attribute, when a "pick" value is used by the select
attribute. See "select" attribute above.</td>
</tr>
<tr>
<td>action</td>
<td> used by string-type choices to inform the engine
on how to combine the multiple choices into a single string.
Possible values include:<br />
<ul>
<li>
"append": append the tags value to the string as built so far.</li>
<li>
"replace": completely replace any string build so far with this ones
value.</li>
<li>
"prepend": always put this strings value at the beginning of the final
string</li>
</ul>
</td>
</tr>
<tr>
<td>requires</td>
<td>a comma-separated list of variable identifiers
which must have already been defined before this tag can be
evaluated. Such variables are usually defined by the user of
the GENERATE command, but can also be defined at parse-time by the
"define" attribute, if you are creative. Each item in the
list is of the format "id=type", so that the parser can check to see
not only if the variable is defined, but that it is defined
properly. Possible types include "#" for a number, "int" for
an integer, "$" for a string, or a semicolon-delimited list of possible
string values.</td>
</tr>
</tbody>
</table>
<a name="structure"> <br />
<span style="font-weight: bold;">Tag values</span>:<br />
A non-container non-basic tag will typically have a string
value. This value may contain any embedded variables or
identifiers, so long as they are preceded with a $ character.<br />
<br />
A string beginning with a $ character will be assumed to be an
identifier, and will be searched for within the list of defined
variables and identifiers. If the identifier resolves to a
tag, the tag will be parsed as a string. If the identifier
resolves to<br />
a string, so much the easier.<br />
<br />
Defined variables or tag names can also be embedded in {} characters;
for example: ${ame}. When embedded in this way, the name may be
preceeded by:<br />
</a><ul>
<a name="structure"> <li>"u:" to force to all-uppercase</li>
<li>"l:" to force all-lowercase</li>
<li>"p:" to force plural</li>
<li>"c:" to force to be capitalized (first letter upper,
rest lower).</li>
</a></ul>
<a name="structure"> <span style="font-weight: bold;">Special embedded
variables</span>:<br />
</a><ul>
<a name="structure"> <li>$SYSTEM_RANDOM_NAME:[NUMX]-[NUMY] generate a random
name with between NUMX and NUMY syllables.</li>
<li>${STAT:[STATNAME]} embed the value from another stat
on the same object. STATs are things like NAME, DISPLAY,
DESCRIPTION, etc...</li>
<li>${STAT:[PATH]:[TO]:[ANOTHER]:[OBJECT]:[STATNAME]}
embed the value from another objects stat, potentially in a different
room. Where path-to-another-object may be: ROOM to refer to the room
containing the object, NORTH,SOUTH,EAST,WEST,UP,DOWN,NORTHEAST..etc..
to specify a room in a specific direction, ANYROOM to specify any room
connected to this one, MOB to specify any mob in the room, ITEM to
specify any item in the room, AREA to specify the area object, or
AREAGATE to specify a connecting room outside the area. For
example a string such as: "To the east is the residence of
${STAT:ROOM:EAST:MOB:NAME}" would embed the name of a mob in a room to
the east of the current room. This command may internally cause
post-processing if necessary, and so is almost guarenteed to always
work unlike some of the special ROOM_ tags.</li>
<li>(a(n)) will remove any indefinite or definite
articles from the string immediately following it and replace it (or
insert) either "a" or "an" depending on the first letter of the word.</li>
</a></ul>
<a name="structure"> </a><h2><a name="using">Using the Random Generator</a></h2>
There are currently two ways to use the Random Generator, one is the
Archon GENERATE command, and the other is the Area type
"StdAutoGenInstance".<br />
<br />
<span style="font-weight: bold;">Generate Command</span>:<br />
<br />
The most straightforward way to access the random generator is using
the Archon GENERATE command. The usage is as follows:<br />
<br />
GENERATE [OBJ TYPE] [ID] (FROM [FILENAME]) ([VAR]=[VAL]...)
([DIRECTION])<br />
<br />
This command uses an xml file to generate random content for your
mud. This content can be anything from whole areas,
to rooms, mobs, items, or simple strings. By default,
the content is built from the file in
resources/randareas/example.xml, though the builder may
specify his or her own xml file path as one of the many
arguments. The arguments, briefly, are:<br />
<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2">
<tbody>
<tr>
<td>OBJ TYPE</td>
<td>One of the following: AREA, ROOM, MOB, ITEM, or
STRING</td>
</tr>
<tr>
<td>ID</td>
<td>one of the "id" xml attributes defined on any tag
in the XML file. Use
GENERATE STRING LIST for a list of all "id" attributes defined in your
file.</td>
</tr>
<tr>
<td>FROM "path/to/xmlfile.xml"</td>
<td>An optional argument to specify your own xml
file, with the resources directory being the default root.</td>
</tr>
<tr>
<td>VAR=VAL</td>
<td>One or more variables and their
definitions. Many tags will have a
specific set of required variables which must be defined in
order for
the content to be generated. Failing to specify one
of the required
variables will cause an error message listing the variables which
must be defined, and the type of data required for the
variable.
Variable types which list numbers as their data types may also
have
math expressions values (so you can use random numbers).
See the help
on MATH EXPRESSION for more information on this. In addition
to
required variables, you may also use the space to enter one or
more
"override" values. Many object fields (such as
LEVEL for mobs and
items, or NAME, etc) as well as the XML id tags, can have their
"random" values overridden by defining them using the generate
command.</td>
</tr>
<tr>
<td>DIRECTION</td>
<td>This applies only to ROOM and AREA object
types. The object, if
successfully generated, will be linked to the current room
that the
player is standing in, in the direction they specify.</td>
</tr>
</tbody>
</table>
<br />
The GENERATE command is an interesting way to deliver large amounts of
dynamic content for your world, though it can never replace
the caring touch of a real, creative builder.
If anyone is interested in writing their own xml content,
please open up the /resources/randareas/example.xml file and
begin reading it and all of the LOADed files. Use those file as an
example on how to construct your own.<br />
<br />
Examples of the Generate Command: <br />
generate area maze_dungeon from randareas/example.xml areasize=50
areaname=test level_range=10?20 aggrochance=50 theme=kobolds
south<br />
<br />
generate string list<br />
<br />
<span style="font-weight: bold;">StdAutoGenInstance
Area Type</span>:<br />
<br />
The StdAutoGenInstance area type is specially formulated to replace any
rooms of its own with auto-generated rooms and content. <br />
<br />
This area type is, firstly, an Instance generator. That means
that each group that goes into the area will have their own unique
generated rooms to play in, which will be different from any other
groups, and will persist until the group gets tired of playing it
(causing the area to time-out and be garbage collected).<br />
<br />
This area type also permits the path and name of the top-level random
generation xml file to be specified, where the /resource directory is
considered the default path root.<br />
<br />
Lastly, any required or optional variables. Many tags will have a
specific set of required variables which must be defined in
order for
the content to be generated. Failing to specify one
of the required
variables will cause the area generation to fail, putting an error
message in your mud.log file. Variable types which list
numbers as their data types may also have
math expressions values (so you can use random numbers).
See the help
on MATH EXPRESSION for more information on this. In addition
to
required variables, you may also use the space to enter one or
more
"override" values for existing defined things.
<h2><a name="glossary">Glossary of XML Tags</a></h2>
<p><a name="areatag"><span style="font-weight: bold;">AREA tags</span></a>:
<br />
As the highest-level possible tag, an area is parsed only with the
variables it is given on the GENERATE command line, and using whatever
it can find in its XML contents for its details. All details
mentioned below will
automatically cause a variable to be defined or re-defined when they
are parsed.
The variable will be called "AREA_DETAILNAME". For instance
"AREA_CLASS" for
class, and "AREA_NAME" for name.<br />
<br />
The layout of an area will cause its rooms to be logically grouped up
into streets, "leaf" rooms (rooms with only one exist), and other
logical
groupings. "leaf" rooms are always done first, followed by
streets, and others. The
layout will automatically define certain variables for each room to
help with parsing the rooms
details. These variables include:<br />
</p>
<ul>
<li>$AREA_NUMLEAFS: the number of leaf rooms for the whole area</li>
<li>$ROOMTAG_NODETYPE: one of surround, leaf, offleaf, street,
square,
interior</li>
<li>$ROOMTAG_NODERUN: for streets, which way they run.
Values are
ns, ew, nwse, nesw</li>
<li>$ROOMTAG_NODEFLAGS: various rooms flags. Values include:
corner, gate,
intersection, tee, offleaf </li>
<li>$ROOMTAG_NODEEXITS: comma separated list of all exits from
a room</li>
<li>$ROOMTAG_NODEGATEEXIT: if this room is a "gate" rooms,
which direction
is the gate in.</li>
<li>$ROOMLINK_N, $ROOMLINK_S, $ROOMLINK_E, $ROOMLINK_W, etc:
"true" if an exit
exists that way.</li>
<li>$ROOMTITLE_N, $ROOMTITLE_S, $ROOMTITLE_E, $ROOMTITLE_W,
etc: if already
done, the title of a room that way.</li>
<li>$NODETYPE_N, $NODETYPE_S, $NODETYPE_E, $NODETYPE_W, etc:
type of room node
in that direction, if any.</li>
</ul>
<p>Required details:<br />
</p>
<ul>
<li>"CLASS": The CoffeeMud class type to use to create the area.</li>
<li>"NAME": The name of the area. Must be unique to your
MUD.</li>
<li>"LAYOUT": The name of the layout generator to use. At
the moment,
supported layouts include MAZE, BOXCITY, BOXCITYSQUARE, CROSS,
GRIDCITY, TREE, APARTMENT</li>
<li>"SIZE": The number of rooms to create in the area.</li>
</ul>
<p>Optional objects: (See below for details on these object tag
types and
their details)<br />
</p>
<ul>
<li>"AFFECT"</li>
<li>"BEHAVIOR"</li>
<li>"ROOM"</li>
</ul>
<p>Optional details: (See Archon's Guide)<br />
</p>
<ul>
<li>"CLIMATE"</li>
<li>"DESCRIPTION"</li>
<li>"THEME"</li>
<li>"BLURBS"</li>
<li>"PREJUDICE"</li>
<li>"BUDGET"</li>
<li>"DEVALRATE",</li>
<li>"INVRESETRATE"</li>
<li>"IGNOREMASK"</li>
<li>"PRICEMASKS"</li>
<li>"AUTHOR"</li>
<li>"ATMOSPHERE" </li>
</ul>
<p><a name="roomtag"><span style="font-weight: bold;">ROOM tags</span></a>:
<br />
Parsed with variables from the generate command, and from any defined
variables internal, and from any internal tags and attributes, and from
any variables defined
by its AREA tag. As with areas, its details will cause variables
beginning with ROOM_ to be
defined.<br />
<br />
Required details: <br />
</p>
<ul>
<li>"CLASS"</li>
<li>"TITLE"</li>
<li>"DESCRIPTION"</li>
</ul>
<p>Optional Objects: (See below for details on these object tag
types and
their details) <br />
</p>
<ul>
<li>"MOB"</li>
<li>"ITEM"</li>
<li>"AFFECT"</li>
<li>"BEHAVIOR"</li>
<li>"EXIT"</li>
</ul>
<p>You can also specify a "LAYOUT" attribute on a room tag, in
which case
all rooms contained inside that room tag (or inserted, or whatever) are
used to build multiple
rooms from that layout, much as specified above on the AREA tag. <br />
<br />
<a name="mobtag"><span style="font-weight: bold;">MOB tags</span></a>:
<br />
Parsed with variables from the generate command, and from any defined
variables internal, and from any internal tags and attributes, and from
any variables defined
by other room tags. As with areas, its details will cause variables
beginning with MOB_ to be
defined.</p>
<p>Required details: <br />
</p>
<ul>
<li>"CLASS": normally the CoffeeMud class the mob will be made
from, though
it may also be the word catalog in order to select a mob from your
catalog, in which case
"name" also becomes a required detail.</li>
</ul>
<p>Optional Objects: <br />
</p>
<ul>
<li>"MOB"</li>
<li>"ITEM"</li>
<li>"AFFECT"</li>
<li>"ABILITY"</li>
<li>"BEHAVIOR"</li>
<li>"FACTION"</li>
</ul>
<p>Optional details: (See Archon's Guide)<br />
</p>
<ul>
<li>"RACE"</li><li>"HPMOD"</li>
<li>"LEVEL"</li>
<li>"NAME"</li>
<li>"DISPLAY"</li>
<li>"DESCRIPTION"</li>
<li>"MONEY"</li>
<li>"ALIGNMENT"</li>
<li> "DISPOSITION"</li>
<li>"SENSES",</li>
<li>"ARMOR"</li>
<li>"DAMAGE"</li>
<li>"ATTACK"</li>
<li>"SPEED"</li>
<li>"TATTS"</li>
<li>"EXPS"</li>
<li>"IMG"</li>
<li>"FACTIONS"</li>
<li>"VARMONEY"</li>
</ul>
<p>(plus or minus others depending upon class)</p>
<p>The "RACE" detail can be the name of a race, or resolve to a
RACE tag,
see below.<br />
<br />
<a name="mobtag"><span style="font-weight: bold;">ITEM tags</span></a>:
<br />
Parsed with variables from the generate command, and from any defined
variables internal, and from any internal tags and attributes, and from
any variables defined
by other room tags. As with areas, its details will cause variables
beginning with ITEM_ to be
defined.</p>
<p>Required details: <br />
</p>
<ul>
<li>"CLASS": normally the CoffeeMud class the item will be made
from,
though it may also be the word catalog in order to select an item from
your catalog, in which
case "name" also becomes a required detail. This may also start
with the string
"metacraft:", in which case the remainder of the "class" value becomes
either the name of the item to
metacraft, the word "anything", "all", or the words "any-" or
"all-" followed by the ID of the common
skill to use. "metacraft:" class strings may also end with the
characters "<"
followed by a math expression evaluating to an upper level limit
for the item to craft, ">"
for a lower limit, or "=" followed by a the base class ID to to filter
in.</li>
</ul>
<p>Optional Objects: <br />
</p>
<ul>
<li>"MOB"</li>
<li>"ITEM"</li>
<li>"AFFECT"</li>
<li>"CONTENT"</li>
<li>"BEHAVIOR"</li>
<li>"EXIT"</li>
</ul>
<p>Optional details: (See Archon's Guide)<br />
</p>
<ul>
<li>"USES"</li>
<li>"LEVEL"</li>
<li>"ABILITY"</li>
<li>"NAME"</li>
<li>"DISPLAY"</li>
<li>"DESCRIPTION"</li>
<li>"SECRET"</li>
<li>"PROPERWORN"</li>
<li>"WORNAND",</li>
<li>"BASEGOLD"</li>
<li>"ISREADABLE"</li>
<li>"ISDROPPABLE"</li>
<li>"ISREMOVABLE"</li>
<li>"MATERIAL"</li>
<li>"DISPOSITION"</li>
<li>"WEIGHT"</li>
<li>"ARMOR"</li>
<li>"DAMAGE"</li>
<li>"ATTACK"</li>
<li>"READABLETEXT"</li>
<li>"IMG"</li>
</ul>
<p>(plus or minus many many others depending upon class)<br />
<br />
"ShopKeeper" type classes may use "SHOPINVENTORY" tags to hold ITEM,
MOB, or ABILITY tags to designate what else is sold. Also, the
SHOPINVENTORY or
those ITEM, MOB, or ABILITY tags may contain optional PRICE or
NUMBER attributes.<br />
<br />
<br />
<a name="affecttag"><span style="font-weight: bold;">AFFECT tags</span></a>: </p>
<p><a name="abilitytag"><span style="font-weight: bold;">ABILITY
tags</span></a>:</p>
<p><a name="culturalabilitytag"><span style="font-weight: bold;">CULTURALABILITY
tags</span></a>: </p>
<p><a name="behaviortag"><span style="font-weight: bold;">BEHAVIOR
tags</span></a>: </p>
<p>Required detail: </p>
<ul>
<li>"CLASS"</li>
</ul>
<p>Optional Detail: </p>
<ul>
<li>"PARMS"</li>
</ul>
Optional Details that apply only when this tag applies to a RACE tag:<br />
<ul>
<li>"PROFF"</li>
<li>"LEVEL"</li>
<li>"QUALIFY"</li>
</ul>
<p><a name="contenttag"><span style="font-weight: bold;">CONTENT
tags</span></a>:
<br />
Content tags:<br />
A pure container tag that contains one or more ITEM tags, as above.<br />
<br />
<a name="exittag"><span style="font-weight: bold;">EXIT tags</span></a>:
<br />
Exit tags:<br />
Required detail: </p>
<ul>
<li>"CLASS"</li>
</ul>
<p>Optional Objects: </p>
<ul>
<li>"AFFECT"</li>
<li>"BEHAVIOR"</li>
</ul>
Optional Details:
<ul>
<li>"NAME"</li>
<li>"DISPLAY"</li>
<li>"DESCRIPTION"</li>
<li>"DOOR"</li>
<li>"LEVEL"</li>
<li>"ABILITY"</li>
<li>"ISREADABLE"</li>
<li>"DISPOSITION"</li>
<li>"READABLETEXT"</li>
<li>"HASADOOR"</li>
<li>"DEFCLOSED"</li>
<li>"HASALOCK"</li>
<li>"DEFLOCKED"</li>
<li>"KEYNAME"</li>
</ul>
<p><a name="raceag"><span style="font-weight: bold;">RACE tags</span></a>:</p>
<p>Required detail: </p>
<ul>
<li>"CLASS"</li>
<li>"NAME"</li>
</ul>
Optional Objects:<br />
<ul>
<li>"WEAPON": tag which should contain an ITEM tag, denoting
the creatures natural weapon</li>
<li>"RESOURCES": tag which should contain one or more ITEM
tags, denoting racial resources</li>
<li>"OUTFIT": tag which should contain one or more ITEM tags,
denoting the racial outfit</li>
<li>"ABILITY"</li>
<li>"CULTUREABILITY": same as ABILITY tag, but these are
cultural abilities</li>
<li>"AFFECT"</li>
</ul>
Optional Details:
<ul>
<li>"CAT"</li>
<li>"VWEIGHT"</li>
<li>"BWEIGHT"</li>
<li>"VHEIGHT"</li>
<li>"FHEIGHT"</li>
<li>"MHEIGHT"</li>
<li>"AVAIL"</li>
<li>"LEAVE",</li>
<li>"BODYKILL"</li>
<li>"AGING"</li>
<li>"HELP"</li>
<li>"BREATHES"</li>
<li>"ARRIVE",</li>
<li>"HEALTHRACE"</li>
<li>"BODY"</li>
<li>"WEAPONRACE"</li>
<li>"DISFLAGS"</li>
<li>"EVENTRACE"</li>
<li>"WEAR" - either a bitmask number, or wear locations names
set equal to
true to forbid, or false to allow, e.g (mouth=true
back=false left_wrist=false)</li>
<li>"ESTATS","ASTATS","CSTATS","ASTATE","STARTASTATE" - either
a |
delimited stat list, or a series of var=value, e.g.
(STRENGTH=5 HITS=2 ATTACK=2 etc..)</li>
</ul>
<p><br />
<a name="factiontag"><span style="font-weight: bold;">FACTION tags</span></a>:
<br />
Required details: </p>
<ul>
<li>"ID"</li>
<li>"VALUE"</li>
</ul>
<span style="font-family: monospace;">
<pre><br /></pre>
</span></td>
</tr>
</tbody>
</table>
</center>
</body></html>
