29 lines
1.6 KiB
Plaintext
29 lines
1.6 KiB
Plaintext
Simulated efunctions
|
|
|
|
There is a mechanism to allow the mudlib to simulate efunctions. All
|
|
simulated efuns must be defined in a special file (the name and location
|
|
of which are to be specified in the config file).
|
|
|
|
When compiling an object and a function call (not a call_other) is found that
|
|
has not been defined in the object then the driver
|
|
will search for that function in the list of simulated efuns. If the
|
|
function is found in that list, then the driver sets up a call to
|
|
that function (as defined in the simulated efun file).
|
|
|
|
Simulated efuns have many uses. One is that it is now possible to make major
|
|
changes (and even removals) to the behavior of efuns without modifying
|
|
the driver (by making a simul_efun having the same name as an efun). Suppose
|
|
you wish to modify the behavior of the move_object() efun. You could do
|
|
so by defining a simulated efun having the same name. The simulate efun
|
|
could perform various restrictive checks and then call efun::move_object().
|
|
The efun:: prefix is necessary so that the driver will know you wish to call
|
|
the move_object efun and not recursively call the simulate_efun within which
|
|
the call to move_object is contained. [Note that valid_override() in master.c
|
|
can be used to conrol which simul_efuns may be overridden via the efun::
|
|
prefix]. Simulated efuns are also useful for adding functions that many
|
|
different objects may need to call but which aren't appropriate for
|
|
inclusion in an inherited file.
|
|
|
|
Any function in the simulated efun file that is declared static, will
|
|
not be callable by functions outside the simulated efun file.
|