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:
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:
Where field is the name of a data field, and value is some value. Values are of one of 6 types:
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 0x0f3)
Text enclosed in Double Quotes. The string can span more than one line as it would in a description.
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 manor.
A list of numbers which can be used with an extra. This type works like the stringlist but doesn't need the quotes.
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.
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:
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.
A label you reference from other parts in your zones. Every unit (room, object, room) 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.
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 the appendix called Reserved keyword listing>
the end tag that ends all unit definitions is also considered a symbol it is just a symbol that must be included with
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.
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.