Difference between revisions of "Sandpit"

Revision as of 13:39, 24 May 2020

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> <BOOK ID="basiczone"><?dbhtml filename="index.html"> <bookinfo> <TITLE>VME basic zone writing manual</TITLE> <author> <firstname>Ken</firstname> <surname>Perry</surname> </author> <copyright><year>2001</year><holder>Ken Perry</holder></copyright> </bookinfo>

<CHAPTER ID="ch-intro"><?dbhtml filename="ch00.html"> <TITLE>Introduction</TITLE>

<SECT1><TITLE>Giving credit where credit is due!</TITLE>

<PARA>The, basic zone writing manual, you are reading now, didn't just come flying out of this authors head. In fact it is a conglomeration of several old texts which are no longer used. I had first thought about quoting and giving credit to each person who had ever modified or created portions of the first documentation but because of the nature of the way they were built it was impossible to know who did what. I therefore have decided to create a list here of everyone who has ever worked on or had a hand in the development of the basic zone writing documentation and references. I will also give a short summary for each. I would also like to thank those listed below for their contribution to the development of one of the best mud servers on the internet today.

<VARIABLELIST id="var-credits"> <VARLISTENTRY> ;Original DIKU coding Team <DICTDEF> <PARA><itemizedlist> <LISTITEM><PARA>Hans Henrik Staerfeldt</PARA></LISTITEM> <LISTITEM><PARA>Sebastian Hammer</PARA></LISTITEM> <LISTITEM><PARA>Michael Seifert</PARA></LISTITEM> <LISTITEM><PARA>Katja Nyboe</PARA></LISTITEM> <LISTITEM><PARA>Tom Madsen</PARA></LISTITEM> <LISTITEM><PARA>Lars Balker Rasmussen</PARA></LISTITEM> </itemizedlist>

You should all know these people they are not only the original DIKU mud developers but a few of them designed and developed the new <ACRONYM>VME</ACRONYM> server. One or more of the previous mentioned people were the authors of the following texts that have been swallowed up by this book. <itemizedlist> <LISTITEM><PARA>abilities.txt</PARA></LISTITEM> <LISTITEM><PARA>guild.txt</PARA></LISTITEM> <LISTITEM><PARA>monster.txt</PARA></LISTITEM> <LISTITEM><PARA>objects.txt</PARA></LISTITEM> <LISTITEM><PARA>rooms.txt</PARA></LISTITEM> <LISTITEM><PARA>vmc.txt</PARA></LISTITEM> </itemizedlist></PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Andrew Cowan <DICTDEF>

<PARA>One of the original administrators of Valhalla mud and now the administrator of the mud connector. Andrew created the first zone tutorial, which was later included into the vmc.txt to clear up some things missing in the old vmc.txt. Again my thanks go out to Andrew for his contributions not only to this document but to the growth of the <ACRONYM>DIL</ACRONYM> programming language.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Ryan Holliday <DICTDEF>

<PARA>Made major updates to the tutorial.txt created by Andrew Cowan, which became version two of the tutorial.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Peter Ryskin <DICTDEF> <PARA>Wrote the original explanation of how to define exits.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY>

;John Clare <DICTDEF>

<PARA>Made major updates to the tutorial.txt created by Andrew Cowan and updated by Ryan Holliday, which became version three of the tutorial.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Marc Bellemare <DICTDEF>

<PARA>An editor and an author Marc combined and revised the tutorial and the vmc.txt into one document making it less Valhalla specific and more for any mud running the <ACRONYM>VME</ACRONYM> server.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Jennifer Garuba <DICTDEF> <para>Created the first document on how to create shop keepers. She also was one of the first builders to have the insite and to make it clear that a manual like this was needed.</para> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Brian Spanton <DICTDEF>

<PARA>Converted the original vmc.txt into HTMl, while at the same time fixing many inconsistencies and typos in it.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Kathy Perry <DICTDEF>

<PARA>Wrote the original compiler howto to make it easier for new builders to compile their zone. She was also the first builder to open my eyes to the fact we needed a true manual on how to build.</PARA>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Mark Pringle <DICTDEF> <para>Main editor, which spell checked and looked over my major grammer mistakes. I am sure he didn't catch them all but at least the ugly ones were caught.</para> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Morgan Shafer <DICTDEF>

<PARA>Wrote the guild definition primer which explained teachers.</PARA> </LISTITEM> </VARLISTENTRY>

</VARIABLELIST></PARA>

</SECT1>

<SECT1> <TITLE> Who should read this book?</TITLE>

<PARA>This book was designed to be read by anyone who is thinking of writing areas for a <ACRONYM>VME</ACRONYM> server. If you have wrote for other mud servers you will still need to at least skim every chapter because the <ACRONYM>VME</ACRONYM> is like no other mud engine and has some very interesting differences.</PARA>

</SECT1>

<SECT1> <TITLE>What does this book cover?</TITLE>

<PARA>The topics covered in this book are everything to do with writing an area for the <ACRONYM>VME</ACRONYM> server. While we do cover using <ACRONYM>DIL</ACRONYM> functions to make your monsters, Rooms, and objects better and smarter we do not cover how to write the <ACRONYM>DIL</ACRONYM> functions covered in the <ACRONYM>DIL</ACRONYM> manual. The following are topics covered by this book. <itemizedlist> <LISTITEM><PARA>compiling and debugging</PARA></LISTITEM> <LISTITEM><PARA>Macros using the CPP</PARA></LISTITEM> <LISTITEM><PARA>Overall Zone structure</PARA></LISTITEM> <LISTITEM><PARA>Writing rooms</PARA></LISTITEM> <LISTITEM><PARA>Writing Objects</PARA></LISTITEM> <LISTITEM><PARA>Writing Monsters</PARA></LISTITEM> <LISTITEM><PARA>Doing the resets</PARA></LISTITEM> </itemizedlist></PARA>

</SECT1> </chapter>

<chapter ID="ch-01"><?dbhtml filename="ch01.html"> <TITLE>General compiler information</TITLE>

<PARA>In order to get your zone onto a valhalla Mud Engine (<ACRONYM>VME</ACRONYM>) server you must convert your zone from readable english text to binary form the server can understand. The way you do this is with a compiler. No don't freak out you don't have to be a skilled programmer to use a compiler. The only thing you have to do is format your rooms, objects, and Non-player characters (NPC) in a form which the compiler can understand. The great thing about the <ACRONYM>VME</ACRONYM> is you can do all your zone writing in your favorite editor with out having to log on to code. For those of you who have coded for other mud servers and are used to coding online this may be a new experience to you but you will find you can plan out better and more well designed areas offline than you can on line.</PARA>

<NOTE> <PARA>In the future the <ACRONYM>VME</ACRONYM> coding team is thinking of adding an online coding module for those mud administrators that can not live with out it. If you are one of these make sure you write <email>whistler@valhalla.com</email> and express your desires so you can be counted. </PARA> </NOTE>

<PARA>This chapter will mainly cover the Valhalla Mud Compiler (<ACRONYM>VMC</ACRONYM>), how it works, and the Valhalla Mud pre processor (<ACRONYM>VMC</ACRONYM> -p) works. We will also throw in some debugging hints but debugging will be covered more as you begin creating parts of your areas in the following chapters. </PARA>

<SECT1><TITLE>The compiler</TITLE>

<PARA>VMC is the Valhalla Mud Engine Compiler. for <ACRONYM>VME</ACRONYM> servers. A compiler takes a source file or better described as your areas input file and converts it to a binary file the server can then load and use online. In the <ACRONYM>VME</ACRONYM> we call areas you build 'zones', therefore the source file for a zone has the extension 'zon'. In order to make this more clear we will start with our first example.</PARA>

<PARA>Lets say you were making a Zone of dragons. You may want to call the file something resembling its contents like, dragon.zon. Notice we have appended the '.zon' extension. The compiler requires all zones to end in '.zon' in order for it to know this is a zone source file.</PARA>

<PARA>Now lets say we have completed writing our first zone and want to compile it. The command is simply: <command> VMC> dragon.zon </command> If the zone compiles correctly it will indicate success by printing a message to the screen and outputting two files both with the same root name as the original zone source file but with different extensions. In this case there would be the following: <VARIABLELIST> <VARLISTENTRY> ;dragon.data <DICTDEF>

<PARA>The file holding the binary version of the zone</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;dragon.reset <DICTDEF>

<PARA>The file containing the reset information for the zone.</PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST> If the zone doesn't compile correctly and you have errors it will print a list of the errors and the location where they can be found so you can fix them. The debugging process will be explained more as you learn how to create rooms, monsters, and objects.</PARA>

</SECT1>

<SECT1><TITLE>The VMC pre-processor</TITLE>

<PARA>The <ACRONYM>VMC</ACRONYM> Pre-Processor (<ACRONYM>VMC</ACRONYM> -p) can be thought of as a powerful search and replace tool used by the compiler before it converts the zone to its binary form. This tool gives you the builder the ability to add comments, create short hand expressions for repeated items, include other files in your zone, and even to do some minor calculations when necessary.</PARA>

<NOTE> <PARA>If you have coded in C or c++ before the Pre Processor the <ACRONYM>VMC</ACRONYM> uses is no different and you can skip this section.</PARA> </NOTE>

<sect2><TITLE>Commenting your zone</TITLE>

<PARA>The practice of adding comments to your zone is a good thing to get into so the administrators and other builders can help you with your zone and know what you were trying to do if there are problems. Comments aren't as important when writing the zone as they will be when you start writing your own special <ACRONYM>DIL</ACRONYM> functions but it is important to know how comments work and that you can use them if you need to. A comment is a block of text the compiler will never see and is there only for you and who ever reads the file. In order to make it so the compiler will not see the block of text you must surround it by a set of symbols that tell the CPP to strip it out before passing the zone on to the compiler. These symbols are the '/*' and the '*/' symbols or the '//' symbols together in front of a single line.</PARA>

<PARA>In order to best explain how comments work we will give you a some what strange example. First we will start by showing you a very basic line you will see time and time again in rooms.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

title "this is a title"

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>This is a title it will show up in everything from rooms, to objects and even NPCs. Now lets see what a commented line would look like.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

//I am going to make a title now title /* I put the keyword first*/ "this is a title/*then the title*/

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>This of course is very ugly but the point is not to be pretty it is to show you both the first way and the second way will look exactly the same to the compiler because all comments are removed before the compiler ever gets it. A better use of a comment in a zone however would be something like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

/* The following ten rooms are the vineyards, there are 97 rooms in the zone. */

//Zone first created 1994

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>You will find comments will make coding large zones much easier because you can add text meant just for the builders eyes.</PARA>

<NOTE><PARA>You will have to decide if you want a multi-line comment or a single line comment and use the '//' or the '/**/' respectively. The rule of thumb is if the comment is longer than 1 line it is easier to put the '/**/' around the comment than to comment each individual line.</PARA></NOTE>

</sect2> <sect2><TITLE>Macros and what they can do for you</TITLE>

<PARA>When making a zone you will find there are things you use more than once. In fact you may find things you want others to use or things you want to use in multiple zones. Its true you could block and copy and stick them everywhere. in fact that is what I did when I first started building. I soon found my zone file was extremely large and hard to upkeep. With a few minor changes and a lot of deleting I used short hand or better known in the world of coding as macros to make my zone readable.</PARA>

<PARA>Lets say you had some flags you were going to set in fifty rooms and you knew they would all be the same. You could type the following line 50 times.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

flags {UNIT_FL_NO_WEATHER, UNIT_FL_CAN_BURY}

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>With the macros however you could make this much easier by just doing the following at the beginning of your zone.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

#define DIRTFLOOR flags {UNIT_FL_NO_WEATHER, UNIT_FL_CAN_BURY}

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>Then where ever you want the flags you just type DIRTFLOOR. You are probably thinking, yeah big deal I can do that with block and copy. True but there is another benefit to this. Lets say later you wanted to also make these 50 rooms no teleport. All you would have to change is the define like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

#define DIRTFLOOR flags {UNIT_FL_NO_WEATHER,UNIT_FL_CAN_BURY,UNIT_FL_NO_TELEPORT}

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Now when you recompile all 50 rooms are changed and you didn't even have to do a search and replace.</PARA>

<PARA>You can also make macros that take arguments. The ability to take arguments is where macros take a leap and a bound out in front of your favorite editor to allow you to do things you can not do easily with search and replace. Lets say you have an exit descr you want to use in 50 swamp rooms because heck everything looks the same in a swamp when you look one direction to the next.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

east to swamp1 descr "You see the swamp stretch out for miles";

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>This could be made into a macro like:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

#define sexit(direction, place) direction to place descr \ "You see the swamp stretch out for miles.";

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>Then all you need to use it is:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

SEXIT(east,swamp1) SEXIT(north,swamp2) SEXIT(south,swamp3)

</PROGRAMLISTING> </INFORMALEXAMPLE> <NOTE><PARA>There is no space between 'SEXIT' and '(' that is important because the CPP sees 'SEXIT(' and 'SEXIT (' as two different things. It is also important to notice all defines must start at the beginning of the line and be either one line long or have a '\' telling the Pre Processor that it should continue with the next line as if it was this line.</PARA></NOTE>

<PARA>You can also combine macros together so you have a set of macros like:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

#define DIRTFLOOR flags {UNIT_FL_NO_WEATHER,UNIT_FL_CAN_BURY,UNIT_FL_NO_TELEPORT} #define DIRTSECT movement SECT_INSIDE \ DIRTFLOOR

</PROGRAMLISTING> </INFORMALEXAMPLE>

<PARA>You may have noticed I capitalize all macros. This is not a must but it is suggested so you can easily tell what is a macro and what is not.</PARA>

</sect2> <sect2><TITLE>Including other files in your zone</TITLE>

<PARA>Another function of the <ACRONYM>VMC</ACRONYM> Pre Processor, '#include', allows you to include other files in your zone file. The <ACRONYM>VME</ACRONYM> comes with some basic include files you can use the macros out of and use as examples on how to make your own include files. These files are the composed.h,, vme.h, values.h, base.h, liquid.h, and wmacros.h. Including composed.h will include all the rest of the include files into your zone because it has include statements that use all the others.</PARA>

<NOTE><PARA>You will want to include the files at the beginning of your zone file because all defines you use must be defined before you use them.</PARA></NOTE>

</sect2> <sect2><TITLE>Doing minor calculations</TITLE>

<PARA> You can also do minor calculations in a macro. Lets say you wanted to make it so the higher level an NPC was the heavier he was and the taller he was. This would be simple with a macro.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

#define MLEVEL(lvl) \ level lvl \ height lvl+72 \ weight lvl*9

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>This macro would increase the height and weight depending on what level you made the NPC pretty simple. There is much more a macro can do for you but the Pre Processor and all its uses go far beyond the scope of this manual. If you are really interested in all the neat things it can do type the following command at the '$' prompt on your Linux box. <command>man cpp</command> The C-Pre Processor is what the <ACRONYM>VMC</ACRONYM> Pre Processor is based on and most if not all functions of the CPP work in the <ACRONYM>VMC</ACRONYM>. </PARA> </sect2>

</SECT1> </chapter>

<chapter ID="ch-02"><?dbhtml filename="ch02.html"> <TITLE>Zone source file</TITLE>

<PARA>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.</PARA>

<PARA>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 <ACRONYM>DIL</ACRONYM> section. The zone section is the only section that has to be in the file, and they may appear in any order.</PARA>

<PARA>Each section is preceded by a section header. These are the six possible headers: <itemizedlist> <LISTITEM><PARA>%zone</PARA></LISTITEM> <LISTITEM><PARA>%rooms</PARA></LISTITEM> <LISTITEM><PARA>%mobiles</PARA></LISTITEM> <LISTITEM><PARA>%objects</PARA></LISTITEM> <LISTITEM><PARA>%reset</PARA></LISTITEM> <LISTITEM><PARA>%<ACRONYM>DIL</ACRONYM></PARA></LISTITEM> </itemizedlist> 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 <ACRONYM>DIL</ACRONYM> 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. </PARA>

<SECT1><TITLE>Definition types</TITLE>

<PARA>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:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

field value

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>Where field is the name of a data field, and value is some value. Values are of one of 6 types: <VARIABLELIST> <VARLISTENTRY> ;integer <DICTDEF> <PARA><indexterm> <primary>Number</primary> </indexterm>

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)</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;string <DICTDEF> <PARA><indexterm> <primary>String</primary> </indexterm>

Text enclosed in Double Quotes. The string can span more than one line as it would in a description.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

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."

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;stringlist <DICTDEF> <PARA><indexterm> <primary>Stringlist</primary> </indexterm>

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.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

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

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;intlist <DICTDEF> <PARA><indexterm> <primary>Intlist</primary></indexterm>

A list of numbers which can be used with an extra. This type works like the stringlist but doesn't need the quotes.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

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

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;flags <DICTDEF> <PARA><indexterm> <primary>Flags</primary> </indexterm>

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.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

flags {2,8} manipulate {8}

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>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:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

flags {UNIT_FL_INVISIBILE,UNIT_FL_BURIED} manipulate {WEAR_BODY}

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>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.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;symbol <DICTDEF> <PARA><indexterm> <primary>Symbol</primary> </indexterm>

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.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

dark_sword /*good symbol*/ rm_5892 /*Bad symbol*/

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>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 <ACRONYM>DIL</ACRONYM> 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.</PARA> <itemizedlist> <LISTITEM><PARA>The first letter of the symbol must be a letter of the alphabet or a '_' character</PARA></LISTITEM> <LISTITEM><PARA>Characters following the first can be numbers, alphabet letters, and '_' characters</PARA></LISTITEM> <LISTITEM><PARA>The name can be no longer than 15 characters</PARA></LISTITEM> <LISTITEM><PARA>No reserved keywords can be used as a name <XREF LINKEND="app-b"></PARA></LISTITEM> </itemizedlist>

<NOTE><PARA>the end tag that ends all unit definitions is also considered a symbol it is just a symbol that must be included with</PARA></NOTE> </LISTITEM> </VARLISTENTRY> </VARIABLELIST></PARA>

<PARA>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 <ACRONYM>DIL</ACRONYM> function or a special function called from the base code.</para>

<NOTE><PARA>Special functions are being replaced with <ACRONYM>DIL</ACRONYM> for better performance and should only be used when no <ACRONYM>DIL</ACRONYM> functions exist to replace them</PARA></NOTE>

<para>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.</PARA>

</SECT1>

<SECT1 id="zoneinfo"> <TITLE>Zone information section</TITLE>

<PARA>The zone information section is the only section that must exist in the source file of your area. With out 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 is 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.</PARA>

<TITLE>Zone section field descriptions</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>Field</ENTRY> <ENTRY>Type</ENTRY> <ENTRY>Description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>creators</ENTRY> <ENTRY>Stringlist</ENTRY> <ENTRY> This field is where you place the creators of the zone. With this field filled out the Administrators and builders can easily find out who the zone was written by and be able to contact them if there are problems. </ENTRY></ROW> <ROW> <ENTRY>lifespan</ENTRY> <ENTRY>Number</ENTRY> <ENTRY> This defines the interval between resets for this zone, in minutes. Default is 60 if this field is left out of the information section. </ENTRY></ROW> <ROW> <ENTRY>notes</ENTRY> <ENTRY>String</ENTRY> <ENTRY> This is a plain text description of the zone for administrators and builders. It is often a good idea to include your e-mail address in the notes so you can be reached easily by the administrators. </ENTRY></ROW> <ROW> <ENTRY>reset</ENTRY> <ENTRY>Number</ENTRY> <ENTRY> This combined with 'lifespan' defines if the zone will be reset. This field gives the condition that must be met to reset the zones you should use the defines in the vme.h, RESET_NOT, RESET_IFEMPTY, and RESET_ANYHOW. Default is RESET_ANYHOW, which means, the zone will be reset even if players are present within it. </ENTRY></ROW> <ROW> <ENTRY>title</ENTRY> <ENTRY>String</ENTRY> <ENTRY> This is the title of the zone, for example Dragons Nest, Dark station, and creators hide out. It is used mainly for the areas command so players can get a list of all the areas in the game. It can however be accessed by the 'zoneptr' variable type in <ACRONYM>DIL</ACRONYM>. If you have a zone that spans across multiple source files you only need to define the title once. If you put the title in all source files it will show up multiple times in the area listing. You would also leave this blank if the zone should not be on the areas list like an administration zone. </ENTRY></ROW> <ROW> <ENTRY>weather</ENTRY> <ENTRY>Integer</ENTRY> <ENTRY> This field sets the humidity level of the zone. If for example you want a hot desert like zone you would want to set this to its highest value. The range of this field is 1000 to -1000. This is an optional field and will not be covered else where because it is simple to use. </ENTRY></ROW> <ROW> <ENTRY>%zone</ENTRY> <ENTRY>Symbol</ENTRY> <ENTRY> This entry defines the name of the zone. Default is the preceding component of the current filename, minus the trailing ".zon". Note, the symbol should be added after the %zone tag, which should always be put, even if you do not add a symbol after it. </ENTRY></ROW> </TBODY> </TGROUP>

<PARA>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.</PARA>

/*very bad*/ %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 whistler@valhalla.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."

</PROGRAMLISTING> </INFORMALEXAMPLE>

<PARA>If you felt like it you could add a '%end' to the proceeding examples and compile them. They would create an empty zone so wouldn't be very exciting but at least its 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.</PARA> </SECT1>

</chapter>

<chapter ID="ch-03"><?dbhtml filename="ch03.html"> <TITLE>Unit building blocks</TITLE>

<PARA>When creating your zone you will find some basic structures are used in all three unit types rooms, objects, and NPCs. In this chapter we will define the main building blocks of all units along with some helpful hints </PARA>

<PARA>No matter which unit type you are dealing with there is a simple basic structure that lets the compiler know not only what unit type it is dealing with but where one unit begins and where it ends. The way the compiler tells what unit type it is dealing with is by the section header '%rooms', '%objects', and '%mobiles'. All rooms must be defined under the '%rooms' header and likewise objects and NPCS under their respective headers. Each unit starts with a symbolic name called the unit symbol and ends with the keyword end. The following would be a legal definition of any unit type:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

symbol_name end

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>If you define a unit like this when it loads it will be blank, while this is not extremely useful it is good to know you can leave out any field you don't feel you need.</PARA>

<VARIABLELIST> <TITLE>Unit building blocks</TITLE> <VARLISTENTRY> ;symbol field <DICTDEF> <PARA><indexterm> <primary>symbol field</primary> </indexterm>

In the last chapter we defined the different field types and the rules you must follow when defining a symbol. It is important enough to relist these rules here so you do not run into problems when creating your units. <itemizedlist> <LISTITEM><PARA>The first letter of the symbol must be a letter of the alphabet or a '_' character</PARA></LISTITEM> <LISTITEM><PARA>Characters following the first can be numbers, alphabet letters, and '_' characters</PARA></LISTITEM> <LISTITEM><PARA>The symbol can be no longer than 15 characters</PARA></LISTITEM> <LISTITEM><PARA>No reserved keywords can be used as a symbol<XREF LINKEND="app-b"></PARA></LISTITEM> </itemizedlist></PARA>

<NOTE><PARA>It is also important to know currently it is hard to deal with units having capital letters in them, this may be fixed in the future but it is good practice to use all lower case characters in the symbols.</PARA></NOTE>

<PARA>Another thing you should think about when defining your symbol names is to be clear about what the unit is. When you list units on the <ACRONYM>VME</ACRONYM> server with <command>wstat</command> the symbolic names are shown if you were to see the list: <computeroutput> i6853 b2419 l1854 </computeroutput> You would have no idea what those three items were unless you personally built them recently, therefore it is a much better coding practice to name things what they are like: <computeroutput> long_sword healer_hut dog </computeroutput> </PARA></LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;title field <DICTDEF> <PARA><indexterm> <primary>title field</primary> </indexterm>

The title field is probably the easiest field on all units it is what is shown on the first line of a room when you enter and it is the name shown when you get an object or attack a NPC. There is only two important things to look at when defining titles one is punctuation and the other is capitalization. Room titles need to be capitalized and so do proper names but the first letter of an object title or a NPC title do not normally need to be capitalized. this is best explained by some examples.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

title "The dragons in."/*good*/ title "a big bull dog."/*bad has a period at the end*/ title "Bill the destroyer"/*good*/ title "A long dagger"/*bad capital 'a'*/

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>Now to show why some of those are good we will demonstrate by some sample output in the game. <computeroutput>

prompt: l The Dragons Inn You are standing in a moldy inn.

prompt: get A long dagger You get A long dagger.

prompt kick dog You kick a bull dog. in the head. </computeroutput> Notice the 'A' and the extra period do not really look right where they end up appearing in the game. These may be minor nit picky details but if you do it right the first time you won't have to deal with the english major that just happens to be playing on your mud.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;names field <DICTDEF> <PARA><indexterm> <primary>names field</primary> </indexterm>

The 'names' field defines the names everything in the game can use to interact with your unit. For rooms the names are used as teleport or goto points for characters and NPCs or they are sometimes used for special DIL functions on objects to trigger in certain rooms. On NPCs and objects names can be used for anything from poking a player to giving a player an object. The names field is very flexible it has even been used to store what a container is holding in order to have quick access to the names in the container. it</PARA>

<PARA>When making rooms it is not necessary to put room names. In fact it is a good way of making sure players can't teleport to certain rooms because if the room doesn't have a name the person can't teleport to it. Objects and NPCs must have names because if you leave names off of them you can not pick them up or kill them depending on which you are dealing with. It is also good practice to use all combinations of the object or NPCs title so a player will know exactly what to type to use the item for example:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

bad_obj title a small dog" names{"small dog","small","dog"} end

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>It is up to you as a builder if you want to use names like 'small' in your names list since you would not 'get small' in real life it may not have to be added to the names list. It is important however to define your extras from big to small because of how the <ACRONYM>VME</ACRONYM> command interpreter handles names of things. For example if you had the following names:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

small_item title "a small item" names {"small","item","small item"}

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>When you try to <command>give small item Bill</command>. The interpreter would try to give small to item and that would not be what you wanted to do. Don't worry the compiler will catch this and give you an error something like: <computeroutput>

Fatal name ordering on line ###.

</computeroutput></PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;descr field <DICTDEF> <PARA><indexterm> <primary>descr field</primary> </indexterm>

The description building block is used in many places. You will find description fields on extras, exits, rooms, NPCs, objects, and as you have already seen the help and the notes field of the zone information section are also description fields.</PARA>

<PARA> Depending on what you are working on description fields can mean totally different things to the person looking in the room. A description field on a room can be the inside or outside of the rooms description. A description on extras can be an NPCs descr or an extra description on the room like if you looked at a 'rug' or a 'chair'. On an exit the descr field describes what you see when you look in that direction from the room you are in. The important thing right now is no matter where you use them they all work the same.</PARA>

<PARA>description fields like the title field have a tag or unlike the title field can have a set of tags before them like in extras or exits but like titles they are just a string surrounded by quotes. You can make multiple line descriptions if the description is on a NPC you may not want to since it is the description shown when you walk into the room. The following would be some examples of room descriptions.</PARA>

descr "this is how you would define a room descr and as you can see it can be much longer than a line if you like."

extra {"basic extra"} "This is a description field on an extra."

extra{"more advanced","extra"}{1,2,3,4,5,6} "This is still the description field. Like the room description or any description field for that matter this can be longer than a line."

east to bathroom descr "You see one big toilet!";

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;extra fields <DICTDEF> <PARA><indexterm> <primary>extra fields</primary> </indexterm>

The extra field is the work horse for the builder. It is the building block that most brings your zone to life. You can use it to describe body parts or items in a room. When you use <ACRONYM>DIL</ACRONYM> you will use extras to store information like quest information or special information you need later. Extras also store the main description on NPCs since the descr field on NPCs is really the long title shown in the room which will be explained later in <xref linkend="ch-05">.</PARA>

<PARA>The extra Is the first structure definition you have run into so it may take some playing with to figure it out. The extra has actually 4 fields three of them must be there in some form. The first is the identifier that tells the compiler that this is an extra, the second is a stringlist, the third is an Optional Intlist, and the final one is the extra description field. If the extra had all the fields it would look like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

extra {"small chair","chair"} {1,2,3,4,5} "Its a chair."

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>If the previous wasn't an example we would have left out the Intlist because it is not necessary to put the Intlist on a chair unless you want it there for some special <ACRONYM>DIL</ACRONYM> you are creating. the Intlist is the only field that can be totally left out but you can leave the string list blank when you want to make the extra the default description when the object, room, or NPC is being looked at, like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

extra {} "This would be what you see when you look at any of the names in the names list."

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>We will go more in-depth into why you want to do this in the following chapters. </PARA></LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<PARA>You are now ready to put these building blocks to work. You have only to learn how to put these fields to work for each of the three unit types and you will be off and running.</PARA>

</chapter>

<chapter ID="ch-04"><?dbhtml filename="ch04.html"> <TITLE>The room section</TITLE>

<PARA> The previous chapter gave you the basic building blocks that will be used all through creating rooms, NPCs, and objects. If you jumped straight to this chapter without reading about the general building blocks you might want to return to <XREF LINKEND="ch-03"> first. This chapter will deal with all the fields of rooms what they are and how to use them but with out the previous chapter you may get lost.</PARA>

<PARA>In order to get started building rooms you should first be aware of the room fields you can use. The <xref linkend="rmfields"> shows a full listing of all the room fields and their types as defined in <xref linkend="ch-03">.</PARA>

<TITLE>Room fields and types listing</TITLE> <TGROUP align=left cols=5 colsep=1> <COLSPEC COLNAME="c1" COLWIDTH="2in"> <COLSPEC COLNAME="c2" COLWIDTH="2in"> <COLSPEC COLNAME="c3" COLWIDTH=".5in"> <COLSPEC COLNAME="c4" COLWIDTH="2in"> <COLSPEC COLNAME="c5" COLWIDTH="2in"> <THEAD> <ROW> <ENTRY COLNAME="c1">Field</ENTRY> <ENTRY COLNAME="c2">Type</ENTRY> <entry></entry> <ENTRY COLNAME="c4">Field</ENTRY> <ENTRY COLNAME="c5">Type</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY COLNAME="c1">symbolic name</ENTRY> <ENTRY COLNAME="c2">Symbol</ENTRY> <ENTRY morerows=9 colname="c3"></ENTRY> <ENTRY COLNAME="c4">manipulate</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">names</ENTRY> <ENTRY COLNAME="c2">Stringlist</ENTRY> <ENTRY COLNAME="c4">alignment</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">title</ENTRY> <ENTRY COLNAME="c2">String</ENTRY> <ENTRY COLNAME="c4">flags</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">descr</ENTRY> <ENTRY COLNAME="c2">String</ENTRY> <ENTRY COLNAME="c4">weight</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">outside_descr</ENTRY> <ENTRY COLNAME="c2">String</ENTRY> <ENTRY COLNAME="c4">capacity</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">extra</ENTRY> <ENTRY COLNAME="c2">Structure</ENTRY> <ENTRY COLNAME="c4">light</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">minv</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">exit</ENTRY> <ENTRY COLNAME="c5">Structure</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">key</ENTRY> <ENTRY COLNAME="c2">string</ENTRY> <ENTRY COLNAME="c4">movement</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">spell</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">end</ENTRY> <ENTRY COLNAME="c5">Symbol</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">dilbegin or dilcopy</ENTRY> <ENTRY COLNAME="c2">Function pointer</ENTRY> <ENTRY COLNAME="c4"></ENTRY> <ENTRY COLNAME="c5"></ENTRY> </ROW> </TBODY> </TGROUP>

<PARA>As you can see there is not a whole lot of fields you have to learn in order to make a room. In fact as you will see shortly some of these fields are not even used on rooms. In <xref linkend=" rmfielddescr"> we will expand your knowledge from just knowing what the field types are to how to set them as well.</PARA>

<sect1 id="rmfielddescr"> <TITLE>Description of room fields</TITLE>

<variablelist id="var-rmfields"> <VARLISTENTRY> ;symbolic name <DICTDEF> <PARA><indexterm> <primary>Room symbol</primary> </indexterm>

The rules of the symbols has been explained in <XREF LINKEND="ch-03">, if you didn't read them yet you may want to review. The important thing to realize with the room symbol is it is always good practice to give the room a symbol resembling the title so administrators and builders can use the <command>goto</command> and the <command>wstat</command> to easily goto the room in question. </PARA></LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;title <DICTDEF> <PARA><indexterm> <primary>Room title</primary> </indexterm>

The room title field should start with a capital and depending on your preference the compiler will not complain if you add punctuation at the end. The following are good examples of a room title.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

title "The Post Office" title "The deep dark jungle floor:" title "The Dragon Station control room"

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>It is really up to you weather you want to use punctuation or not, it is more administrator personal opinion than anything. </PARA></LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;names <DICTDEF> <PARA><indexterm> <primary>Room names</primary> </indexterm>

The names field on the rooms are not that important and only should be used if the builder wishes the room to be accessed by the players by a teleport command. If the room has no names no one will be able to teleport to it. On some muds there will be no teleport spell so the only use for this field will be for <ACRONYM>DIL</ACRONYM> functions the administrator creates. If a builder wants the room to be accessible by teleport then the names should match the title since that is what the player will try to teleport to. A few good examples of names on a room would look as follows.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

title "The Post Office" Names {"post office","office"}

title "the thrown room" names {"thrown room","thrown"}

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;descr <DICTDEF> <PARA><indexterm> <primary>Room description</primary> </indexterm>

The description field is what the player sees when walking into the room or when looking with no arguments. </PARA></LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;outside_descr <DICTDEF> <PARA><indexterm> <primary>Room outside description</primary> </indexterm>

This field is what is shown to a char if the room is loaded inside another room. For example if you had a room linked inside another room and called a barrel this would be the description that lets the character know it is a barrel. An example would be like:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

outside_descr "a big old barrel is laying here on its side."

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>This allows a builder to make a room that looks like an object inside another room. </PARA></LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;movement <DICTDEF> <PARA><indexterm> <primary>movement</primary> </indexterm>

The movement field defines the endurance cost to a character when moving through this room. In the future these fields will be adjustable by the use of a define file. Currently all movement fields are constants and are defined in the vme.h The following is the movement sector types and their values.

<TITLE>Sector movement values</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>Symbol</ENTRY> <ENTRY>Name</ENTRY> <ENTRY>Endurance Cost</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>SECT_INSIDE</ENTRY> <ENTRY>inside</ENTRY> <ENTRY>1</ENTRY> </ROW> <ROW> <ENTRY>SECT_CITY</ENTRY> <ENTRY>city</ENTRY> <ENTRY>1</ENTRY> </ROW> <ROW> <ENTRY>SECT_FIELD</ENTRY> <ENTRY>field</ENTRY> <ENTRY>2</ENTRY> </ROW> <ROW> <ENTRY>SECT_FOREST</ENTRY> <ENTRY>forest</ENTRY> <ENTRY>3</ENTRY> </ROW> <ROW> <ENTRY>SECT_HILLS</ENTRY> <ENTRY>hills</ENTRY> <ENTRY>4</ENTRY> </ROW> <ROW> <ENTRY>SECT_MOUNTAIN</ENTRY> <ENTRY>mountain</ENTRY> <ENTRY>6</ENTRY> </ROW> <ROW> <ENTRY>SECT_DESERT</ENTRY> <ENTRY>desert</ENTRY> <ENTRY>8</ENTRY> </ROW> <ROW> <ENTRY>SECT_SWAMP</ENTRY> <ENTRY>swamp</ENTRY> <ENTRY>8</ENTRY> </ROW> <ROW> <ENTRY>SECT_WATER_SWIM</ENTRY> <ENTRY>water-swim</ENTRY> <ENTRY>4</ENTRY> </ROW> <ROW> <ENTRY>SECT_WATER_SAIL</ENTRY> <ENTRY>water-sail</ENTRY> <ENTRY>50</ENTRY> </ROW> <ROW> <ENTRY>SECT_UNDER_WATER</ENTRY> <ENTRY>under-water</ENTRY> <ENTRY>8</ENTRY> </ROW> <ROW> <ENTRY>SECT_SNOW</ENTRY> <ENTRY>snow</ENTRY> <ENTRY>8</ENTRY> </ROW> <ROW> <ENTRY>SECT_SLUSH</ENTRY> <ENTRY>slush</ENTRY> <ENTRY>6</ENTRY> </ROW> <ROW> <ENTRY>SECT_ICE</ENTRY> <ENTRY>ice</ENTRY> <ENTRY>10</ENTRY> </ROW> </TBODY></TGROUP>

The movement is simply defined by placing the 'movement' keyword first followed by the type of sector you desire. For example a few movement fields would look as follows:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

movement SECT_FOREST movement SECT_HILLS

</PROGRAMLISTING> </INFORMALEXAMPLE> <NOTE><PARA>Only one movement is needed for a room if you put more than one the last one added will be the one used.</PARA></NOTE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;flags <DICTDEF> <PARA><indexterm> <primary>Room flags</primary> </indexterm>

This field on a room is used to set special attributes in order to make the room private or no-teleportable and many others. The following is the list of possible already defined flags. Extras can also be used to create special room flags.

<TITLE>Room unit flag affects</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>Flag</ENTRY> <ENTRY>Description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>UNIT_FL_PRIVATE</ENTRY> <ENTRY>When this flag is set on a room it marks it as a private room. Commands that honor the private flag will not let more than 2 players into this room. Commands like <command>goto</command> and direction commands are a few commands that do honor this flag.</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_INVISIBLE</ENTRY> <ENTRY>Makes unit invisible</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_BURY</ENTRY> <ENTRY>Makes a hard floor so items can't be buried.</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_BURIED</ENTRY> <ENTRY>Makes unit buried when loaded</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_TELEPORT</ENTRY> <ENTRY>makes unit so no one can teleport to it</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_MOB</ENTRY> <ENTRY>Makes it so no mobile will enter the unit</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_WEATHER</ENTRY> <ENTRY>keeps weather and natural light out of unit</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_INDOORS</ENTRY> <ENTRY>Makes unit inside and doesn't affect weather</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_TRANS</ENTRY> <ENTRY>Makes unit transparent</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_SAVE</ENTRY> <ENTRY>Makes it so you can't save with unit</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_SACRED</ENTRY> <ENTRY>Makes unit a double gain unit</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_MAGIC</ENTRY> <ENTRY>Marks a unit to be magic</ENTRY> </ROW> </TBODY></TGROUP>

</PARA></LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;extra <DICTDEF> <PARA><indexterm> <primary>Room extras</primary> </indexterm> </PARA>

<PARA>Extras are the work horse of the <ACRONYM>VME</ACRONYM>. Extras are used in everything from <ACRONYM>DIL</ACRONYM> to just normal extra descriptions on rooms. The first job for an extra was to hold extra description information on a room. For example if you had a computer room and you described it might look something like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

descr "This small room houses the computer power of the <ACRONYM>VME</ACRONYM> development team. All four walls are lined with various pieces of computer equipment old pizza boxes and plenty of empty soda cans."

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>The problem is as a player if you saw this description you might want to know what kind of pizza we eat or maybe you would want to see what kind of soda we drink. Or heaven forbid you might want to know what kinds of computer equipment is scattered about the room. In the <ACRONYM>VME</ACRONYM> servers we do this by adding extra descriptions to the room. In this case the builder of the zone may do something like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

descr "This small room houses the computer power of the <ACRONYM>VME</ACRONYM> development team. All four walls are lined with various pieces of computer equipment old pizza boxes and plenty of empty soda cans."

extra {"soda cans", "cans", "soda", "can"} "These cans are all Canadian blue. Maybe the Valhalla team hates American beer. Strange all of them look to have strange indentations."

extra {"strange indentations", "strange indentation","indentation"} "They are human bite marks. Is this what happens when code doesn't work right?"

extra {"pizza boxes","pizza","boxes","box"} "Dominos could make a fortune from all these boxes and probably already have from the <ACRONYM>VME</ACRONYM> team. you notice all the boxes are empty at least they finish what they start."

extra {"computer pieces","computer parts", "equipment","hardware", "pieces", "parts"} "I bet you thought you would see what we have running. Yeah right you might come over and rob us if we told you that. All you see is an old XT."

extra {"xt"} "Its a hunk of junk really!"

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>There is a lot to notice in the previous examples. First we will start with extras when defined on rooms, NPC, and objects must be in length order for the names. There are a few reasons for this but lets just say the most important reason is we wanted it this way. If you don't put them in order the <ACRONYM>VMC</ACRONYM> will give you a fatal error and will not compile your zone.</PARA>

<PARA>The next thing you should notice is we have used an extra to describe something in another extra. We actually did this twice once for the beer cans and once for the computer parts. That way you can actually give quest information but make the person really have to explore your rooms descriptions to find it.</PARA>

<PARA>The previous example is what we consider normal extras in a room. There are also extras that hold information for DIL functions. These special extras can have extra fields and they can be hidden to the players eyes. Here are some examples of special extras.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

extra {"$rockcount"} "5"

extra {"$playerkill"} "0"

extra {"$coke","$milk","$water"}{1,5,10} "Drinks and amounts"

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>These extras all have the '$' sign appended to the front of the names in order to tell the look command the player shouldn't be able to look at the extra. If you have not already seen <ACRONYM>DIL</ACRONYM> coding you may not understand why you would want extras players can't see. The <ACRONYM>DIL</ACRONYM> language can manipulate these extras by reading and writing them in order to change the way a command or another function works. For example the last <ACRONYM>DIL</ACRONYM> could be used for a shopkeeper to tell how many of each type of drink he has. Notice the drink extra also has something you haven't seen yet, an added integer list after the namelist. all extras can have these but only extras being used with DIL functions really need them.</PARA>

<PARA>Some of these special functions are supported already in the code and the ones that affect the rooms are as follows. In the following $1n is the activator and $2n is the unit in question.</PARA>

<PARA>There is only one special extra already supported for rooms and that would be the '$get'. As we have previously mentioned the extras that start with a dollar sign are not seen by the players. This one however is shown to the player when the person types get on the other names in the extras list. This easier to describe in an example than in words so the following would be a good example.:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

extra {"$get", "statues", "statue"} "You attempt to pick up a statue but quickly discover your feeble attempts will never work."

{"$get", "red roses", "roses"} "You bend down to pick a rose, but then decide to leave the beautiful flower to itself."

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>With this one special extra we have made it so you don't need to make millions of items so the person can act upon them. You can just make the acts as if the items were in the room.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Exits <DICTDEF> <PARA><indexterm> <primary>Exits</primary> </indexterm> </PARA>

<PARA> Every room has ten possible exits; North, East, South, West, Northeast, Southeast, Southwest, Northwest, Up and Down. To enable mobile use of these commands, you must specify these exits as outlined below:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

exit <direction> [to <destination>] [open {<infoflags>}] [key <keyname>] [keyword {<keywords>}] descr <description> ;

</PROGRAMLISTING> </INFORMALEXAMPLE>

<VARIABLELIST> <VARLISTENTRY> ;exit <directions> <DICTDEF> <PARA>Is the direction the exit leads, ie. one of north, south .. up, down.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <TERM>to <destinations></TERM> <LISTITEM> <PARA>The symbolic reference to the room, you want this exit to lead to. If you reference a room within another zone, post pend the name with @<zone name></PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

to myotherroom

to hisotherroom@hiszone

</PROGRAMLISTING> </INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <TERM>open <info flags></TERM> <LISTITEM>

<PARA>These flags describe the state of the door. The following is the list of possible door flags.</PARA>

<VARIABLELIST> <VARLISTENTRY> ;EX_OPEN_CLOSE <DICTDEF> <PARA> Set this if you can open and close this exit, be it a door, gate or otherwise.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;EX_CLOSED <DICTDEF> <PARA>Set this if you want the exit to be closed at boot time.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;EX_LOCKED <DICTDEF> <PARA>Set this if you want the exit to be clocked at boot time.</PARA> <NOTE> <PARA>An interesting aspect is, if you do not specify a key, you can only unlock this door with the 'pick' skill, 'unlock' spell or from <ACRONYM>DIL</ACRONYM> with UnSet();</PARA> </NOTE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;EX_PICK_PROOF <DICTDEF> <PARA>Using this flag renders the 'pick' skill and 'unlock' spell un useable on the lock of this exit.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;EX_HIDDEN <DICTDEF> <PARA>If this bit is set, the exit is hidden until the mobile has successfully searched for it, using the 'search'-command.</PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

</LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;key <keyname> <DICTDEF> <PARA>The symbolic name of a key object used for unlocking this exit.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

key mykey@myzone

</PROGRAMLISTING> </INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;keyword { <stringlist> } <DICTDEF> <PARA>This stringlist holds all the names of the exit, you specify to manipulate the exit. If the exit is hidden exit, these are the keywords the mobile can search for.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

keyword {"wooden door","door"}

keyword {"hidden door","door","hatch","floor"}

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;descr <description> <DICTDEF> <PARA>This string is the description of what you see if you look in the direction of the exit.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;; <DICTDEF> <PARA>Every exit statement needs to be terminated with a semi-colon. </PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<NOTE> <TITLE>General notes</TITLE> <PARA>Even though you do not need an exit in all directions, you can use it to place descriptions of the direction.</PARA> </NOTE> <INFORMALEXAMPLE> <PROGRAMLISTING>

exit north descr "An unsurmountable mountain blocks your way.";

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;minv <DICTDEF> <PARA><indexterm> <primary>Room minv</primary> </indexterm></PARA>

<PARA>This field is rarely used on rooms. It could however be used to make a room invisible inside another room. Or it could be used to store numbered values on a room. The reason this field is on a room is it is part of the base object which all objects are derived from. If the room is going to be inside another room and you don't want it visible the following would make it invisible to all players below the level of 20.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

minv 20

</PROGRAMLISTING> </INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<PARA>This field is not used normally on a room. It is a string that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs (unit pointers like, rooms, objects, and NPCs) are derived from.</PARA>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;manipulate <DICTDEF> <PARA><indexterm> <primary>Room manipulate</primary> </indexterm></PARA>

<PARA>This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.</PARA>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;alignment <DICTDEF> <PARA><indexterm> <primary>Room alignment</primary> </indexterm></PARA>

<PARA>This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;weight <DICTDEF> <PARA><indexterm> <primary>Room weight</primary> </indexterm></PARA>

<PARA>This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.</PARA>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;capacity <DICTDEF> <PARA><indexterm> <primary>Room capacity</primary> </indexterm></PARA>

<PARA>This field is not used normally on a room. It is an integer that can be used for anything you desire. The reason it exists on rooms is it is a part of the base object all unitptrs are derived from.</PARA>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;light <DICTDEF> <PARA><indexterm> <primary>Room light </primary> </indexterm></PARA>

<PARA>This field sets the light on a room. Normally this is not done directly, instead it is set using macros defined in wmacros.h.</PARA>

<TITLE>Light defines</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>Define</ENTRY> <ENTRY>Light Value</ENTRY> <ENTRY>Affect</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>ALWAYS_LIGHT</ENTRY> <ENTRY>1</ENTRY> <ENTRY>Room is always light no matter time of day</ENTRY> </ROW> <ROW> <ENTRY>IN_ALWAYS_DARK </ENTRY> <ENTRY>-1</ENTRY> <ENTRY>When an inside room is always dark - both inside and outside </ENTRY> </ROW> <ROW> <ENTRY>OUT_DARK_NON_NOON </ENTRY> <ENTRY>-1</ENTRY> <ENTRY>Always a dark room, except when it is high noon </ENTRY> </ROW> <ROW> <ENTRY>OUT_ALWAYS_DARK </ENTRY> <ENTRY>-2</ENTRY> <ENTRY>Always a Dark room, no matter the time of day</ENTRY> </ROW> </TBODY></TGROUP>

<PARA>To set natural light that changes depending on the type of day nothing is needed to be put in the light field the compiler will default to '0'. If you for some reason want to set the light to default lighting you can do so but you don't need to. You will also notice there are two macros that set the light to the exact same value. This is for compatibility with older code base and if you wish to combine these two macros or only use one it would not change the way the mud works.</PARA>

<PARA>This is probably one of the simplest fields you will have to deal with in the rooms. In order to set it all that is needed is to place the macro or the light and value on a line in the room and your all done.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

//To Set always light with macro ALWAYS_LIGHT

//To set Always light with out macro light 1

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>You can decide which is easiest for you.</PARA> </LISTITEM> </VARLISTENTRY>

</VARLISTENTRY>

<VARLISTENTRY> ;spell <DICTDEF> <PARA><indexterm> <primary>Room spell</primary> </indexterm></PARA> </LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY> ;dilbegin or dilcopy <DICTDEF> <PARA><indexterm> <primary>Room dilbegin or dilcopy</primary> </indexterm></PARA>

<PARA>The <ACRONYM>DIL</ACRONYM> functions are what give <ACRONYM>VME</ACRONYM> servers the edge over all other muds. We will only give some examples here and leave it up to the <ACRONYM>DIL</ACRONYM> manual to teach you how to create your own functions that will make your rooms, NPC, and objects more than special.</PARA>

<PARA>There are only currently three room functions that come standard with a <ACRONYM>VME</ACRONYM> in the function.zon. There are much more in the zones released with the <ACRONYM>VME</ACRONYM> but you will have to hunt for those. The three that come standard are Safe room, Death room, and forced move. The safe room makes it impossible for players to kill each other, the death room is a function that lets you make things like rock slides and quick sand, and the forced move lets you make an easy river.</PARA>

<PARA>Since these are just <ACRONYM>DIL</ACRONYM>'s written by builders for the Valhalla mud all you have to do is use the dilcopy keyword in the room with the function name you want to use and the arguments the function requires. The following is what you would find in the function.zon for death room.</PARA>

/* Death room <ACRONYM>DIL</ACRONYM> *tick is in 4th's of seconds * Damage is damage done per tick *act_s is string shown to damaged player. */ dilbegin death_room(tick: integer, damage: integer, act_s: string);

var ext: extraptr; u : unitptr; i : integer;

code {

if (tick < 12) tick := 12;

heartbeat := tick;

if (damage < 0) damage := -damage;

if ("$death room for mobs" in self.extra) i := UNIT_ST_PC|UNIT_ST_NPC; else i := UNIT_ST_PC;

while (TRUE) { wait (SFB_TICK, TRUE);

foreach (i, u) { if (u.level >= IMMORTAL_LEVEL) continue;

if (("$no death room" in u.extra) and (u.type == UNIT_ST_NPC)) continue; // Don't allow pcs to get this flag

if (act_s != "") act ("&[hit_me]"+act_s, A_ALWAYS, u, null, null, TO_CHAR); else act ("&[hit_me]You bleed from your wounds.", A_ALWAYS, u, null, null, TO_CHAR);

u.hp := u.hp - damage; position_update (u); }

}

dilend

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>If this <ACRONYM>DIL</ACRONYM> function scares you don't worry you don't have to understand or adjust it you just have to use it. In this function it requires a time, damage, and act. So you could use this in a room definition like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

dilcopy death@function (60,25,"Flames shoot from the floor burning your rear.");

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>This says to copy the <ACRONYM>DIL</ACRONYM> from zone function with the arguments 60 seconds, damage 25% and act as shown. Pretty simple eh?</PARA>

<PARA>All released <ACRONYM>DIL</ACRONYM> room functions are described in <XREF LINKEND="rmdilfunc">. Then we put some to work so you can see how to use them in <XREF LINKEND="rmcomplex"></PARA>

</LISTITEM> </VARLISTENTRY> </VARIABLELIST>

</SECT1>

<sect1 id="rmbasic"> <TITLE>Building your first room</TITLE>

<PARA>Now you are ready! With all you have learned about room fields you are now ready to build your first room. I personally like dragons and I like space so I have chosen to make a dragon station. We will first do a simple room and build on to it in the next sections. In this section we will walk you through creating a basic room and why we choose what we do where we do.</PARA>

<PARA>When making rooms you create the zone source file first as shown in <xref linkend="ch-02">. If you only have rooms you do not need the %reset, %objects, and %mobiles. For the examples in this chapter we will use the zone we created in <xref linkend="ch-02"> and add the %room tag where we will put all the rooms. At the end of the chapter we will have the entire zone so you can see it all together.</PARA>

<PARA>The first part of all rooms is the symbolic name it is good to always pick a name that will match the title so you can use the administrator command <command>goto</command> to easily get to the room. The reason is when you use the command <command>wstat</command> it will only show you a list of the rooms by symbolic name for example if you type <command> wstat zone dragon room </command> You will get the following:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

List of rooms in zone Dragon: chamber portal office

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>If you didn't make it clear what the rooms were by the symbolic name it might look like this:</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

List of rooms in zone Dragon: st_rm1 st_rm2 st_rm3

</PROGRAMLISTING> </INFORMALEXAMPLE>

<PARA>While this might be great when you first start imagine trying to remember what all one hundred rooms are.</PARA>

<PARA>The first room we will create will be a simple chamber with nothing special. We can build on to it later if we need to.</PARA> <INFORMALEXAMPLE> <PROGRAMLISTING>

chamber end

</PROGRAMLISTING> </INFORMALEXAMPLE> <PARA>Pretty easy so far. Now lets add some life to it. The room will need a title and a description. The title should be a one line description of a room sort of like if you were walking someone around your house and telling them what each room was like this is 'My houses big bathroom' or maybe this is 'The computer room'. The description should be something you would tell an interior decorator you were talking to on the phone and asking for advice. He would want to know everything about the room you can see so he could give you good advice.</PARA>

chamber title "The middle chamber of the station" descr "This chamber seems to have the entire station rotating around it. Small human size ornate chairs with dragon designs scrawled on the arms and back are arranged in a triangle like setting with one large chair at the front. This must be where all station meetings are held. large pictures cover the walls depicting dragons in all kinds of situations. Small passages lead of to the west and the east. ." end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>It is a matter of taste if you want the descriptions of the exits in your description or not but I like them so I put them. Now if you were reading this description to someone the person might ask you what is on the pictures or maybe even what exactly do the chairs look like so we better take care of that by adding some extras to our little room.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

extra {"chairs","chair"} "The chairs are made of some metal you don't recognize and every inch is covered with some kind of dragon."

extra {"dragon picture","picture"} "Thousands of dragons dot the skies of this rather life like picture. In the center you see something move. It looks to be a little green dragon."

extra{"green dragon","dragon","green"} "An intelligent looking dragon is sitting perched on a large chair watching you."

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Normally we could put a movement type for the amount of endurance lost when a person is moving through the area but we will leave it blank and go with the default which is SECT_CITY since with the fake gravity that is the closest we could come with the sector types availible. The last thing we need to finish our room is the two exits leading to the other rooms.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

west to portal descr "You see a small room.";

east to office descr "You see what looks to be an office.";

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Thats it that is all there is to making a room. In the next couple of sections we are going to add some more rooms with more advanced features and give some debugging hints for compiling your rooms but if you understand everything so far your going to have no problem. Lets take a look at our entire finished first room</PARA>

chamber title "The middle chamber of the station" descr "This chamber seems to have the entire station rotating around it. Small human size ornate chairs with dragon designs scrawled on the arms and back are arranged in a triangle like setting with one large chair at the front. This must be where all station meetings are held. large pictures cover the walls depicting dragons in all kinds of situations. Small passages lead of to the west and the east. ."

extra {"chairs","chair"} "The chairs are made of some metal you don't recognize and every inch is covered with some kind of dragon."

extra {"dragon picture","picture"} "Thousands of dragons dot the skies of this rather life like picture. In the center you see something move. It looks to be a little green dragon."

extra{"green dragon","dragon","green"} "An intelligent looking dragon is sitting perched on a large chair watching you." west to portal descr "You see a small room.";

east to office descr "You see what looks to be an office."; end

</PROGRAMLISTING></INFORMALEXAMPLE>

</SECT1> <sect1 id="rmdebug"> <TITLE>Compiling and debugging your first room</TITLE> <PARA>It is time we put the zone header information together with your first zone and compile it into a format the <ACRONYM>VME</ACRONYM> server can use. This is done by using the <ACRONYM>VMC</ACRONYM> compiler. Depending on if you are doing this on your own Linux server or if you are building for a <ACRONYM>VME</ACRONYM> already set up you will have to use the compiler access method they have defined. No matter if you are compiling by email, ftp, or at the command line with <ACRONYM>VMC</ACRONYM> the error messages will all be the same. Since I have no idea how your particular set up is designed I will explain the errors that the compiler will return and you will have to ask your system administrator how to access the compiler. The rest of this section is written as if you have your own <ACRONYM>VME</ACRONYM> running on your own Linux box using the <ACRONYM>VMC</ACRONYM> at the command line.</PARA>

<PARA>When you are working on your first zone it is always a good idea to start with one or two rooms and compile them instead of writing all the rooms and then trying to compile. The reason is the more rooms you have the more confused you can make the compiler if you have a lot of errors and you may not be able to figure out where your first mistake was easily. In our case we only have our first room and the header information for the zone so lets put it together now and try and compile it.</PARA>

#include composed.h> %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 whistler@valhalla.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."

%rooms

chamber title "The middle chamber of the station descr "This chamber seems to have the entire station rotating around it. Small human size ornate chairs with dragon designs scrawled on the arms and back are arranged in a triangle like setting with one large chair at the front. This must be where all station meetings are held. large pictures cover the walls depicting dragons in all kinds of situations. Small passages lead of to the west and the east. ."

extra {"chair","chairs"} "The chairs are made of some metal you don't recognize and every inch is covered with some kind of dragon."

extra {"dragon picture","picture"} "Thousands of dragons dot the skies of this rather life like picture. In the center you see something move. It looks to be a little green dragon."

extra{"green dragon","dragon","green"} "An intelligent looking dragon is sitting perched on a large chair watching you." west to portal descr "You see a small room.";

east to office descr "You see what looks to be an office."; end

%end

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>We added the %room tag to our zone header stuck our room in and now its ready to be compiled and put into the <ACRONYM>VME</ACRONYM> server for you to be able to look at it in the game. If you downloaded our example zones for this document you can compile this zone along with us and fix the errors as we do for practice. The filename is debug_rm.zon. Just so you know the errors in this zone are intentional so please don't write me an email telling me there are errors in it.</PARA>

<PARA>The command to compile the zone is <command>VMC debug_rm.zon</command>. Here is what we get when we first try and compile the zone.</PARA>

<ACRONYM>VMC</ACRONYM> v2.0 Copyright (C) 2001 by Valhalla [Apr 28 2001] Compiling 'debug_rm.zon' <debug_rm.zon> @ 2: Bad include argument <debug_rm.zon> @ 48: Token too long Fatal error compiling in preprocessor stage in file 'debug_rm.zon'.

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Don't worry if this looks scary, it really is much easier to read than it looks like. The first thing you need to realize about compiling is always fix one error and compile again because it might fix two or three errors after with one fix. The reason is once a compiler hits something it doesn't understand it gets confused with the rest of the file. It is sort of like if you thought the word 'water' meant 'fire' and you tried to read a book it would get confusing really fast. So you have to correct the definition of 'water' to understand the rest of the book.</PARA>

<PARA>Lets take the first error with this in mind. The first error shows up on line three of the error file it says: </PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

<debug_rm.zon> @ 2: Bad include argument

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>This line is not really cryptic reading it in a more english form would sound like: In file 'debug_rm.zon' you have an error at line 2, the argument to the include statement is not correct. Not all errors will be this clear but the compiler does its best to get you close to the error. Now if you look at line two in debug_rm.zon, you will find, we forgot to put in the '<' symbol. If you fix the line to look like: <INFORMALEXAMPLE><PROGRAMLISTING>

#include <composed.h>

</PROGRAMLISTING></INFORMALEXAMPLE> Then recompile you will have fixed your first error and get a whole new set to play with. The following is the errors we got after fixing line two:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

<ACRONYM>VMC</ACRONYM> v2.0 Copyright (C) 2001 by Valhalla [May 9 2001] Compiling 'debug_rm.zon' <debug_rm.zon> @ 47: EOF in string debug_rm.zon: 4: parse error Token: 'RESET_ANYHOw' debug_rm.zon: 21: parse error Token: 'This' debug_rm.zon: 26: parse error Token: 'and' debug_rm.zon: 26: parse error Token: '.' Grave errors in file 'debug_rm.zon'.

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Now this looks to be a much more interesting error file than the previous one. Remember we mentioned you should always fix the first error first so the compiler doesn't get confused. In this error file the first line is not the first error we need to fix. We have to do some logical reasoning here. The first error the compiler came across was the one on line 4 that shows up around line 4 of the error file. The lines before it are letting you know somewhere else in the file there is a missing quote. If we clean up the first error however we might be able to find this missing quote much easier. So lets do that lets start by looking at line 4 which is saying the compiler doesn't understand what the token 'RESET_ANYHOw' is. This makes sense the token should be 'RESET_ANYHOW' and the compiler is case sensitive. So all we need to do to fix this one is capitalize the 'w' and the error should be cleared up lets try that and recompile and see what the errors look like. With that line fixed the following is the errors we get. </PARA>

<ACRONYM>VMC</ACRONYM> v2.0 Copyright (C) 2001 by Valhalla [May 9 2001] Compiling 'debug_rm.zon' <debug_rm.zon> @ 47: EOF in string debug_rm.zon: 21: parse error Token: 'This' debug_rm.zon: 26: parse error Token: 'and' debug_rm.zon: 26: pars e error Token: '.' Grave errors in file 'debug_rm.zon'.

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Again we must figure out which error message we should deal with first. As before we need to deal with the lowest number error. The error we need to fix first then is the one on line '21'. If you go to line '21' you will notice the line looks fine. When you run into an error like this where the error is not exactly on the line scroll up to the field before the one in question and you should find the problem. In this case we forgot a '"' on the 'title' line and confused the compiler because it thought the ending quote was the one after the 'descr' field. Therefore the compiler didn't understand the 'This' as a field. This is one of the harder errors to find but once you get used to it will come naturally and the compiler does try to get you close. Now if we add the '"' we are missing and recompile the following is the output we get.</PARA>

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Notice there are no errors and it says '<ACRONYM>VMC</ACRONYM> done', this means you have now successfully compiled the zone. I want you to look at the last error file and the fact that we only changed a quote to go from it to no errors. This is why you always deal with one error at a time. Sometimes fixing one error can fix a lot of the weird errors that make no sense. In fact I have seen one quote cause as much as 50 errors so if you jump around trying to fix errors that look like they make sense you may end up making more work for yourself. </PARA>

<PARA>Now that you have a compiled zone you should check and make sure all the files are there. When you compile a zone you will end up with three extra files. the files will have the same filename as your zone with a new extension in this case you should have the following.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

debug_rm.data debug_rm.err debug_rm.reset debug_rm.zon

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>If you have all of these you are all set to go. If not then there is something seriously wrong and you may want to write the <ACRONYM>VME</ACRONYM> staff for help. To get your new zone in the mud all that is needed is to make sure your zone is in the zonelist in the <ACRONYM>VME</ACRONYM> etc directory and copy these files into your zone directory. Then reboot the mud. You should be able to log on your builder character and goto your zone by typing, <command>goto chamber@dragonst</command>.</PARA>

<PARA>There you go you have now compiled your first zone. Its not much to look at but with what you already know you could make a full zone of very basic rooms. The next few sections will teach you some of the more interesting things you can do when making your rooms.</PARA>

</SECT1> <sect1 id="rmdilfunc"> <TITLE><ACRONYM>DIL</ACRONYM> functions for rooms</TITLE>

<PARA>The <ACRONYM>DIL</ACRONYM> language is the language a builder can use to make his own special functions on rooms, NPCs, objects, PCs, and much more. This manual is for basic zone writing and therefore will not go into how to write your own <ACRONYM>DIL</ACRONYM> functions. The <ACRONYM>VME</ACRONYM> however is released with many functions for you as an Administrator and your builders to use to make special rooms, NPCs, and objects. The following is a list of all room functions released with the <ACRONYM>VME</ACRONYM> 2.0 server.</PARA>

<variablelist id="var-roomfunc"> <VARLISTENTRY> ;Death room <DICTDEF> <PARA><indexterm> <primary>Death room function</primary> </indexterm></PARA>

<PARA>This function is a simple function that allows you to create a room to do damage to a player. The death_room can kill them slowly like a fire cave would or it can kill them quickly as if you stuck them in a microwave it is all up to how you set the arguments. It also lets you see the acts the players see so this function can be used on any number of death style rooms. There is no need to understand how the function works just how to use it so with that in mind the following is the functions header.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

//In function.zon dilbegin death_room(tick: integer, damage: integer, act_s: string);

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>As with any function all you have to do is 'dilcopy' the function onto your room with the correct zone name and arguments and it will do the rest. In this <ACRONYM>DIL</ACRONYM> you have three arguments to pass The first is the 'tick' or time which in this <ACRONYM>DIL</ACRONYM> is broken down into 'ticks' which are 4 ticks per second. Thus if you wanted to get something to do damage every minute you would put '60*4' in that spot. The next is the amount of damage you want done per your time. If for example you want '60' hit +points damage done each round you just put '60' as that argument. Finally is the act shown to the character as a string in quotes. So a finished death room on your room would look like this.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy death_room@function(4*60,60, "Flames shoot up from the floor burning your butt.");

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Climb <DICTDEF> <PARA><indexterm> <primary>Climb room function</primary> </indexterm></PARA>

<PARA> This special <ACRONYM>DIL</ACRONYM> is used for the climb skill and should be set on stationary objects (stationary mast, robe, tree, wall, etc). The 'difficulty' is the skill-amount required to climb. A skill of 100 would be a 50% chance for the expert thief / climber. The 'damage' is how much damage is given if you fail to climb the object. When you fail, you "fall" to the 'destination', so you can make gravity work correctly. The destination can be the same room in which you started but it doesn't have to be. The 'direction' is the direction in which you want the person to have to climb enclosed in quotes.</PARA>

<PARA>With all this in mind the following is the <ACRONYM>DIL</ACRONYM> definition and an example use of it.</PARA>

//<ACRONYM>DIL</ACRONYM> definition dilbegin climb(destination:string, difficulty:integer, damage:integer,direction:integer);

//Example use of Climb dilcopy climb@function("deck@ship", 17, 20, "up");

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>We should note here, if you wanted the person to have to climb back down you will need to put a climb <ACRONYM>DIL</ACRONYM> on the room you are climbing too that has the "down" directory as an argument. This <ACRONYM>DIL</ACRONYM> also allows you to link two rooms not linked by normal directions but we suggest you should think before doing this because it may not make sense to not have a link between the two places.</PARA> </LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY> ;Force move <DICTDEF> <PARA><indexterm> <primary>Force move room function</primary> </indexterm></PARA>

<PARA>This function allows you to move a player or NPC from a room to another room with out having the player or NPC type or do anything.</PARA>

<PARA>The following is the definition of the force move <ACRONYM>DIL</ACRONYM></PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin force_move (tick: integer, strings: string, random: integer);

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>The 'tick' parameter is how fast you want the force move to be triggered. The 'tick' is in 1/4 second increments so to get a one second wait you would place a four. The second parameter is two strings the first being the symbolic name of the room you are forcing the character to. The second string is the act you want shown to the player or NPC when it is moved. The final parameter is either a one or a zero. The one stands for true and it would make the timer trigger randomly fifty percent of the time, while a zero would make it not random.</PARA>

<PARA>The following is what the force move would look like if you wanted it to trigger every 30 seconds and give acts of a river.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy force_move@function(4*30,{"river2@riverzon","You float down the river."},0);

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Safe room <DICTDEF> <PARA><indexterm> <primary>Safe room function</primary> </indexterm></PARA>

<PARA>This function creates a safe room where combat is not allowed. The following is the definition and an example of how to use it.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

//Safe room <ACRONYM>DIL</ACRONYM> definition dilbegin safe_room ();

//Example use of Safe room dilcopy safe_room@function ();

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

</sect1>

<sect1 id="rmcomplex"> <TITLE>A more complex set of rooms</TITLE>

<PARA>In the last section you learned to make basic rooms. In this section we will build on what you already know to allow you to make much more fancy rooms. IN this section we will give a much better view of the exits and what can be done with them including doors, hidden doors and rooms inside other rooms. We will also show some examples of the room <ACRONYM>DIL</ACRONYM> functions being used that were described in the previous section. Finally we will pull it all together in a completed zone for you to compile and play with. </PARA>

<sect2 id="rmdoorexits"> <TITLE>Exits with doors</TITLE>

<PARA>When we first defined exits we included the 'keyword' and 'open' fields on a door. In this section we will give an example of two rooms linked together with a door. There is no new information you have not already encountered so we will start with an example.</PARA>

hallway title "Module tunnel" descr "The hallway is about 50 meters long and around 100 meters from side to side and top to bottom...."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to chamber descr "The hallway opens up into a chamber.";

east to office descr "You see what looks to be an office." keyword {"air lock door","air lock","door"} open {EX_OPEN_CLOSE, EX_CLOSED};

end

office title "The station office" descr "Large paintings fill the walls of this part of the station...."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to hallway descr "You see what looks to be a hallway." keyword {"air lock door","air lock","door"} open {EX_OPEN_CLOSE, EX_CLOSED}; end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>One important thing you should notice is, whatever you put as a keyword, along with the direction, is what a person must use to open the door. To make sure the door closes at reset time you will have to add the doors reset to the '%reset' section. The door resets will be explained in <xref LINKEND="ch-07">. Notice also in this example we have a direction both in the room you are going to and the room you came from. This means you need a 'west' direction for every 'east' direction leading to it. If you do not put both you will end up with a one way direction.</PARA>

</sect2>

<sect2> <TITLE>Locked exits</TITLE> <PARA>Now that you have making a door down, you may find that it is not safe to leave your doors unlocked. Well the <ACRONYM>VME</ACRONYM> is ready for you. You have already seen the 'keyword' and 'open' sections and what you can set in them. Now lets use the 'EX_LOCKED field with them and introduce a new macro to allow you to set the difficulty to unlock the lock with out a key.</PARA>

<PARA>First lets look at the macro that allows you to set a difficulty on a lock. If you set the lock with out this macro it will default to 0 and thus be easy to pick.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define DOOR_LOCK_DEF(north_lock, east_lock, south_lock, west_lock,\ up_lock, down_lock, northeast_lock, northwest_lock, southeast_lock,\ southwest_lock)

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>When using this macro you only set the value of the exit you want to add the difficulty to, you can leave the rest of the exits '0'. Only one of these macros are needed on a room no matter how many exits because each of the exits are included.. If you have an exit to the north that is locked and you want it to have a difficulty of 50% the following would be the line you would add to your room</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

DOOR_LOCK_DEF(50, 0, 0, 0, 0, 0, 0, 0, 0, 0)

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Now lets add the macro and the locked flag to the exits and create the room.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

hallway title "Module tunnel" descr "The hallway is about 50 meters long and around 100 meters from side to side and top to bottom...."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to chamber descr "The hallway opens up into a chamber.";

DOOR_LOCK_DEF(0, 50, 0, 0, 0, 0, 0, 0, 0, 0) east to office descr "You see what looks to be an office." keyword {"air lock door","air lock","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED};

end

office title "The station office" descr "Large paintings fill the walls of this part of the station...."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

DOOR_LOCK_DEF(0, 0, 0, 50, 0, 0, 0, 0, 0, 0) west to hallway descr "You see what looks to be a hallway." keyword {"air lock door","air lock","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED}; end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>The only thing you may be wondering about in this example is the 'key' field. I have picked 'nokey' as my value of the key. There is no key in this zone so all this does is create a key hole. If you leave the 'key' field out totally the only way you can open the lock is by a magical spell. It is also important that you read about resets of door locks in <xref LINKEND="ch-07">.</PARA> </sect2>

<sect2> <TITLE>Hidden exits</TITLE>

<PARA>Locking the doors may not be enough. In fact sometimes you may not want to lock the door but you might want to hide it. You can do both or either with the following macro added to your exit.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define SECRET_DOOR_DIFFICULTY(DIR, SKILL) \ extra{SECRET_DOOR} {DIR, SKILL}\ ""

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>So if you wanted a door or just a passage to the north hidden you would add this before or after your exits.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

SECRET_DOOR_DIFFICULTY(NORTH, 50)

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Now lets put it all together and link two rooms together with a hidden door.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

office title "The station office" descr "Large paintings fill the walls of this part of the station..."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to hallway descr "You see what looks to be a hallway." keyword {"air lock door","air lock","door"} open {EX_OPEN_CLOSE, EX_CLOSED};

SECRET_DOOR_DIFFICULTY(SOUTH, 50) south to portal_room descr "You see what looks to be a portal room." keyword {"air lock door","air lock","staff","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED,EX_HIDDEN};

end

portal_room title "Green field room" descr "Like the other rooms on the station this one is large enough for dragons to comfortably fit in. The strange thing about this room though is it is totally empty except for a green field right in the center. there is a door that leads to another room to the north."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

north to office descr "You see what looks to be an office." keyword {"air lock door","air lock","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED};

end

</PROGRAMLISTING></INFORMALEXAMPLE>

</sect2>

<sect2> <TITLE>Rooms inside of rooms</TITLE> <PARA>Now that you have normal exits down its time to take a look at something a bit different. Lets say you wanted to put a barrel in a room that is also a room that has exits to other rooms. Or maybe in my case I want to put a transporter pad in the room that is also a room so you can exit back into the room you came from. In the case of the teleporter I could use an object but as you will find it is much easier to deal with a room for this than an object.</PARA>

<PARA>To put a room in a room it is much different than using the normal exit fields. The only thing needed is the 'in' keyword and the room you are linking the current room into. There is no need for a semi-colon. The following is what the line would look like.</PARA>

in <room that room is in>

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Not too hard. The following are two rooms one in the other.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

portal_room title "Green field room" descr "Like the other rooms on the station this one is large enough for dragons to comfortably fit in. The strange thing about this room though is it is totally empty except for a green field right in the center. there is a door that leads to another room to the north."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"green field","field"} "The field looks to be a green fog shifting and churning as you watch. if you are nuts you could probably enter it."

north to office descr "You see what looks to be an office." keyword {"air lock door","air lock","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED};

//A link to the portal is also here end

room_port names{"green field", "field"} title "Green field" descr "Green Mist swirls about you."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in portal_room end

</PROGRAMLISTING></INFORMALEXAMPLE>

<NOTE> <PARA>After adding a room in a room you should note the room in the description or put an 'outside_descr' on the room inside it. In our example we have chosen to add the description into the room instead of using the 'outside_descr'. Also doors and locks work the same way as before you can even hide this exit. </PARA></NOTE>

</sect2>

<sect2> <TITLE>A room using force move.</TITLE>

<PARA>Sometimes you will want to help players along their path. This could be for a river that flows strongly enough to force a players raft down stream or maybe for a room of quick sand that sucks the player into another room. In these situations we need to use the force move <ACRONYM>DIL</ACRONYM>, explained in the previous section. Here we have built two rooms linked only by a forced move. </PARA>

portal_room title "Green field room" descr "Like the other rooms on the station this one is large enough for dragons to comfortably fit in. The strange thing about this room though is it is totally empty except for a green field right in the center. there is a door that leads to another room to the north."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"green field","field"} "The field looks to be a green fog shifting and churning as you watch. if you are nuts you could probably enter it."

north to office descr "You see what looks to be an office." keyword {"air lock door","air lock","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED};

//A link to the portal is also here

end ship_port names{"green field", "field"} title "Green field" descr "Green Mist swirls about you."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in ship

dilcopy force_move@function( //Time to activation 4, //room and act "portal_room@dragonst!You feel your body dissolving for lack of a better description.&nYou appear on the deck of a ship.", //True or False for randomizing or not FALSE);

end

</PROGRAMLISTING></INFORMALEXAMPLE> </sect2

<sect2> <TITLE>A death room</TITLE>

<PARA>As a final touch to my little example zone I want to create a room that will kill a player instantly. I will use the <ACRONYM>DIL</ACRONYM> function Death room and the room would simply look as follows.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

deathspace title"Open space" descr "You see the ship and the station far off in the distance and you are in Space!"

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

dilcopy death_room@function ( //how often is damage done 4 would be 1 second 4, //damage 400, //act for the damage. "You realize to late that was the trash disposal transporter and you feel your lungs explode.");

end

</PROGRAMLISTING></INFORMALEXAMPLE>

</SECT2> </sect1>

<sect1> <TITLE>Putting the rooms together</TITLE>

<PARA>Using all you have learned so far and putting it all together into one zone. You end up with a very interesting space station with some secret rooms and traps.. The full zone all together looks like this.</PARA>

#include <composed.h> %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 whistler@valhalla.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."

%rooms

chamber title "The middle chamber of the station" descr "This chamber seems to have the entire station rotating around it. It is unbelievably large the ceiling seems to be a good 200 meeters high and the room is perfectly cubic. Small human size ornate chairs with dragon designs scrawled on the arms and back are arranged in a triangle like setting with one large chair at the front. This must be where all station meetings are held. large pictures cover the walls depicting dragons in all kinds of situations. large passages lead of to the west and the east.."

extra {"chair","chairs"} "The chairs are made of some metal you don't recognize and every inch is covered with some kind of dragon."

extra {"dragon picture","picture"} "Thousands of dragons dot the skies of this rather life like picture. In the center you see something move. It looks to be a little green dragon."

extra{"green dragon","dragon","green"} "An intellegence looking dragon is sitting perched on a large chair watching you."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to disposal_room descr "You see a small room.";

east to hallway descr "You see what looks to be a hallway.";

end

hallway title "Module tunnel" descr "The hallway is about 50 meters long and around 100 meters from side to side and top to bottom. The hallway seems to be dust free. The walls and the floors seem to be made out of the same sterile metal-plastic that all space agencies uses. There are large plate glass windows that open up into space. The hallway is filled with a dim light that seems to come from everywhere yet no where all at once. You notice a glimmer of bright light coming from the windows. To the east you see an air lock and to the west the hallway opens up into a larger room."

extra {"windows","window"} "Your eyes are drawn to a large ship lit up with running lights sitting about 1 kilometer from the station."

extra{"floor","walls","wall"} "Well what can be said it looks to be in perfect condition. what else would you want to know?"

extra {"large ship" ,"ship"} "The ship looks really big and is shaped like a dragon. The scales sparkle and seem to be multiple colors."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to chamber descr "The hallway opens up into a chamber.";

east to office descr "You see what looks to be an office." keyword {"air lock door","air lock","door"} open {EX_OPEN_CLOSE, EX_CLOSED};

end

office title "The station office" descr "Large paintings fill the walls of this part of the station. The room is as large as the other rooms big enough for Dragons to lounge while still having a desk in one corner small enough for a humanoid. The floor along the north wall is lined with some kind of fabric and seems very soft to walk on, it may be some kind of dragon lounge judging by how large an area it covers. There is a passage to the west."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"paintings","painting"} "The paintings are of many dragons and riders in all kinds of tasks from combat to look out. All the figures seem to be staring at a staff being held by a depiction of a wizard on the south wall."

extra {"wizard","staff"} "The wizard has his hand stretched out and it seems there is a place you can almost grab the staff. Maybe if you searched the staff you would find it."

extra {"desk"} "Its a desk alright but there doesn't seem to be any drawers and it seems totally empty."

extra{"fabric"} "Wussshhhhh you bound across the comfortable floor wasn't that fun."

west to hallway descr "You see what looks to be a hallway." keyword {"air lock door","air lock","door"} open {EX_OPEN_CLOSE, EX_CLOSED};

SECRET_DOOR_DIFFICULTY(SOUTH, 50) south to portal_room descr "You see what looks to be a portal room." keyword {"air lock door","air lock","staff","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED,EX_HIDDEN};

end

portal_room title "Green field room" descr "Like the other rooms on the station this one is large enough for dragons to comfortably fit in. The strange thing about this room though is it is totally empty except for a green field right in the center. there is a door that leads to another room to the north."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"green field","field"} "The field looks to be a green fog shifting and churning as you watch. if you are nuts you could probably enter it."

north to office descr "You see what looks to be an office." keyword {"air lock door","air lock","door"} key nokey open {EX_OPEN_CLOSE, EX_CLOSED,EX_LOCKED};

//A link to the portal is also here from room_port end

ship_port names{"green field", "field"} title "Green field" descr "Green Mist swirls about you."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in ship

dilcopy force_move@function( //Time to activation 4, //room and act "portal_room@dragonst!You feel your body dissolving for lack of a better description.&nYou appear on the deck of a ship.", //True or False for randomizing or not FALSE);

end

room_port names{"green field", "field"} title "Green field" descr "Green Mist swirls about you." movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

in portal_room

dilcopy force_move@function( //Time to activation 4, //room and act "ship@dragonst!You feel your body dissolving for lack of a better description.&nYou appear on the deck of a ship.", //True or False for randomizing or not FALSE);

end

disposal_room title "Red field room" descr "Like the other rooms on the station this one is large enough for dragons to comfortably fit in. The strange thing about this room though is it is totally empty except for a red field right in the center. there is a door that leads to another room to the east."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"red field","field"} "The field looks to be a red fog shifting and churning as you watch. if you are nuts you could probably enter it."

east to chamber descr "You see the main chamber.";

//A link to the portal is also here from dis_port end

dis_port names {"red field","field"} title "Red field" descr "Red Mist swirls about you."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS} dilcopy force_move@function( //how fast to force move in seconds 4, //room to force move to and act "deathspace@dragonst!You feel your body dissolving for lack of a better description.", //true or false random move or not 0); in disposal_room

end

ship title "War dragon" descr "Blue light softly glows from con duets that line the walls of this ship. The floors beside the east and west wall have what looks to be soft fabric covering. The south wall has small controls that seem to be made for humanoids with two small chairs that look to be pilot seats. view portals are about 50 meters up the side of the ship on the west and east wall and some kind of electronic screen covers the south wall. The ship seems to be a one room ship but there is a green field by the north wall."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

extra {"view port"} "Sorry your not 50 meters tall maybe it is made for a dragon?"

extra {"view screen","screen"} "It seems to be the pilots view screen but you can't seem to see a way to turn it on."

extra {"controls","control"} "The controls are in some weird language and your afraid if you start pushing buttons you might rocket in to the station or worse slam into a planet."

extra {"soft fabric","fabric"} "It looks to be a dragon lounge area."

//A link to the portal is also here from ship_port end

deathspace title"Open space" descr "You see the ship and the station far off in the distance and you are in Space!"

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

dilcopy death_room@function ( //how often is damage done 4 would be 1 second 4, //damage 400, //act for the damage. "You realize to late that was the trash disposal transporter and you feel your lungs explode.");

end

%end

</PROGRAMLISTING></INFORMALEXAMPLE> </sect1> <sect1 id="rmexer"> <TITLE>Suggested room exercises</TITLE>

<orderedlist> <LISTITEM> <PARA>Create a door between the Disposal room and the main chamber of the station. Make the new door pick-proof and magic-proof.</PARA> </LISTITEM> <LISTITEM> <PARA>Create another hallway to the south of the main chamber that leads to a ship attached by an airlock. You will need a door before the hallway and before the ship so no one gets sucked out in space. You will need two more rooms for this one for the hallway and one for the ship. </PARA> </LISTITEM> <LISTITEM> <PARA>Using the Dragon station zone as a guide create your own zone with eight rooms. Don't worry to much about descriptions and extras. Link all eight of the rooms to each of the other rooms. This means each room should have seven exits. If you were to map this it would look like a cube marked with 'X' on the sides.</PARA> </LISTITEM> <LISTITEM> <PARA>Make a 3 room cliff that uses the climb <ACRONYM>DIL</ACRONYM> function to climb from the bottom to top. </PARA> </LISTITEM> </orderedlist>

</SECT1>

</chapter>

<chapter ID="ch-05"><?dbhtml filename="ch05.html"> <TITLE>The NPC section</TITLE>

<PARA>Now that you have rooms down it is time to start filling your area with some life. The NPC is the Non-player Character or mobile. These are the things players will hunt and interact with</PARA>

<PARA>In order to get started building NPCs you should first be aware of the NPC fields you can use. The <xref linkend="npcfields"> shows a full listing of all the NPC fields and their types as defined in <xref linkend="ch-03">.</PARA>

<TITLE>NPC fields and types</TITLE> <TGROUP align=left cols=5 colsep=1> <COLSPEC COLNAME="c1" COLWIDTH="2in"> <COLSPEC COLNAME="c2" COLWIDTH="2in"> <COLSPEC COLNAME="c3" COLWIDTH=".5in"> <COLSPEC COLNAME="c4" COLWIDTH="2in"> <COLSPEC COLNAME="c5" COLWIDTH="2in"> <THEAD> <ROW> <ENTRY COLNAME="c1">Field</ENTRY> <ENTRY COLNAME="c2">Type</ENTRY> <ENTRY COLNAME="c4">Field</ENTRY> <ENTRY COLNAME="c5">Type</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY COLNAME="c1">Symbolic name</ENTRY> <ENTRY COLNAME="c2">Symbol</ENTRY> <ENTRY morerows=17 colname="c3"></ENTRY> <ENTRY COLNAME="c4">level</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">names</ENTRY> <ENTRY COLNAME="c2">Stringlist</ENTRY> <ENTRY COLNAME="c4">height</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">title</ENTRY> <ENTRY COLNAME="c2">String</ENTRY> <ENTRY COLNAME="c4">race</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">descr</ENTRY> <ENTRY COLNAME="c2">String</ENTRY> <ENTRY COLNAME="c4">attack</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">inside_descr</ENTRY> <ENTRY COLNAME="c2">String</ENTRY> <ENTRY COLNAME="c4">armour</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">extra</ENTRY> <ENTRY COLNAME="c2">Structure</ENTRY> <ENTRY COLNAME="c4">speed</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">manipulate</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">position</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">flags</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">default</ENTRY> <ENTRY COLNAME="c5"> Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">weight</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">ability</ENTRY> <ENTRY COLNAME="c5">two Integers</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">capacity</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">weapon</ENTRY> <ENTRY COLNAME="c5">two Integers</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">dilbegin or dilcopy</ENTRY> <ENTRY COLNAME="c2">Function pointer</ENTRY> <ENTRY COLNAME="c4">spell</ENTRY> <ENTRY COLNAME="c5">two Integers</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">defensive</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">romflags</ENTRY> <ENTRY COLNAME="c5"> Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">offensive</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">light</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">mana</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">alignment</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">hit</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">minv</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">money</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">key</ENTRY> <ENTRY COLNAME="c5">String</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">exp</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">open</ENTRY> <ENTRY COLNAME="c5">Integer</ENTRY> </ROW> <ROW> <ENTRY COLNAME="c1">sex</ENTRY> <ENTRY COLNAME="c2">Integer</ENTRY> <ENTRY COLNAME="c4">end tag</ENTRY> <ENTRY COLNAME="c5">Symbol</ENTRY> </ROW> </TBODY></TGROUP>

<PARA>Many of the same fields you found in rooms, as you can see from <xref linkend="npcfields">, can also be found in NPCs. The fields do not always have exactly the same use when coding rooms, NPCs, and objects but they are normally set in the same manor. It is very important that you read and understand the differences of each field as they pertains to rooms and or NPCs.</PARA>

<sect1 id="npcfielddescr"> <TITLE>Description of NPC fields</TITLE>

<variablelist id="var-npcfields"> <VARLISTENTRY> ;symbolic name <DICTDEF> <PARA><indexterm> <primary>NPC symbol</primary> </indexterm>

The rules of the symbols has been explained in <XREF LINKEND="ch-03">, if you didn't read them yet you may want to review. The important thing to realize with the NPC symbol is it is always good practice to give the NPC a symbol that resembles the title so that administrators and builders can use the <command>load</command> and the <command>wstat</command> to easily locate, examine, and load the NPC in question. </PARA></LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;title <DICTDEF> <PARA><indexterm> <primary>NPC title</primary> </indexterm> The NPC title is what is shown if the NPC is being attacked or talking. It is also what is shown if the NPC can be picked up. there should be no punctuation in the NPC title because of how it is used in the <ACRONYM>VME</ACRONYM> server. If you add punctuation or forget to capitalize something that the <ACRONYM>VMC</ACRONYM> thinks you should it will give you a warning when you compile.</PARA>

title "a small dog" title "Hansen" title "a black dragon" title "Drako" title "an elephant"

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <TERM>descr</term> <LISTITEM> <PARA><indexterm> <primary>NPC description</primary> </indexterm>

The description field is what the player sees when walking into the room or when looking with no arguments. The description on a NPC will only show up when the NPC is in the standing position. All other positions will show the title and the position they are in. </PARA>

descr "a small fluffy dog is chasing its tail here." descr "Hansen is standing here sorting the mail."

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY> <VARLISTENTRY>

;names <DICTDEF> <PARA><indexterm> <primary>NPC names</primary> </indexterm>

The NPC name field is much more important then the room name field. It is what is used when players are hunting and killing and even for administrators who are trying to use their administrator commands on a NPC. The names should match the title and the descr fields and have all normal combinations of each.</PARA>

title "a baby black dragon" descr "a tiny baby black dragon is here playing." names {"tiny baby black dragon", "tiny black dragon", "baby black dragon", "black dragon", "tiny dragon", "baby dragon","dragon"}

title "Hansen" descr "Hansen the post man is standing here sorting mail." names{"postman","hansen"}

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>The idea of course is to make any combination that a player may type to try and act upon your NPC. You would not want to describe and title your NPC with an entirely different theme than you created its names with because a player would not know what it is called.</PARA></LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;inside_descr <DICTDEF> <PARA><indexterm> <primary>NPC inside_descr</primary> </indexterm></PARA>

<PARA>The inside description is what a player sees if it is inside the NPC. This could be used to show the player its stomach or if on a mount it could be used to show the back of the horse.</PARA>

inside_descr "The lining of this stomach looks indestructible. Looks like you are in for a long digestion cycle."

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;extra <DICTDEF> <PARA><indexterm> <primary>NPC extra</primary> </indexterm></PARA>

<PARA>The extra's on the NPC can be used to do many things. It can be used to store information for <ACRONYM>DIL</ACRONYM> programs or it can be used to show a part of the NPC like the room extras show a part of the room. There is also a special extra, the NPCs description when you look at it with the look <NPC> command.</PARA>

<PARA>Lets show the NPC description extra first. If you use an extra with no names list it will become the NPCs description when you look at any of the names on the NPC.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

extra {} "The green furry hamster seems to be glowing and it doesn't seem very happy."

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>You can also use extras to show parts of the NPC.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

extra {"hamster head","head"} "This human like head is covered with a lot of green fur and it looks really upset."

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>You can also use the extras to give more detailed and vivid descriptions when the NPC is acted upon.</PARA>

<TITLE>NPC special action extras</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>Extra</ENTRY> <ENTRY>Description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>$get_s</ENTRY> <ENTRY>A message shown to activator when getting a NPC.</ENTRY> </ROW> <ROW> <ENTRY>$get_o</ENTRY> <ENTRY>A message shown to others when getting a NPC.</ENTRY> </ROW> <ROW> <ENTRY>$drop_s</ENTRY> <ENTRY>a message shown to activator when dropping a NPC.</ENTRY> </ROW> <ROW> <ENTRY>$drop_o</ENTRY> <ENTRY>A message shown to others when dropping an NPC.</ENTRY> </ROW> <ROW> <ENTRY>$enter_s</ENTRY> <ENTRY>A message shown to activator When mounting</ENTRY> </ROW> <ROW> <ENTRY>$enter_o</ENTRY> <ENTRY>A message shown to others when mounting.</ENTRY> </ROW> <ROW> <ENTRY>$exit_s</ENTRY> <ENTRY>A message shown to others when dismounting</ENTRY> </ROW> <ROW> <ENTRY>$exit_o</ENTRY> <ENTRY>a message shown to others when dismounting</ENTRY> </ROW> </TBODY></TGROUP>

<PARA> In the following example, $1n is the activator and $2n is the unit in question. Assume you are defining a familiar.</PARA>

extra {"$get_s"} "You pick up the $2n it is very warm and cuddles right up to you."

extra {"$get_o"} "$1n picks up the $2n and you see them cuddle together."

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Finally you can use extras to store information for <ACRONYM>DIL</ACRONYM> programs. We will not cover this because it is a topic covered in-depth in the <ACRONYM>DIL</ACRONYM> documentation.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;manipulate <DICTDEF> <PARA><indexterm> <primary>NPC manipulate</primary> </indexterm></PARA> <PARA>The manipulate filed only has two values for NPCs The two values are 'MANIPULATE_TAKE' and 'MANIPULATE_ENTER'. The 'MANIPULATE_TAKE' makes it possible for a NPC to be picked up this would be good for something like a familiar. The 'MANIPULATE_ENTER' is used for things like mounts when making a mount you will also have to set the capacity so a fat player can jump on. The following is how you set the manipulate flag.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

//Make a NPC takable. manipulate {MANIPULATE_TAKE}

//Make a NPC takable and able to be entered manipulate {MANIPULATE_TAKE|MANIPULATE_ENTER}

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;flags <DICTDEF> <PARA><indexterm> <primary>NPC flags</primary> </indexterm></PARA>

<PARA>This field on a NPC is used to set special attributes in order to make the NPC able to be buried or not or no-teleportable and many others. The NPC flag list uses the UNIT_FL_* variables that both the objects and the rooms also use, therefore while you can set some flags on an NPC it may not have any affect unless you as a builder or administrator adds the functionality. You can also add extras on an NPC that can be used as a special flag which you will learn as you learn to use <ACRONYM>DIL</ACRONYM>. The following is a full list of all unit flags and how they affect NPC, if they do.

<TITLE>NPC unit flag affects</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>Flag</ENTRY> <ENTRY>Description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>UNIT_FL_PRIVATE</ENTRY> <ENTRY> Currently has no affect on a NPC. </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_INVISIBLE</ENTRY> <ENTRY>Makes unit invisible</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_BURY</ENTRY> <ENTRY>Makes it so you can create NPC that can be taken like familiars or pets that can not be buried. This flag is not needed on every NPC because the bury command will not allow you to bury an NPC outside of your inventory. </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_BURIED</ENTRY> <ENTRY>Makes unit buried when loaded</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_TELEPORT</ENTRY> <ENTRY> Makes it so you can not summon the NPC with this flag and the NPC with this flag can not teleport. You can still teleport to NPC with this flag the current way teleport is written. Remember all spells are in <ACRONYM>DIL</ACRONYM> and you can modify them in spells.zon </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_MOB</ENTRY> <ENTRY> Currently has no affect on a NPC. </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_WEATHER</ENTRY> <ENTRY> Currently has no affect on a NPC. </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_INDOORS</ENTRY> <ENTRY> Currently has no affect on NPC. </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_TRANS</ENTRY> <ENTRY>Makes unit transparent If the Unit is transparent you will be able to see any other NPCs that it is carrying. For example if a NPC was carrying a familiar you would see that as you walked into the room. It also is used in mounts so the PC can see outside its mount. If the flag is not set on its mount the player will not see what is in the room. </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_NO_SAVE</ENTRY> <ENTRY>Makes it so a PC can't save with unit</ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_SACRED</ENTRY> <ENTRY> Currently has no affect on a NPC. </ENTRY> </ROW> <ROW> <ENTRY>UNIT_FL_MAGIC</ENTRY> <ENTRY> Currently has no affect on a NPC. </ENTRY> </ROW> </TBODY></TGROUP>

</PARA>

<PARA>If you wanted to make a NPC that a player can carry around but can not save you would set the manipulate and flags as follows.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

manipulate {MANIPULATE_TAKE} flags {UNIT_FL_NO_SAVE}

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;romflags <DICTDEF> <PARA><indexterm> <primary>NPC romflags</primary> </indexterm></PARA>

<PARA>Like flags these are just integer values that are used to change how the NPC interacts with its environment.</PARA>

<TITLE>Room flags for NPCs</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>Flag</ENTRY> <ENTRY>Description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>CHAR_PROTECTED</ENTRY> <ENTRY> Set this flag if the character is protected by the law-system. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_LEGAL_TARGET</ENTRY> <ENTRY> This flag is used by the law system and should not be set unless you are re-writing your law system. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_OUTLAW</ENTRY> <ENTRY> This flag is used by the law system and should not be set unless you are re-writing your law system. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_GROUP</ENTRY> <ENTRY> This is used by the follow and group commands and should not be set unless you are re-writing your, movement, status, and combat systems. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_BLIND</ENTRY> <ENTRY> Set this if the character is blinded. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_HIDE</ENTRY> <ENTRY> Set flag if character is hidden. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_MUTE</ENTRY> <ENTRY> Set flag if character is mute. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_SNEAK</ENTRY> <ENTRY> Set flag if character is in sneaking mode. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_DETECT_ALIGN</ENTRY> <ENTRY> No actual effect on NPCs. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_DETECT_INVISIBLE</ENTRY> <ENTRY> Set flag if character can see invisible units. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_DETECT_MAGIC</ENTRY> <ENTRY> No actual effect on NPCs. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_DETECT_POISON</ENTRY> <ENTRY> No actual effect on NPCs. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_DETECT_UNDEAD</ENTRY> <ENTRY> No actual effect on NPCs. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_DETECT_CURSE</ENTRY> <ENTRY> No actual effect on NPCs. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_DETECT_LIFE</ENTRY> <ENTRY> No actual effect on NPCs. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_WIMPY</ENTRY> <ENTRY> Set flag if character if wimpy. Wimpy characters flee when they are low on hit points, and they gain less experience when killing others. If a character is both wimpy and aggressive (NPC_AGGRESSIVE) it will only attack sleeping players. </ENTRY> </ROW> <ROW> <ENTRY>CHAR_SELF_DEFENCE</ENTRY> <ENTRY> This is an internal combat flag set this only if you create your own combat system. </ENTRY> </ROW> </TBODY></TGROUP>

<PARA>These flags are set in the same way as other flags in rooms NPCs and objects. The following are a few examples. <INFORMALEXAMPLE><PROGRAMLISTING>

//wimpy and hidden romflags {CHAR_HIDDEN, CHAR_WIMPY}

//NPC can see invisible romflags {CHAR_DETECT_INVISIBLE}

</PROGRAMLISTING></INFORMALEXAMPLE></PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;weight <DICTDEF> <PARA><indexterm> <primary>NPC weight</primary> </indexterm></PARA>

<PARA>The weight is the weight of the NPC in pounds. In the future we may adjust this to allow you to make things lighter for example you could set it in ounces or grams. Right now however all we have is pounds so we have some pretty heavy feathers out there.</PARA>

<PARA>To use this you just enter the 'weight' keyword and then the value.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

/80 lbs. weight 80

</PROGRAMLISTING></INFORMALEXAMPLE>

<NOTE><PARA>The weight affects the NPCs natural attack damage.</PARA> </NOTE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;capacity <DICTDEF> <PARA><indexterm> <primary>NPC capacity</primary> </indexterm></PARA>

<PARA>This field along with the NPCs strength and dexterity decides how much a NPC can carry. If you set the capacity to 300 lbs. the NPC will only be able to carry that much depending if it has the strength and dexterity to carry that much. This of course doesn't affect <ACRONYM>DIL</ACRONYM> programs that link the objects directly into the NPC. To set the capacity you just put the keyword and the amount in your NPC.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

capacity 300

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;height <DICTDEF> <PARA><indexterm> <primary>NPC height</primary> </indexterm></PARA>

<PARA>The height field is the size of the NPC in centimeters. This determines the size of the equipment the NPC is wearing. You will learn more about size and height in the object section but for now just understand this makes your NPC the right or wrong size. To set the 'height' you just put the 'height' keyword followed by the number of centimeters.</PARA>

//6 feet tall since 1 inch equals 2.54 height 183

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;dilbegin or dilcopy <DICTDEF> <PARA><indexterm> <primary>NPC dilbegin or dilcopy</primary> </indexterm></PARA>

<PARA>The <ACRONYM>DIL</ACRONYM> functions are what give <ACRONYM>VME</ACRONYM> servers the edge over all other muds. We will only give some examples here and leave it up to the <ACRONYM>DIL</ACRONYM> manual to teach you how to create your own functions that will make your rooms, NPC, and objects more than special.</PARA>

<PARA>There are several NPC functions that come standard with the <ACRONYM>VME</ACRONYM> 2.0. The following is a list of the functions.</PARA>

<itemizedlist> <LISTITEM><PARA>Mercenary</PARA></LISTITEM> <LISTITEM><PARA>obey</PARA></LISTITEM> <LISTITEM><PARA>evaluate</PARA></LISTITEM> <LISTITEM><PARA>guard direction</PARA></LISTITEM> <LISTITEM><PARA>shop keeper</PARA></LISTITEM> <LISTITEM><PARA>combat magic</PARA></LISTITEM> <LISTITEM><PARA>fido</PARA></LISTITEM> <LISTITEM><PARA>zone wander</PARA></LISTITEM> <LISTITEM><PARA>global wander</PARA></LISTITEM> <LISTITEM><PARA>team work</PARA></LISTITEM> <LISTITEM><PARA>rescue</PARA></LISTITEM> <LISTITEM><PARA>agressive</PARA></LISTITEM> </itemizedlist>

<PARA>These are the only NPC functions currently documented in the <ACRONYM>VME</ACRONYM> 2.0 release but if you go through the zones that are released with the <ACRONYM>VME</ACRONYM> you are sure to find many more. Hopefully with the descriptions in <XREF LINKEND="npcdilfunc">. You will be able to use the functions listed here and figure out ones that are not.</PARA>

<PARA>Since these are just <ACRONYM>DIL</ACRONYM>'s written by builders for the Valhalla mud all you have to do is use the dilcopy keyword in the NPC with the function name you want to use and the arguments that function require. The following is what you would find in the function.zon for evaluate.</PARA>

/* Evaluate <ACRONYM>DIL</ACRONYM>. amt is the cost of evaluation in iron pieces. Note: not to be confused with <function>evaluate@commands</function>, which is a command. */ dilbegin aware evaluate (amt: integer);

var u1 : unitptr; arg: string; buf: string; cur: integer; craft: integer; category: integer;

pc : unitptr; pcn: string;

arm_text : stringlist; shi_text : stringlist; craft_text: stringlist; code {

craft_text:= {"horrible","very bad","bad","worse than average","average", "a little better than average","better than average","good","very good", "supreme"}; arm_text:= {"clothes", "leather", "hard leather", "chain", "plate"}; shi_text:= {"small", "medium", "large"};

heartbeat:= PULSE_SEC*3;

:start: arg:= ""; u1:= null;

wait (SFB_CMD, command("evaluate"));

if (visible(pc, self) == FALSE) goto start; // Pc is just trying to evaluate using the command

block;

pc:= activator; if (pc.type == UNIT_ST_PC) pcn := pc.name; else pcn := pc.title;

arg:= argument;

if (visible(self, pc) == FALSE) { exec ("say I don't do business with people I can't see.", self); goto start; }

if (arg == "") { exec ("say Which item do you wish to evaluate, "+pcn+"?", self); goto start; }

u1:= findunit (pc, arg, FIND_UNIT_IN_ME, null);

if (not u1) { exec ("say You do not have such an item, "+pcn+".", self); goto start; }

if ((u1.type != UNIT_ST_OBJ) or ( (u1.objecttype != ITEM_WEAPON) and (u1.objecttype != ITEM_ARMOR) and (u1.objecttype != ITEM_SHIELD) )) { exec ("say The "+u1.name+" is neither a sword, shield nor armor!", self); goto start; }

// Currency, skip for now

if (not transfermoney (pc, null, amt * IRON_MULT)) { exec ("say The cost is merely "+moneystring(amt*IRON_MULT, TRUE)+ ", get them first.", self); goto start; }

category:= u1.value[0]; craft:= u1.value[1] / 5 + 4; // / 5 + 4 is to get corresponding craft_text val

if (craft < 0) craft := 0; if (craft > 9) craft := 9;

// Change the following to use skill_text(craft) instead of itoa(craft) if (u1.objecttype == ITEM_WEAPON) buf := "say The "+u1.name+" is a "+weapon_name(category)+" of "+ craft_text.[craft]+" craftmanship and material.";

if (u1.objecttype == ITEM_ARMOR) buf := "say The "+u1.name+" is made of "+arm_text.[category]+" and is of "+ craft_text.[craft]+" craftmanship and material.";

if (u1.objecttype == ITEM_SHIELD) buf := "say The "+u1.name+" is a "+shi_text.[category]+" shield of "+ craft_text.[craft]+" craftmanship and material.";

exec (buf, self);

goto start;

}

dilend

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>If this <ACRONYM>DIL</ACRONYM> function scares you don't worry you don't have to understand it or adjust it you only have to use it. In fact this is a really easy <ACRONYM>DIL</ACRONYM> to use. It only has one argument which is 'amt', the integer value of money you want the evaluator to charge when a person evaluates their stuff. So to use this function it would look like this on an NPC.</PARA>

dilcopy evaluate@function (5*GOLD_PIECE);

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>this tells the evaluate <ACRONYM>DIL</ACRONYM> to charge 5 gold pieces each time a player evaluates something. For more information on the money see the money field.</PARA>

<PARA>All released <ACRONYM>DIL</ACRONYM> NPC functions are described in <XREF LINKEND="npcdilfunc">. Then we put some to work so you can see how to use them in <XREF LINKEND="npccomplex"></PARA>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;defensive <DICTDEF> <PARA><indexterm> <primary>NPC defensive</primary> </indexterm></PARA>

<PARA>This field sets the NPC natural defense. The defense is a natural bonus the NPC gets when being attacked. If this value is set high enough the NPC becomes almost indestructible. You should use the macro to set the NPC natural attack and defense in <xref LINKEND="npcmacroattdef">.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;offensive <DICTDEF> <PARA><indexterm> <primary>NPC offensive</primary> </indexterm></PARA>

<PARA>This field sets the NPC natural offense. The offense is a natural bonus the NPC gets when being attacked. If this value is set high enough the NPC can do some serious damage when attacking. You should use the macro to set the NPC natural attack and defense in <xref LINKEND="npcmacroattdef">.</PARA>

</LISTITEM> </VARLISTENTRY>

<PARA>This sets the NPC max mana points. Using this field you can create special NPCs that have more or less mana points than the <ACRONYM>VME</ACRONYM> server would normally give when a NPC is loaded.</PARA>

<PARA>this field is simple all you have to do to set it is put the 'mana' keyword followed by the amount of mana points you want the NPC to have as its max. The following definition would make an NPC with only 100 mana points no matter what level.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

mana 100

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM>

</VARLISTENTRY>

<PARA>This sets the NPC max hit points. Using this field you can create special NPCs that have more or less hit points than the <ACRONYM>VME</ACRONYM> server would normally give when a NPC is loaded.</PARA>

<PARA>this field is simple all you have to do to set it is put the 'hit' keyword followed by the amount of hit points you want the NPC to have as its max. The following definition would make an NPC with only 100 hit points no matter what level.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;money <DICTDEF> <PARA><indexterm> <primary>NPC money</primary> </indexterm></PARA>

<PARA>The money field is how you give your NPC money to have while going along its marry way through your world. The money field is an integer that tells the <ACRONYM>VME</ACRONYM> how much money the NPC is carrying. It would however be hard to calculate the amount you want on an NPC with out the macros we have provided. For example to put 5 gold on an NPC you would have to use the following on your NPC.</PARA>

money 25600

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>I of course am not sure this will make 5 gold pieces since I did the math in my head and with all this righting I am doing my math mind doesn't seem to be working right. So to make life easier for you and me we have added some macros to help that are rather self explanatory.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

IRON_PIECE COPPER_PIECE SILVER_PIECE GOLD_PIECE PLATINUM_PIECE

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Now if we wanted to make a NPC carrying five gold it would be as simple as this:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

money 5*GOLD_PIECE

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>the macro method also gains you the ability to tell the <ACRONYM>VME</ACRONYM> what amount of each coin you want on the NPC. If you set it using a single integer the compiler would pick how many of each coin. This of course is not what is desired in fact you want to be able to set your money however you like. So setting more than one coin is as simple as adding a comma between the first and second coin.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

money 5*GOLD_PIECE, 20*IRON_PIECE

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;exp <DICTDEF> <PARA><indexterm> <primary>NPC exp</primary> </indexterm></PARA> <PARA>By default a monster gives 100% of the experience it is worth. This amount is calculated according to the level of the NPC verses the level of the person fighting it. Sometimes the amount of experience is not right since the NPC is really hard to kill for example a dragon with breath weapon and heal at the same level as a merchant with a dagger. These should of course give different experience. The 'exp' field is designed to do just that. The possible range for the 'exp' field is -500% to 500%. If you put the NPC at a negative experience value it will take experience away when it is killed. If you want the default of 100% you do not even need to place this field in your NPC.</PARA>

//add 50% to the experience gained exp 150

/subtract 150% from the experience gained exp -50

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<PARA>Gender, one of these:</PARA>

SEX_NEUTRAL SEX_MALE SEX_FEMALE

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>the values are pretty obvious which is which gender so all we will show here is how to set it.</PARA>

//Setting a male NPC sex SEX_MALE

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;level <DICTDEF> <PARA><indexterm> <primary>NPC level</primary> </indexterm></PARA>

<PARA>When creating a NPC it must be between level 0 and 199. The level of the NPC decides how many skill points and ability points the NPC has. It, along with the 'exp' percentage, determines the amount of experience gained when the NPC is killed. To set the level of the NPC you use the 'level' keyword and then follow it by the level you are setting.</PARA>

//set a NPC to level 50 level 50

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<PARA>The 'race' keyword is what you use to set the characters race. Races in <ACRONYM>VME</ACRONYM> are defined by using an integer that lets the spells and skills act differently for each specific type. The <ACRONYM>VME</ACRONYM> comes standard with many races defined in the values.h. For ease in access we have provided them in <xref linkend="app-c">. For now you can look at the short list below taken from the over all race list.</PARA>

#define RACE_RAT 1102 #define RACE_HORSE 1103 #define RACE_BADGER 1104 #define RACE_SKUNK 1105 #define RACE_BOAR 1106 #define RACE_MOUSE 1107 #define RACE_MONKEY 1108 #define RACE_PORCUPINE 1110 #define RACE_ELEPHANT 1112 #define RACE_CAMEL 1113 #define RACE_FERRET 1114

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>If for example you wanted to make a monkey you could simply put the 'race' keyword and follow it by the monkey define like this:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

race RACE_MONKEY

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>If the race your looking for doesn't exist in the values.h list, you can either add one buy picking a number not already used and creating your own define in the values.h or by adding the define to your zone. Defines added to a single zone will not be accessible if another builder wants to use it. You could also just set it using a number. The following two methods would act the same.</PARA>

<INFORMALEXAMPLE><PROGRAMLISTING> //add define to values.h and use in your zone #define RACE_SPACE_TROLL 5059 race RACE_SPACE_TROLL

//Just plug in a number race 5059

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>If you don't use the macros things can get confusing really fast with the amount of races there are.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;attack <DICTDEF> <PARA><indexterm> <primary>NPC attack</primary> </indexterm></PARA>

<PARA>This field sets the NPCs natural attack type. Do not use this field directly instead use the macro described in <xref linkend="npcmacroattarm"></PARA> </LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY> ;armour <DICTDEF> <PARA><indexterm> <primary>NPC armour</primary> </indexterm></PARA>

<PARA>This field sets the NPCs natural armour type. Do not use this field directly instead use the macro described in <xref linkend="npcmacroattarm"></PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;speed <DICTDEF> <PARA><indexterm> <primary>NPC speed</primary> </indexterm></PARA>

<PARA>Speed determines the NPCs speed. The range is one to twelve. You should not set this when compiling an NPC since the result is really undefined. If you have a special NPC that you want to try to make move faster and hit faster then you could try setting this. This field is mainly added so <ACRONYM>DIL</ACRONYM> can adjust speed. The lower the number the faster the NPC speed.</PARA>

//fastest speed. speed 0

//slowest speed speed 12

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;position <DICTDEF> <PARA><indexterm> <primary>NPC position</primary> </indexterm></PARA>

<PARA>This field sets the position that the NPC will be in when it is first loaded. The following positions are recognized by the compiler.</PARA>

POSITION_DEAD POSITION_MORTALLYW POSITION_INCAP POSITION_STUNNED POSITION_SLEEPING POSITION_RESTING POSITION_SITTING POSITION_FIGHTING POSITION_STANDING

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Some of these positions make no sense you would not load a NPC into a fight or you would not load an NPC that is already dead. The positions are availible for <ACRONYM>DIL</ACRONYM> and you will need to read the <ACRONYM>DIL</ACRONYM> manuals to find out what you would want those for. For now the following are enough.</PARA>

POSITION_SLEEPING POSITION_RESTING POSITION_SITTING POSITION_STANDING

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>The position combined with the default position determines what will be shown when a player looks in the room. If the position of the NPC matches its default position the NPC description will be shown. If it doesn't match the NPCs title and position will be shown. The default value for both 'position' and 'default' is 'POSITION_STANDING'</PARA>

<PARA>To set the position like with other fields you type the 'position' keyword first and follow it by the position you are setting.</PARA>

position POSITION_SITTING

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;default <DICTDEF> <PARA><indexterm> <primary>NPC default</primary> </indexterm></PARA>

<PARA>The default position along with the position determines what is shown when a NPC is in each position. If the position and default positions match the 'descr' field is shown. If they do not match the NPC title is shown along with the current position information. If 'default' is not set it defaults to 'POSITION_STANDING'. The following are possible default positions.</PARA>

POSITION_DEAD POSITION_MORTALLYW POSITION_INCAP POSITION_STUNNED POSITION_SLEEPING POSITION_RESTING POSITION_SITTING POSITION_FIGHTING POSITION_STANDING

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Setting the default field is exactly like setting the 'position' field you place the 'default' keyword first and then the position you want to be default like this:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

default POSITION_RESTING

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;ability <DICTDEF> <PARA><indexterm> <primary>NPC ability</primary> </indexterm></PARA>

<PARA>this field is used to set each of the NPCs abilities. It should not be used directly but instead set through the macro described in <xref linkend="npcmacroability"> </PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;weapon <DICTDEF> <PARA><indexterm> <primary>NPC weapon</primary> </indexterm></PARA>

<PARA>this field is used to set each of the NPCs weapon proficiencies. It should not be used directly but instead set through the macro described in <xref linkend="npcmacroweapspl"></PARA> </LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY> ;spell <DICTDEF> <PARA><indexterm> <primary>NPC spell</primary> </indexterm></PARA>

<PARA>this field is used to set each of the NPCs spells. It should not be used directly but instead set through the macro described in <xref linkend="npcmacroweapspl"> </PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;light <DICTDEF> <PARA><indexterm> <primary>NPC light</primary> </indexterm></PARA>

<PARA>The light field on NPC is not normally set. If however you have a strange creature like a 'light bug' you can set a light value on a NPC. The default light is set to 0 which means it neither adds or subtracts from the rooms light. To set the light value on a NPC you just put the 'light' keyword first and then the value you want to add to the current light.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

//add one to light in room light 1

//default light 0

//take one away light -1

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;alignment <DICTDEF> <PARA><indexterm> <primary>NPC alignment</primary> </indexterm></PARA>

<PARA>This field is a value between -1000 and +1000, where -1000 is ultimate evil, 0 is neutral and +1000 is ultimate good. Good is per definition any value from +1000..+350, neutral is any value from +349..-349 and evil is any value from -350..-1000. Any value in between can also be used.</PARA>

// Quite evil, maybe a Ghoul alignment -750

// Barely evil. alignment -350

//barely good alignment 350

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<PARA>This field is the administrator invisible level of the NPC it is set on. This means that if you set the 'minv' to two hundred it will make it so the NPC can not be seen by anyone below the administrator level of two hundred. This is good for hiding ghosts that only come visible when they attack. In order for the 'minv' to be removed an administrator or a <ACRONYM>DIL</ACRONYM> function must change it.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

minv 239

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<PARA>Currently this field is not used in the <ACRONYM>VME</ACRONYM> 2.0 release. It was added so in the future you wanted to add keys to a NPC for some weird reason like a living trunk then you can. In order to set the key you first place the 'key' keyword and then add the symbolic name of the key.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

//if the key is in your zone key mynpckey

//if the key is in some other zone key someoneelses@keyzone

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<PARA>this field is not used yet in the <ACRONYM>VME</ACRONYM> 2.0 release. The field was added so you could make a NPC that can be opened, closed, locked, and everything else that a room or an object can have set on it. For now we will not document this but if you are interested in how you could use it study the open fields on objects or rooms.</PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST> </SECT1>

<sect1 id="npcmacros"> <TITLE>NPC macros</TITLE>

<sect2 id="npcmacroattarm"> <TITLE>The attack and armour macro</TITLE>

<PARA>The natural attack and armour fields allow you to set the NPC to do damage like a certain type of weapons and to defend like a certain type of armour respectively. Lets say you had a metal cougar it would have an attack type of claw and an armour type of plate while a normal dog would have an armour type of leather and an attack type of bite. The 'NATURAL_DEF' macro is what allows you to set these fields. This macro is defined in wmacros.h and looks like this.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define NATURAL_DEF(weapon_category, armour_category) \ armour armour_category \ attack weapon_category

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>The word natural can sometimes be a little confusing since you can set any of the weapons types you like on the NPC. It doesn't exactly make sense to have a dog that attacks as if it uses a long sword but if you wish it you can do it. The following is a short list of just the natural weapon types but you can find a full list in <xref linkend="app-d"> or in the values.h of your mud just in case you have added some weapon types.</PARA>

#define WPN_FIST 34 #define WPN_KICK 35 #define WPN_BITE 36 #define WPN_STING 37 #define WPN_CLAW 38 #define WPN_CRUSH 39

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Again you don't have to use leather for dogs as we have already mentioned with our metal cat idea you could make a cloth dragon if you really want but its up to you to keep some sanity on your <ACRONYM>VME</ACRONYM>. The following is the list of armour types that can be set. You will see that the list is exactly the same as the list you will find later when making armour.</PARA>

#define ARM_CLOTHES 0 /*Same as a Human in jeans and a T-shirt*/ #define ARM_LEATHER 1 /* A soft flexible leather base armour */ #define ARM_HLEATHER 2 /* A hard un flexible leather base armour */ #define ARM_CHAIN 3 /* A flexible armour composed of interlocking rings */ #define ARM_PLATE 4 /* An un flexible plate armour. */

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Now that you have the defines to work with we will return to our metal cat and normal dog. The definitions for them would look something like this.</PARA>

//Metal Cat NATURAL_DEF(WPN_CLAW, ARM_PLATE)

//normal dog NATURAL_DEF(WPN_BITE, ARM_LEATHER)

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>You should know that the weight of the monster determines the maximum amount of damage it can give when using a natural attack. The weight is categorized as follows:</PARA>

<TITLE>Weight size chart</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>LBS</ENTRY> <ENTRY>Size</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>0 - 5</ENTRY> <ENTRY>Tiny</ENTRY> </ROW> <ROW> <ENTRY>6 - 40</ENTRY> <ENTRY>Small</ENTRY> </ROW> <ROW> <ENTRY>41 - 160</ENTRY> <ENTRY>Medium</ENTRY> </ROW> <ROW> <ENTRY>161 - 500</ENTRY> <ENTRY>Large</ENTRY> </ROW> <ROW> <ENTRY>500 and up</ENTRY> <ENTRY>Huge</ENTRY> </ROW> </TBODY></TGROUP>

<PARA>By default monsters are medium. So make sure you take this into account when you are creating your NPC.</PARA> </sect2>

<sect2 id="npcmacroattdef"> <TITLE>The defense and offense bonus macro</TITLE>

<PARA>There comes a time when you may want to make your NPC super naturally powerful. It is for those times that the offense and defense fields are available for you to set. Normally they default to 0 but you can set them from 0 to 5000. The higher you set the offense number the harder you will hit people you a re in combat with. The higher you set the defense the harder it will be for people to hit your NPC. The following macro allows you to set both the offense and defense.</PARA>

#define ATTACK_DEFENSE(attack, defense) \ offensive attack \ defensive defense

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Using this macro is rather easy you just put the value you want for each and your all done</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

//a really hard hitting hard to kill NPC ATTACK_DEFENSE( 1000, 1000)

</PROGRAMLISTING></INFORMALEXAMPLE> </sect2>

<sect2 id="npcmacroability"> <TITLE>The NPc abilities macro</TITLE>

<PARA>All abilities are in the range [1..200]. Players usually have a maximum of 150, modified by magic... 200 is considered divine. When creating a monster you can not directly specify the size of the abilities, instead you specify a percentage distribution of points. The amount of points are then distributed by the computer according to the specified level. The 'MSET_ABILITY' macro is available for this purpose, and is defined as:</PARA>

#define MSET_ABILITY(str,dex,con,hpp,bra,cha,mag,div) \ ability[ABIL_STR] str \ ability[ABIL_DEX] dex \ ability[ABIL_CON] con \ ability[ABIL_HP] hpp \ ability[ABIL_BRA] bra \ ability[ABIL_MAG] mag \ ability[ABIL_DIV] div \ ability[ABIL_CHA] cha

</PROGRAMLISTING></INFORMALEXAMPLE>

<NOTE><PARA> Note the sum of the ability values must be 100%. This is thus an example of an ability distribution: <INFORMALEXAMPLE><PROGRAMLISTING>

MSET_ABILITY(25,15,10,15,10,5,10,0) /* Sum is 100% */

</PROGRAMLISTING></INFORMALEXAMPLE> </PARA></NOTE>

<PARA>The amount of points distributed depends directly upon the level of the monster and the percentage. If the percentage is too high and the level is also set High some ability points may be lost since a NPC gets all abilities over 255 cut off. For example a level 199 monster with an ability percentage a bit above 20% will make an ability above the 255 points maximum. In the current combat system in the <ACRONYM>VME</ACRONYM> 2.0 it is not necessary to spend points on both 'mag' and 'div' on the NPC since only one or the other is ever used depending on which is higher.</PARA>

</sect2>

<sect2 id="npcmacroweapspl"> <TITLE>The NPc weapon and spell macros</TITLE>

<PARA>NPCs know about weapons and spells but not at the same detailed level as the player. For NPCs the spell and weapon group are used. Thus the Axe hammer category defines all defence and all attack for all kinds of axes and hammers, whereas the player would have to train individually in each axe and hammer type. The same is true for spells. Thus if a monster has 25 points in the weapon sword category it will fight (and defend) with all sword-like weapons at skill 25. When you define weapon and spell skills (monsters have no skill skills) you also define these as percentages, and the program automatically distributes the points. Use the pre-defined macros:</PARA>

#define MSET_WEAPON(axe_ham, sword, club_mace, pole, unarmed, special) \ weapon[WPN_AXE_HAM] axe_ham \ weapon[WPN_SWORD] sword \ weapon[WPN_CLUB_MACE] club_mace \ weapon[WPN_POLEARM] pole \ weapon[WPN_UNARMED] unarmed \ weapon[WPN_SPECIAL] special

</PROGRAMLISTING> </INFORMALEXAMPLE>

<TITLE>MSET_WEAPON arguments</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>Argument</ENTRY> <ENTRY>Description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>axe_ham</ENTRY> <ENTRY>any hammer or axe</ENTRY> </ROW> <ROW> <ENTRY>sword</ENTRY> <ENTRY>any sword like weapon, including dagger and rapier, etc.</ENTRY> </ROW> <ROW> <ENTRY>club_mace</ENTRY> <ENTRY>any club or mace like weapon, flails, morning star, etc.</ENTRY> </ROW> <ROW> <ENTRY>polearm</ENTRY> <ENTRY>any spear or pole like weapon: spear, trident, sickle, scythe etc.</ENTRY> </ROW> <ROW> <ENTRY>unarmed</ENTRY> <ENTRY> Is any bite, claw, sting or other natural attack.</ENTRY> </ROW> <ROW> <ENTRY>special</ENTRY> <ENTRY>any very peculiar weapon, currently only whip.</ENTRY> </ROW> </TBODY></TGROUP>

#define MSET_SPELL(div, pro, det, sum, cre, min, hea, col, cel, int, ext) \ spell[SPL_DIVINE] div \ spell[SPL_PROTECTION] pro \ spell[SPL_DETECTION] det \ spell[SPL_SUMMONING] sum \ spell[SPL_CREATION] cre \ spell[SPL_MIND] min \ spell[SPL_HEAT] hea \ spell[SPL_COLD] col \ spell[SPL_CELL] cel \ spell[SPL_INTERNAL] int \ spell[SPL_EXTERNAL] ext

</PROGRAMLISTING></INFORMALEXAMPLE>

<TITLE>MSET_SPELL arguments</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>Argument</ENTRY> <ENTRY>Description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>div</ENTRY> <ENTRY>Covers all divine sphere spell.</ENTRY> </ROW> <ROW> <ENTRY>pro</ENTRY> <ENTRY>Covers all protection sphere spells.</ENTRY> </ROW> <ROW> <ENTRY>det</ENTRY> <ENTRY>Covers all detection sphere spells.</ENTRY> </ROW> <ROW> <ENTRY>sum</ENTRY> <ENTRY>Covers all summoning spells.</ENTRY> </ROW> <ROW> <ENTRY>Cre</ENTRY> <ENTRY>Covers all creation spells.</ENTRY> </ROW> <ROW> <ENTRY>min</ENTRY> <ENTRY>Covers all mind spells.</ENTRY> </ROW> <ROW> <ENTRY>hea</ENTRY> <ENTRY>Covers all heat spells (fireball, etc.)</ENTRY> </ROW> <ROW> <ENTRY>col</ENTRY> <ENTRY>Covers all cold spells (frostball, etc.)</ENTRY> </ROW> <ROW> <ENTRY>cel</ENTRY> <ENTRY>Covers all cell (electricity) spells (lightning bolt, etc.)</ENTRY> </ROW> <ROW> <ENTRY>int</ENTRY> <ENTRY>Covers all internal (poison) spells (toxicate, etc.)</ENTRY> </ROW> <ROW> <ENTRY>ext</ENTRY> <ENTRY>Covers all external (acid) spells (acid ball etc).</ENTRY> </ROW> </TBODY></TGROUP>

<NOTE><PARA>If your not sure what your weapon or spell is categorized as you can look in the weapons.def or the spells.def for that you are using for your <ACRONYM>VME</ACRONYM> server.</PARA></NOTE> <PARA>The sum of all spell and weapon skills must be 100%. For example, the following would be a legal setting of weapons and spells.</PARA>

// 75% Total, Club/Mace is primary MSET_WEAPON(10,10,20,5,15,5)

// 25% Total, Fire is primary MSET_SPELL(8,0,0,3,0,3,2,3,3,3,3)

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Remember that the groups define both attack and defence. Thus if you make an Orc which has 0% in the flail group it can only use its dexterity to defend itself. Likewise with spell groups. For this reason the groups are both "resistance" as well as attack groups.</PARA> </sect2>

<sect2 id="npcmacrocomposed"> <TITLE>Using the composed.h</TITLE>

<PARA>The file composed.h contains many standard monsters. It is a good idea to study these definitions, as they form the basis of many different monsters. Note that the definitions by no means are perfect, but we are hoping to make a more or less complete monster compendium. If you create certain (general) monsters, please design it as a macro so it can be incorporated in the file. The more monsters created by using these macros the easier it will be for your builders to create NPCs. If you think you have a really all inclusive Composed.h and want to share it with the rest of the <ACRONYM>VME</ACRONYM> servers running out there on the internet. Feel free to submit it to the <ACRONYM>VME</ACRONYM> staff and we will put it in the contribution directories on our release site.</PARA>

<NOTE><PARA>For more information on how to use the composed.h when building your NPC see <xref linkend="npcbasic">.</PARA></NOTE> </sect2> </SECT1>

<sect1 id="npcbasic"> <TITLE>Building your first NPC</TITLE>

<PARA>Now that you have built your first zone with rooms its time to populate it with Non playing characters for your players to hunt, kill, and or interact with. In the last couple of sections you have looked through the fields. In this section we are going to make a nice easy NPC and then show how to use the composed.h to make your NPC building easier. As I have previously stated in the section on room building I like dragons so the first NPC your going to learn to build is a big bad ugly dragon. Don't worry if you hate dragons or you just want to build a normal world you will learn plenty from my dragon example to be able to adjust it to whatever you want.</PARA>

<PARA>When making NPCs you create the zone source file first as shown in <xref linkend="ch-02">. If you only have NPCS you do not need the %reset, %objects, and %rooms fields. For the examples in this chapter we will use the zone we created in <xref linkend="ch-04"> and add the %mobiles section where we will put all the NPC definitions. At the end of this chapter, in <xref linkend="roomnpczone">, we will bring it all together with the rooms we have already defined and our NPCs.</PARA>

<PARA>The first part of all NPC definitions is the symbolic name it is good to always pick a name that will match the name of the NPC so it will be easy to load the NPC. The reason the symbolic and name should match is when you use the command <command>wstat</command> it will only show you a list of the NPCs by symbolic name for example if you type <command> wstat zone dragon mobiles </command> You will get the following: <INFORMALEXAMPLE><PROGRAMLISTING>

List of mobiles in zone Dragon: dragon clerk trashman

</PROGRAMLISTING></INFORMALEXAMPLE> If you didn't make it clear what the NPC was by the symbolic name it might look like this: <INFORMALEXAMPLE><PROGRAMLISTING>

List of mobiles in zone Dragon: npc1 npc2 npc3

</PROGRAMLISTING></INFORMALEXAMPLE> While this might be great when you first start imagine trying to remember each NPC if you have over 30 of them.</PARA>

<PARA>Now lets get started with our dragon. As with the rooms all that is required to make a NPC is the symbolic and end fields. That of course will make a NPC with all defaults.</PARA>

bldragon end

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Thats it for that dragon right? Nope not quite that makes a NPC with all defaults. That means this will probably be a very wimpy human with a symbolic name of dragon and no description, in short it will be a blank when you load it. Now lets start putting the Dragon together.</PARA>

<PARA>The first three things we need are the dragons title, description and names. The description should be what you see when you do a 'look' in the room. The title should be what you see when the NPC is talking or fighting. Finally the names should cover everything in the title and description fields so if you wanted to kill them you can easily know what to type.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

bldragon

title "a black dragon" descr "A big ugly black dragon is clawing the ground here." names {"big ugly black dragon","ugly black dragon","big black dragon", "black dragon","dragon"} ... end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>The names, title and description shouldn't be to hard so I don't think its necessary to go into any more description on the subject. Lets move on. Now we have to take care of what a player sees when he or she looks at a NPC. to make the main description of an NPC you place an extra on the NPC with no names in the list. The blank extra is a special extra that will be shown every time you look at anything in the names list of the NPC. So a description of a NPC would look something like this.</PARA>

extra {} "The black dragons scales glitter like black granite that has been polished for years by water. He has a large neck and huge bat like wings. his eyes watch you as you stand before him. One claw seems to be tapping slightly on the ground as if the dragon is waiting for something."

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Now that you have a main description for the NPC you need to make any smaller descriptions that you want the player to be able to look at. In this case the dragon eyes and claw would be good things to describe and maybe a few other things just for humor.</PARA>

extra {"eyes","eye"} "The dragons eyes seem to follow you no matter where you go in the room nothing seems to escape the dragons attention."

extra {"claws","claw"} "The claw is big black and it looks very deadly. It seems like the dragon has two sets of 4 large claws and 2 sets of 4 smaller claws which to say means the claws are about the size of short swords and long swords."

extra {"scales","scale"} "Its a scale! Haven't you ever seen a dragon before!"

extra {"bat wings","wings"} "The dragon sees you looking and flaps his wings creating one heck of a wind blast."

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Now that we have the NPC all described we should start setting things like race, gender, level, height, weight, defense, offense, alignment, abilities, and finally skills and spells. First we will pick a race. Normally the list of races are in your values.h. We have the list in <xref linkend="app-c"> and I have searched for dragon and found the race I want it is as follows.</PARA>

race RACE_DRAGON_BLACK

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>If you don't think there is any difference in dragons you can set them all to one race like you could define a race called 'RACE_DRAGON' or something like that.</PARA>

<PARA>Now we should chose the gender of our dragon. Make sure your descriptions match what you pick. It would be pretty weird to have a female dragon and have the descriptions say 'he, him, or his'</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

sex SEX_MALE

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Now lets set the height and weight. Remember you set the height in centimeters and the weight in pounds. In the future the <ACRONYM>VME</ACRONYM> will standardize to one or the other but for now we have to play the conversion game.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING> //20 feet (1 inch = 2.54 cm height 625

//566 KG (1 lb. = .45359 kg) weight 1250

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Now that we have the size of the dragon we can pick a level. My dragon is only 20 feet tall and 1250 pounds so I think maybe he is a bit young and will make his level around 70.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

level 70

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>The dragon may not wear armour but by default a dragon should have an armour equal to someone wearing plate mail. Not only that but my dragon doesn't like to use his mouth as his natural attack and he sure can't punch with those big claws so we need to set his attack type to claw.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

NATURAL_DEF(WPN_CLAW, ARM_PLATE)

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Not many black dragons are good so I will pick almost totally evil, since totally evil is -1000 I will set it as follows.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

alignment -900

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Finally we get to the hard part. Many people have trouble setting the NPC abilities, weapons, and spells. There really is nothing to it if you have read <xref linkend="npcmacroability"> and <xref linkend="npcmacroweapspl">. The only thing you have to remember is the numbers you are putting are not the actual amount but a percentage of the skill points you want the game to use on your NPC when having your NPC practice as it loads and all amounts of abilities must add up to 100% as well as all weapons and spells must add up to 100%. For the dragon the following would be what the abilities, weapons, and spells would look like.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

//big strong and magical most ability points on str and mag MSET_ABILITY(20,12,12,12,12,12,20,0)

//Set natural attack highest of weapons because he fights with claws MSET_WEAPON(10,10,10,5,30,5)

//black dragons have natural defense from acid set it highest MSET_SPELL(0,0,0,0,0,0,0,0,0,0,30)

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>That is all you need to make a basic dragon. True this dragon will not do anything but claw you to death if you attack it but in <xref linkend="npccomplex"> we will give the dragon some more abilities with some special <ACRONYM>DIL</ACRONYM> functions. For now lets take a look at our finished product.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

bldragon

title "a black dragon" descr "A big ugly black dragon is clawing the ground here." names {"big ugly black dragon","ugly black dragon","big black dragon", "black dragon","dragon"}

extra {} "The black dragons scales glitter like black granite that has been polished for years by water. He has a large neck and huge bat like wings. his eyes watch you as you stand before him. One claw seems to be tapping slightly on the ground as if the dragon is waiting for something."

extra {"eyes","eye"} "The dragons eyes seem to follow you no matter where you go in the room nothing seems to escape the dragons attention."

extra {"claws","claw"} "The claw is big black and it looks very deadly. It seems like the dragon has two sets of 4 large claws and 2 sets of 4 smaller claws which to say means the claws are about the size of short swords and long swords."

extra {"scales","scale"} "Its a scale! Haven't you ever seen a dragon before!"

extra {"bat wings","wings"} "The dragon sees you looking and flaps his wings creating one heck of a wind blast."

race RACE_DRAGON_BLACK sex SEX_MALE height 625 weight 1250 level 70 NATURAL_DEF(WPN_CLAW, ARM_PLATE) alignment -900 MSET_ABILITY(20,12,12,12,12,12,20,0) MSET_WEAPON(10,10,10,5,30,5) MSET_SPELL(0,0,0,0,0,0,0,0,0,0,30)

end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>As you can see there is a bit more to building an NPC than a room but its really not that much harder. Try changing some stuff and make sure to practice debugging your errors the more compiling you do the better you will get. </PARA>

</SECT1>

<sect1 id="npcdebug"> <TITLE>Compiling and debugging your first NPC</TITLE>

<PARA>As we have previously mentioned in <xref linkend="rmdebug"> it is always a good idea to build one or two things and then compile to make finding errors easy. In this case we have one NPC to compile and rather than having all the rooms get in my way while compiling it I have removed them and only have the '%mobiles' section. The following is what the zone looks like when it has only one NPC in it.</PARA>

#include <composed.h> %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 whistler@valhalla.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."

%mobiles

bldragon

title "a black dragon" descr "A big ugly black dragon is clawing the ground here." names {"big ugly black dragon","ugly black dragon","big black dragon", "black dragon","dragon"}

extra "The black dragons scales glitter like black granite that has been polished for years by water. He has a large neck and huge bat like wings. his eyes watch you as you stand before him. One claw seems to be tapping slightly on the ground as if the dragon is waiting for something."

extra {"eye","eyes"} "The dragons eyes seem to follow you no matter where you go in the room nothing seems to escape the dragons attention."

extra {"claws","claw"} "The claw is big black and it looks very deadly. It seems like the dragon has two sets of 4 large claws and 2 sets of 4 smaller claws which to say means the claws are about the size of short swords and long swords."

extra {"scales","scale"} "Its a scale! Haven't you ever seen a dragon before!"

extra {"bat wings","wings"} "The dragon sees you looking and flaps his wings creating one heck of a wind blast."

race RACE_DRAGON_BLACK sex SEX_MALE height 625 weight 1250 level 70 NATURAL_DEF (WPN_CLAW, ARM_PLATE) alignment -900 MSET_ABILITY(21,12,12,12,12,12,20,0) MSET_WEAPON(10,10,10,5,30,5) MSET_SPELL(0,0,0,0,0,0,1,0,0,0,30)

end

%end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>I removed the '%rooms' section added a '%mobiles' section and stuck the dragon in and now its ready to be compiled and put into the <ACRONYM>VME</ACRONYM> server for you to be able to look at it in the game. If you downloaded our example zones for this document you can compile this zone along with us and fix the errors as we do for practice. The filename is debug_npc.zon. Just so you know the errors in this zone are intentional so please don't write me an email telling me that there are errors in it.</PARA>

<PARA>The command to compile the zone is <command>VMC debug_npc.zon</command>. Here is what we get when we first try and compile the zone.</PARA>

<ACRONYM>VMC</ACRONYM> v2.0 Copyright (C) 2001 by Valhalla [May 9 2001] Compiling 'debug_npc.zon' debug_npc.zon: 32: parse error Token: 'extra' debug_npc.zon: 55: parse error Token: 'alignment' Compilation aborted. </PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>This error file doesn't look any harder than the last one we dealt with when compiling our first room. The problem is when we go to line '32' and look for an error we don't find one. This normally means that the error was hard for the compiler to figure out. The best way to deal with an error like this is to start at the line it gives you and go up and look for an error. When we do this we notice that the extra right above the line that the error is on is missing '{}' so we will add them back in. Most of the time you want to do one error and recompile but sometimes you can shorten the process for example in this error file the word 'alignment has been spelled wrong so we can fix that before we recompile so go to line '56' and fix that. Now with those two errors fixed we can recompile and this is what we get:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

<ACRONYM>VMC</ACRONYM> v2.0 Copyright (C) 2001 by Valhalla [May 9 2001] Compiling 'debug_npc.zon' FATAL: Abilities in 'bldragon' sums up to 101,and not 100. FATAL: Spells&weapons in 'bldragon' sums up to 101, and not 100. WARNING: Fatal errors in zone.

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>As we have said before you have to make sure that abilities add up to 100 percent this error is telling us that my math sucks and that I have added 1 extra percent to the abilities. Not only that but again if we look at both errors I have also put 1 extra on weapons and spells. So we can fix both of these at once. Notice it doesn't give a line number but that is not a problem because you can search for 'MSET_ABIL' and it will take you right to the problems. After I subtract one from the abilities and one from either the spells or weapons the following is the error file I get.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Notice there are no errors and it says '<ACRONYM>VMC</ACRONYM> done', this means that you have now successfully compiled the zone. The main thing I want to point out is that you can sometimes fix more than one error at a time but be carefull when doing this if you try to fix some errors before fixing the first you will be trying to fix things that are not broken. The safest way to compile stuff is still fix one error at a time.</PARA>

<PARA>Now that you have a compiled zone you should check and make sure that all the files are there. When you compile a zone you will end up with three extra files. the files will have the same filename as your zone with a new extension in this case you should have the following.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

debug_npc.data debug_npc.err debug_npc.reset debug_rm.zon

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>If you have all of these you are all set to go. If not then there is something seriously wrong and you may want to write the <ACRONYM>VME</ACRONYM> staff for help.</PARA>

<PARA> To get your new zone in the mud all that is needed is to make sure your zone is in the zonelist in the <ACRONYM>VME</ACRONYM> etc directory and copy these files into your zone directory. Then reboot the mud. You should be able to log on your builder character and load your NPC by typing <command>load bldragon@dragonst</command> and you can list your zones NPCs by typing <command>wstat zone dragonst mobiles</command>.</PARA>

<PARA>There you go you have now compiled your first NPC. As you can see with as little as you have learned so far you can already make a variety of monsters and NPCs of any kind. The next section will cover the <ACRONYM>DIL</ACRONYM> functions you can use with a NPC and then we will get right into some more complex examples.</PARA> </sect1>

<sect1 id="npcdilfunc"> <TITLE><ACRONYM>DIL</ACRONYM> functions for NPCs</TITLE>

<PARA>The <ACRONYM>DIL</ACRONYM> language is the language a builder can use to make his own special functions on rooms, NPCs, objects, PCs, and much more. This manual is for basic zone writing and therefore will not go into how to write your own <ACRONYM>DIL</ACRONYM> functions. The <ACRONYM>VME</ACRONYM> however is released with many functions for you as an Administrator and your builders to use to make special rooms, NPCs, and objects. The following is a list of all NPC functions released with the <ACRONYM>VME</ACRONYM> 2.0 server.</PARA>

<variablelist id="var-npcfunc"> <VARLISTENTRY> ;Mercenary <DICTDEF> <PARA><indexterm> <primary>Mercenary NPC function</primary> </indexterm></PARA> <PARA> This function allows you to make an NPC hireable by players in the game. You simply dilcopy this unto a mob and the player can then type 'contract <character name> and the mob will hunt that char for a fee. This function takes no special arguments. the following is the function definition found in function.zon:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin mercenary_hire();

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>To use it you simply dilcopy it to your NPC as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy mercenary_hire@function();

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Obey <DICTDEF> <PARA><indexterm> <primary>Obey NPC function</primary> </indexterm></PARA>

<PARA>This function when dilcopied on the NPC will make it obey there master. And example mobile of this is the familiar. Upon completing a small quest a Mage receives a familiar that will obey that player and that player only. The player can simply type <command>Tell <familiar name> cast heal <player name></command> and it will carry out the command. This function takes no arguments. The following is the definition found in function.zon:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin obey();

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>To use this function simply dilcopy it to the NPC you want to be a mercenary like so:</PARA>

dilcopy obey@function();

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Evaluate <DICTDEF> <PARA><indexterm> <primary>Evaluate NPC function</primary> </indexterm></PARA>

<PARA>This function when placed on an NPC allows it to evaluate items for a fee. The function definition looks as follows:</PARA>

dilbegin evaluate (amt:integer);

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>The function has one argument 'amt' that lets you set the cost of the evaluation of items. If you wanted to set the value to four gold it would work just like when setting the money field and look as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy evaluate@function(4*GOLD_PIECE);

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Guard Direction <DICTDEF> <PARA><indexterm> <primary>Guard Direction NPC function</primary> </indexterm></PARA> <PARA> This is an enhanced version of the Guard Way Function. It will allow both certain players to enter as well as certain mobs. An optional stop <ACRONYM>DIL</ACRONYM> can be supplied if you wish to do something special. It takes two arguments, the activator and the direction. The following is the function definition:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin guard_dir(direction : string, excludepc : stringlist, excludenpc : stringlist, stopdil : string);

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>This function is dilcopied onto the mob in the room that the mob is initially loaded. Thus is the mob is summoned or commanded away it will not block the directions until it is back to where it was first created. This <ACRONYM>DIL</ACRONYM> takes four arguments. The first is the direction to block. The second arguments is for those PC's you wish to allow to pass in that direction without being stopped. The next for the NPCs you wish to allow to pass. The last is the 'act you wish the blocking mob to display to the PC's that are blocked from proceeding in the selected direction. The third and forth arguments may be 'null', this will pass the defaults to the dilcopy. The third argument is a stringlist that tells which players or NPCs are excluded from the guard. The forth is a <ACRONYM>DIL</ACRONYM> you can pass in to do something special to people who are stopped. We will not show how to use the forth argument because it takes more <ACRONYM>DIL</ACRONYM> knowledge than this manual covers. The following would be a valid dilcopy for this function:</PARA>

dilcopy guard_dir@function("south", {"papi", {"rejji"}, null, null);

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Combat magic <DICTDEF> <PARA><indexterm> <primary>Combat magic NPC function</primary> </indexterm></PARA> <PARA>This function when placed on a mobile allows it to use any of the combat spells. The function definition is as follows: It also allows the NPC to cast heal during combat on itself. </PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin combat_mag(atk_spl : string, def_spl : string, def_pct:integer, spd: integer);

</PROGRAMLISTING></INFORMALEXAMPLE>

<TITLE>Combat magic arguments</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>argument</ENTRY> <ENTRY>Type</ENTRY> <ENTRY>description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>atk_spl</ENTRY> <ENTRY>string</ENTRY> <ENTRY>Attack spell ie "fireball" or "" for none</ENTRY> </ROW> <ROW> <ENTRY>def_spl</ENTRY> <ENTRY>string</ENTRY> <ENTRY>Defense Spell ie "heal" or "" for none</ENTRY> </ROW> <ROW> <ENTRY>def_pct</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>At what % of hitpoints defense spell will be cast</ENTRY> </ROW> <ROW> <ENTRY>spd</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>speed at which mob will uses its attack magic, 1 for all at once (every round) to 5 for every 5 rounds. I suggest 2.</ENTRY> </ROW> </TBODY></TGROUP>

<PARA>Defense spells take priority when the hit points fall below the % specified, after (if) the hits have been restored above that number attack magic will resume. If def_spl is used, function automatically makes sure that it retains enough mana for at least one healing, ie it will attack 4 times if it don't need a healing. The following would be an example of what you would put on your NPC:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy combat_mag@function ("harm", "heal", 25, 2);

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Fido <DICTDEF> <PARA><indexterm> <primary>Fido NPC function</primary> </indexterm></PARA> <PARA>This function turns the NPC into a corpse eating mobile. The following is the functions definition:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin fido(txt1:string,txt2:string);

</PROGRAMLISTING></INFORMALEXAMPLE>

<TITLE>Fido arguments</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>Argument</ENTRY> <ENTRY>Type</ENTRY> <ENTRY>description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>txt1</ENTRY> <ENTRY>string</ENTRY> <ENTRY>The text shown when mob finds and eats corpses, default: 'XXX savagely devours a corpse.' will be shown if txt1 is set to "". If txt1 is set to "stop", the mob will NOT devour corpses (convenient if you want your dogs to only eat food leftovers but not corpses). </ENTRY> </ROW> <ROW> <ENTRY>txt2</ENTRY> <ENTRY>string</ENTRY> <ENTRY> The text shown when mob finds and eats ITEM_FOOD, default: 'XXX hungrily devours YYY.' will be shown if txt2 is set to "". If txt2 is set to "stop", the mob will NOT devour ITEM_FOOD (convenient if you want to make a corpse-eating ghoul, who'd choke on normal food, etc). </ENTRY> </ROW> </TBODY></TGROUP>

<NOTE><PARA>In both cases $1n is the mob itself, $2n is the title of the item devoured.</PARA></NOTE>

<PARA>An example of the 'fido' function on an NPC would look as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy fido@function("$1n slowly devours $2n, crunching the bones.", "$1n grabs $2n and hungrily munches it.");

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Wander zone <DICTDEF> <PARA><indexterm> <primary>Wander zone NPC function</primary> </indexterm></PARA> <PARA>This function allows a mob to wander around more than one zone, but not all zones. You specify what zones the mob can wander. Has optional intelligence which allows the opening and closing of doors. The following is the function definition:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin wander_zones(zones : string, spd : integer, doors : integer, lckd_doors : integer);

</PROGRAMLISTING></INFORMALEXAMPLE>

<TITLE>Zone wander arguments</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>argument</ENTRY> <ENTRY>Type</ENTRY> <ENTRY>description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>zones</ENTRY> <ENTRY>string</ENTRY> <ENTRY>A string of zone names separated by spaces.</ENTRY> </ROW> <ROW> <ENTRY>spd</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>The speed (in seconds) at which the mob wanders. Minimum = 5 secs (for process time).</ENTRY> </ROW> <ROW> <ENTRY>doors</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>Can open/close doors (0 = false, 1 = true)</ENTRY> </ROW> <ROW> <ENTRY>lckd_doors</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>Can open/closed locked doors (0=false, 1=true)</ENTRY> </ROW> </TBODY></TGROUP>

<PARA>The options are not too hard so we will show how to use it and leave it at that</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy wander_zones@function ("halfzon haon_dor", 5, 1);

</PROGRAMLISTING></INFORMALEXAMPLE> <NOTE><PARA>@loadzone option which is used by inputting @loadzone somewhere in the zones string will replace it by the zone the mob is loaded in like this: <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy wander_zones@function ("halfzon haon_dor @loadzone", 5, 1);

</PROGRAMLISTING></INFORMALEXAMPLE></PARA> </NOTE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Global wander <DICTDEF> <PARA><indexterm> <primary>Global wander NPC function</primary> </indexterm></PARA> <PARA>This is similar to wander_zones because it's just a modified version of it, which requires no zones argument since it moves in all zones. The following is the function definition:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin global_wander(spd : integer, doors : integer, lckd_doors :integer);

</PROGRAMLISTING></INFORMALEXAMPLE>

<TITLE>Global wander arguments</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>argument</ENTRY> <ENTRY>Type</ENTRY> <ENTRY>description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>spd</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>The speed (in seconds) at which the mob wanders. Minimum = 5 seconds (for process time).</ENTRY> </ROW> <ROW> <ENTRY>doors</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>Can open/close doors (0 = false, 1 = true)</ENTRY> </ROW> <ROW> <ENTRY>lckd_doors</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>Can open/closed locked doors (0=false, 1=true)</ENTRY> </ROW> </TBODY></TGROUP>

<PARA>The options are not to hard so we will show how to use it and leave it at that</PARA>

dilcopy global_wander@function (60, 1, 1);

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Team work <DICTDEF> <PARA><indexterm> <primary>Team work NPC function</primary> </indexterm></PARA> <PARA>This function when placed on a mob, located in the same room as another mob, will allow the mobile to assist the other in combat. The following is the function definition:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin aware teamwork(lst: string);

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>This function takes one argument which is a string of the mobiles it is to protect. So if we wanted a NPC to protect both Jesper and Enver the dilcopy would look as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy teamwork@function("jesper/enver");

</PROGRAMLISTING></INFORMALEXAMPLE>

<NOTE><PARA>For this to work both mobs must be in the same room or following each other.</PARA></NOTE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Rescue <DICTDEF> <PARA><indexterm> <primary>Rescue NPC function</primary> </indexterm></PARA> <PARA>This function when placed on a mob, located in the same room as another mob, will allow the mobile to rescue the other mob if it is attacked. The function is as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin aware rescue(lst: string);

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>This function takes one argument, a string of those mobiles you wish this NPC to assist should they be attacked.</PARA>

<NOTE><PARA> For this to work both NPCs must be in the same room or following each other.</PARA></NOTE>

<PARA>Again we will use our test subjects Jesper and Enver and if we wanted an NPC to protect them and come to their aid the following would be the dilcopy:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy teamwork@function("jesper/enver");

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Agressive <DICTDEF> <PARA><indexterm> <primary>Agressive NPC function</primary> </indexterm></PARA> <PARA>This function makes a Mob hostile to person(s) in the room with it, under certain conditions which are provided as arguments. In short, the all-singing, all-dancing aggression <ACRONYM>DIL</ACRONYM>. The following is this functions definition:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin aggressive (sx : integer, rce : integer, opp : integer, levl : integer, sanc : integer, tme : integer, tar : integer, align : string, attack : stringlist);

</PROGRAMLISTING></INFORMALEXAMPLE>

<TITLE>Agressive arguments</TITLE> <TGROUP align=left cols=3 colsep=1> <THEAD> <ROW> <ENTRY>argument</ENTRY> <ENTRY>Type</ENTRY> <ENTRY>description</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>sx</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>NOTE: not the sex values in values.h. This decides the sex of your mob's victim. 0 - Sex doesn't matter, 1 - Attack opposite sex to self (if not neutral!), 2 - Attack SEX_MALE, 3 - Attack SEX_FEMALE, 4 - Attack SEX_NEUTRAL. </ENTRY> </ROW> <ROW> <ENTRY>rce</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>Any of the PC races from 0 to 14. A value of -1 means we don't care about the victim's race. </ENTRY> </ROW> <ROW> <ENTRY>opp</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>0 - Non race specific (same as rce := -1) 1 - Attack the specified rce, 2 - Attack any pc race _but_ the specified rce. </ENTRY> </ROW> <ROW> <ENTRY>levl</ENTRY> <ENTRY>integer</ENTRY> <ENTRY> Allow level specific aggression. A value of 30 would make the mob hostile to all pcs level 30 and above. A value of -30 (note the -) would make the mob hostile to all pcs level 30 or below. A value of 0 means level doesn't matter. </ENTRY> </ROW> <ROW> <ENTRY>sanc</ENTRY> <ENTRY>integer</ENTRY> <ENTRY> Does this mob obey the sanc/soothe rules? (ie, if someone has cast sanctuary on themselves, will this mob recognize it, and not attack, or attack anyway). 0 - Doesn't obey sanc or soothe 1 - Obeys only sanc 2 - Obeys only soothe 3 - Obeys both sanc and soothe (SOOTHE is a new spell for ranger's guild) </ENTRY> </ROW> <ROW> <ENTRY>tme</ENTRY> <ENTRY>integer</ENTRY> <ENTRY>Time in ticks to wait before attacking (is automatically put to RANTIME, ie, time variance of time-time/2 to time+time/2). Values accepted are from 0 to 400 (that's 0 - 100 seconds. Can be specified using PULSE_SEC). </ENTRY> </ROW> <ROW> <ENTRY>tar</ENTRY> <ENTRY>integer</ENTRY> <ENTRY> This is a special value which determines which of the eligible victims we pick. -2 - Last eligible victim to into the room. -1 - Weakest eligible victim in room. 0 - Random eligible victim. +1 - Strongest eligible victim in room. +2 - First eligible victim into the room. </ENTRY> </ROW> <ROW> <ENTRY>align</ENTRY> <ENTRY>string</ENTRY> <ENTRY> The desired alignment of the victim. "ANY" - We don't care about the alignment. "GOOD" - Attack only good alignment. "EVIL" - Attack only evil alignment. "NEUTRAL " - Attack only neutral alignment. "OPPOSITE" - Attack opposite alignment to self (provided self isn't neutral). "SALIGN" - Attack same alignment as self. "DALIGN" - Attack any alignment different to self. </ENTRY> </ROW> <ROW> <ENTRY>attack</ENTRY> <ENTRY>stringlist</ENTRY> <ENTRY> This is a 2 string stringlist. These are the messages sent to the people in the room except the victim, and the victim itself, in that order. If the second (victim) string is "", the first string will be shown to the victim, as if they were anyone else in the room. You can leave both blank if you wish. $1n is the mob name (self), $3n is the victim's name. NOTE: the $ values only apply if you supply BOTH string 1 and 2. </ENTRY> </ROW> </TBODY> </TGROUP>

<PARA>The argument descriptions pretty much explain everything there is to know about the agressive function and what it was so we will finish off by giving an example of a dilcopy that will create a NPC that fits the following description</PARA>

<PARA>Let's say our mob is a level 40 Goblin who doesn't like dwarves. He's very particular in that he doesn't like evil female dwarves who are level 20 and above. He does recognize the sanctuary spell, but he doesn't recognize soothe, and he'll wait 10 seconds on average before he attacks. The 2 messages sent are: "$1n savagely attacks $3n with his big axe!" and "$1n attacks you!"</PARA>

<PARA>Here's what the function call would look like:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy aggressive (3, 2, 1, 20, 2, PULSE_SEC*10, 0, "EVIL", {"$1n savagely attacks $3n with his big axe!", "$1n attacks you!"});

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>In this example, 3 (attack females), 2 (attack dwarves), 1 (just dwarves), 20 (Level 20+ victims), 2 (obey only soothe), PULSE_SEC*10 (wait around 10 seconds before attacking), EVIL (attack only evil), and the strings in the stringlist are displayed to the victim and the room, in that order.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Janitors <DICTDEF> <PARA><indexterm> <primary>Janitors NPC function</primary> </indexterm></PARA>

<PARA>This function turns the NPC into a janitor that will pick up items left lying around and will also tell new players. those under level 20, where there corpse is if they come across it in there wanderings. You must also supply the wander_zone <ACRONYM>DIL</ACRONYM> for this to work correctly. The definition for the janitor function is as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin janitors(rate: integer);

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>The Janitor function only takes one argument and that determines how fast the janitor will pick up stuff in seconds.</PARA>

<PARA>To make a Janitor that will pick up stuff every thirty seconds the following would be the dilcopy:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy janitor@function(30);

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Shop Keeper <DICTDEF> <PARA><indexterm> <primary>Shop Keeper NPC function</primary> </indexterm></PARA> <PARA>This is one of the more complex dilcopies and considered by some to be confusing. Below I will step you through the creation of the mobile, and the application of this <ACRONYM>DIL</ACRONYM> using defines to hopefully simplify the use of this function. The function is defined as:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilbegin aware shopkeeper(prod: stringlist, custom_acts : stringlist, opentimes : stringlist, itemtype: string, sellprofit : integer,buyprofit: integer, maxcash : integer,closedil : string, dilparams : string );

</PROGRAMLISTING></INFORMALEXAMPLE>

<VARIABLELIST> <VARLISTENTRY> ;Step 1 <DICTDEF> <PARA>First, figure out what you want your shopkeeper to sell. He can sell pretty much any item from any zone, as long as you know its symbolic name. For Hogan (our example shopkeeper), he is a bartender, so he sells things you would commonly find in a pub, tavern, or bar. His list of items (their symbolic names at which zone) are:</PARA>

grain_alcohol@gobtown1 pretzels@gobtown1 beer_nuts@gobtown1 rum_coke@gobtown1 tuborg@udgaard

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Now, since I use defines, I make a define for Hogan's products. I called it TAVERN_PROD (for tavern's products). And use the following setup and just stick the names of your items in where his items are. Each item will have a setup like this:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

"tuborg@udgaard 15 20"

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>A symbolic name followed by two numbers, with the entire thing in quotes. Where :</PARA>

<itemizedlist> <LISTITEM><PARA>The "tuborg@udgaard" is your item's symbolic name</PARA></LISTITEM> <LISTITEM><PARA>The 15 (our first number in the string) is the number of that item that will load into your shop daily</PARA></LISTITEM> <LISTITEM><PARA>The 20 (our second number in the string) is the limit available of that item in the shop ever</PARA></LISTITEM> </itemizedlist>

<PARA>So this shop would sell tuborgs.. and every mudday, 15 tuborgs will load into our shop to replenish our stock.. and the maximum tuborgs we can have at any given time is 20.</PARA>

<PARA>Next we place all this info into the define we created above, which would look like this:</PARA>

#define TAVERN_PROD \ {"grain_alcohol@gobtown1 15 20", \ "pretzels@gobtown1 10 15", \ "beer_nuts@gobtown1 15 20", \ "rum_coke@gobtown1 10 15", \ "tuborg@udgaard 15 20"}

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>The above is my define for Hogan's products that he sells. Each one is in quotes and they have commas separating them. If you put each item on its own separate line, you need to put a space and then a back slash after the comma which separates the items, like it shows above. The entire define is enclosed in curly brackets, {}. Now we are finished with the items he sells.</PARA> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;Step 2 <DICTDEF> <PARA>Now you must decide what kind of dialogue you would like your shopkeeper to say. There are ten separate responses you can make for your shopkeeper. They do go in a specific order and I will list what each do.</PARA> <VARIABLELIST> <VARLISTENTRY> ;Response 1 <DICTDEF> <PARA>The first response will be used if the shopkeeper doesn't have the particular item you're trying to buy in stock, or if he doesn't sell that item at all.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 2 <DICTDEF> <PARA>The second response is used when the player is trying to sell the shopkeeper something which the player does not have in his inventory. Items worn by the player can not be sold until removed from there worn position.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 3 <DICTDEF> <PARA>The third response is used when the player is trying to sell the shopkeeper something that is not one of those of his trade types. (This will be more clear when we get to the trade type part below. Such as a player trying to sell our bartender a canoe. =)</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 4 <DICTDEF> <PARA>The fourth response is used when the player tries to buy something from the shopkeeper, but doesn't have enough money to buy it.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 5 <DICTDEF> <PARA>The fifth response is used when the sale was successful and the player buys something from the shopkeeper.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 6 <DICTDEF> <PARA>The sixth response is again used when the sale was successful, but this time it's for when the player successfully sells something to the shopkeeper.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 7 <DICTDEF> <PARA>The seventh response is used when the shopkeeper doesn't have enough of the item to sell as the player requests. Such as someone trying to buy 10 tuborgs, but our bartender only has 9.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 8 <DICTDEF> <PARA>The eighth response is Used when the shop is closed and a player tries to buy something from or sell something to the shopkeeper.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 9 <DICTDEF> <PARA>The ninth response is used when the player tries to sell an item to the shopkeeper that the shopkeeper doesn't trade that item.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Response 10 <DICTDEF> <PARA>The tenth (and last!) response is for when the shopkeeper has run out of money and can't afford to buy what the player is trying to sell him.</PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<PARA>Now. again, I made a define called TAVERN_MSG (for tavern messages) and I placed all my responses in it. Don't forget, they do go in that specific order! And below is our setup with responses in it.</PARA>

<NOTE><PARA>In the responses below, $1n refers to the shopkeeper, $2n refers to the item being sold, bought, etc.. and $3n refers to the person dealing with the shopkeeper.</PARA></NOTE>

#define TAVERN_MSG \ {"$1n says, 'This is a tavern, I don't sell such an item as that!'", \ "$1n says, '$3n, you don't even have that!'", \ "$1n says, 'I don't trade with things such as $2n! Just buy a beer!'", \ "$1n says, '$3n, you can't afford $2n.'", \ "$1n says, 'Thank you, $3n, here are %s for $2n.'", \ "$1n says, 'Thank you, $3n.'", \ "$1n says, 'I don't have that many $2ns in stock.'", \ "$1n says, 'I'm on break, come back later.'", \ "$1n says, 'I haven't got a use for $2n.'", \ "$1n says, 'I'd like to buy it, but I can't afford it, sorry.'"} \

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Just like with the items, the responses are in quotes, and are separated with commas. Since I put each on their own separate lines (for neatness sake), I put a space and a back slash, \, after each. The entire define is enclosed in curly braces,{}. And then you're done with your shopkeeper's messages! Don't worry, it gets simpler from here.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Step 3 <DICTDEF> <PARA>Now we get to decide when we want our shop to be open. We get to use military time, so 1 refers to 1am, 6 refers to 6am, 12 refers to 12pm (noon), 18 refers to 6pm, and both 0 and 24 refer to 12am (midnight).. etc.. =) And my define for this I named TAVERN_OPEN_TIMES (for when the tavern is open) and I used the following setup:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define TAVERN_OPEN_TIMES {"12","18"}

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>You just have to make your define and stick your times in quotes and enclose them in curly braces. So Hogan will be opened from 1am ("1") until 11pm ("23"). He will close after 11pm and reopen again at 1am. You may also add multiple open and close times as per the following example:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define TAVERN_OPEN_TIMES {"1","12","16","20"}

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Step 4 <DICTDEF> <PARA>For this step you get to choose your shopkeeper's trade types. And what you pick all depends on what kinds of things you want your shopkeeper to sell and buy. You can find the item types in values.h, but I'll also list them below.</PARA>

<TITLE>Sale types</TITLE> <TGROUP align=left cols=4 colsep=1> <THEAD> <ROW> <ENTRY>Value</ENTRY> <ENTRY>Type</ENTRY> <ENTRY>Value</ENTRY> <ENTRY>Type</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>1</ENTRY><ENTRY>ITEM_LIGHT</ENTRY><ENTRY>14</ENTRY><ENTRY>ITEM_TRAP</ENTRY> </ROW> <ROW> <ENTRY>2</ENTRY><ENTRY>ITEM_SCROLL</ENTRY><ENTRY>15</ENTRY><ENTRY>ITEM_CONTAINER</ENTRY> </ROW> <ROW> <ENTRY>3</ENTRY><ENTRY>ITEM_WAND</ENTRY><ENTRY>16</ENTRY><ENTRY>ITEM_NOTE</ENTRY> </ROW> <ROW> <ENTRY>4</ENTRY><ENTRY>ITEM_STAFF</ENTRY><ENTRY>17</ENTRY><ENTRY>ITEM_DRINKCON</ENTRY> </ROW> <ROW> <ENTRY>5</ENTRY><ENTRY>ITEM_WEAPON</ENTRY><ENTRY>18</ENTRY><ENTRY>ITEM_KEY</ENTRY> </ROW> <ROW> <ENTRY>6</ENTRY><ENTRY>ITEM_FIREWEAPON</ENTRY><ENTRY>19</ENTRY><ENTRY>ITEM_FOOD</ENTRY> </ROW> <ROW> <ENTRY>7</ENTRY><ENTRY>ITEM_MISSILE</ENTRY><ENTRY>20</ENTRY><ENTRY>ITEM_MONEY</ENTRY> </ROW> <ROW> <ENTRY>8</ENTRY><ENTRY>ITEM_TREASURE</ENTRY><ENTRY>21</ENTRY><ENTRY>ITEM_PEN</ENTRY> </ROW> <ROW> <ENTRY>9</ENTRY><ENTRY>ITEM_ARMOR</ENTRY><ENTRY>22</ENTRY><ENTRY>ITEM_BOAT</ENTRY> </ROW> <ROW> <ENTRY>10</ENTRY><ENTRY>ITEM_POTION</ENTRY><ENTRY>23</ENTRY><ENTRY>ITEM_SPELL</ENTRY> </ROW> <ROW> <ENTRY>11</ENTRY><ENTRY>ITEM_WORN</ENTRY><ENTRY>24</ENTRY><ENTRY>ITEM_BOOK</ENTRY> </ROW> <ROW> <ENTRY>12</ENTRY><ENTRY>ITEM_OTHER</ENTRY><ENTRY>25</ENTRY><ENTRY>ITEM_SHIELD</ENTRY> </ROW> <ROW> <ENTRY>13</ENTRY><ENTRY>ITEM_TRASH</ENTRY><ENTRY></ENTRY><ENTRY></ENTRY> </ROW> </TBODY></TGROUP>

<PARA>We are making a bartender, so he should sell food and drinks. So I selected ITEM_FOOD, and it's corresponding number is 19. So I made my define TAVERN_ITEM_TYPE (for our tavern's type of items) using the following setup:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define TAVERN_ITEM_TYPE "19"

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Now, if we had a magic shop, and wanted to sell potions and scrolls, I would make a define called for example MAGIC_ITEM_TYPE and make it like this:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define MAGIC_ITEM_TYPE "2 10"

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>The 2 was our number corresponding to the scrolls, and the 10 corresponded to the potions. That is how you make your shopkeeper sell more than one item type, just stick the corresponding numbers inside quotes with a space separating them.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Step 5 <DICTDEF> <PARA>Now you get to decide how much money your shopkeeper gets to have to buy things with. One platinum piece is equal to 40960. So if I wanted him to have two platinum pieces to spend on buying things from players, I would make a define called TAVERN_MAX_CASH (for the maximum amount of money our shopkeeper gets) and use the following setup:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define TAVERN_MAX_CASH 81920

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>I got 81920 by multiplying the 40960 (one platinum) by 2</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Step 6 <DICTDEF> <PARA>The sixth thing we get to do is to decide how much profit does our shopkeeper get when he sells his items. Items should have a cost to them already tagged on them, so their whatever their cost is, that is equal to 100%. Now, if your shopkeeper wants to take an extra 10% on the items he's selling so he can support his family, then you would make his selling profit 110. So I made a define called TAVERN_SELL_PROFIT (for his profit when he sells things) and gave him 110% selling profit, and used the following setup:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define TAVERN_SELL_PROFIT 110

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Step 7 <DICTDEF> <PARA>This last define is almost exactly like our selling profit, but now, we're doing our buying profit... when a player sells an item to the shopkeeper, he doesn't want to pay full price because it must be used since a player has it. Now the item's cost is 100%, and maybe the shopkeeper only wants to buy items for half its cost. So I would make his buying profit 50, and use the following setup.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

#define TAVERN_BUY_PROFIT 50

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>All of the previous defines you can place anywhere in the zone. I like to place mine before the %<ACRONYM>DIL</ACRONYM> section just to keep them somewhere where I know they all are. You can place each one on the mob itself, but I think that looks cluttered so's why I put them where I put them. And you're going to have a dilcopy placed on your mob also, which I'll explain in step 8.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Step 8 <DICTDEF> <PARA>Okay one last step. Now you get to place the <ACRONYM>DIL</ACRONYM> on your shopkeeper mob using all of those cute little defines you just made. The syntax for the <ACRONYM>DIL</ACRONYM> is:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy shopkeeper@function(products, responses, opentimes, tradetypes, sellprofit, buyprofit, maxcash, closedil, dilparams);

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Take your defines from above the defines that you made are called:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

TAVERN_PROD, TAVERN_MSG, TAVERN_OPEN_TIMES, TAVERN_ITEM_TYPE, TAVERN_SELL_PROFIT, TAVERN_BUY_PROFIT, and TAVERN_MAX_CASH.

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>Now all you have to do is place them in the syntax where they belong like in the below example.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

dilcopy shopkeeper@function(TAVERN_PROD, TAVERN_MSG, TAVERN_OPEN_TIMES, TAVERN_ITEM_TYPE, TAVERN_SELL_PROFIT, TAVERN_BUY_PROFIT, TAVERN_MAX_CASH, "", "");

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>For the last two fields, I just put "", "" because I don't make my own unique <ACRONYM>DIL</ACRONYM> for those. By just putting and empty set of quotes for each, it makes it go to the default. And make sure you don't forget that semicolon at the end either.</PARA>

<PARA>You are pretty much done now. All you have to do is place your defines either up before %<ACRONYM>DIL</ACRONYM> or somewhere in %mob if you'd like, and place the dilcopy onto your mob.</PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<PARA>Just to make sure I've completely beaten a very dead horse, this is what it would look like in the end.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

%zone sample_zon

#define TAVERN_PROD \ {"grain_alcohol@gobtown1 15 20", \ "pretzels@gobtown1 10 15", \ "beer_nuts@gobtown1 15 20", \ "rum_coke@gobtown1 10 15", \ "tuborg@udgaard 15 20"}

#define TAVERN_MSG \ {"$1n says, 'This is a tavern, I don't sell such an item as that!'", \ "$1n says, '$3n, you don't even have that!'", \ "$1n says, 'I don't trade with things such as $2n! Just buy a beer!'", \ "$1n says, '$3n, you can't afford $2n.'", \ "$1n says, 'Thank you, $3n, here are %s for $2n.'", \ "$1n says, 'Thank you, $3n.'", \ "$1n says, 'I don't have that many $2ns in stock.'", \ "$1n says, 'I'm on break, come back later.'", \ "$1n says, 'I haven't got a use for $2n.'", \ "$1n says, 'I'd like to buy it, but I can't afford it, sorry.'"} \

#define TAVERN_OPEN_TIMES {"1","23"} #define TAVERN_ITEM_TYPE "19" #define TAVERN_MAX_CASH 81920 #define TAVERN_SELL_PROFIT 110 #define TAVERN_BUY_PROFIT 50

%mobiles

bartender names {"hogan","goblin","bartender"} title "Hogan" descr "Hogan stands behind the bar waiting to take your order." extra {} "He looks back at you, patiently waiting for your order." M_AVG_GOBLIN(76,SEX_MALE) alignment -1000 exp 100 money 2 SILVER_PIECE, 2 COPPER_PIECE

dilcopy shopkeeper@function(TAVERN_PROD, TAVERN_MSG, TAVERN_OPEN_TIMES, TAVERN_ITEM_TYPE,TAVERN_SELL_PROFIT, TAVERN_BUY_PROFIT, TAVERN_MAX_CASH, "", ""); end

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

</VARIABLELIST>

</sect1>

<sect1 id="npccomplex"> <TITLE>A more complex set of NPCs</TITLE>

<PARA>In the last sections you learned all the fields and how to make a basic NPC. In this section we will use the information from the last sections to create some more unique NPCs for our dragon station zone There is not a lot of new information here we will be using the DIL functions from the previous section and adding some flags to the NPCs to make them act different.</PARA>

<sect2> <TITLE>Magic casting NPC</TITLE>

<PARA>The basic Dragon we made in the <xref linkend="npcbasic"> looks like a real dragon but it is a bit boring when you fight a dragon and don't get toasted by an acid or fire spell or two. in <xref linkend="npcdilfunc"> the 'combat_magic' function was described. This is the function you use to make all NPCs cast magic while in combat. With that in mind lets take a look at how we can make our dragon a bit more interesting g.</PARA>

<PARA>Well lets see a black dragon is supposed to have the ability to either cast fire breath or acid breath depending on who you talk to. Once you learn <ACRONYM>DIL</ACRONYM> you could even make fire breath be a skill not a spell but for now we will stick with what we know. I like the acts of the acid breath spell so we will use that as the spell of choice. The NPC as we defined it before hasn't changed so the following would be the entire dragon with the combat magic function.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

bldragon

title "a black dragon" descr "A big ugly black dragon is clawing the ground here." names {"big ugly black dragon","ugly black dragon","big black dragon", "black dragon","dragon"}

extra {} "The black dragons scales glitter like black granite that has been polished for years by water. He has a large neck and huge bat like wings. his eyes watch you as you stand before him. One claw seems to be tapping slightly on the ground as if the dragon is waiting for something."

extra {"eye","eyes"} "The dragons eyes seem to follow you no matter where you go in the room nothing seems to escape the dragons attention."

extra {"claws","claw"} "The claw is big black and it looks very deadly. It seems like the dragon has two sets of 4 large claws and 2 sets of 4 smaller claws which to say means the claws are about the size of short swords and long swords."

extra {"scales","scale"} "Its a scale! Haven't you ever seen a dragon before!"

extra {"bat wings","wings"} "The dragon sees you looking and flaps his wings creating one heck of a wind blast."

race RACE_DRAGON_BLACK sex SEX_MALE height 625 weight 1250 level 70 NATURAL_DEF (WPN_CLAW, ARM_PLATE) alignment -900 MSET_ABILITY(20,12,12,12,12,12,20,0) MSET_WEAPON(10,10,10,5,30,5) MSET_SPELL(0,0,0,0,0,0,0,0,0,0,30)

//Combat Magic added. dilcopy combat_mag@function("acid breath", "", 25, 2);

end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>That is all there is to it. If you are wondering where I got the 'acid breath' part of the <ACRONYM>DIL</ACRONYM> copy all the spells names are in the spells.def or you can just pick a spell by what you would type if you wanted to cast it yourself in the game. Now if this still looks like a lot to do to make a dragon the dragon above could have been created with exactly the same information by using the composed.h and the 'M_DRAGON_BLACK_OLD' macro. If we use the macro the dragon would look like this</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

bldragon

title "a black dragon" descr "A big ugly black dragon is clawing the ground here." names {"big ugly black dragon","ugly black dragon","big black dragon", "black dragon","dragon"}

extra {} "The black dragons scales glitter like black granite that has been polished for years by water. He has a large neck and huge bat like wings. his eyes watch you as you stand before him. One claw seems to be tapping slightly on the ground as if the dragon is waiting for something."

extra {"eye","eyes"} "The dragons eyes seem to follow you no matter where you go in the room nothing seems to escape the dragons attention."

extra {"claws","claw"} "The claw is big black and it looks very deadly. It seems like the dragon has two sets of 4 large claws and 2 sets of 4 smaller claws which to say means the claws are about the size of short swords and long swords."

extra {"scales","scale"} "Its a scale! Haven't you ever seen a dragon before!"

extra {"bat wings","wings"} "The dragon sees you looking and flaps his wings creating one heck of a wind blast."

M_DRAGON_BLACK_OLD(SEX_MALE)

end </PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>As you can see with the second way the dragon was a lot easier to make because we let the macro set all the other values we just described the NPC and set the macro.</PARA> </sect2>

<sect2> <TITLE>A wandering janitor</TITLE>

<PARA>Our space station is nice but we wouldn't want a lot of people coming to visit if we didn't have a janitor to walk around cleaning up. Dragons most likely wouldn't be low life enough to be Janitors so I think we will leave that up to a hobgoblin. the following would be the definition of a hobgoblin wandering Janitor.</PARA>

janitor names {"ugly janitor", "janitor", "hobgoblin"} title "an ugly janitor" descr "an ugly janitor is walking around, cleaning up."

extra{} "This ugly green thing looks more goblin than hobgoblin but he seems intent on cleaning everything around him."

race RACE_HOBGOBLIN level 6 sex SEX_MALE height 130 /* cm */ weight 120 /* Pounds */ // he is sort of good for cleaning so much alignment 900

NATURAL_DEF(WPN_FIST, ARM_LEATHER) MSET_ABILITY(10,10,10,23,15,22,10,0) \ MSET_WEAPON(10,10,10,10,10,10) /* Average in everything, any wpn */ MSET_SPELL(4,2,2,2,2,2,2,6,6,6,6) /* Resistances */

//give him some money money 5 IRON_PIECE

dilcopy janitors@function(15);

// only want him cleaning the station dilcopy wander_zones@function("dragonst", 20, 1, 1);

end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Like with the dragon if we wanted to create this NPC easier we would use the Hobgoblin defines in composed.h so we don't have to fill out all the information. If we did this it would simply look as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

janitor names {"ugly janitor", "janitor", "hobgoblin"} title "an ugly janitor" descr "an ugly janitor is walking around, cleaning up."

extra{} "This ugly green thing looks more goblin than hobgoblin but he seems intent on cleaning everything around him."

M_AVG_HOBGOBLIN(6, SEX_MALE)

// he is sort of good for cleaning so much alignment 900

//give him some money money 5 IRON_PIECE

dilcopy janitors@function(15);

// only want him cleaning the station dilcopy wander_zones@function("dragonst", 20, 1, 1);

end

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>As you can see you can combine the DIL functions you learned in <xref linkend="npcdilfunc"> to make your NPC do more than one thing.</PARA>

</sect2>

<sect2 id="specteach"> <TITLE>Creating a teacher</TITLE>

<PARA>Setting up teachers on valhalla is harder and more strict formed than most things in the game. The reason is the way you set them up is to use an old form of functions called special. In the future guilds will be in <ACRONYM>DIL</ACRONYM> like everything else but for now the teachers that are released with the <ACRONYM>VME</ACRONYM> are base code. Even though the teachers are base code they still allow for you to adjust many things. The truth is you don't have to use our teachers you could code your own in <ACRONYM>DIL</ACRONYM> but many find this easier.</PARA>

<PARA>Guild teacher definitions are actually less complex than people think they are. There really are no big, mysterious secrets. The key is simply to understand the numbers and how the balance is achieved. (From here on in, GTD will refer to "guild teacher definition", and "entity" will be used to refer to the ability/spell/skill/weapon being offered by the GTD.)</PARA>

<NOTE><PARA> Using TAB characters in GTDs is a very bad idea! It will have extremely adverse effects, including causing the mud to crash. </PARA></NOTE>

<PARA>We need to tart first and explain that to use the teacher special functions you need to use a field not described anywhere else in the NPC descriptions. The field is called a 'special'. The reason the 'special' field was not included in the field descriptions is because it is being removed from the <ACRONYM>VME</ACRONYM> as soon as banks and teachers have been replaced by <ACRONYM>DIL</ACRONYM> there will be no more special functions. For now however we need to use them for the for mentioned purposes. The format for a special function is as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

special <Function define> <function arguments>

</PROGRAMLISTING></INFORMALEXAMPLE> <PARA>For teachers the function definition is 'SFUN_TEACH_INIT' and the arguments range from who can join, what the acts of the teacher are, and what the teacher teaches.</PARA>

<PARA>In the first part of a SFUN_TEACH_INIT definition, there are several pieces of important information which allow the mud to know what you are trying to provide to players. The entire set of arguments are enclosed in double quotes. So a teacher with nothing at all in it would look like this:</PARA>

special SFUN_TEACH_INIT "<arguments go here>"

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>After the opening double quote ("), the first thing necessary is the text formatting code '&l', which tells the compiler to ignore the standard text formatting protocols for the rest of the string or until the '&f' code is given.</PARA>

<PARA>Immediately following the '&l' code, with no spaces at all, the type of entity the function will teach is defined. It is one of the following types:</PARA> <itemizedlist> <LISTITEM><PARA>abilities</PARA></LISTITEM> <LISTITEM><PARA>spells</PARA></LISTITEM> <LISTITEM><PARA>skills</PARA></LISTITEM> <LISTITEM><PARA>weapons</PARA></LISTITEM> </itemizedlist>

<PARA>The first two lines of the SFUN_TEACH_INIT looks like this:</PARA>

special SFUN_TEACH_INIT "&labilities;0;

</PROGRAMLISTING></INFORMALEXAMPLE>

<NOTE><PARA>The '0;' is the end of field marker that will be used through out the teacher fields</PARA></NOTE>

<PARA>The next set of arguments to the teacher function is the acts the teacher will use when a person is trying to train. There are seven acts total and they are as follows:</PARA> <VARIABLELIST> <TITLE>Teacher acts</TITLE> <VARLISTENTRY> ;Line 1 <DICTDEF> <PARA>This line is displayed when the player makes a mistake in typing the name of an entity, whether or not it is actually offered at the teacher. </PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Line 2 <DICTDEF> <PARA>This line is similar to the first, but is usually evident of attempting to practice an entity not offered at this particular teacher. </PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Line 3 <DICTDEF> <PARA>This is the act displayed when the player has insufficient funds to practice the desired entity. </PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Line 4 <DICTDEF> <PARA>This is displayed when the player has not got enough ability or skill practice points to learn the desired entity.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Line 5 <DICTDEF> <PARA>Simply put, the player has exceeded the teacher's expertise in the offered entity and must go elsewhere to learn more, if at all possible.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Line 6 <DICTDEF> <PARA>This line is displayed when the player is either wearing magical, stat-modifying equipment or is affected by spells/skills which modify stats.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Line 7 <DICTDEF> <PARA>This line is what is shown when your armour affects you using special functions in base code. This is rare and may never be seen. In the future when the teachers are made in <ACRONYM>DIL</ACRONYM> this act may not be necessary.</PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<PARA>Now we can add the acts to our example it would look as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

special SFUN_TEACH_INIT "&labilities;0; $1n tells you, 'I have never heard of such an ability.'; $1n tells you, 'I do not know how to teach this ability.'; $1n tells you, 'You haven't got %s for me.'; $1n tells you, 'You haven't got %d ability points.'; $1n tells you, 'I can not teach you any more.'; $1n tells you, 'You must be unaffected by magic, else I can't teach you.'; $1n tells you, 'Remove all equipment, please.';

</PROGRAMLISTING></INFORMALEXAMPLE>

<NOTE><PARA> $1n is the substitution variable for the teacher's title (see the <ACRONYM>DIL</ACRONYM> document for more details).</PARA>

<PARA>%s is the amount of money the teacher requires to teach the entity in question.</PARA>

<PARA>%d is the amount of ability or skill practice points required to practice the given entity.</PARA>

<PARA>The standard GTD termination character, a semicolon (;) ends each act</PARA> </NOTE>

<PARA>about the actual GTDs, or the lines that actually define what the teachers teach and everything to do about how expensive and how high they teach it. A GTD is a single line, composed of several fields. The data contained in these fields determines how a particular entity is practiced.</PARA>

<PARA>Here is an example of a GTD:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

0; 100; scan ; 9; 9000; 7; 0;

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>Note that it has a lot of white space in it. It is really not necessary, as the field terminators are the semicolons. This means that you could just as easily write:</PARA>

0;100;scan;9;9000;7;0;

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>When making teachers most people prefer to put the white space in to make it easier to read and find errors. A larger example would look as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

0; 100; scan ; 9; 9000; 7; 0; 0; 90; consider ; 4; 4000; 5; 10; 0; 0; 100; appraisal ; 9; 4000; 5; 0; 0; 100; fleeing ; 9; 9000; 6; 12; 0;

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA> Each part of the GTD separated by a semicolon is called a field. The following is the fields and their definitions.</PARA>

<VARIABLELIST> <VARLISTENTRY> ;Field 1 <DICTDEF> <PARA> Field 1 is the guild level. It is simply the level at which one is allowed to practice the particular entity in the guild. A level of 0 indicates that one can practice it from the beginning.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Field 2 <DICTDEF>

<PARA>This is the maximum percentage one is allowed to practice the particular entity. It can be anywhere from 1 to 200. For abilities, it should be in increments of 2 (or divisible by 2), and for spells, skills, or weapons, in increments of 5 (or divisible by 5). This means that the effective minimum depends on whether the entity is an ability or a spell, skill or weapon.</PARA>

<PARA>Therefore, the minimums for abilities is 2, and the minimum for spells, skills or weapons is 5. Anything less will be automatically practiced to the effective minimum. This also means that putting an odd number for abilities will result in the player practicing an additional point, and for spells, skills or weapons, practicing up to the nearest 5.</PARA>

<PARA>For example: Percentage maximum for an ability is set for 95%. Player practices the ability, which then becomes 96%. Player then decides to practice a weapon skill. It is set to 77% maximum. After practicing, the player has 80% in the weapon. It is better to simply make the ability 96% and the weapon 80% maximum instead.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Field 3 <DICTDEF> <PARA>Name of Entity</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Field 4 <DICTDEF> <PARA>This is the practice cost minimum in Old gold pieces. Anything less than 10 here will simply be translated as 1 iron piece. Anything other than a number divisible by 10 is rounded up to the nearest iron piece.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Field 5 <DICTDEF> <PARA>This is the practice cost maximum in old gold pieces. It is generally defined as being 1000 times what Field 4 is defined as:</PARA>

<PARA>The reason for this is because there is a scale related to the current practice percentage of the entity. The practice minimum is what the entity costs when it is at 0%, and the practice maximum is what it costs to practice it to maximum percentage.</PARA>

<PARA>It is not necessary to multiply the minimum by 1000 to define the maximum. It can be any number, as long as the maximum exceeds the minimum. Failure to do so will result in the mud crashing. It is unknown what will happen if the fields have 0 entered in them. I warn that it could be rather unpredictable.</PARA>

<PARA>Setting the maximum too high will only serve to dissuade players from practicing and indeed even playing. This is not to say you cannot make a truly powerful entity very expensive. Just make sure that the entity is worth the cost.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Field 6 <DICTDEF> <PARA>This is the only necessary practice points field. It allows one to use their skill or ability practice points to increase their character's powers. This number is generally determined by the desire of the builder to make the entity easier or harder to practice, based upon the logical consideration of how this class would learn/use the entity.</PARA>

<PARA>For instance, a Fighter class would find practicing "fist" to be exceedingly easy, so they may only need 4 points to practice this skill, but on the other hand, a Mage class would not have such an experience so it may cost them 15 points to practice.</PARA>

<PARA>Don't go overboard, making this field an outrageous number will mean that no one is likely to practice the entity, mainly because of lack of points. However, like in the cost fields, it can be made expensive to reflect the power of the entity.</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Field 7 - X <DICTDEF> <PARA>You can repeat field 6 as many times as you want the player to be able to practice in one level so you can set a point cost each time. This is so each time they practice at a level you can make it more expensive.</PARA>

<PARA>An example of this would look as follows:</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

0; 90; consider ; 4; 4000; 5; 10; 0;

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>This example has consider being practiced at guild level 0 up to 90%, costing 4 old gold pieces minimum, 4000 old gold pieces maximum, 5 practice points for the first practice per level and 10 for the second.</PARA>

<PARA> For 15 points a level, the player can practice consider twice. It is actually quite nice to be able to do this, and generally easier entities take advantage of this more often.</PARA>

<PARA>Each additional field is followed by a semicolon</PARA> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> ;Field X <DICTDEF> <PARA>This is the termination field for the GTD. It tells the compiler that the GTD is finished. In fact, if you set a practice point field to 0, it would consider that Field X, and end the GTD.</PARA>

<PARA>Every GTD line must have an end of field marker!</PARA> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<PARA>When we refer to old gold pieces they represent the <ACRONYM>VME</ACRONYM> money system as follows:</PARA>

<TITLE>Old to new money conversions.</TITLE> <TGROUP align=left cols=2 colsep=1> <THEAD> <ROW> <ENTRY>Old gold piece</ENTRY> <ENTRY>New money</ENTRY> </ROW> </THEAD> <TBODY> <ROW> <ENTRY>10</ENTRY> <ENTRY>1 Iron Piece (IP)</ENTRY> </ROW> <ROW> <ENTRY>80</ENTRY> <ENTRY>1 copper piece (CP)</ENTRY> </ROW> <ROW> <ENTRY>640</ENTRY> <ENTRY>1 silver piece (SP)</ENTRY> </ROW> <ROW> <ENTRY>5120</ENTRY> <ENTRY>1 gold piece (GP)</ENTRY> </ROW> <ROW> <ENTRY>40960</ENTRY> <ENTRY>1 platinum piece (PP)</ENTRY> </ROW> </TBODY></TGROUP>

<PARA>Of course, to finish up the entire SFUN_TEACH_INIT, you must include a closing double quotation mark ("). Failure to do so will cause no end of problems for you.</PARA>

<PARA>A finished teacher of ability function would look like this:</PARA>

special SFUN_TEACH_INIT "&labilities;0; $1n tells you, 'I have never heard of such an ability.'; $1n tells you, 'I do not know how to teach this ability.'; $1n tells you, 'You haven't got %s for me.'; $1n tells you, 'You haven't got %d ability points.'; $1n tells you, 'I can not teach you any more'; $1n tells you, 'You must be unaffected by magic, otherwise I can't teach you.'; $1n tells you, 'Remove all equipment, please.';

0; 100; Strength ; 4; 4000; 8; 0; 0; 90; Dexterity ; 14; 14000; 12; 0; 0; 90; Constitution ; 14; 14000; 9; 0; 0; 100; Hitpoints ; 4; 4000; 11; 0; 2; 60; Brain ; 23; 23000; 14; 0; 4; 80; Charisma ; 18; 18000; 14; 0; "

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>There are two other easy to use specials that you will want to use with your teacher. they are 'SFUN_GUILD_BASIS' and 'SFUN_MEMBERS_ONLY'.</PARA>

<VARIABLELIST> <VARLISTENTRY> ;SFUN_GUILD_BASIS <DICTDEF> <PARA>This initializes the teacher and the only argument is the guild name</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

special SFUN_GUILD_BASIS "Udgaard Fighter"

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;SFUN_MEMBERS_ONLY <DICTDEF> <PARA>This simply blocks anyone who is not in the guild from practicing This means the argument is the guild name. and the act separated by a '#', an example would look as follows:</PARA>

special SFUN_MEMBERS_ONLY "Udgaard fighter#$1n says, 'Buggar ye off, $3n.'"

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<PARA>Finally we will show you what a full teacher would look like with the entire specials and the NPC definition.</PARA>

jones

names {"blacksmith", "smith", "Jones"} title "Jones the blacksmith" descr "The venerable Jones Blacksmith is here." extra {} "The smith is old but his arms still retain the strength of his youth. He looks as if he has retired, but he can still put you through the drills of physical training." flags {UNIT_FL_NO_TELEPORT} romflags {CHAR_PROTECTED} //Define from composed.h M_HUMAN_WARRIOR_AXE(80, SEX_MALE)

//negative exp to discourage killing teacher exp -100

special SFUN_GUILD_BASIS GUILD_UDG_FIGHTER special SFUN_MEMBERS_ONLY GUILD_UDG_FIGHTER+"#$1n says, 'Buggar ye off, $3n.'"

special SFUN_TEACH_INIT "&labilities;0; $1n tells you, 'I have never heard of such an ability.'; $1n tells you, 'I do not know how to teach this ability.'; $1n tells you, 'You haven't got %s for me.'; $1n tells you, 'You haven't got %d ability points.'; $1n tells you, 'I can not teach you any more'; $1n tells you, 'You must be unaffected by magic, otherwise I can't teach you.'; $1n tells you, 'Remove all equipment, please.';

0; 100; Strength ; 4; 4000; 8; 0; 0; 90; Dexterity ; 14; 14000; 12; 0; 0; 90; Constitution ; 14; 14000; 9; 0; 0; 100; Hitpoints ; 4; 4000; 11; 0; 2; 60; Brain ; 23; 23000; 14; 0; 4; 80; Charisma ; 18; 18000; 14; 0; "

</PROGRAMLISTING></INFORMALEXAMPLE>

</sect2>

<sect2 id="specguildmaster"> <TITLE>Guild master functions</TITLE>

<PARA>When you make a guild you have to make a guild master for it. This NPC will let people join and leave the guild and it also gives titles. To create a guild master you need to use three 'special' functions. The functions you need are 'SFUN_GUILD_BASIS', 'SFUN_GUILD_MASTER', and 'SFUN_GUILD_TITLES'.</PARA>

<VARIABLELIST> <VARLISTENTRY> ;SFUN_GUILD_BASIS <DICTDEF> <PARA>This initializes the master and the only argument is the guild name</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

special SFUN_GUILD_BASIS "Udgaard Fighter"

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;SFUN_GUILD_MASTER <DICTDEF> <PARA>The guild master function takes 6 arguments. Like the teacher function the arguments must be surrounded by double quotes. The strings in the arguments must be surrounded by tilde marks (~). The following is a description of the arguments and what they do.</PARA>

<VARIABLELIST> <VARLISTENTRY> ;Line1: <DICTDEF> <PARA>The first argument on is what the guild name is. As in the teacher you need to pre-pend the '&l' symbol so the <ACRONYM>VME</ACRONYM> doesn't mess with the formatting of the string when the guild master is compiled.</PARA>

&lGuild = ~Udgaard fighter~

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <term>Line 2</term> <LISTITEM> <PARA>This argument is what quest needs to be done before the character can enter the guild.</PARA>

Guild Enter Quest = ~Fighter Proven~

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <term>Line 3</term> <LISTITEM> <PARA>This argument is the amount it costs to enter the guild in old gold pieces.</PARA> <INFORMALEXAMPLE><PROGRAMLISTING>

Guild Enter Cost = 640

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <term>Line 4</term> <LISTITEM> <PARA>this argument is the quest the player must do before leaving the guild. If the player has not completed this quest the guild master will not let the player leave.</PARA>

Guild Leave Quest = ~Wimp proven~

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <term>Line 5</term> <LISTITEM> <PARA>This argument is how much old gold pieces it will cost to quit the guild. If the player doesn't have enough money the guild master will not let the player join.</PARA>

Guild Leave Cost = 3200

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> <VARLISTENTRY> <term>Line 6</term> <LISTITEM> <PARA>This argument is what guild the guild master will not accept players from. For example the following will make it so no Thief can be in the fighter guild.</PARA>

Guild Exclude Quest = ~Udgaard Thief Quitter~

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<NOTE><PARA>When we refer to old gold pieces they represent the <ACRONYM>VME</ACRONYM> money system as shown in <xref linkend="oldgold"></PARA></NOTE>

<PARA>The following is what a full 'SFUN_GUILD_MASTER' function would look like</PARA>

special SFUN_GUILD_MASTER "&lGuild = ~Udgaard fighter~ Guild Enter Quest = ~Fighter Proven~ Guild Enter Cost = 640 Guild Leave Quest = ~Wimp proven~ Guild Leave Cost = 3200 Guild Exclude Quest = ~Udgaard Fighter Quitter~"

</PROGRAMLISTING></INFORMALEXAMPLE> </LISTITEM> </VARLISTENTRY>

<VARLISTENTRY> ;SFUN_GUILD_TITLES <DICTDEF>

<PARA>This function allows the player to request a title at the guild master. A title will be given every 5 levels up to level 100 so you have 20 titles you can set. The title function takes one title for male chars and one title for female chars so you have to set 40 titles.</PARA>

<PARA>The arguments of this function are easy. The first thing you do is the normal '&l' to let the <ACRONYM>VME</ACRONYM> know not to mess with this string. Then you put the guild name. Finally you follow it by the list of 40 titles. The following is the fighter guilds title list</PARA>

special SFUN_GUILD_TITLES "&lUdgaard fighter the %s Swordpupil the %s Swordpupil the %s Recruit the %s Recruit the %s Sentry the %s Sentress the %s Fighter the %s Fighter the %s Soldier the %s Soldier the %s Warrior the %s Warrior the %s Veteran the %s Veteran the %s Swordsman the %s Swordswoman the %s Fencer the %s Fenceress the %s Combatant the %s Combatess the %s Hero the %s Heroine the %s Myrmidon the %s Myrmidon the %s Swashbuckler the %s Swashbuckleress the %s Mercenary the %s Mercenaress the %s Swordmaster the %s Swordmistress the %s Lieutenant the %s Lieutenant the %s Champion the %s Lady Champion the %s Dragoon the %s Lady Dragoon the %s Cavalier the %s Cavalier the %s Knight the %s Lady Knight"

</PROGRAMLISTING></INFORMALEXAMPLE>

</LISTITEM> </VARLISTENTRY> </VARIABLELIST>

<PARA>Put all three of these functions on your NPC and your all set you have a guild master.</PARA> </sect2>

<sect2 id="specbank"> <TITLE>NPC banker</TITLE>

<PARA>The banker function is the easiest 'special' function there is to use. The following placed on an NPC will make a banker:</PARA>

special SFUN_BANK

</PROGRAMLISTING></INFORMALEXAMPLE>

<PARA>As you see its very simple, so we will just show you a completed banker and leave it at that.</PARA>

bob

names {"Bob"} title "Bob" descr "Bob the Banker is here, sitting behind the counter." extra {} "He has a very serious look on his face."

// define from composed.h M_SHOP_KEEPER(4, SEX_MALE, RACE_HUMAN)

//discourage people from killing banker exp -500

flags {UNIT_FL_NO_TELEPORT}

special SFUN_BANK end

</PROGRAMLISTING></INFORMALEXAMPLE> </sect2>

</SECT1>

<sect1 id="roomnpczone"> <TITLE>Dragon station with rooms and NPCs</TITLE>

<PARA>Now we will add the NPCs we have built to the zone from the previous chapter. This is still not complete while it does compile and you can log into your zone, you still have to load your NPCs and there are no objects. These will be added as you progress through this manual. The following is the source file so far.</PARA>

#include <composed.h> %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 whistler@valhalla.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."

%rooms

chamber title "The middle chamber of the station" descr "This chamber seems to have the entire station rotating around it. It is unbelievably large the ceiling seems to be a good 200 meeters high and the room is perfectly cubic. Small human size ornate chairs with dragon designs scrawled on the arms and back are arranged in a triangle like setting with one large chair at the front. This must be where all station meetings are held. large pictures cover the walls depicting dragons in all kinds of situations. large passages lead of to the west and the east.."

extra {"chair","chairs"} "The chairs are made of some metal you don't recognize and every inch is covered with some kind of dragon."

extra {"dragon picture","picture"} "Thousands of dragons dot the skies of this rather life like picture. In the center you see something move. It looks to be a little green dragon."

extra{"green dragon","dragon","green"} "An intellegence looking dragon is sitting perched on a large chair watching you."

movement SECT_INSIDE ALWAYS_LIGHT flags {UNIT_FL_NO_WEATHER, UNIT_FL_INDOORS}

west to disposal_room descr "You see a small room.";

east to hallway descr "You see what looks to be a hallway.";

end

hallway title "Module tunnel" descr "The hallway is about 50 meters long and around 100 meters from side to side and top to bottom. The hallway seems to be dust free. The walls and the floors seem to be made out of the same sterile metal-plastic that all space agencies uses. There are large plate glass windows that open up into space. The hallway is filled with a dim light that seems to come from everywhere yet no where all at once. You notice a glimmer of bright light coming from the windows. To the east you see an air lock and to the west the hallway opens up into a larger room."

extra {"windows","window"} "Your eyes are drawn to a large ship lit up with running lights sitting about 1 kilometer from the station."

extra{"floor","walls","wall"} "Well what can be said it looks to be in perfect condition. What else would you want to know?"