doc/KURS/LPC-KURS/Introduction - mudlib-public - Gitiles

                              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
	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