Added public files
Roughly added all public files. Probably missed some, though.
diff --git a/doc/KURS/LPC-KURS/Introduction b/doc/KURS/LPC-KURS/Introduction
new file mode 100644
index 0000000..2e3c7ff
--- /dev/null
+++ b/doc/KURS/LPC-KURS/Introduction
@@ -0,0 +1,106 @@
+ LPC Basics
+ Written by Descartes of Borg
+ 23 april 1993
+
+
+ INTRODUCTION
+ This manual, how to use it, and its terms
+
+I have seen a lot of requests lately on USENET for LPC manuals. In addition,
+the immortals on my mud have been telling how good the building documentation
+of Nightmare is, but that there was just no adequate explanation of the
+LPC programming language. So I decided to try my hand at writing a manual.
+Some things you should keep in mind.
+LPC is a very easy programming language to learn, and it has real
+value in that place most of us know as the real world. I began playing
+muds in 1991, and in the space of a month created an unimpressive area
+and musician's guild on the original Bates College MUD called Orlith.
+After that, I moved to Los Angeles for a year and had no contact with
+mudding or computers. In June of 1992, I was back on the internet and
+a wizard of Igor. In September of 1992 I began coding the Nightmare
+mudlib for our use, and then later decided to distribute it due to there
+not being any mudlibs for MudOS at the time that a person could just throw
+up a running mud with (now, that of course is not the case :)).
+So, I have been doing serious coding for less than a year. As a
+Philosophy major in a world of Computer Science majors, I just want to
+make clear that it is not at all required that you have ever done anything
+with your computer than log into a mud in order for you to really come
+to understand LPC coding. This manual makes the following assumptions:
+Someone has taught you basic UNIX commands like ls, cd, mkdir, mv, rm, etc.
+You know how to enter your mud's editor and write a file. No other
+assumptions are made. If you know C, you are handicapped in that LPC
+looks a lot like C, but it is not C. Your preconceptions about
+modular programming development will be a hinderence you will have to
+overcome. If you have never heard of the C programming language (like
+me in May of 1991), then you are only missing an understanding of the
+simple constructs of C like the flow of program execution and logical
+operators and such. So a C guru has no real advantage over you, since
+what they know from C which is applicable to LPC is easy to pick up.
+The stuff they know about C which makes them a guru is irrelevant to
+LPC.
+
+The chapters of this manual are meant to be read in order. Starting with
+the introduction, going sequentially through the chapter numbers as
+ordered in the contents file. Each chapter begins with a paragraph or
+two explaining what you should have come to understand by that point
+in your studies. After those introductory paragraphs, the chapter then
+begins to discuss its subject matter in nauseating detail. At the end
+of the chapter is a briefly worded summary of what you should understand
+from that chapter if I have been successful. Following that may or may
+not be some sidenotes relevant to the subject at hand, but not necessary
+to its understanding.
+
+If at any time you get to a chapter intro, and you have read the preceeding
+chapters thoroughly and you do not understand what it says you should
+understand by that point, please mail me! Clearly, I have failed at that
+point and I need to know where it is I have gone wrong so I can revise
+it properly. Similarly, if you do not understand what the chapter summary
+says you should, please mail me. If your mumud is on the MudOS intermud
+system, mail descartes@nightmare. Otherwise mail borg@hebron.connected.com.
+
+Some basic terms this manual uses:
+driver-
+This is the C program which is the game. It accepts incoming sockets
+(links to other computers), interprets LPC code defined by the mudlib,
+keeps mud objects in memory, makes periodic attempts to clean unused
+mud objects from memory, makes periodic calls to objects, and so on.
+
+mudlib-
+LPC code which defines the world in which you are in. The driver of itself
+is not a game. It is just a program which allows the creation of a
+multi-user environment. In some sense, the driver is like an LPC
+compiler, and the mudlib is like a compiler's library (a very loose
+analogy). The mudlib defines basic objects which will likely be used
+over and over again by people creating in the mud world. Examples of
+such objects are /std/room (or /room/room), /std/user.c (or /obj/player.c),
+and so on.
+
+area or castle:
+Specific creator coded objects which often use a feature of LPC called
+inheritance to make use of the properties of basic mudlib objects and
+turn them into specific objects to be used by players in the game
+
+object:
+a room, a weapon, a monster, a player, a bag, etc. More importantly,
+every individual file with a .c extension is an object. Objects are
+used in different ways. Objects like /std/living.c are inherited by
+objects like monster.c and user.c. Others are cloned, which means a
+duplicate of that code is loaded into memory. And still others are
+simply loaded into memory to be referenced by other objects.
+
+native and compat:
+these two terms refer to two popular flavours of drivers. Native mode
+mudlibs make use of on the design of LPMud driver 3.0 and later. You may
+have a 3.0 driver however, but have a 2.4.5 style mudlib. This is what
+is meant by compat mode. Mudlibs which are native mode are any for
+MudOS, CD, and LPMud mudlibs that
+are listed as native. Compat mudlibs are any LPMud mudlib before 3.0 and
+those which are 3.* compat mudlibs. I believe Amylaar's is compat.
+[ Not true, Amylaar supports native and compat mudlibs, MorgenGrauen
+ is native - Boing ]
+
+Good Luck!
+George Reese
+(Descartes of Borg)
+12 july 1993
+borg@hebron.connected.com