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
Originally the code for an object will be an LPC file in the mud's
directory structure. This file usually has the ending
and is compiled via
It can contain four things: Comments (as in C with
/* ... */, or
// ... till the end of line), preprocessor statements
(as in C like
#endif), declaration of global
variables and functions.
Each loaded object has a name (you can get it with
and given a name look for the corresponding object with
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.
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.
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
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
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
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
notify_fail during the exection of
an action's function.
Please note that in the
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
returns a list of all interactive objects, and the efun
returns a non-zero value if the given object is interactive (as does
living with living objects).
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
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 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