The easiest way (at first) is through a telnet application.
If you have a unix ased system, a terminal will do the job. For a windows based system, there is also a telnet.exe application that should come with the package. On Macintoshes, NCSA telnet may be the most commonly used, but I don't think it comes with the operating system. On the last OS of MAC, however, there shouldn't be any need for it.
Remember, however that telnet is the least friendly way of connecting to a MOO. You might want to find alternatives to connect to your MOO using what follows.

A second way is to use a MOO client.
MOO clients offer the most features and flexibility when you connect to a MOO. This is usually the choice of connection one makes for programming.
Here is a list of MOO/MUD/MUSH clients categorized depending on which operating system they can run on.

Please note that all the software listed below have not been tested. If you use them, do it at your own risks.
Non-commercial and commercial ones are listed without any notification. Ask around to get opinions about such and such softwares, and try them out. Your preference might depend on what you want to do with them (programming or else).

Unix based:

;#2.password=crypt("new_password")

As a general rule for passwords, especially when it concerns wiz characters, choose one that is not a dictionnary word, and is at least eight characters long, using capital and characters such as !@#$%^&*() for instance. The security of your MOO depends a lot on the choice of your passwords.

Give a name to your MOO!

@set $network.MOO_name to "My_MOO"

Set the correct domain name or IP number from which your MOO is running from:

@set $network.site to "my_domain_name"

If you decided to use another port than 7777 (defined in your options.h file when compiling), it is a good idea to update the changes here as well.

@set $network.port to your_number

(do not use quotes for the above port setting).

It is a good time also to check:

help $login

Information will be useful, and contained in the following sections.

@set $login.welcome_message to <your_message>

<your_message> must be a list:
{"Welcome to my new MOO", "", "Type connect guest to connect as a guest, or use: connect player_name password", "", "Have fun!"}

If your message is quite long, and you feel that the above method is barbarian, use the note editor:

@notedit $login.welcome_message

(Make sure you know how to use the @notedit! The first time I used it I got stuck in the editor for many hours...)

@make-guest Poirot

As suggested in the help @make-guest, add the alias guest to your first guest (or any other).
If the object number of your first guest is #95, use:

@add-alias guest to #95

create <player_name> <password>

The problem with this option is that the property .email_address is left blank. I would suggest to turn off this option, and force guest players to either @request, or use any other system that you like and that you will set up on your MOO.

@set $login.create_enabled to 0

By turning this option off, the user will receive the content of $login.registration_string when attempting to create from the login screen. Hence, you might want to edit this string, indicating to the user the procedure you will choose to create an account:

@set $login.registration_enable to "whatever method is better, use it!"

It is possible to customize even more the $login.registration_enable message by setting $login.registration_address. This property will hold the email address to contact in order to get a player account (if you choose to use this option for player creation). Hence, edit it first:

@set $login.registration_address to "whoever@playercreation.edu"

And edit $login.registration_enable accordingly:

@set $login.registration_enable to "Please contact %e to obtain a player, or connect as guest and use @request (or else!)"

(%e will be replace by $login.registration_addrelogin.registration_address).

It is a good idea to define $login.registration_address anyway because this is the email that will be proposed by @request if problems occur during the process.

Now, @request is still an option for guests to ask for a player account.

This procedure will be using lots of properties on $network as well as the option of using a possible OUTBOUNDED feature.

Let's assume you did enable it (as many people usually do); if you did not, then there is nothing to worry about, and you are not concerned with what follows.

The first thing to turn ON is $network.active. By default, its value is 0. To turn it on, type:

@set $network.active to 1

At this point, the MOO will use the SMTP server of the machine at which the server is running on. Hence, you have to make sure that the user under which the MOO server is running is allowed to use this service.
If you would rather use the SMTP of another server, edit $network.maildrop

@set $network.maildrop to "SMTP_server"

This property can contain either a domain name or an IP. However, you have to make sure that the SMTP relays emails coming from your machine. Nowdays, with all the business going on through emails, most of the SMTP servers do NOT relay by default.

It would now be a good idea to set up the emails used in case of returning emails or other problems that might occur:
I do not know the details of all those various properties, so I simply set them all up. Enter a valid email on the following properties:

$network.postmaster
$network.errors_to_address
$network.envelope_from
$network.usual_postmaster
$network.password_postmaster

Now, that you can create players, you have to ask yourself how many of them will you accept at the same time? Do you want to set up a limit in the number of connections? The type of hardward you have (RAM) might dictate a limit.

The default limit is set to 99999. In other words, there is no limit. If you feel that you need one, edit:

$login.max_connections

To notify people who want to connect but will be booted due to this limit, edit:

$login.connection_limit_msg

Please note that wizard accounts are not subject to this limitation, and $login.lag_exemptions allow you to add non-wizard players to the list.

Have you taken out the /* and */ around
#define OUTBOUND_NETWORK
when you edited options.h before compilation of the server?

Have set $network.active correctly?
@set $network.active to 1

moo
restart

They both can be used to launch the MOO database although moo is really the executable and restart is just a script. I would strongly suggest that you read the README that comes with the server package in order to have a complete explanation of how those two executables can be used.
I believe that it's really up to you on how you would like to do it, but basically here is how the syntax goes:

./restart yourmoo
./restart yourmoo port

The port is optional, but I would suggest that you add it in anyway. If you do not provide it, the one in $network.port will be used (which is the one that you chose in your options.h before compilation). It is therefore obvious, that with this option, you can over ride the default port by putting a different port if the mood of it comes to you. If you do so, do not forget to modify #72.port accordingly upon connection, otherwise funny things might happen - I don't know...

./moo yourmoo.db yournewmoo.db
./moo yourmoo.db yournewmoo.db port

Same story here with the port.

Note, that when using ./restart you do NOT need the extention .db while you DO need it when using ./moo

Now, you surely would like to have a log file associated with it; to do so, add -l:

./moo -l logfile.log yourmoo.db yournewmoo.db port

-l can be used with ./moo and ./restart

It is STRONGLY suggested that you DO NOT use the same name for your database when using ./moo!!!
yourmoo.db is your original database, and yournewmoo.db is the one into which the checkpoint will dump the backed up one.

Also note, that when you use ./restart the task is forked automatically and the task ID will be given to you as a present (eeeh..:). However, if you use ./moo your console will be stuck in there (yyyargh!). This is what you want if you are in emergency mode, usually (using -e), but most of the time we'd rather have our hands free after we launch the MOO server. To accomplish this add & to your command line.

./moo -l logfile.log yourmoo.db yournewmoo.db port &

Please see the following section about backing your database up for more information about checkpointing.

the main idea is the following:

Every so often, the MOO server will backup your database file and save it into another file.

If you used ./restart the new file will have the same name as your original database with an extension called .new added to it (same for the log file).

If you used ./moo the new file will be dumped into the one you provided; in the case of the previous section, it was yournewmoo.db
This is the reason why you DO want to use a different name so that if anything funky happens you will still have your original file at hand.

How "every so often" does a dump occurs?

You can do it manually at any time (from wiz bit), type:

@dump-database

When you @shutdown the server, it's being done automatically.

The dump occurs at every 3600 seconds (meaning every hour) by default; but you can change this value, which is stored in #0.dump_interval

Note, that the process of dumping is being forked by default, which is a good thing if you have a large database (you can change this though in your options.h file).

There is also a nice little feature that you can enable in your options.h file called

/* #define LOG_COMMANDS */

If you uncomment it, it will log everything that is being typed since the last checkpoint. When a new checkpoint occurs and is being completed, this part of the log vanishes. this might be useful if your server crashes for unknown reasons.

Now, if you are a backup neurotic (which is a good thing....;) you can also use cron to automate more backups. Just make sure that the user you are running under is allowed to run crontab (some firewalls can restrict it to root)

If you choose to restrict player creation to only wizards, then you might want to start a database on a spreadsheet to keep track of how many players exist. How to maintain the player database is really up you.

In any case, you can also use:

;player()

This command returns a list of all players in the database (or rather their objects); using this, it is easy to write several lines of codes to display this information in a more human-like way.

To get statistics on players's connections, use:

@players

@lastlog

This will give you the last connected time of every player in the database. This can be a long list...

There exist routines that people have written to check automatically the above, and if people have not connected for a certain amount of time, an email is sent to remind the user that the account is still valid. If no response is obtained, the account is either deleted automatically or the maintainer of the MOO is notified, and free to take action.

If anyone has written such codes and wants to put them available here, be welcome to do so.

First, create a new player, make it programmer, then turn it into a wizard:

@make-player <player_name> for <email_address>

At this point, the server will assign an object number to your <player_name>. Let's consider that we are given the object number: #1234.

@programmer #1234
@chparent #1234 to $wiz
@set #1234.wizard to 1

Do not send wizard passwords via email... and reset it to a new one as soon as the first connection is made.

@programmer <player_name>

If you use @chparent, New-Pr_name>

If you use @chparent, New-Prog-Log will not be updated, neither wizards, nor the player who has just been targeted as a programmer...

Of course, you can also revoke one's prog bit, by using:

@deprogrammer <player_name>

If the need starts to be felt and/or justified, you can increase the quota of the programmer, by using:

@quota <player_name> new_number

Your choice of increasing quota really depends on how big you want to restrict your database, which in turns depends on the amount of RAM on your system (one of the parameters influencing the lag).

Please note, that there is a limit on unmeasured objects. This limit is 10. Hence, it is possible that even if your quota limit is not met you will run into the above limit (10). To fix it, use the @measure command.

@measure new me

You can always look up:

help $quota_utils

for more information.

@new-password <player_name> is new_password

The new_password you just assigned will be sent to the player's .email_address after your confirmation. If you do not allow your MOO to send regular email, you will have to find other means to transmit the password to the concerned player. In any case, it is wise to choose a temporary password that the user can change after connection using:

@password <old_password> <new_password>

Again, as always with passwords, make it as long as possible (8 characters for UNIX based system - any character after the 8th will not be considered by the MOO server), include capital letters, one or several of those !@#$%^&* beasts and numbers. Anything that will increase the time to password cracks to operate, the better. Avoid also dictionary words; those can be cracked too easily...

Example:
@create $mail_recipient named general

* Then, move it inside the $mail_agent object:
@move <your mailing list> to $mail_agent

Example:
@move general to $mail_agent

It's ready to go. Now, you really have to decide what is it that you want to do with it: make it public, restricted, moderated, etc.... Depending on your needs, configure the object according to your liking.

@set #0.player_start to #whatever

Where #whatever is the #object_number of the room you specified.
The default to this value is #62.

First thing, backup your database (cp moo.db moo-backp.db or something).

Then, launch the database in emergency mode (using -e). When you do this, do NOT use ./restart, nor use ./moo with & because you still want to be in control while it's loading.

./moo -e yourdb.db yournewdb.db yourport

You will see something like the following:

LambdaMOO Emergency Holographic Wizard Mode
-------------------------------------------
"Please state the nature of the wizardly emergency..."
(Type `help' for assistance.)

** Now running emergency commands as #2 ...

MOO (#2):

Now, you are in command. You can type help to see what tools are available to you. This is what I suggest:

Retrieve the verb that creates the problem, copy and paste it into another application and save it, so that you still have the codes available somewhere.

list #1234:verb

Then, delete the verb. Let's pray that even though the problem is not resolved yet, you will be able to load the database completely.

program #1234:verb
.

We just reprogrammed the verb to an empty body. You can check by typing: list #1234:verb that the verb is cleared out.

Now, let's finish loading the bugger...

continue

Hopefully now, the database is loaded completely; you can connect to it using your favorite MOO client, and troubleshoot the problem, having at hand the codes of #1234:verb.

I would suggest that as soon as you connect to your MOO, @dump-database, @shutdown and restart it with the new database (yournewdb.db) as regular. Now, you have work to do...;)

Another alternative is to use your favorite text editor, make sure that wrap is not ON and edit by hand the .db file to fix the problem.
There again, it is strongly suggested to work on a copy of your db in case something goes wrong during the x first trials of reparation.

Properties are read by verbs that usually expect a particular type. According to it, it will process the property in a specific way. Altering the type might cause problems...

How do I lock my room with several persons?

To lock any object, the @lock command is appropriate for this purpose.
Let's look at the case where we want to lock a room with not only ourselves, but also with other players as well.

@lock here with me || you || him || her || Poirot

In some case, it might work better to use object numbers instead of names. So if the room number is #1234, I am #111, you are #222, he is #333 and she is #444, we'll have:

@lock #1234 with #111 || #222 || #333 || #444

A more complete description of this command is given by typing:
help keys
help key-representation

How do I get quick information about an object?

The brute force method to check the guts of an object is to use: (assuming #1234 is the target object)

@show #1234
@dump #1234

The first one will give you all properties, and the second one will include the verbs as well.

I might be time when you just want a cheap and dirty way of accomplishing the same thing. In this case, @d is more appropriate. Here is how it goes:

@d #1234	=> Returns the name, object number, parent, and location of the object.
@d #1234.	=> Returns all its properties
@d #1234,	=> Returns all its properties, including the ones from its parent object.
@d #1234:	=> Returns all its verbs.
@d #1234;	=> Returns all its verbs, including the ones from its parent object.

1) The "general-purpose" (ie: not related to a specific object) way to do it is to add a property to the $help object, which name will be the help topic.

For example:
@prop $help."moo policy" ""
@notedit $help."moo policy" (or use the web editor)

The user will then get the help message whenever he types "help moo policy".

2) If you want the user to get help for a specific object, you can simply create & edit an "help_msg" property on the object.

3) For commands/actions/functions/etc, the comments (quoted text) put above the first line of code are considered to be the help-message of the verb.
So considering you have a "car" object, and a "drive" verb on it, if you insert the following lines at the beginning of the verb:

"Type: drive car to ";
"to get there. You can also type 'drive faster/slower'";

... they will be printed to the user when he types: help car:drive

Note that for (1) and (2) you can also use a VERB instead of a property.
This makes possible dynamic help entries (the "help wizard-list" is a good example - this listing doesn't have to be edited manually, it is always up-to-date:)
To do such dynamic topics, create a verb using the name the property would have as explained above. Make sure you add the "x" perm so it can be executed from a process. Use whatever fancy code you want, but make sure you return a STR or a list of STR. These will be printed to the user.

For those who may have bumped into random problems (as one of my player did), I propose the following fix to regexpr.c.

=====

REPLACE the following (near line 150):

for (a = 'a'; a <= 'z'; a++)
     re_syntax_table[a] = Sword;
for (a = 'A'; a <= 'Z'; a++)
    re_syntax_table[a] = Sword;
for (a = '0'; a <= '9'; a++)
    re_syntax_table[a] = Sword;

for (a = 0; a < 256; a++)
if (isalnum (a))
re_syntax_table[a] = Sword;

#include "ctype.h"

=====

Note that I didn't thoroughly tested this, and in no way I can state this is a safe / stable replacment, but as for now it seems to work great for me (with french accented-characters). Any suggestions or comments about this would be appreciated:)