Object Hierarchy

Number	Handle	Description
#0	$system_object	The root object in MOO. It holds onto the system functions like #0:do_login_command and #0:server_started. Properties on #0 can be accessed via $property, rather than the more common $0.property.
#1	none	This is root class from which all base objects in MOO are descended. Otherwise, it does nothing. Even #0, the root object is descended from #1. #1, like God, is descended from #-1, which is called $nothing in MOO.
#2	$command_mode	This object manages the command line interface for lilyCore. The user, admin, and sendlist processing verbs are all here; no valuable properties are located here.
#3	$admin	This object is the owner of virtually all the original lily verbs. This prevents the normal MOO security systems from working, and requires a lot of attention from the developers to maintain a secure shield around MOO. This is a bad idea, but it is a LOT faster than the normal style MOO suggestions. The interactive programmer and wizard commands are located here.
#4	$string_utils	This object was in the tiny Core Maker gave me originally. It handles almost all of our string processing needs, not handled by MOO itself. There are more verbs on this object which are not used in lilyCore, than are used. $string_utils:print() is the most commonly used verb, but largely for debugging purposes.
#5	$code_utils	All the verb managment and programmer utility functions are here. Once you start messing around with this code, you don't need my help.
#6	$player	At the very center of lilyCore's design is the player object. It contains all of the properties and verbs necessary for most player-player, player-disc, and player-game interaction. The player object even parses its own commands. Every user account is direct descended from $player.
#7	$event_mgr	The event manager keeps track of a player's event preferences, as set by /notify, /signal, and /timestamp. It also provides methods for processing these preferences. Each user account has it's own instance of $event_mgr.
#8	$sset	This object implements a fast-string matching algorithm that Maker could well have invented. It works by breaking the string into two character substrings and using those to reference a hash bucket. The search space is cut down quickly and easily.
#9	$sset_p	The child of $sset that manages the user namespace.
#10	$disc	The discussion object manages the state and permissions for discussions. All existing discussions are children of this object. Rather than create and destroy discussions often, a cache of all the recently destroyed discussion objects is maintained. The /create command uses this list if possible before creating a new object. A system of recording objects which hold reference handles to existing objectsis required so when an objet is recycled old permissions are not retained.
#11	$lily_utils	This object holds the utility functions for lily, so the player object is not overloaded, many of the functions here were once stupidly added to the $code_utils object. It also acts as a catchall for properties which are needed to speed up lily commands, remember that making little lists often is much more expensive than keeping them around in properties.
#12	$list_utils	This object holds list management utilities like match, sort, merge, and scalarSort.
#13	$sset_c	The child of $sset that manages the user and administrator command namespace. Helper and programmer commands are handled using builting MOO techniques.
#14	$help_mgr	The help subsystem. It manages the help command set, help indexes, and a database of help text. The help is stored as a list of help words then at the same offset in the database is the text for that help. Help for modules is not stored here, and is integrated using the actual /help command.
#15	$disc_review_mgr	A child of $review_mgr, this object provides storage space and methods for maintaining a review buffer of notifications and messages sent to a discussion. Each discussion has it's own instance of $disc_review_manager.
#16	$scheduler	New in 2.0 is an object dedicated to scheduling events. This is what is used to add date stamps to the review buffers. In the future a user interface for regular schmoes will be added to allow CONNECT-style signal.
#17	$sset_t was $client	Much as users have their own player object, clients from online consulting have their own object. This object holds state for the client and does command interpretation. In this way we avoid needing to protect the system from clients, rather we protect the clients from the system.
#18	$helper	This object is the hack done for Prisoner's WWW hyper-text help page. It allows the login process to be avoided entirely, and help text to be fetched for display on a Web page.
#19	$review_mgr	This object provides storage space and methods for maintaining a review buffer of notifications and messages sent to a user. Each user has it's own instance of $review_mgr.
#20	$server_options	This object is new for MOO-1.8.x and is the source of configuration values for the MOO server. Two examples are fg_ticks and bg_ticks.
#21	$set_utils
#22	free object	This is an object available for use as master object.
#23	$game	The parent object for all games. It implements a suggested set of game verbs and holds the default game properties, but it isn't clear it is valuable.
#24	$magic8ball	A sample discussion watching game. Funny for a few minutes.
#25	$uno	An attempt at writing an Uno game. It revealed how little I know about Uno. Anyone who wants to write an Uno game is a friend for life. :)
#26	$transfer	This is the experimental user and discusion transfer tool. Upgrading between Core releases is a PAIN IN THE KEASTER! This utility is going to make it a ton easier, we hope.
#27	$text_agent	This is the delivery agent for sending traditional, text only, events to telnet based lily clients.
#28	$slcp_agent	This is the delivery agent for sending events using the SLCP client-server protocol.
#29	$jabber_agent
#30	$reaper	This object cleans sections of the database at various intervals. It moves idle users from 'here' to 'away', it idles users to death when they have been detached for too long, it validates the cached $here, $away, and $detach counters, and it reaps discussions according to a complex and very customized set of rules. To configure this object type '$configure reaper'.
#31	$slcp_utils
#32	$drink	A 'game object' which can be used to track consumption of beverages -- and for programmers that usually means caffeinated beverages! This implements the /drink and $drink commands (which are always available to all users), and also allows one to attach the 'drink game' to a discussion, so you can see what other people are drinking when they /drink it.
#33	$http_agent
#34	$memo_pad
#35	$waterlogin
#36	$sset_d
#37	$cvs
#38	$hearts	Card Game. Just reserving the object number. This is partially written, but not quite ready yet to install as part of the official lilycoreDB.
#39	Version Control	Potential version control built in to the lily server. Just reserving the object #.
#40	Irc Bridge	game for tying mirroring a discussion to an IRC server.. <Just reserved. not written yet> See IrcBridge
#41-#99	free objects	These are objects available for use as master objects.

Aside: Note that "reserved" objects are just a notice of work being done. Such work shouldn't actually rely on that specific number being used for the new feature. All references to objects added by these WIP's should be based on some $-variable.

(I suspect several entries in this page are out-of-date, to the point of being completely wrong. I'm not going to check them over right now though. -- gad/Dec 19/2005)
to top