-=[ LPC Basics ]=- directives (preprocessors): LPC allows most of the ANSI preprocessor controls. Since this is only a light brush of LPC, I will deal only with the directives, #define, #undef, and #include. I will leave an explanation of conditional directives later. #define: The #define directive allows you to do a macro substitution. The directive defines an identifier, that substitutes a string when encountered in the source file. Example: #define query_name() QN will substitute 'query_name()' whenever 'QN' is found in your code. #define can used more powerfully as a psuedo- function, #define PAY(XXX) this_player()->add_money(-XXX) if PAY(20) was called then, 20 coins would be deducted from this_player(). The macro does not have to be only one line, #define MOVE_OBJ(NN,FF) if(!present(NN,this_object())) {\ move_object(clone_object(FF),this_object());\ } However, you must be careful using pseudo-functions. They are not very leanient. For example, MOVE_OBJ("bob","players/zilanthius/monsters/bob"); would work fine. But, MOVE_OBJ( "bob", path+"/monsters/bob"); would not work. One because of the spaces, and two because of the 'path+'. #undef: #undef un-defines a macro. Why have this? There are times when you do not want a particular macro defined, that was carried through with an #include "file". example: cloning a bag into a room using room.h #include "/include/room.h" #undef EXTRA_RESET #define EXTRA_RESET if(!present("bag,this_object())) {\ move_object(clone_object("objects/bag"),this_object());\ } #include: The #include directive instructs the compiler to read another file for 'library' routines. In effect it adds the file to the 'head' file to the top of your object.'file.h' files are known as "header" files for this reason. #include "/include/array.h" Will instruct the compiler to put /include/array.h at the head of the file. For example the function, write_file_array(filename,your_array); can be used if array.h is included. (write_file_array() writes an array of strings, or ints line by line into filename). Some wizards make a "path.h" header file for directory paths. Eg. "path.h" #define PATH "/players/zilanthius/" #define OBJ "/players/zilanthius/obj/" #define MONSTER "/players/zilanthius/monsters/" #define WEAPON "/players/zilanthius/weapons/" etc. inherit: I don't have a clear concept of the hows and whys of inheritance. But I will have a go at explaining it. So please forgive any misconceptions. Inherit says that this new object is the same as an old one, plus some modifications. It is useful because it conserves coding effort. It is already debugged. Secondly, it has all the standard criteria that other objects expect to see in another object for the mud to run smoothly. Since Lpc is object orientated, objects already have a series of hard-coded functions that can be applied to that object. For example, file_name(ob). However, lpc allows you to "soft-coded" functions available in that object. When then object is loaded, these soft-coded functions are loaded into memory. For example, short(). This is fine when you have one object, but if you make unique objects for everything, then the machines memory is going to be filled with objects; objects must contain an objects global variables, and the soft-coded functions to manipulate those variables. But if you look at those soft-coded functions, most mirror each other. It is only the abstract variables in the functions that change. So inheritance allows you to cut down memory usage, by loading only one copy of the soft-coded function into memory and using that function as a mirror. Cloning an object seems to do the same thing, except, that it is exact copy rather, than a manipulation of a mirror. The main point is that using the configurable objects (bag, armour, weapons, monster, etc) saves mud memory, and also gives the overall mud a general consistency.