[MUD] Mudlib detailed/mudos running process/minimum Mudlib/mud file structure

Now most of the Chinese mud is developed on the basis of the Eastern Story (ESII), and its catalogue structure is basically the same,
There are also individual mud in order to change the name of the individual directory for different names, but the essence of nothing changes.
The most abominable thing to do is xkx, a good daemon directory for a non-native kungfu,
Inside but still skill,condition these foreign names, simply let a person faint! I really don't see the benefit of such a change,
In addition to the trouble (Xkx to some of the orders of the Han, what cha,du ... And so on). But
Some are modified to make the system more reasonable.
There are already many versions of the Mudlib catalogue, and there is no difference, as I explained below.
On the basis of my own mudlib, if there is a different place in the catalogue, it should be properly penetrated.

/adm here is the most basic, bottom-up program that is the control hub for the entire mud.
This directory can be modified only by admin permissions.
/adm/daemons Daemon directory. A daemon is a control program that is frequently called in a game.
All the basic functions of mud are controlled by these. These programs are typically loaded into memory automatically as soon as the game starts.
According to the Unix file naming habits, the program here is more D.C end,
COMBATD.C, for example, is the process of controlling combat. In addition, because these program calls are very frequent,
Macro definitions are generally made (see/INCLUDE/GLOBALS.H), such as/ADM/DAEMONS/COMBATD.C
Defined as combat_d, these macro definitions can be used in place of these file names in other programs.
/ADM/ETC System configuration directory, this directory is defined as Config_dir here is the game system documentation file,
such as the game's Welcome screen, wizard list, ban off the IP record.
/adm/obj There are only two files, but it is the most important thing in the whole mud.
MASTER.C: This is the MudOS Master object, the commander in chief of the entire mud.
SIMUL_EFUN.C: Anti-true function Loading Wizard, which is the first thing to load when mud starts.
The so-called Efun, refers to the system function, that is, the function defined in MudOS.
These functions do not have to do any instructions to invoke directly in any of the mud's programs,
And since they are pre-defined, that is, MudOS already knew what they were doing,
Therefore, it is more efficient than other functions defined in Mudlib. But their disadvantage is that modification is very inconvenient,
Modifications to any of the Efun functions must be recompiled mudos to take effect. So
In Mudlib, there is also the definition of anti-truth function, that is, Simul_efun,
These functions work exactly like Efun, but they are defined in udlib and can be modified at any time.
However, you must restart the game to take effect.
By the way, a mud-priming process, the mud initiates initialization process in the following steps:
1. Load the anti-true function Simul_efun
2. Load the Master object master, here is the Create () function called Master to load it into memory.
3. Load the daemon that requires pre-loading, and call the Master's preload () function,
Files that require pre-loading are defined in/adm/etc/preload.
4.MUD enters multi-user status, allowing the player to log in.
The above procedure must be executed correctly, otherwise the game will not start correctly.
The two files of master.c and simul_efun.c can only be automatically loaded by MudOS when the game is started.
Can not be loaded in the game with the Update method, and the two objects are not
Allow non-rooted objects to destroy (destruct) it, because their Destruction equals the game off.
/adm/simul_efun anti-True function directory, here is the definition of various types of anti-truth functions of the file,
These files are loaded into memory by Simul_efun_ob (that is,/adm/obj/simul_efun).

/cmds game Command Directory, here is the game can be used in various commands,
Only Admin can modify this directory
/cmds/adm only commands that can be used by the Tenjin (Admin)
/cmds/arch commands that can only be used by the Great Wizard (Arch)
/cmds/wiz commands that can only be used by Wizards (wizard)
/cmds/app commands that can only be used by Wizards of the Wizarding Apprentice (wizard)
/cmds/imm only the honor player (immortal) can use the command
/CMDS/USR commands that can only be used by a regular player (player)
/CMDS/STD all mobs (NPC and player) can use the command command directory in subset format,
Commands with high privileges include commands with low privileges, such as gods can use all game commands,
Normal players can only use commands in the/CMDS/USR and/CMDS/STD directories.

/data Game Data Directory, only arch above permission to modify this directory
/data/board data for each message board
/data/login Player Login Data
/data/user player file, hehe, here is the record of every player's labor results
/DATA/NPC Some special NPCs, like store owners.
/data/daemon important system data, such as emote words, English-Chinese translation dictionaries
/data/mail Player Letters

/feature the standard inheritance function. It is important that only admin can modify these functions for this directory.
is a standard definition of various functions in mud, including players, NPCs, objects, rooms, etc.
These functions reflect the uniqueness of the mud, and a good mudlib must be optimized for these functions.
To design a new program, you must know all the files in this directory.

/obj system objects, which are various objects that are often called in mud.
The object in this directory is copied followed by the object that called him has the same euid,
That means having the same permissions, so if an NPC is compiled and copied by admin,
Also has the admin permission. This is very important, and some objects must have the same euid as the player to use it properly.
, such as a character paper. For security reasons, objects in this directory cannot be copied casually.
Only arch above can modify this directory.
/obj/board each message board in the game
/OBJ/NPC some special NPCs.
/obj/sheet various character paper
/obj/weapons weapon
/obj/misc other messy things, such as a mailbox.

/quest game in the various Tasks quest files, this directory requires the wizard above permission to modify

/binaries files generated by the compilation process, this directory root permissions can be modified

The/D area directory, the game's map of the gate and the places where NPCs are stored. This directory wizard can modify the above permissions.
This is the simplest and most commonly used thing in the whole mudlib, and is something that the player can touch directly.
Any room that the player stays in should correspond to a file in this directory,
Each NPC in the room also corresponds to a file. There are many subdirectories under this directory,
corresponding to different areas of the game (domain).
/D/DOMAIN/NPC NPC in this area
/d/domain/npc/obj the objects in the area of NPC
/d/domain/obj items in this area

/data_bak Archive backup directory to save important data that needs to be backed up. Admin can modify

/include header file directory, only admin can modify. Here are the files needed for each file in the game,
Some of the following are of particular importance:
GLOBALS.H: Globally defined header file, which is a special header file,
He doesn't need to be called in any file, but all the variables defined here can be used directly in any file.
This is typically used to define very important or many places that need to be called
The variable. Changes to this file must be restarted before the game can take effect. Command.h:
This defines the directory of commands that each permission level can use, so, in addition to the admin,
Anyone should be absolutely forbidden to modify this file.
/include/race head file of the race
/include/net the network function header file

/open System temp directory, FTP login directory, anyone has write permission.

/questobj FY3 's task-specific directory, storing individual task item files. The permissions above the wizard can be modified.

/U wizarding working directory, storing semi-finished products for each wizard development process.
The subdirectory names here can only be used for the euid of each wizard,
Only those who correspond to Euid have the right to modify the corresponding directory. For example, a directory is lion,
So only lion, this ID, or someone higher than lion's permission.
Before you can modify the content underneath it.

/clone Items directory, store the game need to copy a variety of items, the wizard above permissions can be written.
Items in this directory are generally copied (clone) from other places, but their euid are fixed,
Does not change Tiaogan with its objects, which is the maximum difference between this directory and the/obj directory.
This directory can be modified above arch level
/clone/armor Equipment
/clone/drug Pharmaceuticals
/clone/fruit fruit, the difference between fruit and food is eating can add food and water at the same time,
And some fruits have the effect of beauty.
/clone/liquid container, like a wine-bag teapot
/clone/money as the name implies, people see people love things
/clone/user player objects, including LOGIN.C (Link_ob) and user.c (body),
Only Admin can modify this directory
/clone/books various Cheats
/clone/food eat.
/clone/gift a variety of gifts, generally good stuff
/clone/weapon weapon
/clone/misc other debris, such as corpses, skulls.

/daemon Oh, why this directory called this name I have not understood, see the instructions below.
Only arch above can be modified in this directory.
/daemon/skill all the skills in the game
/daemon/condition characters in various states, such as poisoning, recovery and so on.
/daemon/class This should be understood as "organization" or "union", is what esii from the foreign mud preserved,
However, with the development of Chinese mud, the concept of trade unions is gradually diluted, its meaning has been completely different from before,
Now his meaning is a bit like "identity", such as Taoist monk, Monk, Lama, soldier, common people ....
An individual has a personal identity. In many cases, this is similar to the gate, but not exactly the same.
It's a special thing for people of different identities,
But now it is usually used to store special uses of various special skills (perform)

/doc documentation. Various text files in the game, arch above can be modified
/doc/help various Help files
/doc/efuns usage of various system functions
/doc/story Various background stories

/log system Diary, record the game process of various important events, is the wizard to deal with disputes and remove the main source of the bug.
A good wizard should develop a habit of reading system diaries often. Only root permissions can be modified in this directory.

/P player directory, where content players have permission to write. Mainly store content that needs to be modified by the player,
such as player room, self-created martial arts and so on.

/STD Standard Object Directory, game of all kinds of standard objects,
Only Admin can modify other objects in the game to inherit the corresponding files here.
/std/armor standard inheritance of equipment items, such as clothing, armor, etc.
/std/board Message Board
The standard inheritance of/std/char organisms consists of two types of mobs: Players (player) and non-players (
NPC) They all need to inherit the/std/char/char.c object,
The difference between them and other objects is that they have a heartbeat (heartbeat).
/std/drug The standard inheritance of drugs, in fact, this is generally not used, this part of the function is put in the
/feature file, this is reserved for compatibility with the old system.
Standard Inheritance of/std/item items
Standard inheritance of/std/room rooms
Someone asked what the difference was between a room and an item. To tell you the truth, this is a really bad question.
The two objects are basically similar in structure and have no distinguishing features.
The usual way of judging now is that the room is no environment (environment), but not all items
(including biological) have the environment, so, hehe, this problem still needs to further improve the mud procedure,
It's almost impossible to judge now.
Standard inheritance of/std/skill skills
Standard inheritance of/std/weapon weapons
/std/misc other objects, such as money and paper.
It is worth noting that/std This directory is not the same as the general mudlib structure,
General Mudlib is not so classified storage, we can judge according to their own understanding.

The above is based on my understanding of the interpretation of the various directories, not necessarily the authority of the argument,
Just to let everyone know, if there is any mistake please correct me.
As a new Wizard of the beginning, it is important to understand the role of each catalogue accurately.
You have to know which directory to do what, which directory you can change, which directory you can't move.
In general, it takes at least half a month to "read" the program to be a qualified sorcerer,
Understand the structure of the entire mudlib and understand the role of each file
(not necessarily fully understood, but at least you should know what he is doing),
This will not be in the process of open procedures in the future do not know what the function of how to achieve, thereby taking a lot of detours.
When you get to know the whole mudlib, you can try to write your own program.
Generally you can only write in your own working directory. Just start by trying to write a simple room,
Then try to write a simple NPC, and then try to put the NPC in this room ...
You will soon become a qualified wizard.
Reference: Fire West Tourhttp://218.200.132.6:6666/list.asp?id=248

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

MudOS Running Process

Today I saw some of the station's articles, plus the view of the original program, the MudOS started, the process of running the program is clear. Little brother think as long as there is a good mudos, you can write a new mudlib box frame. I take the user connection to explain the program's running flow. The

notes the master and global two files in the Config.xxx file, which is a very important file.
MudOS will load the above two files (other files also have, but the above file is the main)
into memory, MudOS has defined some special functions, such as create (), init (), etc.,  
These functions are automatically called by MudOS in a particular event.
--mudos automatically calls the Connect () function in Master.c
--then the Connect () function calls Login_ob the object, [and Login_ob is an object constant, and the value defined in Global.h is "Login_ob Login.c ", that is, connect () called Login.c this object]
-There are some special functions in LOGIN.C, if the user correctly logged in the process, MudOS automatically call LOGIN.C in the logon () this special function.
--The object constant called Login_d in logon (), login_d the value defined in the Global.h file is "/adm/daemons/logind",
--and MudOS then calls the LOGIND.C into memory and runs.

We generally think that mudos in its settings file before compiling the user login to define the program path and file name,
compiled path and file name can not be changed, when the user is connected, MudOS automatically start the user login program according to the path.
In fact, MudOS is just a low-level support program for mud.

We can use MudOS to completely abandon the existing Mudlib framework and make new creations.
This will enable China's mud species to diversify.

-------------------------------------------=

How big is the minimum mudib?

This smallest is said to be able to drive MudOS, can successfully connected.
The standard description of the single-machine dedicated MudOS and its config.cfg are now downloaded online:
First find a separate MudOS run, need configuration file, load Config.cfg ... Prompt after run: Open Log/debug.log file failed. OK, the root configuration we build directory:/log, and then run, now prompt: The Simul_efun file adm/obj/simul_efun.c is not loaded. OK, we build directory:/adm/obj, and build an empty file in the obj directory simul_efun.c, and then run, now is: Adm/obj/simul_efun.c line 0:cannot #i nclude globals.h
ADM/OBJ/SIMUL_EFUN.C Line 1:parse Error
No error handler for error: *error in loading object '/adm/obj/simul_efun '
Program: (None), object: (None),.. File: (None)
The Simul_efun (/adm/obj/simul_efun) and Master (/adm/obj/master) objects must be loadable.
It seems to be config.h file, the root of the configuration file, we build a directory:/include, and in this directory add an empty file Globals.h, and then run: The master File/adm/obj/master is not loaded., Now we are building an empty file in the obj directory master. Run: No function Get_root_uid () in Master object; Possibly the mudlib doesn ' t want Package_uids to be defined. It seems that the empty master.c is not, we add the following statement in MASTER.C: String Get_root_uid () {RE Turn "Root"; }
String Get_bb_uid () {return "Backbone";}
String Creator_file (string file) {return "Root";}, now run again, Ok,mudos successfully run.

But now with Zmud connection connected after lose, how to do, now in MASTER.C add a following statement: Object connect (int port)
{
Object OB;

OB = new (__dir__ "user.c");
return OB;
}. Also create a new empty file in master.c same directory user.c, now run MudOS, and connect, success ...

Now look at what files and directories are used altogether?
1./log
2./adm/obj/simul_efun.c
3./include/globals.h
4./adm/obj/master.c
5./adm/obj/user.c

There is only master.c in the content, the others are empty, how big these 5 add up? 237 bytes, how about that?

[MUD] Mudlib detailed/mudos running process/minimum Mudlib/mud file structure