blob: 13cf0081b24cfc35963cf8dece5bbfa88a6fcdb5 [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001CONCEPT
2 driver modes / native driver mode
3
4DESCRIPTION
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
169SEE ALSO
170 hooks(C), uids(C), move_object(E), initialisation(LPC)