| 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 |
|
| #33 |
$http_agent |
|
| #34 |
$memo_pad |
|
| #35 |
$waterlogin |
|
| #36 |
$sset_d |
|
| #37 |
$cvs |
|
| #38-#99 |
free objects |
These are objects available for use as master objects. |