diff --git a/doc/KURS/LPC-KURS/chapter5 b/doc/KURS/LPC-KURS/chapter5
new file mode 100644
index 0000000..29d2a0c
--- /dev/null
+++ b/doc/KURS/LPC-KURS/chapter5
@@ -0,0 +1,161 @@
+                           LPC Basics
+                  Written by Descartes of Borg
+                  first edition: 23 april 1993
+                  second edition: 01 july 1993
+
+CHAPTER 5: The Basics of Inheritance
+
+5.1 Review
+You should now understand the basic workings of functions.  You should be
+able to declare and call one.  In addition, you should be able to recognize
+function definitions, although, if this is your first experience with LPC,
+it is unlikely that you will as yet be able to define your own functions.
+There functions form the basic building blocks of LPC objects.  Code
+in them is executed when another function makes a call to them.  In making
+a call, input is passed from the calling function into the execution of
+the called one.  The called function then executes and returns a value
+of a certain data type to the calling function.  Functions which return
+no value are of type void.
+
+After examining your workroom code, it might look something like this
+(depending on the mudlib):
+
+-----
+inherit "/std/room";
+
+void create() {
+    ::create();
+    set_property("light", 2);
+    set_property("indoors", 1);
+    set("short", "Descartes' Workroom");
+    set("long", "This is where Descartes works.\nIt is a cube.\n");
+    set_exits( ({ "/d/standard/square" }), ({ "square" }) );
+}
+-----
+
+If you understand the entire textbook to this point, you should recognize
+of the code the following:
+    1) create() is the definition of a function (hey! he did not declare it)
+    2) It makes calls to set_property(), set(), and set_exits(), none
+       of which are declared or defined in the code.
+    3) There is a line at the top that is no variable or function declaration
+       nor is it a function definition!
+
+This chapter will seek to answer the questions that should be in your head
+at this point:
+    1) Why is there no declaration of create()?
+    2) Where are the functions set_property(), set(), and set_exits() declared
+       and defined?
+    3) What the hell is that line at the top of the file?
+
+5.2 Object oriented programming
+Inheritance is one of the properties which define true object oriented
+programming (OOP).  It allows you to create generic code which can be used
+in many different ways by many different programs.  What a mudlib does is
+create these generalized files (objects) which you use to make very specific
+objects.
+
+If you had to write the code necessary for you to define the workroom above,
+you would have to write about 1000 lines of code to get all the functionality
+of the room above.  Clearly that is a waste of disk space.  In addition,
+such code does not interact well with players and other rooms since every
+creator is making up his or her own functions to perform the functionality
+of a room.  Thus, what you might use to write out the room's long description,
+query_long(), another wizard might be calling long().  This is the primary
+reason mudlibs are not compatible, since they use different protocols for
+object interaction.
+
+OOP overcomes these problems.  In the above workroom, you inherit the
+functions already defined in a file called "/std/room.c".  It has all
+the functions which are commonly needed by all rooms defined in it.  When
+you get to make a specific room, you are taking the general functionality
+of that room file and making a unique room by adding your own function,
+create().
+
+5.3 How inheritance works
+As you might have guessed by now, the line:
+
+-----
+inherit "/std/room";
+-----
+
+has you inherit the functionality of the room "/std/room.c".  By inheriting
+the functionality, it means that you can use the functions which have
+been declared and defined in the file "/std/room.c"  In the Nightmare Mudlib,
+"/std/room.c" has, among other functions, set_property(), set(), and
+set_exits() declared and defined.  In your function create(), you are
+making calls to those functions in order to set values you want your
+room to start with.  These values make your room different from others, yet
+able to interact well with other objects in memory.
+
+In actual practice, each mudlib is different, and thus requires you to use
+a different set of standard functions, often to do the same thing.  It is
+therefore beyond the scope of this textbook even to describe what
+functions exist and what they do.  If your mudlib is well documented,
+however, then (probably in /doc/build) you will have tutorials on how
+to use the inheritable files to create such objects.  These tutorials
+should tell you what functions exist, what input they take, the data
+type of their output, and what they do.
+
+5.4 Chapter summary
+This is far from a complete explanation of the complex subject of inheritance.
+The idea here is for you to be able to understand how to use inheritance in
+creating your objects.  A full discussion will follow in a later textbook.
+Right now you should know the following:
+    1) Each mudlib has a library of generic objects with their own general
+       functions used by creators through inheritance to make coding objects
+       easier and to make interaction between objects smoother.
+    2) The functions in the inheritable files of a mudlib vary from mudlib
+       to mudlib.  There should exist documentation on your mud on how to
+       use each inheritable file.  If you are unaware what functions are
+       available, then there is simply no way for you to use them.  Always
+       pay special attention to the data types of the input and the data
+       types of ay output.
+    3) You inherit the functionality of another object through the line:
+
+-----
+inherit "filename";
+-----
+       
+       where filename is the name of the file of the object to be inherited.
+       This line goes at the beginning of your code.
+
+Note:
+You may see the syntax ::create() or ::init() or ::reset() in places.
+You do not need fully to understand at this point the full nuances of this,
+but you should have a clue as to what it is. The "::" operator is a way
+to call a function specifically in an inherited object (called the scope
+resolution operator).  For instance, most muds' room.c has a function
+called create().  When you inherit room.c and configure it, you are doing
+what is called overriding the create() function in room.c.  This means
+that whenever ANYTHING calls create(), it will call *your* version and not
+the one in room.c.  However, there may be important stuff in the room.c
+version of create().  The :: operator allows you to call the create() in
+room.c instead of your create().
+An example:
+
+-----
+#1
+
+inherit "/std/room";
+
+void create() { create(); }
+-----
+
+-----
+#2
+
+inherit "/std/room";
+
+void create() { ::create(); }
+-----
+
+Example 1 is a horror.  When loaded, the driver calls create(), and then
+create() calls create(), which calls create(), which calls create()...
+In other words, all create() does is keep calling itself until the driver
+detects a too deep recursion and exits.
+
+Example 2 is basically just a waste of RAM, as it is no different from room.c
+functionally.  With it, the driver calls its create(), which in turn calls
+::create(), the create() in room.c.  Otherwise it is functionally
+exactly the same as room.c.