Developing mudlib from scratch

Build mudlib--with Akuma, "first talk."

First: Let it run.
Note: Every talk I will upload a match lib, some files are old, some are new, I try to write clear notes in Lib. A more detailed description is written in the body of each lecture.

What is the simplest way to run a Lib? Each person who writes LPC based on MudOS may give different answers. I remember a friend who had released a lib of less than 5k.

I'm going to be a little bit smaller, tgz. 1851 bytes later. Well... OK.
We don't expect much from this lib, but at least he should have done the following two things:
1. Can run up and accept the user's connection (you use Zmud, Telnet or, in short, can be connected to the port)
2. The user after the connection can input, and Lib should be given a certain response (then the simplest way is to complete a so-called echo server---you enter what, the server will return you what).

"With the Lib version of this talk is 0.1, the file name is newlib.0.1.tar.gz, see the Attachment"
Here is the directory structure:
.
|--ADM
| '--obj
| |--master.c
| '--SIMUL_EFUN.C
|--include
| '--globals.h
|--Log
'--obj
'--user.c

First of all, the directory structure, a good clear directory structure used very comfortable, I generally respected single-level directory structure, but in view of the habit problem, I used in the/adm and Xkx similar method, that is, the master and Simul placed under the/adm/obj/.
Roughly speaking:
Currently we have only created four basic directories:/adm/include/log/obj.
ADM puts all the "unique" things, such as the most critical of the two objects master.c and SIMUL_EFUN.C, as well as the future will slowly appear in various daemons.
Include is the directory where all header files are located and there is currently only one globals.h.
Log is used to store a variety of log output, there is nothing to say.
obj is the entity file of all the objects that are eventually used in the Lib, which is what will be eventually new () or Load_object (). For the moment there is only one connected object, namely USER.C. (You see, now we are not even login.c, because our current goal is only to allow mud to accept the connection, disconnection, account authentication and so on to be completed later)

Here we start with something basic: How does MudOS start?
We don't talk about mudos ourselves, only the part about Lib.
Some people think that MudOS first loaded is MASTER.C (please note that this master.c is not the master who can be used to apprentice), in fact, this view is a bit problematic.
In general, the first file loaded by MudOS is SIMUL_EFUN.C.
We know that in order to run a mud, in addition to the LIB, you also need driver and a configuration file for driver config.cfg. In Config.cfg, there are three files to be defined: SIMUL_EFUN.C,MASTER.C and globals.h. If you like, we can of course give these three files a different name, such as master.c change called core.c,globals.h can be called dangzhongyang.h, casual ... But everyone is used to it, I will not change it.

Focus 1. About SIMUL_EFUN.C
Just now we said that MudOS will try to load this simul_efun.c after the boot.
Here is a concept called Simul. As we all know, MudOS provides a large number of functions (Efun) for the purposes of the game, such as determining whether a player's userp (), such as a series of functions for manipulating strings, and so on.
However, MudOS is not omnipotent, he can not anticipate all possible needs, sometimes we have to self-encapsulation some features (for example, Log_file () so convenient and useful features, mudos not provided), if the scope of application is very narrow, Of course we can write him directly into the code, but like log_file so popular and commonly used features, we can't use every time to c/p to the corresponding file, one is inconvenient, one is also prone to error is not?
So, MudOS provides a way to solve this problem, this is Simul efun, simply say "Analog efun", this function can help us to encapsulate the function of the mind, and anywhere in the lib like the use of Efun as the use of him (though slow it ....) Of course, in terms of efficiency, the quickest way is to transplant the efun into the MudOS, really make a efun, but this is another topic, not the scope of our discussion. The
does not have much to do with this work, and it is simple to write the function definition and body into the simul_efun.c specified by Config.cfg. (Refer to the Log_file () function in the simul_efun.c of my lib for details) so that we can make him work like a efun.
"Digression" many mudlib after a long period of development, accumulated a lot of simul, all stuffed into the SIMUL_EFUN.C is also very troubled, not beautiful and easy to manage, so they will adopt another approach: inheritance. The
simply means to use SIMUL_EFUN.C as a portal file, to write all the Simul functions into other files, and to include these "other files" in the main file using only the inheritance (Inherit) method. (using include seems to be OK ...) I'm not quite sure.)

============ Split Line ===== 2 skillful nonsense, interested students can refer to oop===============
"Digression 2" for the OOP features of LPC. The
LPC language appears earlier, although in general we consider him to be object-oriented, but it does not fully conform to all object-oriented concepts.
For example, he only supports the function reference to the object, not the element reference to the object, when we want to get or change a variable in an object, we can only be implemented by the function;
again, for encapsulation, LPC does not implement polymorphism in good condition. And only a limited support variable-length parameter table (VARARGS,LPC only supports a variable-length parameter).
============ Split Line ===== 2 skilled nonsense, interested students can refer to their own oop===============

Connect () function in key 2.master.c
We said at the beginning that the most important thing now is for MudOS to be able to accept connections. So here we need to talk about MudOS accept user connection mechanism.
We know that the most interesting part of LPC is that he is oop (not entirely indifferent, anyway, knowing that all things in Lib are ok), then assigning an object to each user is a normal and convenient way to manage it.
The question is, how do you let MudOS know "This is a wired object"?
Here is a very important master_apply (which we talked about below), Master_apply::connect ()
His prototype is:
Object Connect ()
The function is that when the mud receives a connection (whether you're using Zmud or Telnet, anyway, you're connected to the port service provided by MudOS), MudOS calls the master's Connect () function and expects to return an object. This object is equivalent to hanging a number in the MudOS. MudOS will treat it as a user-connected object, for example, think of him as Userp () and Interactive () (some of these functions have some subtle and bizarre differences, and we'll talk about them when we're free).
Please see the Connect () in my lib:
Object Connect ()
{
Log_file ("New_user_login", Time () + "\ n");
return new ("/obj/user.c");
}
Very simple, master.c as long as the passive waiting for MudOS call, and at the appropriate time to build a user_ob is OK.

Here's one more word:
A complete login process that includes two steps in the MudOS:
A. Call master Apply's connect () to get the Wired object;
B. Invoke another apply function on this wired object: Logon ()
The second step is to give the login verification process a suitable calling interface. At present, our 0.1 version of the Lib still does not have such a cow B technology, so he was floating.
We'll add it when the future is in place.

======================= Split Line ===============================================
Apply with Focus 3.master
In fact master.c in addition to the constructor function create (), the basic is apply.
What is apply?
Presumably, the so-called apply, is the kind of MudOS stealth Call function interface, these interfaces are for MudOS service, we usually in Lib, just passively through this interface to tell MudOS in some cases "can" or "no", or "who should be" this way.
In the ordinary object of this interface we call him "apply", in master is the so-called master apply.

Often you see more of the apply include like ID () (called by present () implicit call), like Reset () (called by the Reset mechanism).
Master apply, such as valid_xxx, which is related to permissions.
OK, here we probably know that there is such a thing OK, specific later encountered the need to use the apply, we again like this connect () as explained.

======================= Split Line ===============================================
Key 4.globals.h
Will everyone encounter such a problem, I define a macro, but forget him in which header file? or write A. c When you often have to include countless header files, in fact, for the one or two of his macro?
Thanks to the author of MudOS, he helped us solve this problem to some extent through Globals.h:
When we have some macro definitions that are very full-sentence (such as the definition of a directory, the definition of some important OB, etc.), we can throw them into the globals.h.
And, more conveniently here: we don't need explicit in the program include this globals.h,mudos automatically helps us to include it in every. C.
So, when you have some macros that are very global, just plug it in to globals.h ...

Another point, see now this very simple globals.h
#ifndef __globals_h__
#define __globals_h__

#define LOG_DIR "/log/"

#endif

Find out what's different?
We used the #ifdnef #define #endif的方式.
The advantage of this is to avoid the redefine caused by the. h Nesting (for example A.C contains A.H and b.h, unfortunately A.C also inherits B.C, and B.C itself contains b.h, so there is actually nesting)

======================= Split Line ===============================================
Key 5.USER.C
Our user.c now has a very simple function. In the normal LIB, in order to facilitate login authentication and disconnection, this file is divided into two. namely Login.c and user.c (perhaps someone is directly using BODY.C?) I'm not sure, but that's what it means anyway. One responsible for password authentication, one responsible for real user behavior and data. And, through the EXEC () function, the user tag MudOS is considered to be switched between two.

Now we are very simple here, not certified, so directly there is only one user.c, the future refinement here.

Next, how does MudOS get the user's instructions?
In normal mudlib, we usually do this through a series of complex behaviors, such as getting user input through a "full-time" add_action (command_hook) Hook, And through a daemon of names such as COMMANDD.C to find the proper instruction file, and execute it.
In the future we will also improve such a structure, but now ... Since we only want to complete an echo server. For the time being, we'll handle him in a much simpler way: string Process_input (String arg)
This is another apply, in the "normal" mudlib, we usually use this apply to achieve the resolution of global alias.
Here we go straight through
String Process_input (String arg)
{
Write (arg+ "\ n");
}
Such a pattern to complete the work of "Echo Server".

There is a problem here, we have not found a string type of function I did not return, which leads directly to the run up, we each command knocked in will return a >what?
It doesn't matter, anyway this version we are just about the demo, next time we fix him.

Well, this time we've got four files, and we've built a lib that can run and react. Everyone can run for a look (the attachment I provide a bin file, including driver and Config.cfg, is the Linux version, because I run on my server driver very much, so I changed the name of driver mud to avoid the unfortunate be killall. ）
If you want to run under Linux, just chmod +x mud, and reconfigure the mudlib and bin directories in config.cfg to be OK.
If you want to test under win, then I am sorry, I do not have the appropriate version of the Mudos.exe (which kind of boss to provide one)

================= and cut ===================================================.
Summary and trailer:
First write this kind of thing (statement, I did not write a language book, so not very can write, may be too messy, the content is also very scattered, sorry), we have what suggestions and comments welcome thread, I try to improve.
The attachment is two files:
Bin.tar.gz is the Linux version of MudOS and config
Newlib.0.1.tar.gz is the Lib that synchronizes with this lecture. There may be a problem, that is involved in the Chinese is the UTF8 format, we may use it is garbled, this can be used Uedit to turn the code (mainly I used to directly under the shell to knock the codes, also do not change the coding, fortunately as a guide to use the LIB, there will not be too much Chinese content in the inside).
Next, I think I will complete the login verification and command system. So that we can have space to do some experiments (with instructions to write the test code is very convenient to say).
In addition, if possible, may fill a not so perfect permission system, perhaps not, I see progress to put ...

Developing mudlib from scratch