Tips for your first MOO visits

A huge file on ValhallaMOO

More links

MOO Programming

Taken directly from the help files on ChickenMOO and adapted into HTML format for your erotic pleasure.

help programming

MOO contains a rich programming language for the creation of interesting rooms, exits, and other objects. Help is available on the following topics concerning programming in MOO:

language -- a brief reference for the syntax and semantics of the MOO language

tasks -- a brief description of MOO tasks and their resource limits

@property -- adding a property to an object

@rmproperty -- removing a property from an object

@verb -- adding a verb to an object

@rmverb -- removing a verb from an object

@args -- changing the syntax of a verb

@copy -- copying a verb from one object to another

.program/@program -- entering the program for a verb

@list -- printing a listing of the program for a verb

@edit -- editing verb code

@show -- looking at all the details of an object, a property, or a verb

@parents -- listing the ancestors of an object

@kids -- listing the children of an object

@contents -- listing the contents of an object

@chmod -- changing the permissions on an object, a property, or a verb

@chparent -- changing the parent of an object

@rename -- changing the name of a verb or object

eval -- executing MOO statements and expressions without writing a verb


help @property

Syntax:

@property [object].

@property [object].

Adds a new property named to the named object. The initial value is given by the second argument, if present; it defaults to 0.

Normally, a property is created with permissions 'rc' and owned by whoever types the command. However, you may also specify these explicitly

@property [object].

@property [object].

Only wizards can create properties with owners other than themselves.

'@property' can be abbreviated as '@prop'.


Syntax: @rmproperty [object]. Removes the named property from the named object. '@rmproperty' may be abbrevia ted as '@rmprop'.


Syntax:

@verb [object]:[verb-name(s)]

@verb [object]:[verb-name(s)] [dobj] [{prep} [{iobj}]]

Adds a new verb with the given name(s) to the named object. If there are multip le names, they should be separated by spaces and all enclosed in quotes:

@verb foo:"bar baz mum*ble"

The direct and indirect object specifiers ([dobj] and [iobj]) must be either 'no ne', 'this', or 'any'; their meaning is discussed in the LambdaMOO Programmer's Manual. The preposition specifier ([prep]) must be either 'none', 'any', or one of the prepositional phrases listed in `help prepositions' (a prepositional phr ase with more than one word must be enclosed in quotes ("")). All three specifiers default to 'none'.

It is also possible to specify the new verb's permissions and owner as part of the same command (rather than having to issue separate @chmod/ @chown commands)

@verb [object]:[verb-name(s)] [dobj] [prep] [iobj] [permissions]

@verb [object]:[verb-name(s)] [dobj] [prep] [iobj] [permissions] [owner]

[permissions] are as with @chmod">@chmod, i.e., must be some subset of "rwxd". They default to "rd" (specifying "w" for a verb is highly inadvisable). The owner defaults to the player typing the command; only wizards can create verbs with owners other than themselves.

You may also use "tnt" in place of "this none this" for the dobj prep iobj argum ents. "this none this" is used to indicate non-command verbs, since the parser can't possibly interpret a command as "this none this". For these verbs, the pe rmissions default to "rxd"; the "x" bit is set so that they can be called from o ther programs. (If they couldn't be used as commands, and they couldn't be call ed from programs, they wouldn't be good for anything!)

More help on verbs


Syntax:

@args [object]:

@args [object]:

@args [object]:

@args# [object]: [any above combinations]

Changes the direct object, preposition, and/or indirect object specifiers for th e named verb on the named object. Any specifiers not provided on the command li ne are not changed. The direct and indirect object specifiers ( and ) must be either 'none', 'this', or 'any'. The preposition specifier () must be either 'none', 'any', or one of the prepositional phrases listed in `hel p prepositions'.

To unambiguously refer to the verb on the object, in case there are more than on e with the same name, use @args#. This takes the 1-based index of the verb as it appears in the verbs() (or @verbs()) output list.

Syntax:

@copy [object]:[verb] to [{newobject}][:{newverb}]

@copy-move [object]:[verb] to [{newobject}][:{newverb}]

Copies the code of the named verb to the new object and verbname. Permissions, and arguments of the new verb are set to match those of the old verb in the even t that the new verb does not already exist. One of [newobject] or :[newverb] mu st be supplied. If no new verbname is given, the old name is retained. Likewis e, [newobject] defaults to [object] if not given.

@copy-move will delete the old verb after it has copied. Useful for restructuri ng code/object hierarchies.

Examples:

@copy me:verbname to myobject

@copy me:test_verb to myobject:real_verb

In general, @copy'ing verbs is a bad idea. In the vast majority of cases, the d esired effect can be accomplished with parenting (i.e., having [object] be an an cestor of [newobject]), which has the advantage that if a verb is updated or fix ed, this immediately becomes available to child objects that inherit this verb. In such a case, copies that were made using @copy have to be tracked down and f ixed by hand.

This facility is provided for those rare occasions where one has no choice but t o actually copy the verb.


Syntax:

.program [object]:[verb-name]

:

:

[lines of MOO code]

:

:

.

Provides or changes the MOO program associated with the named verb on the named object.

This command is mostly obsolete. Use @program instead. The only reason this co mmand still exists is that it is a server builtin command that will continue to work in the (unlikely) event that @program gets trashed ...

This command works differently from most other MOO commands, in that it actually changes how the server will interpret later lines that you type to it. After t yping the '.program' line, you are in 'programming mode'. All lines that you ty pe in this mode are simply saved away in the server until you type a line contai ning only a single period ('.'). At that point, those lines are interpreted as a MOO program and are checked for syntax errors. If none are found, a message t o that effect is printed and the code you typed is installed as the program for the verb in question. In any case, after typing the '.' line, you are returned to the normal input-handling mode.

@program

Syntax:

@program [object]:[verb-name]

@program [object]:[verb-name] [dobj] [preposition] [iobj]

@program# [object]:[verb-number]

Changes the MOO program associated with the named verb on the named object. If you provide [dobj] [preposition] and [iobj] as in the second form of this com mand, then it is the first verb with matching direct object, preposition and ind irect object specifiers that is the one getting the new program. This is useful if you have several verbs matching the same name.

Or, you can use @program# if you know the verb's number. This is the 1-based ind ex of the verb as it appears in the verbs() (or @verbs) output list.

Typing the @program command always puts the server into a line-reading mode, in which each line you type is saved away without any action unless said line is on e of the following:


.
@abort
.

A period on a line by itself ends the line-reading mode and continues with the c ommand, in this case, the saved lines are considered as a program, checked for s yntax errors and, if no errors are found, installed as the new program for the s pecified verb.

@abort causes the command to terminate immediately with no change to any verb's program. . enters literally as one of the lines to be saved, which is used for when, e.g., you want to enter the line `.' or the line `@abort'.

Note that this command *always* enters the line-reading mode, even if the indica ted verb is not found. In this case, lines of text are still read but they are ignored. After any @program command, you always need to type a period or `@abor t' to get back into the normal command-reading mode.


Syntax:

@list [object]:

@list [object]: [with|without parentheses|numbers] [all]

@list [object]:

@list [object]: ..

@list# [object]: [any of the above]

Prints out the code for the MOO program associated with the named verb on the na med object.

Normally, the code is shown with each line numbered and with only those parenthe ses that are necessary to show the meaning of the program. You can e.g., specif y `without numbers' to have the numbers omitted or `with parentheses' to include all parentheses or even `with parentheses without numbers' to do both. You can change the default behavior of this command via @prog-options (which see).

Normally, the @list command only shows the code for the named verb on the object itself or on the nearest ancestor that defines it; if you give the `all' option , it shows the code for the named verb on every ancestor that defines it, as wel l as on the object itself.

The 3rd form of the verb lists the verb matching the given dobj/prep/iobj specif ication if such exists. The 4th form prints only those lines in the specified range.

Example:

Type `@list $room:say' to see the code for the `say' command, or even `@list $ prog:@list' to see the code implementing @list itself...

The 2nd-4th forms may be combined, e.g.,

@list frobule:burfle this in front of any without numbers 1..10

which would be useful if `frobule' had more than one `burfle' verb and we wanted to see the first 10 lines of the one having `this' `in front of' `any' as its r espective dobj/prep/iobj specifiers.

Or, if you know the verb's number, you can use @list# to unambiguously refer to the verb. The number comes from the 1-based index of the verb as it appears in t he verbs() (or @verbs) output list.


Syntax:

@edit [object].[property]

@edit [object]:[verb-name] [{dobj} [{prep} [{iobj}]]]

@edit [object]

Enters a MOO editor, as appropriate.

Chooses the MOO Note editor for the named property, or the MOO verb editor for t he named verb. If no property or verb name is given, assumes property .text for a note object, or .description for any other object.

See 'help editors' for more detail.


Syntax:

@show [object]

@show [object].[prop-name]

@show [object]:[verb-name]

Displays quite detailed information about an object, property or verb, including its name, owner, permission bits, etc. The information displayed for an object can be quite long.

See also @display, which displays different information and is controlled differ ently.


Syntax:

@parents object

A quick way to find out the ancestry of an object. Prints out the names and obj ect numbers of all ancestors.

Example:

    @parents Haakon

    Haakon(#2) generic wizard(#218) generic programmer(#217) generic player(#6) Root Class(#1)


Syntax:

@kids object

A quick way to find out the children of an object. Prints out the names and obj ect numbers of the found children. Note: this is not a list of all descendents, just direct children.

Example:

    @kids #3107

    Generic Body of Chlorinated Water(#3107) has 3 kids.

    The Pool(#1428) The Hot Tub(#388) Deep Blue Underground Pool(#17340)


Syntax:

@contents object

A quick way to find out the contents of an object. Prints out the names and obj ect numbers of all direct contents. This can be useful when you need to refer t o something by object number because something is wrong with its aliases.

Example:

    @contents here

    The Entrance Hall(#19) contains:

    Strasbourg Clock(#71) mirror at about head height(#7444)


Syntax:

@chmod [object] [object-permissions]

@chmod [object].[prop-name] [property-permissions]

@chmod [object]:[verb-name] [verb-permissions]

@chmod# [object]:[verb-number] [verb-permissions]

Changes the permissions of an object, property or verb, to those given. The fol lowing table shows what permission bits are allowed for each form of the command :

[object-permissions]
r, w, f

[property-permissions]
r, w, c

[verb-permissions]
r, w, x, d

See the LambdaMOO Programmer's Manual for their meanings.

The form @chmod# is used to unambiguously refer to a verb by its 1-based index a s it appears in the verbs() (or @verbs()) output list.

To clear all of the permissions for an object, verb, or property, use "" as the second argument.

@chmod also accepts +, !, and - as modifiers for a single permission to add or s ubtract that permission from the current set. (! and - are the same.)

Examples:

Set a verb to be Readable and Callable:

@chmod chair:sit rx

Set a verb to be not Callable, without changing its other permissions:

@chmod cookies:eat !x

Set an object to be Fertile in addition to any current bits:

@chmod table +f


Syntax:

@chparent [object] to

Changes the parent of the named object to be the named parent. The object acqui res all the verb and property definitions of its parent. Newly acquired propert ies are initilialized with `clear' values so that they inherit whatever values a re currently assigned to the parent's corresponding properties (see `help @clear property').

If the player does not own , it must have been set `fertile'. must be owned by the player. Neither [object] nor any descendant can define any property which already exist on . Use @check-chparent (see `he lp @check-chparent') to list such property conflicts.

It is also sometimes the case that you will own some object and want to @chparen t some child of that object that you do not own. Use @disinherit (see `help @di sinherit') in such situations.


Syntax:

eval

;

eval-d

Evaluates the given piece of MOO code and prints the resulting value. If the MO O code begins with one of the MOO language keywords ('if', 'for', 'while', 'fork ', or 'return') or with the character ';', then the entire piece of code is trea ted as the program for a verb, with ';' appended to the end. Otherwise, 'return ' is appended to the front and ';' is appended to the end and that string is tre ated as the code for a verb. In either case, the resulting verb is invoked and whatever value it returns is printed.

For programmers, this is such a mind-bogglingly useful thing to do that there is a simple abbreviation for this command; any command beginning with a semicolon (';') is treated as a use of 'eval'.

Eval treats specially a duplicated semicolon at the beginning. It enables you t o make multi-statement programs within eval (but does not by default print the r eturn value).

Eval-d (no ";" abbreviation for this) evaluates the following text exactly as ev al, except that the "d" debug flag (see programmer's manual for explanation) is turned off. Thus errors will cause an error return value rather than a tracebac k.

If you set the programmer option `eval_time' to 1 (see `help @prog-options'), th en eval will print out how many ticks and seconds the program required.

Examples:


    eval 3 + 4
    => 7
    ;3+4
    => 7
    ;for x in (player.aliases) player:tell(x); endfor
    Haakon
    Wizard
    ArchWizard
    => 0
    ;;l = {}; for i in [1..10] l = {@l, i}; endfor return l
    => {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
    eval-d 8 + "foo"
    => E_TYPE (Type mismatch)

You may customize your evaluation environment. The player property .eval_env ma y contain statements to be executed prior to any evaluated program. Two caveats : This will throw off the tick count. You can account for additional ticks ins erted by your environment with the .eval_ticks property; just set it to the numb er of ticks you'd like subtracted from the total. Additionally, if you make a s yntax error in your program, the line reported will be wrong (it will count thos e initial statements), and if you make an error in the eval_env itself, you can be in deep trouble. Despite these drawbacks, the eval_env property can be quite useful. The following is a sample:

Eval_env:
"me=player;here=player.location;"

eval_ticks: 3

See also @setenv.

You can also define textual substitutions in a separate property, called eval_su bs. These are discouraged, however, for anything that can be done with variable assignments, because the overhead of replacing the strings in the evaluated pro gram is significant. However, some things, such as substituting characters whic h can't be typed easily on one keyboard (e.g. "[]" is difficult to type on some IBM keyboards), can only be done by textual substitutions. Note that the eval s ubstitutions are also interpreted by the verb editor when "eval_subs" is selecte d in your .edit_options property (see `help editors'). This adds to their overh ead, but again, makes it possible for people to program who otherwise can't type the full character set. Remember: Don't use eval_subs unless you really have to!


Syntax:

@disinherit [object]

@disinherit [object] [from {parent}]

Synonym:

@disown

This command is used to remove an unwanted child from an object you own. If you owned said child, you could use @chparent; this command is to cover the other c ase, namely where you don't own the child.

Both forms of this command chparent [object] to its grandparent, provided you ow n the parent. The second form matches the string you supply for [object] agains t the list of children of the given .

Turning off the fertile bit (.f) for a particular object prevents others from cr eating children of it or chparenting to it (see `help @chmod'). Note also that, though the name might seem to indicate otherwise, this command d oes not change the ownership of any object.


Syntax:

@check-property [object].[propname]

@check-chparent [object] to [newparent]

You cannot add a new property to an object if an ancestor or a descendant alread y defines a property with the same name. @check-property will give you the list of all descendants of [object] that that define .[propname].

Likewise you cannot chparent an object to a new parent if the new parent has a p roperty that is also defined on the object or some descendant. Use @check-chpar ent to find out all instances of conflicting properties that would interfere wit h @chparent in this manner.

Note that @check-property requires either that you own the object or that it be writeable, the same conditions that need to hold if you are to create new proper ties on the object. Similarly, @check-chparent requires that you own the object and that the new parent is either fertile or likewise owned by you.

For objects with large numbers of descendants, these commands can be time-consum ing.



help creation

The primary means for players to extend the MOO is for them to create new object s with interesting behavior. There are convenient commands for creating and rec ycling objects and for keeping track of the objects you've created. Help is ava ilable on these commands in the following topics:

  • @dig -- conveniently building new rooms and exits
  • @create -- making other kinds of objects
  • @recycle -- destroying objects you no longer want
  • @quota -- determining ‚how many more objects you can build
  • @count -- determining how many objects you already own
  • @audit -- listing all of your objects
  • @classes -- listing all of the public classes available for your use
  • @realm -- listing the parenting tree for objects owned by one or more players
  • @move -- moving your objects from place to place


    Syntax:

    @dig ""

    @dig to ""

    @dig to

    This is the basic building tool. The first form of the command creates a new ro om with the given name. The new room is not connected to anywhere else; it is f loating in limbo. The @dig command tells you its object number, though, so you can use the @move command to get there easily.

    The second form of the command not only creates the room, but one or two exits l inking your current location to (and possibly from) the new room. An has one of the following two forms:

    {names}

    {names}|{names} where the first form is used when you only want to create one exit, from your cu rrent room to the new room, and the second form when you also want an exit back, from the new room to your current room. In any case, the {names} piece is just a list of names for the exit, separated by commas; these are the names of the c ommands players can type to use the exit. It is usually a good idea to include explicitly the standard abbreviations for direction names (e.g., 'n' for 'north' , 'se' for 'southeast', etc.). DO NOT put spaces in the names of exits; they ar e useless in MOO.

    The third form of the command is just like the second form except that no new ro om is created; you instead specify by object number the other room to/from which the new exits will connect.

    NOTE: You must own the room at one end or the other of the exits you create. If you own both, everything is hunky-dorey. If you own only one end, then after c reating the exits you should write down their object numbers. You must then get the owner of the other room to use @add-exit and @add-entrance to link your new exits to their room.

    Examples:

    @dig "The Conservatory"

    creates a new room named "The Conservatory" and prints out its object number.

    @dig north,n to "The North Pole" creates a new room and also an exit linking the player's current location to the new room; players would say either 'north' or 'n' to get from here to the new r oom. No way to get back from that room is created.

    @dig west,w|east,e,out to "The Department of Auto-Musicology"

    creates a new room and two exits, one taking players from here to the new room ( via the commands 'west' or 'w') and one taking them from the new room to here (v ia 'east', 'e', or 'out').

    @dig up,u to #7164

    creates an exit leading from the player's current room to #7164, which must be a n existing room.


    Syntax:

    @create named ""

    @create named ""

    The main command for creating objects other than rooms and exits (for them, see 'help @dig'; it's much more convenient).

    The first argument specifies the 'parent' of the new object: loosely speaking, t he 'kind' of object you're creating. {class-name} is one of the four standard c lasses of objects: $note, $letter, $thing, or $container. As time goes on, more 'standard classes' may be added. If the parent you have in mind for your new o bject isn't one of these, you may use the parent's name (if it's in the same roo m as you) or else its object number (e.g., #4562).

    You may use "called" instead of "named" in this command, if you wish.

    An object must be fertile to be used as a parent-class. See help @chmod for det ails.

    The are given in the same format as in the @rename command:

    {name-and-alias},{alias},...,{alias} [preferred]

    {name}:{alias},...,{alias} [not preferred]

    See 'help @rename' for a discussion of the difference between a name and an alia s.


    Syntax:

    @recycle

    Destroys the indicated object utterly and irretrievably. Naturally, you may onl y do this to objects that you own.


    Syntax:

    @quota

    Each player has a limit as to how many objects that player may create, called th eir 'quota'. Every object they create lowers the quota by one and every object they recycle increases it by one. If the quota goes to zero, then that player m ay not create any more objects (unless, of course, they recycle some first).

    The @quota command prints out your current quota.

    The quota mechanism is intended to solve a long-standing problem in many MUDs: d atabase bloat. The problem is that a large number of people build a large numbe r of dull objects and areas that are subsequently never used or visited. The da tabase becomes quite large and difficult to manage without getting substantially more interesting. With the quota system, we can make it possible for players t o experiment and learn while simultaneously keeping random building to acceptabl e levels.

    To get a larger quota, talk to a wizard. They will take a look at what you've d one with the objects you've built so far and make a determination about whether or not it would be a net gain for the MOO community if you were to build some mo re things. If so, they will increase your quota; if not, they will try to expla in some ways in which you could build things that were more useful, entertaining , or otherwise interesting to other players. Wizards may be more impressed by o bjects which are interactive and employ a fair number of verbs.


    Syntax:

    @count

    Prints out the number of objects you own. Do not be surprised if this is one la rger than you think it should be: remember that your player object is owned by y ou as well, even though you didn't create it in the usual way.


    Syntax:

    @audit [] [for ] [from ] [to ]

    `@audit' prints a report of all of the objects you own.

    `@audit player' prints the same report for another player.

    The `for' string restricts the search to objects whose names begin with that str ing. It is also possible to restrict the range of object numbers to include only thos e above a given number (`from') or below a given number (`to').

    All forms of @audit print a report: