Added public files
Roughly added all public files. Probably missed some, though.
diff --git a/doc/KURS/LPC-KURS2/chapter6 b/doc/KURS/LPC-KURS2/chapter6
new file mode 100644
index 0000000..98b3552
--- /dev/null
+++ b/doc/KURS/LPC-KURS2/chapter6
@@ -0,0 +1,276 @@
+Intermediate LPC
+Descartes of Borg
+November 1993
+
+ Chapter 6: Intermediate Inheritance
+
+6.1 Basics of Inheritance
+In the textbook LPC Basics, you learned how it is the mudlib maintains
+consistency amoung mud objects through inheritance. Inheritance
+allows the mud administrators to code the basic functions and such that
+all mudlib objects, or all mudlib objects of a certain type must have so
+that you can concentrate on creating the functions which make these
+objects different. When you build a room, or a weapon, or a monster,
+you are taking a set of functions already written for you and inheriting
+them into your object. In this way, all objects on the mud can count on
+other objects to behave in a certain manner. For instance, player objects
+can rely on the fact that all room objects will have a function in them
+called query_long() which describes the room. Inheritance thus keeps
+you from having to worry about what the function query_long() should
+look like.
+
+Naturally, this textbook tries to go beyond this fundamental knowledge
+of inheritance to give the coder a better undertstanding of how
+inheritance works in LPC programming. Without getting into detail that
+the advanced domain coder/beginner mudlib coder simply does not yet
+need, this chapter will try to explain exactly what happens when you
+inherit an object.
+
+6.2 Cloning and Inheritance
+Whenever a file is referenced for the first time as an object (as opposed
+to reading the contents of the file), the game tries to load the file into
+memory and create an object. If the object is successfully loaded into
+memory, it becomes as master copy. Master copies of objects may be
+cloned but not used as actual game objects. The master copy is used to
+support any clone objects in the game.
+
+The master copy is the source of one of the controversies of mud LPC
+coding, that is whether to clone or inherit. With rooms, there is no
+question of what you wish to do, since there should only be one instance
+of each room object in the game. So you generally use inheritance in
+creating rooms. Many mud administrators, including myself, however
+encourage creators to clone the standard monster object and configure it
+from inside room objects instead of keeping monsters in separate files
+which inherit the standard monster object.
+
+As I stated above, each time a file is referenced to create an object, a
+master copy is loaded into memory. When you do something like:
+void reset() {
+ object ob;
+ ob = new("/std/monster");
+ /* clone_object("/std/monster") some places */
+ ob->set_name("foo monster");
+ ... rest of monster config code followed by moving
+it to the room ...
+}
+the driver searches to see if their is a master object called "/std/monster".
+If not, it creates one. If it does exist, or after it has been created, the
+driver then creates a clone object called "/std/monster#<number>". If
+this is the first time "/std/monster" is being referenced, in effect, two
+objects are being created: the master object and the cloned instance.
+
+On the other hand, let's say you did all your configuring in the create()
+of a special monster file which inherits "/std/monster". Instead of
+cloning the standard monster object from your room, you clone your
+monster file. If the standard monster has not been loaded, it gets loaded
+since your monster inherits it. In addition, a master copy of your file
+gets loaded into memory. Finally, a clone of your monster is created
+and moved into the room, for a total of three objects added to the game.
+Note that you cannot make use of the master copy easily to get around
+this. If, for example, you were to do:
+ "/wizards/descartes/my_monster"->move(this_object());
+instead of
+ new("/wizards/descartes/my_monster")->move(this_object());
+you would not be able to modify the file "my_monster.c" and update it,
+since the update command destroys the current master version of an
+object. On some mudlibs it also loads the new version into memory.
+Imagine the look on a player's face when their monster disappears in
+mid-combat cause you updated the file!
+
+Cloning is therefore a useful too when you plan on doing just that-
+cloning. If you are doing nothing special to a monster which cannot be
+done through a few call others, then you will save the mud from getting
+loaded with useless master copies. Inheritance, however, is useful if
+you plan to add functionality to an object (write your own functions) or
+if you have a single configuration that gets used over and over again
+(you have an army of orc guards all the same, so you write a special orc
+file and clone it).
+
+6.3 Inside Inheritance
+When objects A and B inherit object C, all three objects have their own
+set of data sharing one set of function definitions from object C. In
+addition, A and B will have separate functions definitions which were
+entered separately into their code. For the sake of example throughout
+the rest of the chapter, we will use the following code. Do not be
+disturbed if, at this point, some of the code makes no sense:
+
+OBJECT C
+private string name, cap_name, short, long;
+private int setup;
+
+void set_name(string str)
+nomask string query_name();
+private int query_setup();
+static void unsetup();
+void set_short(string str);
+string query_short();
+void set_long(string str);
+string query_long();
+
+
+void set_name(string str) {
+ if(!query_setup()) {
+ name = str;
+ setup = 1;
+}
+
+nomask string query_name() { return name; }
+
+private query_setup() { return setup; }
+
+static void unsetup() { setup = 0; }
+
+string query_cap_name() {
+ return (name ? capitalize(name) : ""); }
+}
+
+void set_short(string str) { short = str; }
+
+string query_short() { return short; }
+
+void set_long(string str) { long = str; }
+
+string query_long() { return str; }
+
+void create() { seteuid(getuid()); }
+
+OBJECT B
+inherit "/std/objectc";
+
+private int wc;
+
+void set_wc(int wc);
+int query_wc();
+int wieldweapon(string str);
+
+void create() { ::create(); }
+
+void init() {
+ if(environment(this_object()) == this_player())
+ add_action("wieldweapon", "wield");
+}
+
+void set_wc(int x) { wc = x; }
+
+int query_wc() { return wc; }
+
+int wieldweapon(string str) {
+ ... code for wielding the weapon ...
+}
+
+OBJECT A
+inherit "/std/objectc";
+
+int ghost;
+
+void create() { ::create(); }
+
+void change_name(string str) {
+ if(!((int)this_object()->is_player())) unsetup();
+ set_name(str);
+}
+
+string query_cap_name() {
+ if(ghost) return "A ghost";
+ else return ::query_cap_name();
+}
+
+As you can see, object C is inherited both by object A and object B.
+Object C is a representation of a much oversimplified base object, with B
+being an equally oversimplified weapon and A being an equally
+simplified living object. Only one copy of each function is retained in
+memory, even though we have here three objects using the functions.
+There are of course, three instances of the variables from Object C in
+memory, with one instance of the variables of Object A and Object B in
+memory. Each object thus gets its own data.
+
+6.4 Function and Variable Labels
+Notice that many of the functions above are proceeded with labels which
+have not yet appeared in either this text or the beginner text, the labels
+static, private, and nomask. These labels define special priveledges
+which an object may have to its data and member functions. Functions
+you have used up to this point have the default label public. This is
+default to such a degree, some drivers do not support the labeling.
+
+A public variable is available to any object down the inheritance tree
+from the object in which the variable is declared. Public variables in
+object C may be accessed by both objects A and B. Similarly, public
+functions may be called by any object down the inheritance tree from the
+object in which they are declared.
+
+The opposite of public is of course private. A private variable or
+function may only be referenced from inside the object which declares it.
+If object A or B tried to make any reference to any of the variables in
+object C, an error would result, since the variables are said to be out of
+scope, or not available to inheriting classes due to their private labels.
+Functions, however, provide a unique challenge which variables do not.
+External objects in LPC have the ability to call functions in other objects
+through call others. The private label does not protect against call
+others.
+
+To protect against call others, functions use the label static. A function
+which is static may only be called from inside the complete object or
+from the game driver. By complete object, I mean object A can call
+static functions in the object C it inherits. The static only protects against
+external call others. In addition, this_object()->foo() is considered an
+internal call as far as the static label goes.
+
+Since variables cannot be referenced externally, there is no need for an
+equivalent label for them. Somewhere along the line, someone decided
+to muddy up the waters and use the static label with variables to have a
+completely separate meaning. What is even more maddening is that this
+label has nothing to do with what it means in the C programming
+language. A static variable is simply a variable that does not get saved to
+file through the efun save_object() and does not get restored through
+restore_object(). Go figure.
+
+In general, it is good practice to have private variables with public
+functions, using query_*() functions to access the values of inherited
+variables, and set_*(), add_*(), and other such functions to change
+those values. In realm coding this is not something one really has to
+worry a lot about. As a matter of fact, in realm coding you do not have
+to know much of anything which is in this chapter. To be come a really
+good realm coder, however, you have to be able to read the mudlib
+code. And mudlib code is full of these labels. So you should work
+around with these labels until you can read code and understand why it
+is written that way and what it means to objects which inherit the code.
+
+The final label is nomask, and it deals with a property of inheritance
+which allows you to rewrite functions which have already been defined.
+For example, you can see above that object A rewrote the function
+query_cap_name(). A rewrite of function is called overriding the
+function. The most common override of a function would be in a case
+like this, where a condition peculiar to our object (object A) needs to
+happen on a call ot the function under certain circumstances. Putting test
+code into object C just so object A can be a ghost is plain silly. So
+instead, we override query_cap_name() in object A, testing to see if the
+object is a ghost. If so, we change what happens when another object
+queries for the cap name. If it is not a ghost, then we want the regular
+object behaviour to happen. We therefore use the scope resolution
+operator (::) to call the inherited version of the query_cap_name()
+function and return its value.
+
+A nomask function is one which cannot be overridden either through
+inheritance or through shadowing. Shadowing is a sort of backwards
+inheritance which will be detailed in the advanced LPC textbook. In the
+example above, neither object A nor object B (nor any other object for
+that matter) can override query_name(). Since we want to use
+query_name() as a unique identifier of objects, we don't want people
+faking us through shadowing or inheritance. The function therefore gets
+the nomask label.
+
+6.5 Summary
+Through inheritance, a coder may make user of functions defined in
+other objects in order to reduce the tedium of producing masses of
+similar objects and to increase the consistency of object behaviour across
+mudlib objects. LPC inheritance allows objects maximum priveledges in
+defining how their data can be accessed by external objects as well as
+objects inheriting them. This data security is maintained through the
+keywords, nomask, private, and static.
+
+In addition, a coder is able to change the functionality of non-protected
+functions by overriding them. Even in the process of overriding a
+function, however, an object may access the original function through
+the scope resolution operator.
+
+Copyright (c) George Reese 1993