#OBJECTS Section

The #OBJECTS section consists of the #OBJECTS header, one or more object descriptions (see below) and the #OBJECTS section ender #0 as shown here:

#OBJECTS object descriptions #0

A object description looks like this:

#vnum keywords~ short description~ long description~ material~ type objectflags wearflags value line (differs with type, see below) level weight value condition E extended keywords~ extended description ~ A applytype applyvalue F flag line

There is an example at the end of this page.

Here's what the (underlined) terms mean:

#vnum

Each unique object gets a unique vnum as assigned on your object list. Remember to precede the vnum with the hash sign ('#')!

Although the MUD program does not care whether the vnums for objects are in ascending order and consecutive, your area file will be very difficult to maintain if this is not so. Start with the first vnum you were assigned and number consecutively up to as many as you need for all your objects.

keywords

These are all the words by which the player can refer to the object. In order for the player to be able to refer to the object in 'take object' and other interaction, at least some of the keywords should be words visible in the object's short description (see below), and the long description (see below).

The simplest way to get this right is to code some keywords from the 'short name' on your object list, then code the long and short descriptions, then come back to the keyword list and add any keywords you think the player may consider using after having seen the short or long description.

Example: You build a suit of armor. Keyword as per the object list: 'armor'. You later build a long description stating 'A shiny green suit of armor lies on the ground here'. Unless you're playing some kind of guessing game with the player, you MUST add 'suit' to the keywords so as to give the player a chance to call it 'suit' as well as 'armor'. You may also add 'green' so the player can refer to 'green armor' to keep it separate from other armors. For objects of which there are many different kinds in the game, several keywords will help single it out when using spells like locate object.

Don't forget the tilde ('~') at the end of the keywords line!

short description

This is the description the player sees when interacting with the object, when he sees the object in his inventory, equipment or a container. This desc should only take up about half a line and fit into a sentence like 'you wear ... on your head'. There should be no period at the end of the short description.

Don't forget the tilde ('~') at the end of the short description!

long description

This is the description the player sees when he looks in the room or enters the room and the given object is lying on the ground. Example: 'A shining green suit of armor lies here.' This must be a full sentence starting with a capital and ending with a period. In spite of its name, the long description should not be very long. One line should be enough to tell the player what he is looking at. The full description and life history of the object go into the extended descriptions (see below).

If you are building a puzzle and don't want the player to see an object upon entering a room or using LOOK, then you may leave out the long description but not the tilde! This is often done with portals and containers (containing valuable items) because it makes the most sense in this context. It is absolutely necessary in such cases to mention the hidden object in the room description, though, or it will never be found. If you use an empty long description, you must still always enter a short description. Otherwise meaningless messages result when the object is manipulated.

Note that the tilde ('~') goes at the end of the line containing the long description! This is not consistent with the way it's done for #MOBILES, so you will have to remember to do it right.

material

This is what the object is made of. It seems to be immaterial, (pardon the pun) as it's shown by LORE and the IDENTIFY spell but doesn't seem to affect anything. It's there for realism and role play, mainly. So you can code any old string here that maintains credibility. The tilde, however, is mandatory, as always.

type

The single word in this field indicates what kind of object you are describing. It must be one of the keywords found in the Item Type and Value Line Table. Coding the item type correctly is crucial to producing the right object.

objectflags

The object flags encode the properties of an object. To code them, you enter either a 0 (for no properties) or an appropriate combination of the letters found in the Object Flag Table.

wearflags

Wear flags indicate how the object may be used. Most equipment items will have a TAKE flag and may have one (or rarely more) of the others. For the rare item that has no flags at all (such as a fountain, which cannot be taken, worn or anything), code a 0 (zero). For all others, refer to the Wear Flag Table.

value line

The value line must always contain 5 items. These may be keywords, single-quoted strings, flag letters or numbers. The contents of the 5 slots are different for each item type. Consult the Item Type and Value Line Table for details on how to code the value line for your item.

level

The level of the object, as a single number in the range from 0 to MAXLEVEL (currently 100). Trying to equip a mob with an item of level higher than the mob results in a bug message at load time. Please don't! This would also make valuable equipment too easy to get.

weight

The weight of the object, expressed in tenths of pounds. i.e. you want to code 10 times the weight in pounds. Be somewhat realistic.
Some guidelines:

• The One Ring is a small item weighing 0.3 pounds (coded as 3).
• A necromancer sword weighs 40 pounds and is too heavy for some characters to wield as a second weapon.
• A character with 13 STR can carry about 200 pounds total, including his money.
• Nothing in the game can weigh more than about 3200 pounds (coded as 32000). This is not a guideline, this is a hard limit. Exceeding this limit causes things to have negative weight. That's not what you want.

value

The cost of the item, in silver. For Quest Items, i.e. those having an ITEM_QUESTSELL object flag, the cost is in Quest Points.

condition

The condition of an object is coded as a single letter, as follows:

P	Perfect	D	Damaged
G	Good	B	Broken
A	Average	R	Ruined
W	Worn	I	Indestructible

An indestructive item will not change condition no matter how much it is used. Coding an item as ruined makes no sense because the item can still be used but will not deteriorate further. For minimum lifetime, code the item as broken. Most items are coded as perfect.

extended keyword(s)

extended description

Extended keywords and an extended description, together with the preceding 'E' and the two separating tildes ('~') make up what I'll call a detail description. Detail descriptions are optional, that is, the MUD program won't mind if you don't have a single one in your object. But to give the players in your area a richer experience, all items should have at least one detail description. Each object can have as many of these detail descriptions as you want, one after the other, each with its own 'E', extended keywords, tilde, extended description and final tilde.
Detail descriptions are used to convey additional information about an object, which the player accesses by LOOKing or EXAMINEing the keyword.
A sword, for example, may have:

keywords:	sword double edged
short description:	a double-edged sword
long description:	A double-edged sword gleams evilly on the ground.
first detail description extended keyword: sword double edged edges extended description: This sword has a very wicked looking blade. Both edges are slightly jagged but appear to be razor sharp! Some dark stains mar its surface. second detail description extended keyword: stains surface extended description: Upon closer examination, the stains on the sword's surface turn out to be the remnants of old, dried blood. It's obvious that this sword was an instrument of deadly utility and no polished showpiece.

Here's how all these things interrelate:

• The keywords are used to manipulate (take, wield, put, etc) the object.
• The short description is seen by the player when he manipulates the object ("You take a double-edged sword from your backpack.") or sees it in his inventory, equipment or a container.
• The long description is seen by the player when he enters a room where the object is lying on the ground, or does a LOOK there.
  The long description is also what he sees if he does a LOOK <keyword> and the object does not have an extended keyword matching the keyword he typed in.
  
• The extended descriptions are seen by the player if he does a LOOK <keyword> and that keyword matches an extended keyword. EXAMINE, directed at an object, has the same effect.

What this means is that a general-purpose LOOK in the room will always show the object's long description ("A double-edged sword gleams evilly on the ground here"), but a LOOK SWORD will first try to match on an extended keyword. Since, in our case, 'sword' is one of the keywords for the first extended description, the player will get the story about the jagged blade with the razor sharp edges.
Thus, extended keywords are used to make sure a LOOK at an item will be directed at the detailed extended description rather than the relatively short so-called long description. To make sure this works no matter which keywords the player LOOKs at, your best bet is to duplicate all of the object's keywords into the keywords of the first detail description.

If there is no detail description with keywords matching the object's keywords, all the player sees is the long description ("A double-edged sword gleams evilly on the ground here") yet again. If most objects in an area have no detail descriptions, players will be bored by what they find and will quickly cease LOOKing at anything.

In our case, the player is curious about the sword and types LOOK SWORD. He is shown the first extended description. Note that a clever player may deduce that a 'double edged sword' has two edges, and may think to type LOOK EDGES. This is why the extra keyword 'edges' was included in the list.

Our inquisitive player is intrigued by the stains on the sword's surface (both are words he sees in the first extended description) and so he types LOOK STAINS or perhaps LOOK SURFACE. By building a second detail description keyed by these two words, we give the player the chance to find out more about the item.

Some puzzle or quest items have been known to have long strings of detail descriptions, with nouns in one extended description being used as keywords in another detail description. By continually LOOKing at words he sees in an item's description, the player can thus dive into a long and detailed story. Note that, in most cases, nouns are used to link descriptions together. Most often, the extended keywords will be one or more of the exact words found in another extended description, but for extra difficulty synonyms or other words derived from a description may also be used. However, try not to expect miracles from the players. If you think players may need prodding to dig their way through detail descriptions, you may use color coding to highlight those words in a description leading to another detail description.

applytype

applyvalue

An object can be given the ability to enhance or worsen a player's stats if equipped. This is done by specifying an Apply Type and an Apply Value, the combination of which I'll call an Apply.
The Apply Type specifies which stat is changed, in accordance with the Apply Type Table. The Apply Value specifies by how much the stat is changed.
Applies are optional; an object may have none of them, or as many as make sense and do not disrupt game balance. Each individual apply is coded as two lines, with an A in the first line and an apply type and apply value in the second.
Apply values are added to the character's stats of that type. Negative values can be used to reduce the user's stats. This is beneficial for Armor Class and SAVEs.

Example:	A 3 2	Improve INT by 2.
	A 5 -1	Decrease CON by 1.
	A 17 -5	Improve AC by -5.

Lotus, Dizzy MUD's Creator, formulated some guidelines for object stats, especially applies, which make good sense and form a sound basis for off-the-cuff balancing of your equipment:

---

• Try not to overload items. Here are a few tables for designing. These are by no means carved in stone.
• Attributes

  Levels 1-30:	No more than +4 in total, no more than +2 on any single attribute.
  Levels 30-60:	No more than +5 total, no more than +3 on any single attribute.
  Levels 60-90:	No more than +6 total, no more than +3 on any single attribute.

• Hit/Dam roll:
  No more than +1/+1 per every 10 levels. Not to exceed +8 on either side.
• Hit points/Mana:
  No more than +1 per level combined. For example:

  Level 80:	+40 hp, +40 mana
  Level 30:	+25 hp, +5 mana
  Level 50:	+50 mana

• Movement:
  No more than +1 per level.
• Saves and AC:
  No more than -1 per 10 levels combined. For example:

  level 50:	-2 AC, -3 Sv
  level 90:	-9 AC

• Finally, don't max out all 5 categories :) Maybe one or two of them.

---

As Lotus said, the above rules are not carved in stone. You may be flexible to some extent in that you may code some (few) objects with stats well in excess of these guidelines in individual respects, but that you will need to balance these overshoots by making the equipment inferior in other ways. If you attempt to do this, you need to be very familiar with the stats of other, similar equipment in the game because you MUST stay within the limits of game balance or your creations will be turned down.

flagline

Flag lines are actually 2 lines each. They serve 3 purposes:

• to put spell affects on an object, such as Sanctuary, Haste, Detect Hidden, etc.
• to put immunities, resistances or vulnerabilities on an object.
• as an alternative means of putting applies on an object (see applies, above)

In all cases, these changes are applied to a character when that character wears, holds or wields the object so flagged.

Like applies, flag lines are optional. Use none or as many as required. Each apply must adhere to the syntax shown below, starting with the F line and continuing with a A, I, R or V line as shown.

Flag Line Syntax Table

Affect flag line (for affects) F A 0 0 Affect-flags The affect flags are coded as a combination of letter codes as found in the Affect Flag Table. Although the table speaks of mobs, the same effects can be coded on objects, and will affect a character equipping with that item, including the same silly malfunctions mentioned for the mob affects. If in doubt, experiment. Example: F A 0 0 DF   An object flagged like this will enable its wearer to DETECT INVIS and DETECT HIDDEN. The effects of objects flagged in this manner are PERMANENT, i.e. the object will confer the affect on the player whenever it is used, for as long as the object exists. Therefore, some affects should be coded either only for immortal use or not at all. Things like SANCTUARY make an object far too powerful; areas with such items coded in them will likely be turned down or returned for correction.

Immunity flag line F I 0 0 Immunity-flags The immunity flags are coded as a combination of letter codes as found in the Immunity/Resistance/Vulnerability Flag Table. Although the table speaks of mobs, the same effects can be coded on objects, and will affect a character who wears, holds or wields an object so coded. With possible rare exceptions, immunities should not be coded into any objects. Most immunities make the bearer so powerful any objects thus coded are a threat to game balance.

Resistance flag line F R 0 0 Resistance-flags The resistance flags are coded as a combination of letter codes as found in the Immunity/Resistance/Vulnerability Flag Table. Resistance flags confer a big advantage to the bearer of an object so coded, therefore these flags should be put on objects only in rare cases which have been cleared with the Implementor beforehand.

Vulnerability flag line F V 0 0 Vulnerability-flags The vulnerability flags are coded as a combination of letter codes as found in the Immunity/Resistance/Vulnerability Flag Table. Vulnerability flags are not subject to restrictions. Any player who equips an object which makes him vulnerable does so by his own choice and at his own risk. A minor vulnerability on an otherwise good object might be considered as an interesting way to force a player to weigh his alternatives.

Affect flag line (for applies) F A applytype applyvalue 0 This kind of coding may be used to put applies on objects. The outcome is the same as if applies (using an A line and just the two numbers as described above under applytype/applyvalue) are used. This method is just more complicated and more confusing. While it's possible to combine an apply with, say, an affect or an immunity using this syntax, it makes for a hard-to-maintain area to code objects like this, and I strongly advise against doing this.

OBJECT example #30015 lantern silver~ a silver lantern ~ A silver lantern spreads some light here.~ silver~ light AG A 0 0 -1 0 0 40 0 4000 P E lantern~ The lantern looks quite valuable. The light it spreads seems to be very special. ~ E light~ This light does more for you than just lighten the darkness! It seems to be able to reveal each and everything! ~ A 26 2 A 18 2 A 19 2 F A 0 0 DF