MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | CONCEPT |
| 2 | driver modes / native driver mode |
| 3 | |
| 4 | DESCRIPTION |
| 5 | During the evolution of LPMud there has been a hiatus as the |
| 6 | old driver became too restricting for the demands of modern |
| 7 | muds: it did a lot of things the mudlib could do better or |
| 8 | completely different. Removing these things from the driver |
| 9 | weren't a problem, but to keep compatible with the existing |
| 10 | mudlibs (namely the well-known 2.4.5 lib), it was possible to |
| 11 | undo these changes. First by setting a runtime option, then |
| 12 | by compiling the driver either in 'compat' or in 'native' mode. |
| 13 | |
| 14 | Starting with 3.2.1, the distinction between compat and native |
| 15 | mode is more and more transferred into the mudlib, with the |
| 16 | future goal of having a modeless driver. |
| 17 | |
| 18 | Starting with 3.2.7, native mode no longer exists as such, |
| 19 | only 'plain' (quasi a superset of 'native' and 'compat') |
| 20 | and 'compat' mode, and since 3.2.9 the mode selection can be |
| 21 | made via commandline option. |
| 22 | |
| 23 | The main mode of the driver is determined at compile time |
| 24 | by preprocessor symbols to be defined/undefined in config.h: |
| 25 | |
| 26 | COMPAT_MODE: when defined, the compat mode specifics are activated |
| 27 | by default. |
| 28 | |
| 29 | Additional modifications can be achieved by the specification |
| 30 | of commandline arguments (most of them have a default setting |
| 31 | entry in config.h as well): |
| 32 | |
| 33 | strict-euids: when active, euid usage is enforced. |
| 34 | compat: when active, the compat mode is used. |
| 35 | |
| 36 | Following is the description of the changes (de) activated by |
| 37 | these defines. A shorthand notation is used: 'compat' means |
| 38 | 'if compat mode is active' and '!compat' means 'if |
| 39 | compat mode is not active', etc. |
| 40 | |
| 41 | |
| 42 | Predefined Preprocessor Symbols |
| 43 | If compat, the symbols COMPAT_FLAG and __COMPAT_MODE__ are |
| 44 | defined for all LPC programs. |
| 45 | If strict-euids, the symbol __STRICT_EUIDS__ is defined |
| 46 | for all LPC programs. |
| 47 | For compatibility reasons, the symbol __EUIDS__ is defined |
| 48 | for all LPC programs all the time. |
| 49 | |
| 50 | |
| 51 | Preloading Of Objects |
| 52 | The driver has the possibility to preload objects before the |
| 53 | game is actually opened to the world. This is done by |
| 54 | calling master->epilog(), which has to return 0 or an array. |
| 55 | If its an array, its elements (as long as they are strings) |
| 56 | are given one by one as argument to master->preload() which |
| 57 | may now preload the objects (or do anything else). |
| 58 | |
| 59 | |
| 60 | Initialisation Of Objects |
| 61 | It is task of the mudlib (through the driver hooks) to call |
| 62 | the initialisation lfuns in newly created objects. The |
| 63 | following table shows the traditional calls: |
| 64 | |
| 65 | mode : init call : reset call |
| 66 | -------------------------------------------- |
| 67 | !compat & !native : create() : reset(1) |
| 68 | !compat & native : create() : reset() |
| 69 | compat & !native : reset(0) : reset(1) |
| 70 | compat & native : reset(0) : reset(1) |
| 71 | |
| 72 | If INITIALIZATION_BY___INIT was defined, the lfun __INIT() |
| 73 | is called first on creation to initialize the objects |
| 74 | variables. |
| 75 | |
| 76 | |
| 77 | Movement Of Objects |
| 78 | The efun move_object() is implemented in the mudlib through |
| 79 | driver hooks and the set_environment() efun. |
| 80 | move_object() itself exists just for convenience and |
| 81 | compatibility. |
| 82 | |
| 83 | In original native mode, move_object() could applied only to |
| 84 | this_object() as the object to move, and it called the lfun |
| 85 | exit() in the old environment if in compat mode. As a side |
| 86 | effect, the lfun exit() may not be target of add_action()s |
| 87 | in compat mode. |
| 88 | |
| 89 | In compat mode, objects may be moved using the transfer() |
| 90 | efun. It does make assumptions about the design of the |
| 91 | mudlib, though, as it calls the lfuns query_weight(), |
| 92 | can_put_and_get(), get(), prevent_insert() and add_weight(). |
| 93 | |
| 94 | |
| 95 | Efuns In General |
| 96 | creator(), transfer() |
| 97 | These exist only in compat mode (creator() is |
| 98 | identical with getuid()). |
| 99 | |
| 100 | object_name(),function_exists() |
| 101 | In !compat mode, the returned filenames start with a |
| 102 | leading '/', in compat mode they don't. |
| 103 | |
| 104 | parse_command() |
| 105 | This command exists in two versions: the old is used with |
| 106 | compat, the new with !compat. However, |
| 107 | SUPPLY_PARSE_COMMAND must be defined in config.h in both |
| 108 | cases (this efun is not very useful at all). |
| 109 | |
| 110 | process_string() |
| 111 | If this_object() doesn't exist, it defaults to this_player() |
| 112 | and receives the backbone uid (returned by master->get_bb_uid()) |
| 113 | as euid. If strict-euids, this uid must not be 0. |
| 114 | |
| 115 | Userids and Effective Userids |
| 116 | This is probably the most important difference between the |
| 117 | modes. |
| 118 | |
| 119 | LPMud always had userids (uids) attributing the objects, |
| 120 | though they were called 'creator names' in compat mode. |
| 121 | Internally, the compat mode uses the 'creator names' as |
| 122 | (e)uid. |
| 123 | |
| 124 | With the introduction of native/plain mode, additionally |
| 125 | 'effective userids' (euids) were introduced to improve |
| 126 | security handling (which was only a partial success). |
| 127 | The hardcoded handling of euids and uids was quite complex |
| 128 | and too mudlib-insensitive, so most of it got moved from the |
| 129 | driver into the mudlib with 3.2.1. |
| 130 | |
| 131 | In strict-euids mode, only objects with a non-zero euid may load |
| 132 | or create new objects. |
| 133 | |
| 134 | --- In Detail --- |
| 135 | |
| 136 | Userids of the Master |
| 137 | The masters (e)uid is determined by a call to |
| 138 | master->get_master_uid(). |
| 139 | In strict-euids mode, the result has to be a string, |
| 140 | otherwise the driver won't start up at all. If the result is |
| 141 | valid it is set as the masters uid and euid. |
| 142 | In !strict-euids mode, the result may be any value: 0 or a |
| 143 | string are treated as the uid to set, a non-zero integer |
| 144 | leads to the use of the uid set in the default 'global' |
| 145 | wizlist entry, and any other value defaults to 0. |
| 146 | The euid is either set to the returned string (if any), |
| 147 | or to 0. |
| 148 | The masters uid is determined only on startup this way, |
| 149 | at runtime the uids of a reloaded master determined as |
| 150 | for every object by a call to the appropriate driver |
| 151 | hooks. |
| 152 | |
| 153 | Userids of New Objects |
| 154 | To determine the (e)uids for a new object (loaded or |
| 155 | inherited, or cloned), the appropriate driver hook is |
| 156 | evaluated (H_LOAD_UIDS, H_CLONE_UIDS) and the result set |
| 157 | as (e)uid. The result may be a single value, in which case the |
| 158 | euid is set to 0, or an array ({ uid, euid }). |
| 159 | In strict-euids mode, both uid and euid must be 0 or a string, |
| 160 | any other value causes the load/clone to fail. |
| 161 | In !strict-euids mode, the uid (however returned) may also be |
| 162 | a non-zero integer to use the uid of the global |
| 163 | wizlist entry as uid. The euid is then |
| 164 | set to either 0 or the second entry of the returned |
| 165 | array if it's a string. |
| 166 | |
| 167 | --- --- |
| 168 | |
| 169 | SEE ALSO |
| 170 | hooks(C), uids(C), move_object(E), initialisation(LPC) |