Newbie Wizards FAQ


<< Back to Top

This FAQ list is designed to help new MOO arch-wizards (MOO owners) get answers to their questions. Entries come from items on the moo-cows mail list, personal questions from experience on our MOO, and from your contributions. The questions on this list most directly pertain to the core database, LambdaCore; to the extent that the core db you start with differs from LambdaCore, answers to these questions may vary from what is presented here.

<< Back to Top

So, how much do I have to know about MOO programming to run my own MOO?

Some people might answer this way: If you're not a programmer with plenty of experience on MOO, creating your own objects and helping others fix theirs, you really should hire, bribe, or marry such a person before you throw up a MOO. You'll need this person as an ongoing partner. Many things just don't have any documentation beyond their MOO code. There isn't much chance of getting all the help you need from any mailing list.

<< Back to Top

I just got my MOO server going, now what?

Telnet to the server on the port you started it on (You did read the included documentation on starting the server, yes? You did use the included restart script, yes?).

Now you should see:

So you'll type "connect wizard" and you'll see:

At this point you can do almost anything. You'll first want to set the wizard's password (help @password). Then you can type

to see other properties that you might want to set immediately.

<< Back to Top

How do I ... ?

Wait! Did you 'read the manual'? The following are very useful:

<< Back to Top

How do I restrict creation of new characters to the @make-player command (ie. prevent create <playername> <password> from the login screen?).

This stops people from creating their own characters at the welcome message. If you have a network active, the default seems to be that people can still login as guest and create their own character with @request. We hacked the @request verb to change this, but that may not be the easiest of best solution.

<< Back to Top

How do I edit my welcome screen?

You can set the welcome message with something like:


<< Back to Top

How do I edit the default `help' message?

<< Back to Top

How do I write new help?

Add a new property to a help database (such as $help). For example, if you want to add a new help topic called `fnords', you'd do:

Then type the help text you want for that topic into the note editor, and save it.

You may prefer to create a new help database just for your database's help topics. If so, you should first create a new child of the Generic Help Database ($generic_help), then add properties to that. You also need to add your new help database's object number to the .help list on the generic player.

<< Back to Top

Why does mail to the internet fail when I create a character?

Make sure you compiled the MOO server with "outgoing network connections" enabled (in the options.h file); you may also have to:

The network is necessary so the server can automatically e-mail the new user with their character name and password. You should also set the properties on $network correctly for your MOO.

<< Back to Top

What's the deal with @make-player? If you try to add alias arguments, they just concatenate into a long player name with no aliases.

*The aliases argument seems to be broken in the 1-Oct-94 core. Add aliases later. Aliases work with this command in the previous version.

<< Back to Top

What's the deal with @make-player? There's no help.

[The following help is from the help database on LambdaMOO, and is out in the current core, but you don't have that or you wouldn't ask, eh? ]


If the email address is already in use, prompts for confirmation. (Say no, this is a bug: it will break if you say yes.) If you say no at one of the confirming prompts, character is not made.

If network is enabled (via $ then asks if you want to mail the password to the user after character is made.

[From Judy Anderson, who wrote the help for this on Lambda]

<< Back to Top

OK, I need some help here. How do I make a trusted player into a wizard?

Don't. Instead, create a fresh player #p and do

and then tell your helper the password to the new player. Alex Stewart notes that adding the @programmer call avoids certain sticky situations that might be encountered by non-programmer wizards.

The reason you really only want to do this with a freshly created player is that every verb owned by the player will suddenly acquire wizard permissions. For an existing player, you'd need to go through and make sure that player in question owns no verbs that will do any damage if given wizard permissions (remember, anyone may call any verb...). [from Roger Crew]

<< Back to Top

How come no one can connect as guest?


then edit the description. Only ONE of the guest characters must be named or aliased as 'guest' for guest connections to work. Try this:

Repeat @make-guest <guestname>, adding descriptions as you go, until you have a number of guests equal to your desired maximum number of guest connections.

<< Back to Top

What should the new ArchWiz understand about permissions/security?

A lot. Here's some code you could put into a verb to help you find writeable verbs that act with wizards authority (i.e. a verb anyone could modify, that has the power of a wizard):

[contributed by [email protected], and modified by Scott Lynch]

Until you really grok permissions, it may be best to do all your programming as a programmer character.

<< Back to Top

No player's disconnect date is getting modified, what's up?
No one is getting mail notification, what's wrong?

There seems to be a problem with the verb disfunc and confunc verbs on #6, generic player on the distribution of LambdaCore-21Oct93.db. To fix it, @edit #6:disfunc and also #6.confunc, and change each line 1 to this:

Of course, this only works for sure if you're using the above db version, and haven't touched your disfunc and confunc verbs on this object. Be careful.

<< Back to Top

LambdaCore is awfully bare. How can I get some other objects and system features into my MOO without recoding them from scratch?

[Hmm. Well in the sense that you don't get some system features (weather, rpg system, diurnal environment, etc.) or objects (talking robots, morphing player class, etc.) that you've seen on established MOOs I guess LambdaCore could be called bare. LambdaCore is really a pretty complete base for coding a MOO, with LOTS of underlying necessities that some would be bored and frustrated to tears to have to code themselves. As more daughters of the LambdaCore appear I'll list them here. OK, enough editorial on with the question. ed.]

The recommended procedure for porting objects presently has two components: social and technical.

  1. On the MOO you're porting the object to, @create using the apropriate parent, and note down the new object number (#xxxx).
  2. Turn on recording and turn off autowrap on your client; you do this to record dump your about to do on the source moo.
  3. On the MOO you're porting object #nnnn from:
    1. @wrap off
    2. @dump #nnnn with create id=#xxxx
  4. Edit the dump you recorded.
    1. Remove the @create from the first line from the first line of the dump, since you've already created the object.
    2. Scan for hard-coded object numbers other than the one that is the object you created. Fix those, pointing them to the correct object on your MOO, or recoding so they're not needed.
    3. Scan for things that might have inadvertently been captured along with the dump, e.g.:
        You sense that Nern is looking for you in the Living Room: Nern pages, "Come out and help me torture some guests."
  5. Upload the dump to your MOO with your client; this dump script will put the properties and verbs on the object.
  6. Now, test and/or debug the object.

[Thanks to Judy Anderson, for some of the nitty gritty details above; if something is in error, it is one of my ad-libs, -ed.].

<< Back to Top

I dumped this object, but it has a few hundred properties containing object numbers from objects and players on the source MOO. How can I get rid of these?

One obvious way is to edit them out of the dump with a text editor before uploading. This could cause errors and may be tedious. It might be better to redump the object, adding noprops to your @dump command. Then scan the verb code for what properties need to be on the object; add them back with @prop.

<< Back to Top

My client totally hashes my @dump script when I upload it, putting in linebreaks where it shouldn't. What do I do?

Check the @dump script file to make sure it doesn't have line breaks where it shouldn't. If it does, the problem is not with your upload but with your procedure for @dump (you did @wrap off, no?), with your client recording, or with the editor you used to scan the script; one of those or something else is breaking the lines.

If your file is OK the problem really is with the upload:

<< Back to Top

How can I make all new players children of a specific player class?

Set $player_class equal to that class. For example, to make every new player a builder class, you'd want:

<< Back to Top

Why do I get a range error on line 3 of #15:length_date_gt, which is used by commands such as @subscribe?

You encounter this when there are no messages in #18, the Player-Creation Log. This is typical when a LambdaCore-based MOO is brand new. Change the verb to this:

[Courtesy Fran Litterio via post from Pavel Curtis]

<< Back to Top

I've been trying to get @mail-options +netmail to work on my moo and I always get this: Mail sending failed: 503 Need MAIL before RCPT. I then get both an emailed and @mail copy of the msg. What's up?

This appears to be a bug in the Solaris (SunOS 5.x) sendmail daemon). Everyone may want to make the following change anyway, as it makes the MOO's sendmail routines more technically compliant with the SMTP spec.

Edit $network:raw_sendmail and change the following (line 48):


[Courtesy of Alex Stewart]

<< Back to Top

Whats up with this my_huh: security hole?:

A security hole in the :my_huh process (the part of :huh parsing which handles feature objects, in LambdaCore) has been discovered, which permits player class owners to run feature commands with their children's permissions. This is an undertandably bad hole, especially if your MOO moves functions from player classes and moves them onto features, and uses caller_perms() to check permissions.

The permissions checks on $player:my_huh reads:

It is recommended to either change that if statement to remove the (caller!=this) check, or leave it in and changing the set_task_perms() to a set_task_perms(caller_perms()). How your MOO uses :my_huh would be the best way to tell which is the better change.

[Courtesy Seth Rich]

<< Back to Top

Hey! There is always new news. What's going on?

Never mind. Do this as the wizard on your 1-Oct-94 core:

<< Back to Top

Hey! Where's the help on $news? I've @examined it, but nothing works.

Here is how to do it with your 1-Oct-94 core:

First, find the object number for $news:

To add new news:

Once you are finished composing and sending your message to *news, do:

To add that message, do:

If a message is old and you want it removed, do:

[From posts to Moo-Cows by Seth I. Rich and Colin Moock]

<< Back to Top

To contribute to or comment on this FAQ, send email to [email protected]; corrections, additions, attributions gratefully received.

To ask a question about MOO programming, subscribe to moo-cows (to [un]subscribe to the moo-cows mail list send email to new address here soon with your nice polite request in plain english). The URL to obtain this list is: