Man object creation

From LSWiki

Files

/obj/master/kernel.c

Description

The current Ain Soph calls a sequence of several functions in every object when it is created, as defined by the driver hook settings for H_CREATE_OB and H_CREATE_CLONE that kernel.c sets up. This document is to describe these functions, their purpose, the way they are intended to work together, and the circumstances under which you might want to use each.

At this writing, these functions, other than create(), have only just been defined, and it remains a matter of some work to fully implement the manner in which they are meant to operate. This document, therefore, presently also serves as a guide for those who may wish to work on the lib to more fully support these concepts. Hopefully in the future, we may remove this paragraph.

The first function called is preinit(). This function is not intended for use by content developers; its purpose is to initialize data structures and so on. This function is useful for setting up mappings and arrays that need to be initialized, for example. It is particularly important to call

preinit() when you overload it, though it's always best practice to call

parent functions in the other create-time functions as well.

The second function called is configure(). Ideally, almost all of the code which has previously occured in the create() functions of characters, armour, weapons, and so on should wind up moving to this function. After configure() is called, the object should have defined all of the values necessary to define what it is, but should not have "done" anything; i.e., we should be able to set up a character's configuration in this function but not set up their limbs and so forth until create(). Among other things, this should reduce (though probably not eliminate) the need for certain configuration functions to be called in a particular order.

The third function called is create(), which we should all be familiar with. The concept here is, at this stage we should begin implementing the configuration which was done in configure(). As an entirely new opportunity, we can also now *validate* that configuration -- complain that critical values were not set, or the like. In create() we might set up elements of a character's state that are implied but not specified by the values from configure(), begin cloning and moving objects, set up call outs, and so on.

The fourth function, only called in the case of cloned objects, is clone(). This can conveniently be used to take actions that should only be done for cloned instances of a base class, such as maintenance call outs. It is not recommended that extensive configuration be done here; doing full configuration in the base class allows outside code to predict the likely characteristics of clones by examining the base class.