Phantasmal Site > DGD > DGD Reference Manual (legacy) > Making and Using LPC Files

3.6 Making and Using LPC Files

You may be getting pretty tired of the code command by now. Even if you're not, you're probably starting to understand why we don't use it for big programs. Retyping all that stuff can get ugly. Typos are difficult to correct if you're retyping everything. And the code would certainly look better if it could be formatted properly.

To start using LPC files, you'll first need to be able to edit text files somehow. That means you'll need an editing program, or editor.

Since you're running your own copy of DGD, the easiest way for you to edit files is to use an editing program that's on your desktop. While it's possible to use the built-in DGD editor, it's probably easier not to. The built-in one isn't a very good editor by modern standards, and it's hard to use if you're used to normal desktop editing programs.

On Unix, whatever editor you've already got will almost certainly do. On Windows, however, you'll need to be careful because most editors put Windows-style line breaks into text files. DGD requires Unix-style line breaks in its text files. If you don't know what line breaks are, don't worry too much, but do follow the instructions here anyway. TextPad is a freely available Win32 editor that will handle line breaks properly. There are also versions of emacs and vi for Windows, and either will work. I don't know the situation on Macintosh computers, so I don't know what editors are available that will handle non-native line breaks.

It's useful to know what the code command does so you can get your code to work similarly. The code command makes a new object from a file every time you use it. That file looks something like this:

#include <float.h>
#include <limits.h>
#include <status.h>
#include <trace.h>
#include <type.h>

/* The exec() function, from the code command */
mixed exec(object user, mixed argv...) {
    mixed a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;

    <Your Code>
}

It's actually a little more complicated than that — for instance, a return statement is added before your code if that code doesn't end with a semicolon or end-curly-brace. Also, your code has all the history references turned into something more palatable. The history variables aren't part of DGD's dialect of LPC. They're only part of the Kernel Library.

To create the LPC file, you'll need to use your editor to create a file called /usr/admin/myobj.c. Note that that filename is relative to the directory of the Kernel Library, so if you installed DGD in C:\DGD, you'll need to make the file C:\DGD\mud\usr\admin\myobj.c. If you installed dgd in /home/bob/dgd, you'll need to make the file /home/bob/dgd/mud/usr/admin/myobj.c.

You should make an LPC file exactly like the above, except that where it says "<Your Code>", you should substitute return 7;. That way, the test object will return the number 7 when you call its function. So you'll have created the object that the Kernel Library would create internally if you used the command code 7.

Now you'll need to compile the object. To do that from the admin user's command line you'll want to type compile /usr/admin/myobj.c. You may just be able to type compile myobj.c for the same result — use the pwd command to make sure you're in the /usr/admin directory.

In either case, you should see a result like $15 = </usr/admin/myobj>. If you get errors instead then your code isn't quite right or there's something wrong with the file (did you use the right name?). Look at both again carefully. If DGD can't find the file, then perhaps you didn't put it in the right place, or perhaps you didn't type the "compile" line perfectly. Check them both again. Try it until you get the result above.

Once you have, you've made a usable object. To call a function on it, you'll want to use its history entry. This command line will assume that the object was $15 (as in the paragraph above). If yours was a different history number, you should substitute your own number. Type code $15->exec(this_user()). You should get a result like $16 = 7. You've successfully returned the number 7. Success!

Go back and look at the code again. You may have realized that the long line starting with mixed declares all those single-letter variables I mentioned earlier. Mixed declares a variable, just as int and float do. A mixed variable can hold any DGD type. You could just make all of your variables mixed rather than bothering with all the different types. But there are some serious disadvantages to doing that, as we'll discuss later on.

DGD doesn't actually have magic variables that are available everywhere called 'c' and 'f' and so on. The code command provides them. But in a regular LPC file, you'll have to declare them if you want to use them. Constants like ST_VERSION aren't really part of the language either. The code command has them because of the #include directives at the start of the source file. In your own code, you'll need to specifically include the files for any constants you may wish to use. So if you want to use ST_VERSION, you'll need to include status.h from your LPC object.

There's also a weird line starting with /* and ending with */. That line is called a comment, and it's designed to let other programmers know things about your code. It has no effect, so you can comment on your own code, to humans only. A comment is allowed to span multiple lines, or it can cover only part of a single line.. It goes from the /* to the */, whether that's only part of a line, or pages and pages.

We'll cover more about the specifics of myobj.c and what we mean by a function later on. We'll cover more about what the "code" command to call it actually did. However, in the mean time, you have a good simple way to store your code and make modifications to it instead of retyping the whole thing every time. That'll be useful for longer bits of code like what you typed in the Loops and Looping section.