Nove at 11:24, 26 May 2020

2020-05-26T11:24:14Z

Nove: Created page with "== 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 sho..."

2020-05-25T14:08:26Z

Created page with "== 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 sho..."

New page

== 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:
<nowiki>
field value</nowiki>
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.
<nowiki>
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."</nowiki>
;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.
<nowiki>
<fieldname> {"string1","string2","string3", ...}</nowiki>
;intlist
: A list of numbers which can be used with an extra. This type works like the stringlist but doesn't need the quotes.
<nowiki>
extra {"mynumberlist"} {1,2,3,4,5,6,7,...}
"This is a number list attached to an extra"</nowiki>
;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.
<nowiki>
flags {2,8}
manipulate {8}</nowiki>
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:
<nowiki>
flags {UNIT_FL_INVISIBILE,UNIT_FL_BURIED}
manipulate {WEAR_BODY}</nowiki>
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.
<nowiki>
dark_sword /*good symbol*/
rm_5892 /*Bad symbol*/</nowiki>
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)
<blockquote style="background-color: #E8E8E8; font-style: italic; ">the end tag that ends all unit definitions is also considered a symbol it is just a symbol that must be included</blockquote>

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.

<blockquote style="background-color: #E8E8E8; font-style: italic; ">Special functions are being replaced with DIL for better performance and should only be used when no DIL functions exist to replace them</blockquote>

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.

← Older revision		Revision as of 11:24, 26 May 2020
Line 115:		Line 115:
	fields which will both be defined more later because they can be used		fields which will both be defined more later because they can be used
	differently depending on what you are using them for.		differently depending on what you are using them for.
		+
		+	<div style='padding-top: 30px; padding-bottom: 20px; text-align: left;float:left;width:50%;'>[[Manual:Zone_Manual/General_Compiler_Information/The_VMC_pre-processor\|Previous: The VMC pre-processor]]</div>
		+	<div style='padding-top: 30px; padding-bottom: 20px; text-align: right;float:right;width:50%;'>[[Manual:Zone_Manual/Zone_Source_File/Zone_information_section\|Next: Zone information section]]</div>

Manual:Zone Manual/Zone Source File - Revision history

Nove at 11:24, 26 May 2020

Nove: Created page with "== 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 sho..."