Difference between revisions of "Manual:Zone Manual/The Objects Section"
Line 684: | Line 684: | ||
Then we put some to work so you can see how | Then we put some to work so you can see how | ||
to use them in (Link to objcomplex) | to use them in (Link to objcomplex) | ||
+ | |||
+ | <div style='padding-top: 30px; padding-bottom: 20px; text-align: left;float:left;width:50%;'>[[Manual:Zone_Manual/The_NPC_Section/Suggested_NPC_exercises|Previous: Suggested NPC exercises]]</div> | ||
+ | <div style='padding-top: 30px; padding-bottom: 20px; text-align: right;float:right;width:50%;'>[[Manual:Zone_Manual/The_Objects_Section/Object_macros|Next: Object macros]]</div> |
Latest revision as of 11:32, 26 May 2020
The objects section
The previous chapters would be enough for you to create an entire game of nudists with no technology and no items of any kind. This of corse would be a very boring game of naked people fighting with no weapons. don't worry the VME has a solution to this you can build objects to dress up the NPCs and to fill the rooms with cluttered junk.
In order to get started building objects you should first be aware of the object fields you can use. The (Link to objfields) shows a full listing of all the object fields and their types as defined in (Link to ch-03).
Field | Type | Field | Type |
---|---|---|---|
symbolic name | Symbol | affect | affect function |
names | Stringlist | dilbegin or dilcopy | function pointer |
title | String | key | String |
descr | String | open | Integer |
inside_descr | String | manipulate | Integer |
extra | Structure | spell | Integer |
minv | Integer | value | Integer |
alignment | Integer | cost | Integer |
flags | Integer | rent | Integer |
weight | Integer | type | Integer |
capacity | Integer | end tag | Symbol |
light | Integer |
Many of the same fields you found in rooms and NPCs, as you can see from (Link to objfields), can also be found in objects. 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, objects, and or NPCs.
Description of object fields
- symbolic name
- The rules of the symbols has been explained in
(Link to ch-03), if you didn't read them yet you may want to review. The important thing to realize with the object symbol is it is always good practice to give the object a symbol that resembles the title and description so administrators and builders can use the load and the wstat to easily locate, examine, and load the object in question.
- title
- The object title is what is shown if the object is being picked up, dropped, given to someone, when you do the inventory command, , or being used in combat.
there should be no punctuation in the object title because of how it is used in the VME server. If you add punctuation or forget to capitalize something that the VMC thinks you should it will give you a warning when you compile. The following are good examples of an object title.
title "a big rock" title "the flame tongue" title "a lap top" title "a garbage bag" title "an oval hover car"
- descr
The description field is what the player sees when walking into the room or when looking with no arguments. It is good practice to make this no longer than one line not counting the 'descr' tag.
Some examples of the object description field would be as follows:
descr "a green bloody sword is laying here." descr "A massive wooden round table sits here." descr "a funny looking hammer is laying here."
- names
- The object names are as important as the NPC names. They are what you act on when picking the object up, dropping it, throwing it, just about anything you do to objects use these name fields. On drink containers you add the liquid name at the end, so people can drink the liquid. You always need to make sure you put every possible name that the player may use to examine or take your item. The rule of thumb is if it is in the title or description it should be in the names list. conversely if it is not in the title or description it shouldn't be in the names list because the players will not use it if they don't know about it.
The following is some examples of good 'names' fields with respect to their 'title' and 'descr'.
title "a big rock" descr "a big rock is here blocking the road." names {"big rock","rock"} title "an old twisted staff" descr "An old twisted staff has been discarded here." names{"old twisted staff","twisted staff","old staff","staff"}
The idea of course is to make any combination that a player may type to try and act upon your object. You would not want to describe and title your object with an entirely different theme than you created its names with because a player would not know what it is called.
- inside_descr
- The inside description is what a player sees if it is inside the object. This is used for things like Coffins or boxes or boats that a player can climb inside. The inside description is defined the same way the normal description is but you can make it as many lines as you want like you would with a room description.
inside_descr "You are inside a black coffin with a red velvet padding - scary!" inside_descr "You are inside the pink time machine. a small control panel is on the floor and seems to be operated by stepping on it."
- extra
- The extra's on the object like the NPC, can be used to do many things. It can be used to store information for DIL programs or it can be used to show a part of the object like the room extras show a part of the room. They can even be used to create new acts when a person picks the item up,
drops, or enters it.There is also a special extra that is the object's description when you look at it with the look <object> command.
Lets go over the object description extra first. If you use an extra with no names list it will become the object's description when you look at any of the names on it.
extra {} "Its just a rock nothing special about it." extra {} "The ice cube is about 40 meters perfectly cubed. It seems to be melting slightly but waiting for it to finish would be sort of like waiting for the ice age to end."
You can also use extras to show parts of the object.
extra {"crack"} "There is a big crack in the side of the ice cube. Maybe if you mess with the crack you will be able to open it or something." extra {"bed post","post"} "Its a big gold bed post don't you wish you could get this sucker off it would make you a rich adventurer indeed."
You can also use the extras to give more detailed and vivid descriptions when the object is acted upon.
Extra | Description |
---|---|
$wear_s | A message shown to activator when wearing (+wield/grab/hold) an
item. |
$wear_o | A message shown to others when wearing an item. |
$rem_s | A message shown to activator when removing worn stuff. |
$rem_o | A message shown to others when removing an item. |
$get_s | A message shown to activator when getting an item. |
$get_o | A message shown to others when getting an item. |
$drop_s | A message shown to activator when dropping an item. |
$drop_o | A message shown to other when dropping an object. |
$enter_s | A message shown to activator when entering an item. |
$enter_o | A message shown to other when entering an item. |
$exit_s | A message shown to activator when leaving an item. |
$exit_o | A message shown to other when leaving an item. |
In the following example of an ice cube, 1n is the activator and $2n is the unit in question.
extra {"$get_s"} "You pick up the $2N, it is very cold and begins to melt in your hands." extra {"$get_o"} "$1n picks up the $2N, you notice that a drop of water hits the ground as it begins to melt in $1s hand."
Finally you can use extras to store information for DIL programs. We will not cover this because it is a topic covered in-depth in the DIL documentation.
- manipulate
- This field is what defines the things that can be done to the object. For example a piece of armour should be able to be taken and worn, while a fountain should be able to be entered but not taken unless its some magical portable fountain. There are two sets of manipulate flags even though you can use them together. We separate them because the first two are flags that tell you if you can take or enter something while the rest of the manipulate flags are for worn positions.
First the two flags for taking and entering are:
Manipulate | Description |
---|---|
MANIPULATE_TAKE | Set this flag if the unit can be taken
(picked up/moved about). |
MANIPULATE_ENTER | Set this flag if it is possible to
enter a unit, ie set it in a coffin if you want players to be able to enter the coffin. |
These flags are set to indicate on what body positions a particular object can be worn:
- MANIPULATE_WEAR_FINGER
- MANIPULATE_WEAR_NECK
- MANIPULATE_WEAR_BODY
- MANIPULATE_WEAR_HEAD
- MANIPULATE_WEAR_LEGS
- MANIPULATE_WEAR_FEET
- MANIPULATE_WEAR_HANDS
- MANIPULATE_WEAR_ARMS
- MANIPULATE_WEAR_SHIELD
- MANIPULATE_WEAR_ABOUT
- MANIPULATE_WEAR_WAIST
- MANIPULATE_WEAR_WRIST
- MANIPULATE_WIELD
- MANIPULATE_HOLD
- MANIPULATE_WEAR_EAR
- MANIPULATE_WEAR_BACK
- MANIPULATE_WEAR_CHEST
- MANIPULATE_WEAR_ANKLE
Currently you can only set one of the worn positions flags on an item at a time. You can set both enter and take on an item with a position or just one or the other. Some legal examples of combinations are as follows:
//An earring manipulate {MANIPULATE_TAKE, MANIPULATE_WEAR_EAR} //A backpack manipulate {MANIPULATE_TAKE, MANIPULATE_ENTER, MANIPULATE_WEAR_BACK} //strange true but its legal an earring pack manipulate {MANIPULATE_TAKE, MANIPULATE_ENTER, MANIPULATE_WEAR_EAR}
- flags
- This field on an object is used to set special attributes in order to make the object able to be buried or not or no-teleportable and many others. The object flag list uses the UNIT_FL_* variables that both the NPCs and the rooms also use, therefore while you can set some flags on an object it may not have any affect unless you as a builder or administrator adds the functionality. You can also add extras on an object that can be used as a special flag which you will learn as you learn to use DIL. The following is a full list of all unit flags and how they affect objects, if they do.
Flag | Description |
---|---|
UNIT_FL_PRIVATE | Currently has no affect on a NPC. |
UNIT_FL_INVISIBLE | Makes unit invisible |
UNIT_FL_NO_BURY | Makes it so you can create objects that
can not be buried for example a weapon that for some reason shouldn't be buried. |
UNIT_FL_BURIED | Makes
unit buried when loaded |
UNIT_FL_NO_TELEPORT | Makes it so you can not teleport into this object. This flag only
works on containers. |
UNIT_FL_NO_MOB | Currently has no affect on an object. |
UNIT_FL_NO_WEATHER | Currently has no affect on a NPC. |
UNIT_FL_INDOORS | Currently has no affect on an object. |
UNIT_FL_TRANS | Makes unit transparent If the Unit is
transparent you will be able to see any NPCs that it is carrying. For example if a canoe was carrying a familiar you would see that as you walked into the room. If this flag is not set and you are in a canoe you will not see outside the canoe and no one will see in. |
UNIT_FL_NO_SAVE | Makes it so a PC can't save with
unit |
UNIT_FL_SACRED | Currently has no affect on an object. |
UNIT_FL_MAGIC | This flag is used by spells to tell if the object is magic. |
If you wanted to make an object that a player can carry around but can not save you would set the manipulate and flags as follows.
manipulate {MANIPULATE_TAKE} flags {UNIT_FL_NO_SAVE}
- type
- This field is what you use to set the objects type. The type field is used when spells are cast or commands are executed on the object. You can add your own item types but they will not change the actions of base code commands. The following is the list of item types and what they mean when you set them. Some are not supported with the current code but you can add support for them if you like by making DIL commands, which is covered in another manual.
Type | Description |
---|---|
ITEM_LIGHT | Items of this type can be lighted and extinguished. |
ITEM_SCROLL | Items of this type can be read as a magical scroll. |
ITEM_WAND | Items of this type can be used with the use
command. |
ITEM_STAFF | Items of this type can be used with the tap
command as a magical staff |
ITEM_WEAPON | Items of this type are used as weapons. |
ITEM_FIREWEAPON | Currently not supported but could be used to classify a special type
of weapon. |
ITEM_MISSILE | Currently not supported but could be used to classify a special type
of weapon. |
ITEM_TREASURE | Items of this type are of some great value to sell but nothing else
like a Gem or a block of gold. |
ITEM_ARMOR | Items of this type can be worn or used as armour. |
ITEM_POTION | Items of this type can be used with the quaff as
a position. |
ITEM_WORN | Items of this type can be worn but not normally used for armour it
is more for clothing. |
ITEM_OTHER | This item type is for items that don't fit any other type. Now
that you can make your own commands with the VME 2.0 you should just make your own item type instead of using this value. |
ITEM_TRASH | Items of this type are usually junk or broken equipment. |
ITEM_TRAP | Not currently supported but could be used to make a trap command by
creating a trap item |
ITEM_CONTAINER | Items that can be used as containers. |
ITEM_NOTE | Items of this type can be used to write on like paper or
slates. |
ITEM_DRINKCON | Items of this type can carry liquids. |
ITEM_KEY | Items of this type can be used as a key. |
ITEM_FOOD | Items of this type can be eaten |
ITEM_MONEY | Items of this type can be spent as currency |
ITEM_PEN | No longer supported but could be used to force people to have a
writing instrument before writing a message. |
ITEM_BOAT | Items of this type can be used as a water craft |
ITEM_SPELL | Not currently supported but it could be used to make a page in a spell book |
ITEM_BOOK | Not currently supported but could be used to make
regular and spell books. |
ITEM_SHIELD | Items of this type can be used as a shield. |
ITEM_SKIN | Not currently supported in the release but could be used to make the
skin command and create skins of animals |
ITEM_BOARD | Items of this type are used for public communications in the form
of boards that can be read from and written to. |
Unlike flags and manipulate fields only one item type can be set on an object at a time. The format for the 'type' field is simply the keyword followed by the value as follows:
type ITEM_BOARD
- weight
- The weight is the weight of the object 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.
To use this you just enter the 'weight' keyword and then the value.
/80 lbs. weight 80
- capacity
- This field sets the size of a container object. If the object does not have the manipulate enter flag set then this field doesn't have to be set. The capacity is currently by pounds since the weight of objects is set in pounds. In the future we may take into account size and weight but right now it goes only by weight. The following line of code would set an item to carry 600 pounds of stuff.
capacity 600
- key
- The key field sets the key name of the key that will open the item. This field should be set to the symbolic name of the key that opens the item it is on. If the item is in the same zone as the key then you do not need to put the zone extension on the key name. The following are the three possible examples of using the key field.
//if object and key are in same zone. key brasskey //if key and object are in same zone key brasskey@zonename //if key and object are not in same zone key brasskey@otherzonename
Notice you can put the zone name on it if the key is in the same zone but if the key is not in the same zone you must put the zone name on it.
- cost
- This is the field you set to add a cost to your object. If you leave this field out it will default to no cost and will not be able to be sold at stores. The system for setting cost on an item is the same as setting money on a NPC. As with a NPC we could set it using a single number but it would not be easy to understand. For example 5 gold pieces would be something like:
money 25600
I am no more sure this will make five gold pieces than I was when I used this same example with the money field in NPC. The problem is I just did the math in my head so its not very accurate. It is much easier to use the defined money types to set exactly what you want as follows:
IRON_PIECE COPPER_PIECE SILVER_PIECE GOLD_PIECE PLATINUM_PIECE
Now if we wanted to make an object costing five gold it would be as simple as this:
money 5*GOLD_PIECE
the define method also gains you the ability to tell the VME 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 cost however you like. So setting more than one coin is as simple as adding a comma between the first and second coin.
money 5*GOLD_PIECE, 20*IRON_PIECE
- rent
- This field tells how much it costs you to keep an item while your offline. The rent is not always taken if the VME server is set up to not take any rent then it will not matter if you set this or not. Also the VME can be set up to take a percentage of this field so it may not take the exact amount you et. If the VME server is set up to take 100%
of the rent then what you set will be taken. To set this field you do the same as you do with the cost field.
money 5*GOLD_PIECE, 20*IRON_PIECE
- minv
- This field is the administrator invisible level of the object it is set on. This means that if you set the 'minv' to two hundred it will make it so the object can not be seen by anyone below the administrator level of two hundred. This is good for hiding objects that you need for administrators but you don't want players to see.
In order for the 'minv' to be removed an administrator or a DIL function must change it.
minv 239
- alignment
- The object alignment is not currently used. It is an integer value that can be set on an object to be used with any DIL functions.
In the future it will be what determines if a good or evil person can wield an item. The value is set by placing the 'alignment' keyword first followed by the alignment desired from -1000 to +1000.
alignment -250
- open
- The open field is used if you want to give your object the ability to be opened, closed, and or locked. If you add the open flags you need to also add a key field which has already been explained.
The following are all the possible open flags and what they are used for.
- EX_OPEN_CLOSE
- Set this if you can open and close this object.
- EX_CLOSED
- Set this if you want the object to be closed when loaded.
- EX_LOCKED
- Set this if you want the object to be locked when loaded.
An interesting aspect is that if you do not specify a key, you can only unlock this door with the 'pick' skill, 'unlock' spell or from DIL with UnSet();
- EX_PICK_PROOF
- Using this flag renders the 'pick' skill and 'unlock' spell un useable on the lock of this object.
- EX_INSIDE_OPEN
- Usable on container objects only, this enables the mobile to 'open' and
'lock' from the inside.
The simplest use of this field is to make an object that opens and closes. A coffin for example would have its flags set as follows:
open {EX_OPEN_CLOSE}
If you wanted to set an object that is locked and closed and having a brass key that can open it, when it is loaded. It would look as follows.
open {EX_OPEN_CLOSE, EX_CLOSED, EX_LOCKED} key brass_key
You would have to define the key in the object section as well and the symbolic name for that key would be 'brass_key'
- spell
- The spell field is the power of the objects defense against spells. You can set it from zero which is just not setting the field all the way to 200% which means a person who has 100% in a spell will fail almost all the time. To set this field it would look as follows:
//Spell resistance at 150% spell 150
- value
- The object values are used for just about any special item from armour to drink containers. They should not be set directly unless you have a reason to do so, like a special DIL command that checks a value on an item. You also have to be carefull not to over write what a value is already used for example value one is already used on weapons and armours for craftsman ship that will be explained later in
(Link to objmacros).
If you find you need to set the values there are a total of five of them and they can be set to any integer value as follows:
value[0] 5 value[1] 16 value[2] -2 value[3] -10 value[4] 12
- affect
- The affect field should not be set directly, instead you should use the macros defined in (Link to objmacros).
- dilbegin or dilcopy
- As has been mentioned in previous sections the DIL functions are what give VME servers the edge over all other muds.
We will only give some examples here and leave it up to the DIL manual to teach you how to create your own functions that will make your rooms, NPC, and objects more than special.
There are several object functions that come standard with the VME 2.0. The following is a list of those functions.
- Guild restrict
- Anti-guild restrict
- Quest restrict
- Quests restrict
- Alignment restrict
- Level restrict
- Virtual level restrict
- Race restrict
- Ability restrict
- Skill restrict
- Spell restrict
- Weapon restrict
- Gender restrict
- Player restrict
- boards
- tuborg/dilbegin
These are the only object functions currently documented in the VME 2.0 release but if you go through the zones that are released with the VME you are sure to find many more. Hopefully with the descriptions in (Link to objdilfunc). You will be able to use the functions listed here and figure out ones that are not.
Since these are just DIL'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 requires. The following is what you would find in the function.zon for tuborgs.
dilbegin tuborg(s:string); external sub_drink_info@commands(d:unitptr); var u : unitptr; code { :start: wait(SFB_CMD, ( (command("drink")) or (command("sip")) or (command("taste")) ) ); u := activator; secure (u,start); if (findunit (activator,argument,FIND_UNIT_INVEN|FIND_UNIT_SURRO,null)!=self) goto start; if ( command("sip") or command("taste") ) { block; act("$1n tastes $2n enjoying every drop.", A_HIDEINV, u, self, null, TO_ROOM); act("The taste of the $2N is nothing less than divine.", A_HIDEINV, u, self, null, TO_CHAR); goto start; } if ( u.thirst >20 ) { block; act("Your not thirsty.", A_HIDEINV, u, null, null, TO_CHAR); goto start; } block; act ("You drink $2n and it makes you feel more energetic!", A_HIDEINV, u, self, null, TO_CHAR); act ("$1n drinks $2n and looks more energetic!", A_HIDEINV, u, self, null, TO_ROOM); u.thirst := u.thirst + 10; u.full := u.full + 10; if (u.thirst > 24) { u.thirst := 24; } if (u.full > 24) { u.full := 24; } u.endurance := u.endurance+50; if (u.endurance > u.max_endurance) { u.endurance := u.max_endurance; } sub_drink_info@commands(self); quit; } dilend
If this DIL 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 DIL to use. The argument on the tuborg function is not used yet so all you have to do is pass in a blank string or any string for that matter. So if you wanted to make a tuborg in the game you would just add this to your drink container.
dilcopy tuborg@function ("");
All of the above listed DIL object functions are described in (Link to objdilfunc). Then we put some to work so you can see how to use them in (Link to objcomplex)