Manual:Zone Manual/Zone Source File
Zone source file
In this chapter we will define all the sections of a zone file and go in-depth on the zone info 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
- %rooms
- %mobiles
- %objects
- %reset
- %DIL
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 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 manor.
<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_INVISIBILE,UNIT_FL_BURIED}
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,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.
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
(Link to app-b)
the end tag that ends all unit definitions is also considered a symbol it is just a symbol that must be included
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 a '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.
