blob: f9ad56668b0a2f026ea169681b2654fc2d396cbb [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001 LPC Basics
2 Written by Descartes of Borg
3 first edition: 23 april 1993
4 second edition: 16 june 1993
5
6CHAPTER 2: The LPC Program
7
82.1 About programs
9The title of this chapter of the textbook is actually poorly named, since
10one does not write programs in LPC. An LPC coder instead writes *objects*.
11What is the difference? Well, for our purposes now, the difference is
12in the way the file is executed. When you "run" a program, execution
13begins at a definite place in the program. In other words, there
14is a place in all programs that is noted as the beginning where program
15execution starts. In addition, programs have definite end points,
16so that when execution reaches that point, the execution of the program
17terminates. So, in short, execution of a program runs from a definite
18beginning point through to a definite end point. This is not so with
19LPC objects.
20
21With muds, LPC objects are simply distinct parts of the C program which
22is running the game (the driver). In other words, execution of the mud
23program begins and ends in the driver. But the driver in fact does
24very little in the way of creating the world you know when you play
25a mud. Instead, the driver relies heavily on the code created in LPC,
26executing lines of the objects in the mud as needed. LPC objects thus
27have no place that is necessarily the beginning point, nor do they
28have a definite ending point.
29
30Like other programming languages, an LPC "program" may be made up of
31one or more files. For an LPC object to get executed, it simple
32needs to be loaded into the driver's memory. The driver will call lines
33from the object as it needs according to a structure which will be
34defined throughout this textbook. The important thing you need to
35understand at this point is that there is no "beginning" to an LPC
36object in terms of execution, and there is no "end".
37
382.2 Driver-mudlib interaction
39As I have mentioned earlier, the driver is the C program that runs on
40the host machine. It connects you into the game and processes LPC code.
41Note that this is one theory of mud programming, and not necessarily
42better than others. It could be that the entire game is written in C.
43Such a game would be much faster, but it would be less flexible in
44that wizards could not add things to the game while it was running. This
45is the theory behind DikuMUDs. Instead, LPMUDs run on the theory that
46the driver should in no define the nature of the game, that the nature
47of the game is to be decided by the individuals involved, and that
48you should be able to add to the game *as it is being played*. This
49is why LPMUDs make use of the LPC programming language. It allows
50you to define the nature of the game in LPC for the driver to read and
51execute as needed. It is also a much simpler language to understand
52than C, thus making the process of world creation open to a greater
53number of people.
54
55Once you have written a file in LPC (assuming it is corrent LPC ), it justs
56sits there on the host machine's hard drive until something in the game
57makes reference to it. When something in the game finally does make
58reference to the object, a copy of the file is loaded into memory and
59a special *function* of that object is called in order to initialize
60the values of the variables in the object. Now, do not be concerned
61if that last sentence went right over your head, since someone brand
62new to programming would not know what the hell a function or a variable
63is. The important thing to understand right now is that a copy of the
64object file is taken by the driver from the machine's hard drive and
65stored into memory (since it is a copy, multiple versions of that
66object may exist). You will later understand what a function is, what
67a variable is, and exactly how it is something in the game made reference
68to your object.
69
702.3 Loading an object into memory
71Although there is no particular place in an object code that must exist
72in order for the driver to begin executing it, there is a place for which
73the driver will search in order to initialize the object. On compat
74drivers, it is the function called reset(). On native muds it is the
75function called create(). [ MorgenGrauen is native - Boing ]
76
77LPC objects are made up of variables (values which can change) and
78functions which are used to manipulate those variables. Functions
79manipulate variables through the use of LPC grammatical structures,
80which include calling other functions, using externally defined
81functions (efuns), and basic LPC expressions and flow control
82mechanisms.
83
84Does that sound convoluted? First lets start with a variable. A
85variable might be something like: level. It can "vary" from sitation
86to situation in value, and different things use the value of the player's
87level to make different things happen. For instance, if you are a
88level 19 player, the value of the variable level will be 19. Now
89if your mud is on the old LPMud 2.4.5 system where levels 1-19 are
90players and 20+ are wizards, things can ask for your level value to
91see if you can perform wizard type actions. Basically, each object
92in LPC is a pile of variables with values which change over time.
93Things happen to these objects based on what values its variables
94hold. Often, then things that happen cause the variables to change.
95
96So, whenever an object in LPC is referenced by another object currently
97in memory, the driver searches to see what places for values the
98object has (but they have no values yet). Once that is done, the driver
99calls a function in the object called reset() or create() (depending
100on your driver) which will set up the starting values for the object's
101variables. It is thus through *calls* to *functions* that variable
102values get manipulated.
103
104But create() or reset() is NOT the starting place of LPC code, although
105it is where most LPC code execution does begin. The fact is, those
106functions need not exist. If your object does just fine with its
107starting values all being NULL pointers (meaning, for our purposes
108here, 0), then you do not need a create() or reset() function. Thus
109the first bit of execution of the object's code may begin somewhere
110completely different.
111
112Now we get to what this chapter is all about. The question: What
113consists a complete LPC object? Well, an LPC object is simply
114one or more functions grouped together manipulating 0 or more
115variables. The order in which functions are placed in an object
116relative to one another is irrelevant. In other words:
117
118-----
119void init() { add_action("smile", "smile"); }
120
121void create() { return; }
122
123int smile(string str) { return 0; }
124-----
125
126is exactly the same as:
127
128-----
129void create() { return; }
130
131int smile(string str) { return 0; }
132
133void init() { add_action("smile", "smile"); }
134_____
135
136Also important to note, the object containing only:
137
138-----
139void nonsense() {}
140-----
141
142is a valid, but trivial object, although it probably would not interact
143properly with other objects on your mud since such an object has no
144weight, is invisible, etc..
145
1462.4 Chapter summary
147LPC code has no beginning point or ending point, since LPC code is used
148to create objects to be used by the driver program rather than create
149individual programs. LPC objects consist of one or more functions whose
150order in the code is irrelevant, as well as of zero or more variables whose
151values are manipulated inside those functions. LPC objects simply sit
152on the host machine's hard driver until referenced by another object in
153the game (in other words, they do not really exist). Once the object
154is referenced, it is loaded into the machine's memory with empty
155values for the variables. The function reset() in compat muds or
156create() in native muds is called in that object if it exists to allow
157the variables to take on initial values. Other functions in the object
158are used by the driver and other objects in the game to allow interaction
159among objects and the manipulation of the LPC variables.
160
161A note on reset() and create():
162create() is only used by muds in native mode (see the textbook Introduction
163for more information on native mode vs. compat mode). It is only used
164to initialize newly referenced objects.
165
166reset() is used by both muds in compat mode and native mode. In compat
167mode, reset() performs two functions. First, it is used to initialize
168newly referenced objects. In addition, however, compat mode muds use
169reset() to "reset" the object. In other words, return it to its initial
170state of affairs. This allows monsters to regenerate in a room and doors
171to start back in the shut position, etc.. Native mode muds use reset()
172to perform the second function (as its name implies).
173
174So there are two important things which happen in LP style muds which
175cause the driver to make calls to functions in objects. The first is
176the creation of the object. At this time, the driver calls a function
177to initalize the values in the object. For compat mode muds, this
178is performed by the function named reset() (with an argument of 0,
179more on this later though). For muds running in native mode, this is
180performed by the function create().
181
182The second is the returning of the room to some base state of affairs.
183This base set of affairs may or may not be different from the initial
184state of affairs, and certainly you would not want to take up time
185doing redundant things (like resetting variables that never change).
186Compat mode muds nevertheless use the same function that was used to
187create the object to reset it, that being reset(). Native mode muds,
188who use create() to create the room, instead use reset() to reset it.
189All is not lost in compat mode though, as there is a way to tell the
190difference between creation and resetting. For reset purposes, the
191driver passes either 1 or the reset number as an argument to reset()
192in compat mode. Now this is meaningless to you now, but just keep in
193mind that you can in fact tell the difference in compat mode. Also
194keep in mind that the argment in the creation use of reset is 0 and
195the argument in the reset use is a nonzero number.