Crashcourse - Part 15

[previous part] [Table of contents]

In this course we want to take a look at our new containers. You will learn how to create them easily, how to add special features and use them effectively within quests.

If you think you're already smart enough (don't you?) you can simply read the container documentation ('man container') and start to code them on your own. Here's a small example to start with:


You'll notice that we include both 'mudlib.h' AND 'container.h'. Almost all functions of the containers take defined arguments (just like 'TRUE' and 'FALSE') so it will be best to use these defines right away. And to make use of these defines you have to include the 'container.h'. We start by inheriting the standard container. The rest should be pretty obvious - apart from a few new functions.

set_max_weight() is used to tell the object how heavy the inventory can be in total (meaning the sum of the items you can put into the container). Set_weight() sets the weight of the bag itself (as usual).

NOTE: Please note that the item system (as we are using it right now) is not 'realistic' and the bags actually 'cheat' to allow you to carry more items. Because we are using only the 'weight' measure it is not possible to check the 'size' of objects - and hence this cheat is necessary to make any use of bags at all. This system will be changed as soon as someone has enough time to re-think this whole inventory stuff and implements it. Until then remember to set the max weight to a value that makes sense in game-play.

The next new functions are set_can_open() and set_def_open(). The first one tells the object that it can be opened in general. When you omit this line the object will be always open (like a box without lid). At the time the object is cloned it will be closed. If you want it to be open you can use the function set_open() to change the state of the container.
By default the container will remain unchanged whenever a reset occurs. To change that you can use the function set_def_open() and the state of the container will be set according to the parameter you used in the function. You can use TRUE, FALSE and INDIFFERENT. The latter is the default value and means the state of the container won't change at all. Usually you wouldn't want to change this value. However, whenever coding special (quest) containers it is usefull if the container is set up to its original state and the quest is ready for the next player.

Now, how about some special stuff in our containers?

FILENAMES: small_chest.c and key.c

This small chest can be locked. You need a keyobject with the same keycode to unlock it. Let's take a look at the new functions in this object (remember to read the man pages for these functions to find out what arguments can also be used).

The first new functions are set_can_lock() and set_def_lock(). They work similarly to the 'open'-functions. The function set_keycode() is used to define which key can open the chest. Remember to set the same keycode in the corresponding key (look at the key-example). Only then the key can be used to unlock the chest.

Only thing left is the messaging stuff. You can use the function set_msgs() to set up your own messages. By default messages will be printed to the player and the room, whenever a status of the container has changed (container has been opened or locked or the like). Type 'man set_msgs' to get some examples for the use of this function. In our small chest the open/close-messages for the player have be altered. Furthermore the messages to the room for all four actions have been changed. Using the latter synopsis you can set the msgs-array with one function call only (however, if you would set all messages seperately the result would be the same). Just try it out - create your own container and try to change the messages so that something more exciting is printed to the player or the room.
(btw, you can change the default reset messages, too. This way you can reset the status of a container and noone will notice it).

Ok, this is quite a lot (and easy to do, right?), so what other specials are there? Take a look at:

FILENAME: iron_chest.c and iron_chest_funcs.c

The key for the other chest will open this one as well, but let's take a look at the new things. At first you will notice that the parameters for set_msgs() are 0. Whenever a message is set to zero no message will be printed at all. So it's up to you to print your own messages whenever the status of the container changes. But how can you call your own functions? Again, 'HOOKS' is the answer. If you are not familiar with hooks read the Part 5 of the crashcourse first. If you ARE familiar with hooks then it should be fairly simple to understand what's been done in this example. Read the man pages of the __open, __close, __lock and __unlock hooks and you'll know about the default parameters. Well, after all it's just a little example what you can do with a container. It's up to you to create dungeons and treasure vaults with many locked chests that contain the biggest and most valuable treasures a player can find. And you can set up dangerous traps using hooked functions. And you can do alot more with the new containers... not only chests! (Ever thought of wardrobes, coffins with mummies inside... oops, I should better use these ideas myself to code some really tough dungeons :-) Ghorwin - March 2001

WRITTEN: 26-Mar-2001 - Ghorwin
LAST UPDATE: 26-Mar-2001 - Ghorwin

[previous part] [to the top] [Table of contents]