CONCEPT native (native driver mode) NOTE The following paragraphs are mostly of historical value and need to be rewritten. Nowadays, it is possible to select the good pieces of both compat and native mode at driver compile time. Also, please don't be irritated by the references to NightFall, as I said, it is somewhat historical :-) DESCRIPTION Native (in contrast to compatibility) mode is the name for specifying that a certain #define COMPAT_MODE in the driver is not to be used. Native mode generally introduces a mudlib world concept which is more logic. Compat mode has stayed supported in the driver to allow for 2.4.5 mudlibs to be used with the 3.0 (now 3.1) driver. Today Nightfall is still running with sort of a 2.4.5 mudlib. Native mode introduces some radical changes which make it impossible to use an unchanged 2.4.5 mudlib and difficult to adapt a 2.4.5 mudlib to native mode. Some people call native mode mudlibs "3.0 mudlibs", "3.0" or "mudlib3", which means that it is the right mudlib to run under a 3.x driver. Perhaps I should explain what "driver" is. The driver is the C-Program which reads the LPC files, compiles them and brings the compiled object into existance. It is comparable to an operating system because it executes "system call", in LPC simply called "efuns" or external functions. It is also responsible for calling specific functions in objects in the mudlib, like heart_beat(), id(), create() or reset(). The driver also automatically loads and starts Armageddon when the memory is becoming low. Now, with native mode there are some drastic changes in how some efuns work and how security is handled (who may read and write where). The changes are explained in detail below. move_object() move_object can no longer move other objects, but can only move itself (First argument must be this_object()). Also the efun transfer() doesn't exist anymore. All moving is now done by calling the lfun ob->move() in the object which should be moved. It is up to the object to decide if it wants to be moved and it will also check if it will fit into containers the user might want to put it in. Weight update is done automatically by move(). The efun exit() doesn't exist any more in native mode. A return code of 1 means the object was successfully moved. Likewise there is an lfun remove() in every standard object which can be called to destruct the object. Thus the object will have a chance to decide if it really wants to be destructed. For emergency, destruct() still detructs unconditionally any object, but it's use should be avoided whenever possible. File names The efuns file_name() and function_exists() returns filename with leading '/' in native mode (used to be without slash in compat mode). User ID system In native mode there is a new complex permission system. Basically, the ability of an object to do things (clone objects, write files) is based on the userid the object has. Normally this means that objects made by a wizard can only do what the wizard could do in person (his user object that is). A more detailed discussion about this system is in userids(C). Because of the userid system, the efun creator() is no longer needed in native mode. Preloading In compat mode there used to be the file /room/init_file where all castles and some extra files were preloaded automatically. The new preloading in native mode starts by calling a function epilog() and preload() in /secure/master.c. The master object will then collect preload objects from different places. The only place for wizards files to be preloaded is putting them in a domain preload file /d/<domainname>/preload.c. Preprocessor symbols The symbol 'LPC3' will automatically be defined when loading objects. It can be used for '#ifdef LPC3' etc. This was defined already in 3.0 compat mode. The symbol 'COMPAT_FLAG' is additionaly defined if the driver runs in compat mode. <config.h> defines two additional symbols, 'COMPAT' or 'NATIVE'. For mud specific code you may also use the symbol 'MUDNAME' which is defined as "nightfall" in <config.h>. Object create, reset and cleanup When an object is loaded or cloned for the first time, a function create() is called in that object. After a certain time, and when someone comes near the object, reset() will be called in the object. In compat mode there was only the function reset() which was called with a parameter of 0 or 1. To faciliate some upward compatibility, reset() will still be called with a parameter of 1, but reset will never be called with argument 0, but create() is called instead. If the clean_up function is defined in an object, it gives the obejct the possibility to destruct itself when nobody comes near it for a while (about 2 hours). Rooms are autodestructed if there is nothing in them and the clean_up function is not redefined by the object inheriting /std/room. clean_up must return a nonzero value if the object should autodestruct. clean_up is called with an argument which is non-zero if the program of the object is inherited by another object. snoop Snoop has become more secure. valid_snoop() in master.c decides if snooping is allowed. set_snoop() now takes two parameters, snooper and snoopee and asks master.c if snooping is allowed. If snoop succeeds, set_snoop returns the object snooped on, otherwise it returns 0. query_snoop() can only be called from master.c. global variable initialization It is now possible to initialize non-local variables. If such initialization is used, then a function __INIT() will automatically be defined, which can be called. __INIT() is automatically called when the object is created for the first time, as well as when it is cloned. The __INIT() function will also call __INIT() of all inherited files, if there are any. Strict types are enforced. Example: object created_me = this_player(); The variables are initalized and __INIT is called in the same order as variables are declared respectively inherit statements are encountered. SEE ALSO userids(C), move_object(E), snoop(E), initialisation(LPC)