A cat of all files in this dir, incase you're looking for things.
Again things got a mess when the 8.3 filenames for dos got
through to this.

Leto


.\"function added to objects to handle initialization of variables.
.TH __INIT 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
__INIT - function added to objects to handle initialization of variables.

.SH SYNOPSIS
__INIT( void );

.SH DESCRIPTION
When the driver compiles an object that contains variable declarations that
initialize the variables, then the driver inserts a function named __INIT()
in the compiled object in which the initializations are performed.  For
example, in the following object:
.PP
  int x = 3;

  void
  create()
  {
     write(x + "\\n");
  }

.PP
the driver would translate it into the following internal form before compiling
the object:
.PP
  int x;

  __INIT()
  {
     x = 3;
  }

  void
  create()
  {
     write(x + "\\n");
  }
.PP
If you add a function named __INIT() to one of your objects, then the
driver will call it at object-load-time just as if the driver had inserted
the function on its own.  Be aware that if you do this and the driver needs
to add __INIT in order to initialize variables, then there will be a conflict.
.\"determine the author for a given object
.TH author_file 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
author_file - determine the author for a given object

.SH SYNOPSIS
string author_file (string file);

.SH DESCRIPTION
This function must exist in the master object.  It is called by the
author statistic functions in the driver to determine what author a
given object should be associated with.  This is totally arbitrary and
up to the mudlib designers wishes.  It should be noted that the author
that the object is assigned to will receive "credit" for all of the
objects behavior (errors, heart_beats, worth, etc).

.SH SEE ALSO
author_stats(3), domain_stats(3), domain_file(4)
./"provides an interface to interact with users
.TH catch_tell 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
catch_tell - provides an interface to interact with users

.SH SYNOPSIS
void catch_tell( string message );

.SH DESCRIPTION
If INTERACTIVE_CATCH_TELL is defined in options.h, whenever the driver
has something to tell an object due to say(), shout(), tell_object(), etc.
catch_tell in the player object will be called with the message to
be printed.  The message can be displayed, discarded, or modified in
any way desired.  This is a useful way to have flexible earmuffs, or
to support intelligent clients.

.SH SEE ALSO
message(3), receive(3), receive_message(4)
.\"periodically called in inactive objects
.TH clean_up 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
clean_up - periodically called in inactive objects

.SH SYNOPSIS
int clean_up( int inherited );

.SH DESCRIPTION
The clean_up() function is called by the driver on a regular basis in all
objects that have been inactive for the time specified for clean_up() in the
runtime configuration file.  One flag is passed to the function, specifying
whether or not the object has been inheritted by anything.  If clean_up()
returns 0, clean_up() will never be called again on that object.  If it returns
1, it will be called again when the object remains inactive for the specified
clean_up() delay.
.PP
One thing that might be commonly done by an object in this function is
destructing itself to conserve memory.
.\"serves as the mudlib interface for the virtual object facility
.TH compile_object 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
compile_object - serves as the mudlib interface for the virtual object facility

.SH SYNOPSIS
object compile_object( string pathname );

.SH DESCRIPTION
The driver calls compile_object(3) in the event that the mudlib instructs
the driver to load a file that does not exist.  For example, the driver
will call compile_object("/obj/file.r") in master if the mudlib calls
call_other("/obj/file.r", "some_function") or new("/obj/file.r")
and /obj/file.r.c names a file that does not exist.  The compile_object()
function is expected to return 0 if the mudlib does not wish to
associate an object with the file name "/obj/file.r".  If the mudlib
does wish to associate an object with the filename "/obj/file.r", then
the mudlib should return the object it wishes associated.  After an
association is made between an object and a filename, then it will be
as if the file, file.r.c, did exist (to the driver) and when loaded produced
the object that compile_object() returned.
.\"returns a pointer to the user (player) object to the driver
.TH connect 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
connect - returns a pointer to the user (player) object to the driver

.SH SYNOPSIS
object connect( void );

.SH DESCRIPTION

The driver calls connect() in the master object whenever a new user logs
into the driver.  The object returned by connect() is used as the initial
user object.  Note that it is possible to use exec(3) to switch the user
connection from the initial user object to some other object.

.SH SEE ALSO
exec(3), logon(4)
.\"function in master that is called when the driver crashes.
.TH crash 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
crash - function in master that is called in the event the driver crashes

.SH SYNOPSIS
.nf
void crash( string crash_message, object command_giver,
            object current_object );

.SH DESCRIPTION
The driver calls crash() in master in the event that the driver crashes
(segmentation fault, bus error, etc).  This function offers a way to
shutdown the mudlib (safe players and other important data) before the driver
crashes.  It also lets you log various useful information such as what
signal crashed the driver, what object was active, who the current player
was etc.

.SH SEE ALSO
slow_shutdown(4), shutdown(3)
.\"object initialization
.TH create 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
create - object initialization

.SH SYNOPSIS
void create( void );

.SH DESCRIPTION
Every object should have a create function defined within it.  Within
that function, all initial object initialization should be done.
create() is called on *all* objects.  *NOTE* - This behavior is
different than the stock 3.1.2 LPmud driver.  In 3.1.2, if an object
is created first by being inherited, then create() wasn't called on
it.  In MudOS, this behavior has changed so that it is *always* called
when an object is created.  As a result, you may see some odd behavior
if you have a create in a parent object that does a write, you will
see two writes, as if create() had been called twice on the same
object.  In reality, create *is* being called twice, but on two
*different* objects: the parent, and the child that is calling
parent::create() manually.

.SH SEE ALSO
reset(4), __INIT(4)

.SH AUTHOR
Wayfarer@Portals
.\"specifies the uid to give to a newly created object
.TH creator_file 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
creator_file - specifies the uid to give to a newly created object

.SH SYNOPSIS
string creator_file(string filename);

.SH DESCRIPTION
The creator_file() function is called in the master object each time a new
object is created.  The `filename' of the object is passed as the sole
parameter, and the string that creator_file() returns is set as the new
object's uid.  If the AUTO_SETEUID option is enabled at compile-time of the
driver, it is also set as the new object's euid.
.PP
One exception: if the AUTO_TRUST_BACKBONE option is enabled at compile-time of
the driver, and creator_file() returns the backbone uid (as specified by
get_bb_uid() in the master object), the object is given the uid and euid of
the object that loaded it.

.SH SEE ALSO
seteuid(3), new(3), clone_object(3), call_other(3)
.\"allows master to relocate object when environment is destructed
.TH destruct_env_of 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
destruct_env_of - allows master to relocate object when environment is destructed

.SH SYNOPSIS
void destruct_env_of( object );

.SH DESCRIPTION
This master apply is called by destruct() on each of
the destructed object's contents, when the
destructed object has no environment (eg a room).
It allows the mud to specify what to do with the destructed
object's contents (eg players) or inventory.

.SH NOTE
This master apply used to be named destruct_environment_of().

.SH SEE ALSO
destruct(3), move(4)
.\"determine the domain for a given object
.TH domain_file 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
domain_file - determine the domain for a given object

.SH SYNOPSIS
string domain_file( string file );

.SH DESCRIPTION
This function must exist in the master object.  It is called by the
domain statistic functions in the driver to determine what domain a
given object should be associated with.  This is totally arbitrary and
up to the mudlib designers wishes.  It should be noted that the domain
that the object is assigned to will receive "credit" for all of the
objects behavior (errors, heart_beats, worth, etc).

.SH SEE ALSO
author_stats(3), domain_stats(3), author_file(4)

.SH AUTHOR
Wayfarer@Portals
.\"returns an array of the filenames of the objects to be preloaded.
.TH epilog 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
epilog - returns an array of the filenames of the objects to be preloaded.

.SH SYNOPSIS
.nf
string *epilog( int load_empty );
void preload( string filename );

.SH DESCRIPTION
The driver calls epilog() in master after the master object has been loaded.
Mudlibs typically use epilog to initialize data structures in master (such
as security tables etc).  epilog() should returns an array of filenames
which correspond to objects that the mudlib wants to have preloaded; that is,
loaded before the first player logs in.  For each filename returned in the
array, the driver will called preload(filename) in master.

The variable 'load_empty' is non-zero if the -e option was specified
when starting up the driver.  It can be used as a signal to the mudlib
to not load castles, etc.

.SH SEE ALSO
preload(4)
.\"master apply for mudlib error handler
.TH error_handler 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
error_handler - function in master object to handle errors

.SH SYNOPSIS
void error_handler( mapping error, int caught );

.SH DESCRIPTION
This function allows the mudlib to handle errors instead of the driver.
The contents of the 'error' mapping are:
.PP
.nf
    ([
        "error"   : string,     // the error
        "program" : string,     // the program
        "object"  : object,     // the current object
        "trace"   : *string,    // a trace back
        "line"    : int         // the line number
    ])
.fi
.PP
The 'caught' flag is 1 if the error was trapped by catch().

.SH SEE ALSO
catch(3), error(3), throw(3), log_error(4)

.SH AUTHOR
Beek
.\"handle mudlib specific flags specified at driver startup
.TH flag 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
flag - handle mudlib specific flags specified at driver startup

.SH SYNOPSIS
void flag( string );

.SH DESCRIPTION
This master apply is called for each command line
option passed to the driver with the -f flag.
.\"get the backbone uid
.TH get_bb_uid 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
get_bb_uid - get the backbone uid

.SH SYNOPSIS
string get_bb_uid( void );

.SH DESCRIPTION
This master apply is called by the driver on startup,
after it has loaded the master object, to get the
backbone uid defined by the mud.  The function should
return a string, eg "BACKBONE"

.SH SEE ALSO
get_root_uid(4)
.\"get the root uid
.TH get_root_uid 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
get_root_uid - get the root uid

.SH SYNOPSIS
string get_root_uid( void );

.SH DESCRIPTION
This master apply is called by the driver each time
it loads the master object, to verify that the master
object has loaded, and to get the root uid defined by
the mud.  The function should return a string, eg "ROOT"

.SH SEE ALSO
get_bb_uid(4)
.\"back up editor file on abnormal exit
.TH get_save_file_name 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
get_save_file_name - back up editor file on abnormal exit

.SH SYNOPSIS
string get_save_file_name( string );

.SH DESCRIPTION
This master apply is called by ed() when a player disconnects
while in the editor and editing a file.  This function
should return an alternate file name for the file to
be saved, to avoid overwriting the original.

.SH NOTE
This apply used to be named get_ed_buffer_save_file_name().

.SH SEE ALSO
ed(3)
.\"function called by present() in order to identify an object
.TH id 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
id - function called by present() in order to identify an object

.SH SYNOPSIS
int id( string an_id );

.SH DESCRIPTION
The present(3) efunction calls id() to determine if a given object is named
by a given string.  id() should return 1 if the object wishes to be known
by the name in the string anId; it should return 0 otherwise.

.SH SEE ALSO
present(3)
.\"function in an object called by move_object() to initialize verb/actions
.TH init 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
init - function in an object called by move_object() to initialize verb/actions

.SH SYNOPSIS
void init( void );

.SH DESCRIPTION
When the mudlib moves an object "A" inside another object "B", the
driver (the move_object() efunction) does the following:
.TP
1.
if "A" is living, causes "A" to call the init() in "B"
.TP
2.
causes each living object in the inventory of "B" to call init() in
"A".  regardless of whether "A" is living or not.
.TP
3.
if "A" is living, causes "A" to call the init() in each object in
the inventory of "B".
.PP
Note: an object is considered to be living if enable_commands(3) has
been called by that object.
.PP
Typically, the init(4) function in an object is used to call add_action(3)
for each command that the object offers.

.SH SEE ALSO
reset(4), move_object(3), enable_commands(3), living(3), add_action(3)
.\"log errors intelligently
.TH log_error 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
log_error - log errors intelligently

.SH SYNOPSIS
void log_error( string file, string message );

.SH DESCRIPTION
Whenever an error occurs during compilation, the function log_error in
the master object is called with the filename that the error occurred
in and the error message itself.  Then, log_error is free to do
whatever it thinks it should do with that information.  Usually this
is deciding based on the filename where the error message should be
logged, and then writing it to that file.

.SH SEE ALSO
error_handler(4)

.SH AUTHOR
Wayfarer@Portals
.\"attach an object to a login connection
.TH logon 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
logon - attach an object to a login connection

.SH SYNOPSIS
object logon( void );

.SH DESCRIPTION
This master apply is called by the driver each time
a new connection is received at the mud port.  The
function should return a login/connection/player object.
The input_to() efun can't be called here.

.SH SEE ALSO
connect(4)
.\"resolve relative path name
.TH make_path_absolute 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
make_path_absolute - resolve relative path name

.SH SYNOPSIS
.nf
string make_path_absolute( string rel_path );

.SH DESCRIPTION
This master apply is called by the ed() efun to
resolves relative path names of a file to read/write, to an absolute path
name.

.SH SEE ALSO
ed(3)
.\"ask an object to move to the specified destination
.TH move 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
move - ask an object to move to the specified destination

.SH SYNOPSIS
int move( object dest, int flag );

.SH DESCRIPTION
This apply is called by destruct() on each of the
destructed object's contents or inventory.  In so doing, the driver
passes the flag 1.  This allows objects to choose between
moving to the destructed object's environment or be
destructed.  This function should return 0 if the move was
ok.  The object is destructed if the return value is non-zero
(ie failed to move).

.SH SEE ALSO
destruct(3), move_object(3), init(4), destruct_env_of(4)
.\"called by the MudOS driver when an interactive object drops its connection
.TH net_nead 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
net_dead - called by the MudOS driver when an interactive object
drops its connection

.SH SYNOPSIS
void net_dead( void );

.SH DESCRIPTION
If an interactive object (i.e. the player object) suddenly loses its
connection (i.e. it goes "net dead"), then the driver calls this
function on that object giving it a chance to clean up, notify its
environment etc.  Be aware that functions that depend on the object
being interactive will not work as expected.

.SH AUTHOR
Wayfarer@Portals
.\"called by the driver to find out an object's name
.TH object_name 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
object_name - called by the driver to find out an object's name

.SH SYNOPSIS
string object_name( object );

.SH DESCRIPTION
This master apply is called by the sprintf() efun, when
printing the "value" of an object.  This function should
return a string corresponding to the name of the object
(eg a user's name).

.SH SEE ALSO
file_name(3)
.\"returns an array of the filenames of the objects to be preloaded.
.TH preload 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
preload - preload an object into memory.

.SH SYNOPSIS
.nf
string *epilog( int load_empty );
void preload( string filename );

.SH DESCRIPTION
The driver calls epilog() in master after the master object has been loaded.
Mudlibs typically use epilog to initialize data structures in master (such
as security tables etc).  epilog() should returns an array of filenames
which correspond to objects that the mudlib wants to have preloaded; that is,
loaded before the first player logs in.  For each filename returned in the
array, the driver will called preload(filename) in master.

The variable 'load_empty' is non-zero if the -e option was specified
when starting up the driver.  It can be used as a signal to the mudlib
to not load castles, etc.

.SH SEE ALSO
epilog(4)
.\"specifies the privs string to give to a newly created object
.TH privs_file 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
privs_file - specifies the privs string to give to a newly created object

.SH SYNOPSIS
string privs_file( string filename );

.SH DESCRIPTION
The privs_file() function is called in the master object when a new file
is created.  The `filename' of the object is passed as the argument, and
the string that privs_file() returns is used as the new object's privs
string.

The privs_file() functionality is only available if the driver is compiled
with the PRIVS option defined.

.SH SEE ALSO
query_privs(3), set_privs(3)
.\"accepts a copy of all user input from the MudOS driver
.TH process_input 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
process_input - provide a hook for the MudOS driver to send a copy of what the
player is typing to the player object.

.SH SYNOPSIS
string process_input( string );

.SH DESCRIPTION
If process_input is present in the player object, then the MudOS driver
parser will send it a copy of each line the player types.  Process_input
makes it easy to implement features like command history and protection
against wizcuffs.  process_input can also modify the player input before it
is parsed.  If process_input returns a non-zero string, that string is
used by the driver instead of what the player typed.

.SH AUTHOR
Truilkan@TMI
.\"provides the interface used by the message() efun.
.TH receive_message 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
receive_message - provides the interface used by the message efun.

.SH SYNOPSIS
void receive_message( string class, string message );

.SH DESCRIPTION
The message() efun calls this method in the player object.  The class
parameter is typically used to indicate the class (say, tell, emote,
combat, room description, etc) of the message.  The receive_message() 
apply together with the message() efun can provide a good mechanism for
interfacing with a "smart" client.

.SH SEE ALSO
catch_tell(4), message(3), receive(3), receive_snoop(4)
.\"catch incoming snoop text
.TH receive_snoop 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
receive_snoop - catch incoming snoop text

.SH SYNOPSIS
void receive_snoop( string message) ;

.SH DESCRIPTION
If RECEIVE_SNOOP is defined in options.h, whenever a user is snooping another
user, all snoop text is sent to receive_snoop() in his user object.  Inside
of this function, you can do as you wish with the text.  A common activity
would be to receive() it.

.SH SEE ALSO
catch_tell(4), receive(3), receive_message(4)
.\"allows an object to do self-maintenance
.TH reset 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
reset - allows an object to do self-maintenance

.SH SYNOPSIS
void reset( void );

.SH DESCRIPTION
After every reset interval (whose exact length is determined on
a mud by mud basis, but averages around every 2 hours), reset()
is called in every object that currently exists.  If LAZY_RESETS
is defined in options.h in the driver, reset() will only be called
in objects when they are touched (near players), so unused objects
will not be loaded from the swap file to reset.  The reset() call
is usually used to check if any treasures and/or monsters in the room
have been removed so they can be replaced.

.SH SEE ALSO
set_reset(3), create(4)
.\"retrieve a user's editor setup or configuration settings
.TH retrieve_ed_setup 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
retrieve_ed_setup - retrieve a user's editor setup or configuration settings

.SH SYNOPSIS
int retrieve_ed_setup( object user );

.SH DESCRIPTION
This master apply is called by the ed() efun to retrieve
a user's ed setup/configuration settings.  This function
should return the setup (contained in an int).

.SH SEE ALSO
save_ed_setup(4)
.\"save a user's editor setup or configuration settings
.TH save_ed_setup 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
save_ed_setup - save a user's editor setup or configuration settings

.SH SYNOPSIS
int save_ed_setup( object user, int config );

.SH DESCRIPTION
This master apply is called by the ed() efun to save
a user's ed setup/configuration settings (contained in
an int).  This function should return an int for
success (1 or TRUE)/failure (0 or FALSE).

.SH SEE ALSO
retrieve_ed_setup(4)
.\"informs the mud that a slow shutdown is in progress
.TH slow_shutdown 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
slow_shutdown - informs the mud that a slow shutdown is in progress

.SH SYNOPSIS
void slow_shutdown( int minutes );

.SH DESCRIPTION
This master apply is called when the driver can't
allocate any more memory from the heap and had to
use its reserved memory block.  This function can
only be called if the "reserved size" config file
setting was set.  The minutes remaining to driver
shutdown is passed to this function.

.SH SEE ALSO
crash(4), shutdown(3)
.\"process telnet suboptions
.TH telnet_suboption 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
telnet_suboption - process telnet suboptions

.SH SYNOPSIS
void telnet_suboption( string buffer );

.SH DESCRIPTION
This apply is called on the interactive object with the parameter given
by the SE telnet suboption, for mudlib defined processing.  For example,
this allows for future support of terminal types.
.PP
The first byte of the buffer is typically a type descriptor,
ie TELOPT_TTYPE. The next byte is a procession option, such
as TELQUAL_IS.  Following this is the type dependent data.
In the case of a terminal type call, the data is the terminal
type name.
.PP
Possible suboptions:
.IP
.nf
#define TELQUAL_IS    0 // option is...
#define TELQUAL_SEND  1 // send options
#define TELQUAL_INFO  2 // ENVIRON: informational version of IS
#define TELQUAL_REPLY 3 // AUTHENTICATION: client version of IS
#define TELQUAL_NAME  4 // AUTHENTICATION: client version of IS
.fi
.\"controls whether or not a LPC->C compiled object can use asm { }
.TH valid_asm 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_asm - controls whether or not a LPC->C compiled object can use asm { }

.SH SYNOPSIS
int valid_asm( string file );

.SH DESCRIPTION
When the driver is compiled with LPC_TO_C, valid_asm() is called whenever
the asm { } structure is found in code.  If it returns 0, the compilation
will terminate with an error.
.PP
The asm { } structure is used as follows:
.IP
.nf
asm {
  <C code>
}
.fi
.PP
It causes the code between the braces to be literally inserted into the
compiled file.
.\"controls whether or not an object may be compiled via LPC->C at runtime
.TH valid_compile_to_c 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_compile_to_c - controls whether or not an object may be compiled via LPC->C at runtime

.SH SYNOPSIS
int valid_compile_to_c( string file );

.SH DESCRIPTION
When the driver is compiled with LPC_TO_C and RUNTIME_LOADING defined,
valid_compile_to_c will be called in the master object whenever a program
loads whose name ends in ".C" instead of ".c".  If it returns 1, the
program compiles to C.  If it returns 0, it compiles as a normal LPC
object.  The name is passed including the trailing ".C".
.\"allows or disallows objects to hide and see hidden objects
.TH valid_hide 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_hide - allows or disallows objects to hide and see hidden objects

.SH SYNOPSIS
int valid_hide( object ob );

.SH DESCRIPTION
Add valid_hide to master.c in order to allow objects to hide themselves,
or see other objects that have hidden themselves.  When an object tries to
use the set_hide() efun to hide itself, valid_hide will be called with the
object that is wanting to hide as the sole parameter.  It should return 1
to allow it, or 0 to not allow it.  The same call takes place when it needs
to be determined if a certain object should be able to see hidden objects.

.SH SEE ALSO
set_hide(3)
.\"controls the use of link(3)
.TH valid_link 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_link - controls the use of link(3)

.SH SYNOPSIS
int valid_link( string from, string to );

.SH DESCRIPTION
The driver calls valid_link(from, to) in the master object from inside the
link(from, to) efunction.  If valid_link() returns 0, then the link()
will fail.  If valid_link() returns 1, then the link(3) will succeed if
rename() would succeed if called with the same arguments.

.SH SEE ALSO
link(3)
.\"allows control over which objects can be loaded
.TH valid_object 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_object - allows control over which objects can be loaded

.SH SYNOPSIS
int valid_object( object obj );

.SH DESCRIPTION
After loading an object, the driver will call valid_object() with the newly
created object as its argument, in the master object.  If the function
exists, and returns 0, then the object will be destructed and the efun that
caused it to load will error out.  If it does not exist, or returns 1, then
loading will proceed as normal.  In conjunction with 'nomask' and the
inherits() efun, this could allow safely restricting destruct() via
a simul_efun.

.SH SEE ALSO
valid_override(4)
.\"controls the use of efun:: to override simulated efuns that mask efuns.
.TH valid_override 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_override - controls the use of efun:: 

.SH SYNOPSIS
int valid_override( string file, string efun_name );

.SH DESCRIPTION
Add valid_override to master.c in order to control the use of the efun::
prefix.  The valid_override function in master.c will be called each
time the driver attempts to compile a function call that begins with
efun::.  If valid_override returns 0, then that compile will fail.  Thus
valid_override provides a way to modify the behavior of efuns that isn't
circumventable via the efun:: prefix (by having a simul_efun of the same
name as the efun to be modified and having valid_override disallow that
simul_efun from being overriden).
.PP
If you wish to have the original 3.1.2 efun:: behavior, simply add
a line to master.c that looks like this:
.TP
   int valid_override(string file, string efun) { return 1; }
.PP
Here is an example valid_override that is more restrictive:
.PP
  int
  valid_override(string file, string name)
  {
      if (file == "/adm/obj/simul_efun") {
          return 1;
      }
      if (name == "destruct")
          return 0;
      if (name == "shutdown")
          return 0;
      if (name == "snoop")
          return 0;
      if (name == "exec")
          return 0;
      return 1;
   }

.SH AUTHOR
Truilkan@Basis

.SH SEE ALSO
valid_object(4), function_exists(3)
.\"checks if a certain person has read permission on a file
.TH valid_read 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_read - checks if a certain person has read permission on a file

.SH SYNOPSIS
int valid_read( string file, mixed user, string func );

.SH DESCRIPTION
Every time a user tries to read a file, thie driver calls valid_read
in the master object to check if the read should be allowed.  The
arguments are the filename, the name of the person making the read, and
the calling function name.  If valid_read returns non-zero, the read is
allowed.

.SH SEE ALSO
valid_write(4)
.\"controls whether or not an object can save its loaded program
.TH valid_save_binary 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_save_binary - controls whether or not an object can save its program

.SH SYNOPSIS
int valid_save_binary( string file );

.SH DESCRIPTION
When the driver is compiled with ALWAYS_SAVE_BINARIES, or an object uses
'#pragma save_binary', valid_save_binary is called with the program's filename.
If valid_save_binary returns 1, the save will be allowed, otherwise it will
not.
.\"secures the use of seteuid(3)
.TH valid_seteuid 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_seteuid - secures the use of seteuid(3)

.SH SYNOPSIS
int valid_seteuid( object obj, string euid );

.SH DESCRIPTION
The driver calls valid_seteuid(ob, euid) in the master object from inside the
seteuid(euid) efunction.  If valid_seteuid() returns 0, then the seteuid()
call will fail.  If valid_seteuid() returns 1, then the seteuid(3) will
succeed.  

.SH SEE ALSO
seteuid(3), geteuid(3), getuid(3), export_uid(3)
.\"controls which objects can be shadowed
.TH valid_shadow 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_shadow - controls which objects can be shadowed

.SH SYNOPSIS
int valid_shadow( object ob );

.SH DESCRIPTION
When an object attempts to shadow `ob' (with the shadow() efun), valid_shadow
in the master object is called.  One object parameter is passed, which is the
object that previous_object() is attempting to shadow.  valid_shadow() should
return 0 if the shadow should not be permitted, in which case the shadow() call
will return 0 and fail.  If valid_shadow() returns 1, the shadow is allowed.

.SH SEE ALSO
shadow(3), query_shadowing(3)
.\"provides security governing the use of the socket efunctions
.TH valid_socket 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_socket - protects the socket efunctions.

.SH SYNOPSIS
.nf
int valid_socket( object caller, string function,
                  mixed *info );

.SH DESCRIPTION
Each of the socket efunctions calls valid_socket() prior to executing.
If valid_socket returns 0, then the socket efunction fails.  If
valid_socket returns 1, then the socket efunction attempts to succeed.
The first argument 'caller' is the object that called the socket efunction.
The second argument is the name of the socket efunction that is being
called (e.g. socket_write() or socket_bind()).  The third argument is
an array of information.  The first element of the array (when applicable)
is file descriptor being referenced.  The second element of the array
is the owner of the socket (object).  The third element of the array is
the address (string) of the remote end of the socket.  The fourth element
of the array is the port number associated with the socket.
.\"checks if a certain person has write permission on a file
.TH valid_write 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
valid_write - checks if a certain person has write permission on a file

.SH SYNOPSIS
int valid_write( string file, mixed user, string func );

.SH DESCRIPTION
Every time a user tries to write a file, thie driver calls valid_write
in the master object to check if the write should be allowed.  The
arguments are the filename, the name of the person making the write, and
the calling function name.  If valid_write returns non-zero, the write is
allowed.

.SH SEE ALSO
valid_read(4)
.\"called by the MudOS driver when a prompt should be printed
.TH write_prompt 4 "5 Sep 1994" MudOS "Driver Applies"

.SH NAME
write_prompt - called when the parser wants a prompt to be written.

.SH SYNOPSIS
void write_prompt( void );

.SH DESCRIPTION
If write_prompt is present in the player object, the driver will call it
whenever the default prompt would normally be printed.  The driver will
not call write_prompt when the player is in input_to or ed.

.SH AUTHOR
Truilkan@TMI
