LDMud

Objects

An object is the combination of LPC code (collection of functions) and corresponding data (the global variables of the object). Objects are the main components of a virtual world with LDMud. Every code you want to execute must belong to an object. Objects are accessed via functions. To manipulate the data of an object there must exist a function within the object that does so, and this function can be called via call_other.

Compilation

Originally the code for an object will be an LPC file in the mud's directory structure. This file usually has the ending .c and is compiled via load_object or clone_object. It can contain four things: Comments (as in C with /* ... */, or // ... till the end of line), preprocessor statements (as in C like #include, #if, #ifdef, #else, or #endif), declaration of global variables and functions.

Each loaded object has a name (you can get it with object_name, and given a name look for the corresponding object with find_object). When using load_object this name is the same as its filename without the ending .c. Such an object is called blueprint. That's because when cloning with clone_object LDMud first looks for an already loaded blueprint. If a blueprint doesn't exist, it is loaded first. And after that the clone is created. Clones have also the filename in their object name, but its appended by a # and a number. So all objects have unique names.

The Master Object

There is one holy object that has the ultimate power. It's called the master object. It's whereabouts are given as a command line argument (default is secure/master.c in the mudlib directory) and it is loaded as the first object. The master object can or in some instances must set driver hooks to customize several aspects of the LDMud virtual machine, manages access to files and privileged efuns, deals with errors in LPC code, handles incoming network connections, etc.. For a more complete list look at master-all in the documentation of the driver source code.

Environment and inventory

An object can have a surrounding object. This object is then called the object's environment. So in a virtual world there are player objects and room objects and the player objects have their room object set as their environment (as do the furniture, monsters, or items lying around). The environment of an object can be set with move_object/set_environment and queried with environment. The other way round you can get all the objects that have the same environment with all_inventory. It's also possible that an environment has a surrounding object itself. So there are efuns to look further at the other or inner objects with all_environment resp. deep_inventory.

Living and interactive objects

There are a special kind of objects that can have actions defined for them. Actions are just functions that are called when a specific command was given. And objects that can give commands are called living objects. Commands are enabled with enable_commands (making the current object a living object) and disabled with disable_commands (making it a dead object). An action can only be registered by an object in the environment or the inventory of the living object, or by the environment or the object itself. Actions are defined with add_action:

    int hello_fun(string args)
    {
        write("Hello you too!\n");
        return 1;
    }

    void init()
    {
        add_action("hello_fun", "hello");
    }

In the above example, whenever a living object enters "hello" or something like "hello y'all" the function hello_fun is called and the efun this_player will return that living object. The function will get one argument and that is the string following "hello" on the command (e.g. "y'all") or 0 if there was none. The function must return a non-zero value if it was successful. If it returns zero LDMud will look for further matching actions and calls their functions. If there was no successful action an error message is printed. The error message can be set with notify_fail during the exection of an action's function. Please note that in the init function in the example will not automatically called by LDMud. It is customary that mudlibs call such a function in all nearby objects when a living object moved.

There are also special special objects, these are living objects that have a network connection associated with them. These are usually the players in your world and these are called interactive objects. These network connections are treated as telnet connections and the telnet negotations done there are handled by the driver per default. And all text messages coming through there will be interpreted as commands. Incoming network connections are given to the master object when calling it's connect function and can be transferred to other objects with the exec efun. The efun users returns a list of all interactive objects, and the efun interactive returns a non-zero value if the given object is interactive (as does living with living objects).

Shadows

An object can catch external function calls to another object and answer these calls itself. Such an object is called shadow. One object may only shadow one other object and mustn't be shadowed itself. Shadowing is started with the shadow efun and needs permission by the master object. After then each call_other to the shadowed object will be redirected to the shadow. If the shadow doesn't define then this call will be passed to the shadowed object. The only calls that will not be redirected are the ones from the shadow itself.

Lightweight Objects

Lightweight objects are similar regular objects but have some restrictions and advantages: They don't have a name, cannot have an environment or inventory, cannot be living or interactive, cannot have shadows or be a shadow. But they have a much smaller memory footprint than regular objects and are destructed automatically. They can be copied and saved.

Similar to regular objects, lightweight objects are built from LPC files via new_lwobject.