<h3>Chapter 2 - Driver/Mudlib Interaction</h3> <hr size="1"> <a name="2.1"><p><strong>2.1 Driver Review</strong></p></a> <p> In <i>LPC Basics</i>, you learned about the functions create(), reset(), and init(). Of course, today the actual names of these functions may vary from driver to driver (LPMud 3.2.1 and DGD have no preset name for any of these, and the Nightmare Object Library sets reset times to a huge time such that the driver never calls it), but you still have the concept of a constructor function, a periodic resetting function, and an an inital contact function. Traditionally these functions were handled as driver applies. </p> <p> <i>Intermediate LPC</i> introduced the main driver loop. This driver loop basically looks for new connections passing them to the login object, sends outgoing messages to connected users with messages waiting, processes commands for connected users with commands pending, calling heart beats, then pending call outs. DGD has no heart beats, and thus skips the heart beat section. </p> <p> The trend these days is to move away from the init()/add_action() paradigm and do command handling almost entirely at the mudlib level. In Chapter 5, I discuss advanced command processing. No matter how you do it, however, you cannot escape the fact that the driver determines when a command is available and calls some mudlib level function to process that command. </p> <p> In this chapter, you should get a full understanding of how drivers work with mudlibs in general. Naturally, each driver has its own peculiarities. In the last year, the exact manner in which the driver interacts with the mudlib has started to become the greatest point of divergence of the LPMud drivers. To come to a full understanding of how your driver works, you should of course read every bit of documentation for your driver. And perhaps even read the source code. </p> <hr size="1"> <a name="2.2"><p><strong>2.2 Basic Objects</strong></p></a> <p> Each driver requires at least one special interface object, and most require a second object for defining special functions. With DGD, the primary interface between the driver and mudlib is the driver object. Other drivers use an object called the master object. In spite of the name difference, both objects have the same basic purpose, to allow the driver interact in a few selective cases where it needs to with the mudlib. </p> <p> The difference between DGD and the other drivers becomes more pronounced with the other basic mudlib object, the auto object for DGD and the simul efun object for others. To the end area builder, an auto object acts just like a simul efun object does, with some minor exceptions. Namely, both objects are used to define special functions considered local to all objects as well as override efuns/kfuns. </p> <p> The differences are certainly much more in depth than I noted above. Most of the differences, however, are only truly of interest to people dealing with the internals of driver design. Those differences which are relevant to mudlib design will be discussed in the section on each pair of objects below. </p> <hr size="1"> <a name="2.3"><p><strong>2.3 The master and driver objects</strong></p></a> <p> The primary interface between the driver and the mudlib is the master object, or the driver object on DGD muds. Though certainly not identical, they serve the same purpose for the drivers in which they are used, namely to server as the focus for encapsulating queries the driver makes of the mudlib. DGD attempts to limit this severely, and thus the actual make up of the DGD driver object is quite different from that of the master object for other drivers. </p> <p> The primary task common to both the master object and driver object is to identify to which object an incominng connection should be attached. </p>