Zone Source File

In this chapter we will define all the sections of a zone file and go in-depth on the zone information section. Once complete with this chapter you should be able to create an empty yet compilable zone.

A zone source file is split up into 6 sections: a zone-declaration section, a mobile (NPC) section, an object section, a room section, a reset section, and the DIL section. The zone section is the only section that has to be in the file, and they may appear in any order.

Each section is preceded by a section header. These are the six possible headers:

• %zone
• %dil
• %rooms
• %mobiles
• %objects
• %reset

The first four sections may be considered lists of definitions. The reset section can be considered a program in a simple programming language. And the DIL section is a bit special - it includes the zone templates (DIL functions that can be used from any zone, on anything, as opposed to “specialized” DIL functions placed inside a unit’s definitions). After all sections you are using are defined you must tell the compiler you are done - the special symbol %end must be placed at the end of the zone for this reason.

Definition Types

When creating your zone there are six main building blocks. We call these definition types. Each type represents some kind of data you want the compiler to be able to recognize. These data definitions take the basic form:

field value

Where field is the name of a data field, and value is some value. Values are of one of 6 types:

Integer

A whole number or if you are in practice of using Hex you can use the C style hex numbers in either upper or lower case (i.e. 0X0f3 or 0x0f3).

String

Text enclosed in Double Quotes. The string can span more than one line as it would in a description.

title "The dark dragon altar"
descr
"There are many things you can see and there are many things that
can't be seen but this is still a description none the less."

Stringlist

A set of strings, it can be a single string or multiple depending on your needs. These are used in names, extras, creators, and special keywords all to be defined later in their respective places. These are defined in the following manner:

<fieldname> {"string1","string2","string3", ...}

Intlist

A list of numbers which can be used with an extra. This type works like the stringlist but doesn’t need the quotes.

extra {"mynumberlist"} {1,2,3,4,5,6,7,...}
"This is a number list attached to an extra"

Flags

Like the Intlist the flag is defined with a list of numbers. The list of numbers is not taken literally, however it is combined to create one number by binary ORing the number list together. If that confuses you don’t worry, it takes some getting used to. These types are used for manipulation, flags, and positions.

flags {2,8}
manipulate {8}

In the previous example the ‘flags’ value after this zone compiles would be 10 because binary ORing the two flags together is a lot like adding. The two numbers probably make no sense so most flags you use will have defines; if I used the defines found in vme.h, the previous example would look like this:

flags {UNIT_FL_INVISIBLE,UNIT_FL_BURIED}
manipulate {MANIPULATE_WEAR_BODY}

We will cover this more in-depth later but it was necessary to give a good overview so you understand this field type enough to recognize what it is when you see it.

Symbol

A label you reference from other parts in your zones. Every unit (room, object, NPC) and even the zone itself has a unique label that can be referenced. It is important to make symbol names that are clear so the Administrators of the mud know what each item is when using the online administration commands.

dark_sword   /* good symbol */
rm_5892      /* bad symbol */

When loading items online the zone symbol and the item symbol are combined to create a reference to the item. For example if our zone name was ‘dragon’ and our item was ‘dark_sword’ the symbolic name for this item would be dark_sword@dragon. Using symbols will be covered more in the DIL manual and in the administration manuals for loading objects online. For now it is enough to understand symbols must follow the following rules when being defined:

• The first letter of the symbol must be a letter of the alphabet or a _ character
• Characters following the first can be numbers, alphabet letters, and _ characters
• The name can be no longer than 15 characters
• No reserved keywords can be used as a name (see the appendix on Reserved Keywords)

Note: The end tag that ends all unit definitions is also considered a symbol - it is just a symbol that must be included.

Other Field Types

There are two other field types that can not be defined as a regular field type. These are the function reference and the structure. The function reference can be either a reference to a DIL function or a special function called from the base code.

Note: Special functions are being replaced with DIL for better performance and should only be used when no DIL functions exist to replace them.

The structure field types are a combination of other field types to make a special field type for the unit being defined. A good example of this is an ‘exit’ for a room. The exit has everything from flag, string, stringlist, and even description fields. The exit field will be defined much more in-depth in the chapter on rooms but it is important to know some fields are considered Structure fields because they can have many values. The only two structure fields are the exit and extra fields which will both be defined more later because they can be used differently depending on what you are using them for.

Zone Information Section

The zone information section is the only section that must exist in the source file of your area. Without this section the compiler is unable to create the zone because frankly it doesn’t know what to call it. It is also the easiest of the sections to learn because there are only a few possible fields. The Zone-section defines the global parameters for the current zone. It is usually wise to place this section in the top of the source file to make it easy to find the zone information when editing the file.

Zone Section Fields

Zone Information Examples

The only field that must exist when you go to create the zone information section is the %zone. Leaving the %zone field out will cause an error when you try to compile it. We suggest you not only put the %zone field but you also add a symbol or as I call it a zone name. The following are three legal examples of a Zone information header. You be the judge of which is more informative.

/* wrong */
%zone

/* bad but better than nothing */
%zone bug_planet

/* The way it should be done! */
%zone dragonst
lifespan 20
reset RESET_ANYHOW
creators {"whistler"}

notes
"This is the dragon station I shortened it to dragonst for ease in
loading. If you have any questions email me at admin@example.com"

help
"Not sure what could help you now. You are stuck on one of the
weirdest space stations you have ever seen and you smell burning
sulfur."

If you felt like it you could add a %end to the preceding examples and compile them. They would create an empty zone so wouldn’t be very exciting but at least it’s possible. We will not go into any compiling until we have at least one unit type to compile because it is pretty useless to do. The next chapters will define the basic unit building blocks you will use for rooms, objects, and NPCs and start you off on compiling.