diff --git a/doc/KURS/LPC-KURS/chapter8 b/doc/KURS/LPC-KURS/chapter8
new file mode 100644
index 0000000..a794713
--- /dev/null
+++ b/doc/KURS/LPC-KURS/chapter8
@@ -0,0 +1,195 @@
+                           LPC Basics
+                  Written by Descartes of Borg
+                  first edition: 23 april 1993
+                  second edition: 12 july 1993
+
+CHAPTER 8: The data type "object"
+
+8.1 Review
+You should now be able to do anything so long as you stick to calling
+functions within your own object.  You should also know, that at the
+bare minimum you can get the create() (or reset()) function in your object
+called to start just by loading it into memory, and that your reset()
+function will be called every now and then so that you may write the
+code necessary to refresh your room.  Note that neither of these
+functions MUST be in your object.  The driver checks to see if the
+function exists in your object first.  If it does not, then it does not
+bother.  You are also acquainted with the data types void, int, and string.
+ 
+7.2 Objects as data types
+In this chapter you will be acquainted with a more complex data type,
+object.  An object variable points to a real object loaded into the
+driver's memory.  You declare it in the same manner as other data types:
+    object ob;
+It differs in that you cannot use +, -, +=, -=, *, or / (what would it
+mean to divide a monster by another monster?).  And since efuns like
+say() and write() only want strings or ints, you cannot write() or
+say() them (again, what would it mean to say a monster?).
+But you can use them with some other of the most important efuns on any
+LPMud.
+ 
+8.3 The efun: this_object()
+This is an efun which returns an object in which the function being executed
+exists.  In other words, in a file, this_object() refers to the object your
+file is in whether the file gets cloned itself or inherted by another file.
+It is often useful when you are writing a file which is getting inherited
+by another file.  Say you are writing your own living.c which gets
+inherited by user.c and monster.c, but never used alone.  You want to log
+the function set_level() it is a player's level being set (but you do not
+care if it is a monster.
+You might do this:
+ 
+void set_level(int x) {
+    if(this_object()->is_player()) log_file("levels", "foo\n");
+    level = x;
+}
+ 
+Since is_player() is not defined in living.c or anything it inherits,
+just saying if(is_player()) will result in an error since the driver
+does not find that function in your file or anything it inherits.
+this_object() allows you to access functions which may or may not be
+present in any final products because your file is inherited by others
+without resulting in an error.
+ 
+8.4 Calling functions in other objects
+This of course introduces us to the most important characteristic of
+the object data type.  It allows us to access functions in other objects.
+In previous examples you have been able to find out about a player's level,
+reduce the money they have, and how much hp they have.
+Calls to functions in other objects may be done in two ways:
+ 
+object->function(parameters)
+call_other(object, "function", parameters);
+ 
+example:
+this_player()->add_money("silver", -5);
+call_other(this_player(), "add_money", "silver", -5);
+ 
+In some (very loose sense), the game is just a chain reaction of function
+calls initiated by player commands.  When a player initiates a chain of
+function calls, that player is the object which is returned by
+the efun this_player().  So, since this_player() can change depending
+on who initiated the sequence of events, you want to be very careful
+as to where you place calls to functions in this_player().  The most common
+place you do this is through the last important lfun (we have mentioned
+create() and reset()) init().
+ 
+8.5 The lfun: init()
+Any time a living thing encounters an object (enters a new room, or enters
+the same room as a certain other object), init() is called in all of
+the objects the living being newly encounters.  It is at this point
+that you can add commands the player can issue in order to act.
+Here is a sample init() function in a flower.
+ 
+void init() {
+    ::init();
+    add_action("smell_flower", "smell");
+}
+ 
+Ito smell_flower().  So you should have smell_flower() look like this:
+ 
+1 int smell_flower(string str);        /* action functions are type int */
+2
+3 int smell_flower(string str) {
+4    if(str != "flower") return 0;     /* it is not the flower being smelled */
+5    write("You sniff the flower.\n");
+6    say((string)this_player()->query_cap_name()+" smells the flower.\n");
+7    this_player()->add_hp(random(5));
+8    return 1;
+9 }
+ 
+In line 1, we have our function declared.
+In line 3, smell_flower() begins.  str becomes whatever comes after the
+    players command (not including the first white space).
+In line 4, it checks to see if the player had typed "smell flower".  If
+    the player had typed "smell cheese", then str would be "cheese".  If
+    it is not in fact "flower" which is being smelled, then 0 is returned,
+    letting the driver know that this was not the function which should
+    have been called.  If in fact the player had a piece of cheese as well
+    which had a smell command to it, the driver would then call the function
+    for smelling in that object.  The driver will keep calling all functions
+    tied to smell commands until one of them returns 1.  If they all return
+    0, then the player sees "What?"
+In line 5, the efun write() is called.  write() prints the string which
+    is passed to it to this_player().  So whoever typed the command here
+    sees "You sniff the flower."
+In line 6, the efun say() is called.  say() prints the string which is
+    doing the sniffing, we have to call the query_cap_name() function
+    in this_player().  That way if the player is invis, it will say
+    "Someone" (or something like that), and it will also be properly
+    capitalized.
+In line 7, we call the add_hp() function in the this_player() object,
+    since we want to do a little healing for the sniff (Note: do not
+    code this object on your mud, whoever balances your mud will shoot you).
+In line 8, we return control of the game to the driver, returning 1 to
+    let it know that this was in fact the right function to call.
+ 
+8.6 Adding objects to your rooms
+And now, using the data type object, you can add monsters to your rooms:
+ 
+void create() {
+    ::create();
+    set_property("light", 3);
+    set("short", "Krasna Square");
+    set("long", "Welcome to the Central Square of the town of Praxis.\n");
+    set_exits( ({ "d/standard/hall" }), ({ "east" }) );
+}
+ 
+void reset() {
+    object ob;
+ 
+    ::reset();
+    if(present("guard")) return;     /* Do not want to add a guard if */
+    ob = new("/std/monster");        /* one is already here           */
+    ob->set_name("guard");
+    ob->set("id", ({ "guard", "town guard" }) );
+    ob->set("short", "Town guard");
+    ob->set("long", "He guards Praxis from nothingness.\n");
+    ob->set_gender("male");
+    ob->set_race("human");
+    ob->set_level(10);
+    ob->set_alignment(200);
+    ob->set_humanoid();
+    ob->set_hp(150);
+    ob->set_wielding_limbs( ({ "right hand", "left hand" }) );
+    ob->move(this_object());
+}
+ 
+Now, this will be wildly different on most muds.  Some, as noted before,
+in that object so you have a uniquely configured monster object.  The
+last act in native muds is to call move() in the monster object to move
+it to this room (this_object()).  In compat muds, you call the efun
+move_object() which takes two parameters, the object to be moved, and the
+object into which it is being moved.
+ 
+8.7 Chapter summary
+At this point, you now have enough knowledge to code some really nice
+stuff.  Of course, as I have been stressing all along, you really need
+to read the documents on building for your mud, as they detail which
+functions exist in which types of objects for you to call.  No matter
+what your knowledge of the mudlib is, you have enough know-how to
+give a player extra things to do like sniffing flowers or glue or whatever.
+At this point you should get busy coding stuff.  But the moment things
+even look to become tedious, that means it is time for you to move to
+the next level and do more.  Right now code yourself a small area.
+Make extensive use of the special functions coded in your mud's
+room.c (search the docs for obscure ones no one else seems to use).
+Add lots o' neat actions.  Create weapons which have magic powers which
+gradually fade away.  All of this you should be able to do now.  Once
+this becomes routine for you, it will be time to move on to intermediate
+stuff.  Note that few people actually get to the intermediate stuff.
+If you have played at all, you notice there are few areas on the mud
+which do what I just told you you should be able to do.  It is not
+because it is hard, but because there is a lot of arrogance out there
+on the part of people who have gotten beyond this point, and very little
+communicating of that knowledge.  The trick is to push yourself and
+think of something you want to do that is impossible.  If you ask someone
+in the know how to do X, and they say that is impossible, find out
+youself how to code it by experimenting.
+
+George Reese
+Descartes of Borg
+12 july 1993
+borg@hebron.connected.com
+Descartes@Nightmare (intermud)
+Descartes@Igor (not intermud)