Object Data Flow

Regular LPC objects are loaded from an LPC source file — these new objects are loaded from a source file, but not an LPC one (and not named whatever.c). This makes the object loading path more complicated, so here’s an attempt to put a few of us on the same page.

This is obviously a first draft, scribbled down quickly so we have something to discuss. Let me hear any thoughts you might have. #### Loading (simple case)

In theory, these objects load just like any other object — call a function in the object and the mudlib will compile it for you. What actually happens is slightly more complex, but it should be totally transparent.

Here’s an example. When someone does a call_other() into a master object and provides a string as the target, DRIVER::call_object() figures out what to do. In the normal case (i.e., loading from an LPC file), here’s what it does:

1. Trim the .c off the end of the string, if present
2. Does an object with that name exist?
   1. If yes, find that object and return it.
   2. If no, continue
3. Attempt to compile the source file
4. Return the resulting error or master object

Now, assume that instead of whatever.c, it finds whatever.xml. We can get into the idea of multiple types, whether they have different suffixes, etc. later; for now just assume everything is a room:

1. Trim the .c off the end of the string, if present
2. Does an object with that name exist?
   1. If yes, find that object and return it.
   2. If no, continue
3. Assemble a string containing the LPC to inherit XML-Room and load whatever.xml
4. Attempt to compile the LPC as if it were /path/to/whatever.c
5. Return the resulting error or master object

The third “simple” case is that both whatever.c and whatever.xml exist; whatever.c takes precidence. If this is a wizard who already had whatever.xml generated by some tool and now wants to just add code to the object, they simply inherit XML-Room as above in whatever.c and override whatever they need to.

Loading (complex case)

I haven’t written this section yet, but it is soon to come. This section will discuss how manyrooms.xml is loaded to become a cluster of related master objects.