This document describes how the world is booted up in 3.0.

Booting the world is the process of starting the Gamedriver and preload all
relevant gamedata, before users are allowed to connect to the game.

Booting in earlier versions of LPmud
====================================

In versions of LPMud earlier than 3.0, booting was done by first starting the
gamedriver and then preload all objects listed in a file: /room/init_file
This file was basically a list of all the castles, one per wizard, in the game.


Booting in version 3.0-
=======================

When the gamedriver is started up, one object is loaded:

	/secure/master.c

When this is done and the create() in it has been called, the gamedriver
checks for special options given with the '-f' flag from commandline when 
the process was started (see /secure/master.c)

When ready, the actual preloading begins. This is done by a call to the
epilog() function in /secure/master.c It returns an array of possible 
filenames to preload. The GD then calls the function preload() in 
/secure/master.c with each of these filenames. 

When the array of filenames to preload is exhausted the gamedriver starts to
allow users to connect to the game.

All connects to the game is handled by a call to the function connect() in
/secure/master.c This function returns the object that should be connected
to the user. This is a special 'login' object that handles the login procedure,
such as name and password queries. It also takes care of new players. When
the 'login' object is done it connects the user to the actual player object.
This can be different from player to player, depending on such things as race,
occupation, guild etc. The player is then moved to a start location.


Preload files returned by epilog()
==================================

/secure/master.c holds a list of all the domains and all the wizards in the
game. This list is consulted by epilog() so that one object for each domain
and one object for each domain-less wizard gets preloaded. The filenames of 
these objects are:

	/d/Domain_name/preload.c
	/d/Wiz/wizard_name/preload.c

There is one important consideration in the scheme of preloading. In 3.0 the
gamedriver keeps track of who is responsible for which objects. This is done
by having a userid and an effective userid connected to each object. An objects
userid is inherited from the effective userid of the object forcing its load.

/secure/master.c sets its effective userid to each domainlord and wizard
before loading each such 'preload' object. This must also be done by the
preload object of a domain if it wants to preload objects made by its
member wizards. This is down by the efun: seteuid(wizard_name) before forcing
a load of that wizards preload object.

This is the only time you need to care about userid's unless you plan to make
wizardtools or make rooms without inheriting /std/room.c









