This is a listing of the contents of the major LambdaMOO `help' databases as of Tuesday, June 2, 1993. If you're seeing this for the first time, you may want to skip down to `help summary' There are actually several distinct help `databases' that comprise the LambdaCore/LambdaMOO help system. Typing `help index' gives a list of all of the ones that are currently searched when you ask for help on a given topic; the actual list is dependent your current player class, (occasionally) on what room you are in, and on the value of your .help property (see `help $help' for details). LambdaCore provides the following help databases General Help Topics ($help) help with commands for ordinary players and builders. `help gen-index' gives a list of topics. [GENERAL] Editor Help Topics ($editor_help) Information about the editing commands available in the MOO editors (@edit, @notedit, the mail editor). `help edit-index' gives a list of topics. [EDITOR] Programmer Help Topics ($prog_help) help topics for programmers. This includes general programming topics and information about commands available to programmers. `help prog-index' gives a list of topics. [PROGRAMMER] Core Utility Help Topics ($core_help) This describes various objects and utilities available in LambdaCore, often in gory detail. First-time readers can probably skip this. `help core-index' gives a list of topics. [CORE] Wizard Help Topics ($wiz_help) help topics for wizards (system administrators). These will most likely only be of interest to those planning to run a LambdaCore-based MOO. `help wiz-index' gives a list of topics. [WIZARD] Builtin Function Help ($builtin_function_help) descriptions of server builtin functions. These are lifted straight from the LambdaMOO Programmers' Manual and thus are not repeated below. `help builtin-index' gives a list of topics. Verb Help ($verb_help) This help_db extracts documentation strings directly from verbs in response to requests like `help object:verbname'. There is no corresponding index. In addition, for players on LambdaMOO itself, we also have LambdaMOO-Specific Help Topics (#3223 on LambdaMOO) help topics for ordinary players on LambdaMOO. This includes descriptions commands that are not in the LambdaCore $player class and policies that are peculiar to LambdaMOO itself. `help lmoo-index' gives a list of topics. [LAMBDA] LambdaMOO-Specific Programmer Help Topics (#56204 on LambdaMOO) help topics for programmers players on LambdaMOO. For now, this just shadows certain topics in Builtin Function Help. [LAMBDA-PROG] What follows is a combined listing of seven of the above help databases, Except for the initial summary, the texts are listed in alphabetical order by name (ignoring leading @ or $ signs); this should make it easy to find any particular text. For each text, we indicate with [GENERAL], [EDITOR], [PROGRAMMER], [CORE], [WIZARD], [LAMBDA], or [LAMBDA-PROG] which of the above databases it came from. "*subst*" on any given topic indicates that the help text contains parameters that depend on the current state of the MOO (e.g., `help registration' depending on what $login:registration_string() returns). See `help $generic_help' if you really want to know what all of the %-clauses do in such help-texts. There is a full list of all topics at the very end. ===== help summary ======[LAMBDA]============================================= Help is available on the following general topics: introduction -- what's going on here and some basic commands index -- index into the help system players -- setting characteristics of yourself movement -- moving yourself between rooms communication -- communicating with other players manipulation -- moving or using other objects miscellaneous -- commands that don't fit anywhere else building -- extending the MOO programming -- writing code in the MOO programming language editors -- editing text and code in the MOO @pagelength -- what to do if lines scroll off your screen too fast @linelength -- what to do if lines are truncated tinymud -- a list of equivalences between MOO and TinyMUD concepts/commands ===== help " ======[GENERAL]============================================== SEE say ===== help # ======[PROGRAMMER]=========================================== #[.|.parent] [exit|player|inventory] [for ] returns information about the object (we'll call it ) named by string. String is matched in the current room unless one of exit|player|inventory is given. If neither .|.parent nor is specified, just return . If . is named, return .. .parent returns parent(). If is given, it is evaluated, with the value returned by the first part being substituted for %# in . For example, the command #JoeFeedback.parent player for tonum(%#) will return 26026 (unless Joe has chparented since writing this). ===== help : ======[GENERAL]============================================== SEE emote ===== help :: ======[GENERAL]============================================== SEE emote ===== help ; ======[PROGRAMMER]=========================================== SEE eval ===== help ? ======[GENERAL]============================================== SEE help ===== help abort ======[EDITOR]=============================================== Syntax: abort Abandons this editing session and any changes. ===== help @abort-shutdown ======[WIZARD]=============================================== Syntax: @abort-sh*utdown [] This aborts any shutdown currently in progress (i.e., set in motion by @shutdown). All players are notified that no shutdown will actually occur; , if given will be included in this notification. ===== help @add-entrance ======[GENERAL]============================================== Syntax: @add-entrance Add the exit with the given object number as a recognized entrance to the current room (that is, one whose use is not considered teleportation). Usually, @dig does this for you, but it doesn't if you don't own the room in question. Instead, it tells you the object number of the new exit and you have to find the owner of the room and get them to use the @add-entrance command to link it up. ===== help @add-exit ======[GENERAL]============================================== Syntax: @add-exit Add the exit with the given object number as a conventional exit from the current room (that is, an exit that can be invoked simply by typing its name, like 'east'). Usually, @dig does this for you, but it doesn't if you don't own the room in question. Instead, it tells you the object number of the new exit and you have to find the owner of the room and get them to use the @add-exit command to link it up. ===== help @add-feature ======[GENERAL]============================================== Usage: @add-feature @remove-feature Add or remove a feature from your list. A feature is an object which provides additional commands you can use. For more information, see `help features'. ===== help @add-feature ======[PROGRAMMER]=========================================== (continued) Note to programmers: @add-feature and @remove-feature are front-ends for player:add_feature and :remove_feature. :add_feature returns * E_PERM unless caller == this || $perm_utils:controls(caller_perms()) * E_INVARG if feature is not an object or is invalid * E_PERM if the object is not feature_ok * a true value otherwise and calls feature:feature_add, if the verb exists. :remove_feature returns * E_PERM unless caller == this || $perm_utils:controls(caller_perms()) || caller_perms() == feature.owner * a true value otherwise and calls feature:feature_remove, if the verb exists. ===== help @add-owned ======[GENERAL]============================================== Syntax: @add-owned Adds an object to your .owned_objects property in case it managed not to get updated properly upon creation of that object. Checks to ensure that the objects is really owned by you and otherwise belongs in your .owned_objects property. See help @audit for more information. ===== help @addalias ======[GENERAL]============================================== Syntax: @addalias [,...,] to @addalias [,...,] to : The first form is used to add aliases to an object's list of aliases. You can separate multiple aliases with commas. The aliases will be checked against the object's current aliases and all aliases not already in the object's list of aliases will be added. Example: Muchkin wants to add new aliases to Rover the Wonder Dog: @addalias Dog,Wonder Dog to Rover Since Rover the Wonder Dog already has the alias "Dog" but does not have the alias "Wonder Dog", Munchkin sees: Rover the Wonder Dog(#4237) already has the alias Dog. Alias Wonder Dog added to Rover the Wonder Dog(#4237). If the object is a player, spaces will also be assumed to be separations between aliases and each alias will be checked against the Player Name Database to make sure no one else is using it. Any already used aliases will be identified. Example: Munchkin wants to add his nicknames to his own list of aliases: @addalias Foobar Davey to me @Addalias recognizes that Munchkin is trying to add an alias to a valid player and checks the aliases against the Player Name Database. Unfortunately, DaveTheMan is already using the alias "Davey" so Munchkin sees: DaveTheMan(#5432) is already using the alias Davey Alias Foobar added to Munchkin(#1523). The second form of the @addalias command is for use by programmers, to add aliases to a verb they own. All commas and spaces are assumed to be separations between aliases. ===== help @addroom ======[LAMBDA]=============================================== SEE @rooms ===== help @addword ======[LAMBDA]=============================================== Syntax: @addword @addword object.property @addword object:verb Will add all words found and unknown into your personal dictionary. Your dictionary is stored in a property named ".dict". ===== help alias ======[GENERAL]============================================== SEE name ===== help also-to ======[EDITOR]=============================================== Syntax: also-to [] Synonym: cc (MAIL ROOM) Adds additional recipients to the To: line of your message. Same rules apply as for the `to' command. ===== help @answer ======[GENERAL]============================================== Syntax: @answer [] [sender] [all] [include] [noinclude] Synonym: @reply Prepares for you to compose a MOO email message to the players who either received or composed the indicated message from your collection. The usual editor is invoked (see `help editors' for details). The subject line for the new message will be initialized from that of the indicated message. If you leave off the message number, the reply will be to your current message, if that exists. In fact you may give a general message-sequence (see `help message-sequences') argument here, provided that it indicates only a single message (e.g., `@answer last:1') If there is a Reply-to: field in the message you are @answer'ing, its contents will be used to initialize the To: line of your reply. Otherwise, a To: line is determined depending on whether you specified `sender' or `all' in the command line (or your .mail_options). `include' includes the text of the original message in your reply, `noinclude' does not. `sender', `all', `include', and `noinclude' can each be abbreviated (e.g., `@answer i'). Defaults are `sender' and `noinclude', but you can change this by setting your .mail-options (see `help mail-options'). ===== help @arb ======[LAMBDA]=============================================== Usage: @arb @arb all This command gives information about the members of the Architecture Review Board (see `help @quota'). Specifically, it gives exactly the same sort of information that the @who command provides. "@arb" tells you about those members who are currently logged in; "@arb all" tells you about all members. ===== help @args ======[PROGRAMMER]=========================================== Syntax: @args : @args : @args : Changes the direct object, preposition, and/or indirect object specifiers for the named verb on the named object. Any specifiers not provided on the command line 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 `help prepositions'. ===== help @audit ======[GENERAL]============================================== 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 string. It is also possible to restrict the range of object numbers to include only those above a given number (`from') or below a given number (`to'). All forms of @audit print a report: #14 Gemba [The Pool] #144 Popgun [Gemba] #1479 Cockatoo [The Living Room] #1673 Bottom of Swimming Pool #2147 Cavern <-*west #2148 tunnel Bottom of Swimming ->Cavern The first column is the object's number, the second its name. The third column shows the object's location: Gemba is in The Pool, and is carrying the Popgun (#144). For exits, the third column shows source ->dest (preceded by a * if owned by someone else). For rooms, the third column shows any entrances owned by someone else, listed as <-*. @audit uses a property .owned_objects on the player, for speed. This property is updated at the time of each object creation and destruction and ownership change. The verb @auditdb (same args as @audit) actually searches through the entire database for objects. See also @verify-owned, @sort-owned, and @add-owned. See also @prospectus, which gives some additional information. ===== help ballots ======[LAMBDA]=============================================== SEE petitions ===== help @ballots ======[LAMBDA]=============================================== Syntax: @ballots [all] Prints a list of all open ballots (or, if the argument `all' is given, all existing ballots) in tabular form, showing each ballot's object number, title, and vote counts, along with an indication of whether or not you have voted on it. ===== help $biglist ======[CORE]================================================= Generic BigList Utilities ---------------------------- $biglist is a collection of routines for maintaining huge persistent (sorted) lists in a format that is less likely to spam the server (which runs into a certain amount of trouble dealing with long ordinary lists --- btw we use `biglist' to refer to the huge data structure we're about to describe and `list' to refer to ordinary MOO lists {...}). The biglist in question lives on a particular object, to which we will refer in the discussion below as the `home' object, and its various elements appear as leaves of a tree whose nodes are kept in properties of the home object. It should be noted that the home object does not need to be (and in fact should *not* be) a descendant of $biglist one; $biglist merely provides utilities for manipulating the properties on the home object that are used in a particular biglist manipulation. All of the utilities below refer to `caller' to locate the home object. Thus verbs to manipulate a given biglist must be located on or inherited by its home object itself. The home object needs to define the following verbs :_make(@args) => new property on home object with value args :_kill(prop) delete a given property that was created by :_make :_get(prop) => home.prop :_put(prop,@args) set home.prop = args :_ord(element) given something that is of the form of a biglist element return the corresponding ordinal (for sorting purposes). If you never intend to use :find_ord, then this can be a routine that always returns 0 or some other random value. See $generic_biglist_home or $big_mail_recipient for examples. Those of the following routines that take a biglist argument are expecting either {} (empty biglist) or some biglist returned by one of the other routines :length(biglist) => length(biglist) (i.e., number of elements) :find_nth(biglist,n) => biglist[n] :find_ord(biglist,k,comp) => n where n is the largest such that home:(comp)(k,home:_ord(biglist[n])) is false, or the smallest such that home:(comp)(k,home:_ord(biglist[n+1])) is true. Always returns a value between 0 and length(biglist) inclusive. This assumes biglist to be sorted in order of increasing :_ord values with respect to home:(comp)(). Standard situation is :_ord returns a number and comp is a < verb. :start(biglist,s,e) => {biglist[s..?],@handle} or {} :next(@handle) => {biglist[?+1..??],@newhandle} or {} These two are used for iterating over a range of elements of a biglist The canonical incantation for doing for elt in (biglist[first..last]) ... endfor is handle = :start(biglist,first,last); while(handle) for elt in (handle[1]) ... endfor handle = :next(@listdelete(handle,1)); endwhile The following all destructively modify their biglist argument(s) L (and M). :set_nth(L,n,value) => L[n] = value replaces the indicated element :insert_before(L,M,n) => {@L[1..n-1],@M,@L[n..length(L)]} :insert_after (L,M,n) => {@L[1..n], @M,@L[n+1..length(L)]} takes two distinct biglists, inserts one into the other at the given point returns the resulting consolidated biglist :extract_range(L,m,n) => {{@L[1..m-1],@L[n+1..]}, L[m..n]} breaks the given biglist into two distinct biglists. :delete_range(L,m,n[,leafkiller]) => {@L[1..m-1],@L[n+1..]} :keep_range (L,m,n[,leafkiller]) => L[m..n] like extract_range only we destroy what we don't want. :insertlast(L,value) => {@L,value} inserts a new element at the end of biglist. If find_ord is to continue to work properly, it is assumed that the home:_ord(elt) is greater (comp-wise) than all of the :_ord values of elements currently in the biglist. :kill(L[,leafkiller]) destroys all nodes used by biglist. Calls home:leafkiller on each element. ===== help blacklist ======[WIZARD]=============================================== The Site Blacklist ------------------ $login maintains three lists of hosts/domains to support player registration schemes and blocking of connections from highly untrusted hosts: .redlist -- all connections from these sites are disabled .blacklist -- player creation and guest logins are disabled .graylist -- advisory list of potential trouble spots (putting a site on the .graylist merely annotates it in @net-who listings). The lists are kept in a special format so it is highly recommended that you either use $wiz:@*list/@un*list or the following verbs to query/update the respective lists rather than bash them directly: $login:*listed (host) is host is on .*list? $login:*list_add (domain or subnet) add domain or subnet to .*list $login:*list_remove(domain or subnet) remove domain or subnet from .*list where `*' is one of `black', `red', or `gray'. One may either specify a domain name (e.g., "baz.edu") or a numeric IP address (e.g., "36.0.23.17"). Domain names match all hosts underneath that domain, so, e.g., puting "baz.edu" on a list effectively adds "x.bax.edu" for all x as well. Likewise, an incomplete numeric address, e.g., "128.42" will match that entire subnet, in this case all hosts whose IP numbers have the form "128.42.m.n" for arbitrary integers m and n. One may also give a domain name containing a wildcard ("*"), e.g., "fritz*.baz.edu", in which case all hostnames matching in the sense of $string_utils:match_string() are considred to be on the list. Wildcard matching should be avoided since it is more time-consuming. It should be noted that, since there is no direct access to the domain name service from within the MOO, it is possible for a host to be blacklisted or redlisted via its domain name, and yet have someone be able to connect from that host (and, in the case of a blacklisted host, create a character) --- this can happen if the name service is down and connection_name() on that player thus has given the numeric IP address rather than the domain name. Similarly, if you list a host by IP number alone, it will still be possible to get in via the site's domain name. Thus to be completely assured of shutting out a site, you need to list it both by domain name and IP number. ===== help @blacklist ======[WIZARD]=============================================== Syntax: @redlist [ [commentary]] @blacklist [ [commentary]] @graylist [ [commentary]] Syntax: @unredlist [ [commentary]] @unblacklist [ [commentary]] @ungraylist [ [commentary]] With no argument, the current contents of the list are printed. Otherwise, the specified domain or subnet is added to or removed from the list and mail will be sent to $site_log. If the given domain or subnet has subdomains/subsubnets that are already on the list, you will be prompted as to whether you want to remove them. Note that adding an entry for a particular domain or subnet effectively adds all subdomains/subsubnets, so unless there's some reason for keeping an explicit entry for a particular subdomain, chances are you will indeed want to remove them. One reason to keep an explicit entry for a subdomain would be if you intended to unlist the full domain later but wanted to be sure you didn't unlist the subdomain in the process. See `help blacklist' for a description of the functions of these lists. ===== help @bug ======[GENERAL]============================================== SEE @typo ===== help building ======[GENERAL]============================================== There are a number of commands available to players for building new parts of the MOO. Help on them is available under the following topics: creation -- making, unmaking, and listing your rooms, exits, and other objects topology -- making and listing the connections between rooms and exits descriptions -- setting the names and descriptive texts for new objects locking -- controlling use of and access to your objects ===== help building ======[LAMBDA]=============================================== (continued) Please see 'help theme' for policy about what kind of building is appropriate. ===== help burn ======[GENERAL]============================================== Syntax: burn Destroy the named letter irretrievably. Only players who can read the letter can do this. ===== help cc ======[EDITOR]=============================================== SEE also-to ===== help @check ======[GENERAL]============================================== Syntax: @check where is one or more of: -- the number of lines to be displayed -- a player's name, someone to be "trusted" during the assignment of responsibility for the message. -- a player's named prefixed by !, someone not to be "trusted". @check-full where . @check-chparent to You cannot add a new property to an object if an ancestor or a descendant already defines a property with the same name. @check-property will give you the list of all descendants of that that define .. Likewise you cannot chparent an object to a new parent if the new parent has a property that is also defined on the object or some descendant. Use @check-chparent to find out all instances of conflicting properties that would interfere with @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 properties 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-consuming. ===== help @check-property ======[PROGRAMMER]=========================================== SEE @check-chparent ===== help @chmod ======[PROGRAMMER]=========================================== Syntax: @chmod @chmod . @chmod : Changes the permissions of an object, property or verb, to those given. The following table shows what permission bits are allowed for each form of the command: r, w, f r, w, c r, w, x, d See the LambdaMOO Programmer's Manual for their meanings. 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 subtract 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 Writeable in addition to any current bits: @chmod table +w ===== help @chown ======[WIZARD]=============================================== Syntax: @chown [to] @chown . [to] @chown : [to] Changes the ownership of the indicated object, property or verb. Verb ownership changes are fairly straightforward, being merely a matter of changing the verb_info() on a single verb. Changing an object ownership includes changing the ownership on all +c properties on that object. Note that @chown will not change the ownership of any other properties, nor will it change verb ownerships. Use @grant if you need to do a more complete ownership change. The quota of the former owner is increased by one, as is the quota of the new owner decreased by one. Changing a property ownership is truly hairy. If the property is +c one shouldnot be doing this, unless it is to correct a past injustice which caused the property to be owned by the wrong player. In the case of -c properties, the property ownership is changed on all descendent objects (currently, if +c instances of a -c property are found in the traversal of all of the descendants, these are not changed, being deemed sufficiently weird that they should be handled on a case-by-case basis...). If there's any justice, a future version of the server will prevent occurrences of (1) +c properties being owned by someone other than the object owner (2) -c properties with different owners on descendant objects (3) -c properties that are +c on some descendants. ===== help @chparent ======[PROGRAMMER]=========================================== Syntax: @chparent to Changes the parent of the named object to be the named parent. The object acquires all the verb and property definitions of its parent. Newly acquired properties are initilialized with `clear' values so that they inherit whatever values are currently assigned to the parent's corresponding properties (see `help @clearproperty'). If the player does not own , it must have been set `fertile'. must be owned by the player. Neither nor any descendant can define any property which already exist on . Use @check-chparent (see `help @check-chparent') to list such property conflicts. It is also sometimes the case that you will own some object and want to @chparent some child of that object that you do not own. Use @disinherit (see `help @disinherit') in such situations. ===== help @classes ======[GENERAL]============================================== Syntax: @classes @classes ... The wizards have identified several useful classes of objects in the database. The @classes command is used to see which classes exist and what their member objects are. The first form simply lists all of the defined classes along with short descriptions of the membership of each. The second form prints an indented listing of that subset of the object parent/child hierarchy containing the objects in the class(es) you specify. ===== help @clearproperty ======[PROGRAMMER]=========================================== Syntax: @clearproperty . This clears 's property. That is the property value becomes `clear' and all further references to this property will use the value of the same property on the parent object. Note that you can only clear inherited properties. Nor is this the same as removing a property; the property continues to exist. `@clearproperty' can be abbreviated as `@clearp'. Example: @create #1 named foo You now have foo with object number #42 and parent Root Class (#1). [foo, as a child of #1 has a .description property which starts out clear] ;#1.description => "" ;#1.description = "You see nothing special" => "You see nothing special" ;#42.description => "You see nothing special" ;#42.description = "Something special" => "Something special" [foo.description is now no longer clear; it has a value of its own] ;#1.description = "Boring" => "Boring" ;#42.description => "Something special" @clearp foo.description Property #42.description cleared; value is now "Boring". [foo.description is now clear again] ;#1.description = "" => "" ;#42.description => "" ===== help commands ======[GENERAL]============================================== SEE summary Type 'help ' for information on a particular topic. ===== help @comment ======[GENERAL]============================================== SEE @typo ===== help common_quota ======[GENERAL]============================================== Syntax: @quota Each player has a limit as to how many objects that player may create, called their '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 may 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: database bloat. The problem is that a large number of people build a large number of dull objects and areas that are subsequently never used or visited. The database becomes quite large and difficult to manage without getting substantially more interesting. With the quota system, we can make it possible for players to experiment and learn while simultaneously keeping random building to acceptable levels. ===== help communication ======[GENERAL]============================================== There are several commands available to allow you to communicate with your fellow MOOers. Help is available on the following communication-related topics: say -- talking to the other connected players in the room whisper -- talking privately to someone in the same room page -- yelling to someone anywhere in the MOO emote -- non-verbal communication with others in the same room gagging -- screening out noise generated by certain other players news -- reading the wizards' most recent set of general announcements @gripe -- sending complaints to the wizards @typo @bug @idea @suggest -- sending complaints/ideas to the owner of the current room whereis -- locating other players @who -- finding out who is currently logged in mail -- the MOO email system security -- the facilities for detecting forged messages and eavesdropping. ===== help compile ======[EDITOR]=============================================== Syntax: compile [as :] (VERB EDITOR) Installs the new program into the system if there are no syntax errors. If a new object:verb is specified and actually turns out to exist, that : becomes the default for subsequent compilations. ===== help @complete ======[LAMBDA]=============================================== Syntax: @complete prefix This verb is part of the MOO spelling checker. It will show you all the words in the dictionary that start with the prefix letters you specify. You should be specific as to what you're looking for (for example, you might use @complete comput, rather than @complete co) in order to avoid getting an excessive number of words output. Refer to help spelling for more information. ===== help $container ======[CORE]================================================= The Generic Container (for programmers) In addition to the command verbs described under `help containers' and the _msg properties described in `help container-messages', the following verbs and properties are available for use within programs .opened == TRUE iff the container is open .dark == TRUE iff the contents of the container may be seen .opaque -- describes the correlation between .open and .dark == 0 container is always !dark == 1 container is dark iff it is closed == 2 container is always dark :set_opaque(newvalue) changes the .opaque value for the container => newvalue or E_PERM or E_INVARG :set_opened(newvalue) opens/closes the container (updates .open and .dark) according to newvalue => newvalue or E_PERM :is_openable_by(player) what the :open command uses to test whether the player should be able to open the container. By default this refers to .open_key (set by @(un)lock_for_open), but the object owner is free to customize this. N.B.: There is no way to directly set .dark; .dark can be changed only by changing one of .opaque or .opened. Use :set_opaque(0) and :set_opaque(2) to have .dark change independently of the value of .opened. ===== help container-messages ======[GENERAL]============================================== *subst* Several kinds of messages can be set on a container object; they are printed to various audiences at certain times whenever an attempt is made to use the container. The ones whose names begin with 'o' are always shown prefixed with the name of the player making the attempt and a single space character. The standard pronoun substitutions (with respect to the player) are made on each message before it is printed; see 'help pronouns' for details. The default message is given in brackets after each name below: @empty[%[$container.empty_msg]] Printed in place of the contents list when the container is empty. @open [%[$container.open_msg]] Printed to the player who successfully opens the container. @oopen [%[$container.oopen_msg]] Printed to others in the same room if the player successfully opens the container. @open_fail [%[$container.open_fail_msg]] Printed to the player who cannot open the container. @oopen_fail [%[$container.oopen_fail_msg]] Printed to others in the room when a player fails to open a container. @close [%[$container.close_msg]] Printed to the player who closes a container. @oclose [%[$container.oclose_msg]] Printed to others in the room when a player closes a container. @put [%[$container.put_msg]] Printed to a player when an object is successfully placed in a container. @oput [%[$container.oput_msg]] Printed to others in the room when a player successfully places an object in a container. @put_fail [%[$container.put_fail_msg]] Printed when a player fails to put an object in a container. @oput_fail [%[$container.oput_fail_msg]] Printed to others in the room when a player fails to place an object in a container. @remove [%[$container.remove_msg]] Printed when a player succeeds in removing an object from a container. @oremove [%[$container.oremove_msg]] Printed to others in the room when a player succeeds in removing an object from a container. @remove_fail [%[$container.remove_fail_msg]] Printed when a player fails to remove an object from a container. @oremove_fail [%[$container.oremove_fail_msg]] Printed to others in the room when a player fails to remove an object from a container. ===== help containers ======[GENERAL]============================================== Containers are objects that allow you to store other objects inside them. The following help topics cover verbs that can be used with containers: put -- putting an object into a container remove -- taking an object out of a container Containers may be open or closed, using the verbs 'open container' and 'close container'. Containers have a separate lock to determine if a player may open them. See the following help topics: @lock_for_open -- setting the lock for opening a container @unlock_for_open -- clearing the lock You can make a container by creating a child of the standard container, $container (see 'help @create'). Containers have a large number of messages which get printed when players act upon them. See 'help container-messages' for more information. Containers have opacity. See 'help @opacity' for more information. ===== help @contents ======[GENERAL]============================================== Syntax: @contents object A quick way to find out the contents of an object. Prints out the names and object numbers of all direct contents. This can be useful when you need to refer to 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) ===== help copy ======[EDITOR]=============================================== Syntax: c*opy [] to Copies the specified range of lines to place given by . If happens to be the current insertion point, the insertion point moves to the end of the inserted lines. See `help insert' for a list of possibilities for . ===== help @copy ======[PROGRAMMER]=========================================== Syntax: @copy : to [][:] 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 event that the new verb does not already exist. One of or : must be supplied. If no new verbname is given, the old name is retained. Likewise, defaults to if not given. 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 desired effect can be accomplished with parenting (i.e., having be an ancestor of ), which has the advantage that if a verb is updated or fixed, 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 fixed by hand. This facility is provided for those rare occasions where one has no choice but to actually copy the verb. ===== help @count ======[GENERAL]============================================== Syntax: @count Prints out the number of objects you own. Do not be surprised if this is one larger than you think it should be: remember that your player object is owned by you as well, even though you didn't create it in the usual way. ===== help cracking ======[LAMBDA]=============================================== Famous last words: ``I really only wanted to see if it could be done.'' ``I wasn't going to wreck anything. Honest.'' ``Geez, you've got that huge hole there; you're just asking for it.'' It's a natural thing to wonder about holes in the system and how easy it is to break in, whether it be to get yourself a wizard bit (i.e., by nefarious means that don't involve asking for one) or do other neat things that should normally require a wizard bit. Doubtless, some would consider a successful break-in to be a spectacular achievement, a mark of programming machismo, so to speak. Some would suppose that this entitles them to a wizard bit, or to do anything they like to the database. This is highly debatable. If I accidentally drop my keys somewhere in my front yard and you manage to find them, this is not likely to mark you as a master locksmith, no matter how much time you spent painstakingly examining every square inch of turf. Though I'll probably be happy to get my keys back and might even be inclined to give some sort of reward, the mere act of finding the keys does not entitle you to go through the house and take anything that interests you. Nor does it entitle you to make copies of the keys before giving them back to me --- I'll say nothing of your expecting me to sign over the title to the house. Moreover, I'll be extremely annoyed if I have to take the time to search through the house in order to make sure nothing is missing, likewise if I have to change the locks. You may be entirely innocent, but you have to be careful just the same. It may seem like a shoot-the-messenger policy when in fact we actually LIKE having security holes found. The key point is that, if you SAVE us time by finding a hole for us, then we're happy. But, if you COST us time because we're not absolutely sure we can trust you and have to grep the db looking for any Trojan horses we think you might have planted, then we're not happy. If having you around costs us more time than it saves, then, suffice it to say, you won't be around and we can go to some fairly extravagant lengths to try to ensure this. Thus, if you're going to hunt security holes, you MUST understand the rules of the game. It's particularly important here, since in matters of security, we can't take chances; while we do take regular checkpoints, vandals can still make life miserable for everyone. Thus, it's @toad first, ask questions later. So here are the cardinal rules: 1. If you find out about a major security hole, you tell us AS SOON AS POSSIBLE. Nor does it matter HOW you find out, i.e., whether you find it yourself or someone else points it out to you. It's the mere existence of the hole that's a problem. *You* may not intend to do anything evil, but there are other people around who are at least as bright as you, including some that are significantly less scrupulous, and it only takes one to do damage. What is a major security hole? You'll know it when you see it. Figure if you can use it to set your wizard bit then it's major. There are also minor security holes (e.g., finding a way to read $site_db) which we also like to find out about, but for which one is unlikely to suffer a summary @toading (unless of course, a major security hole was involved in creating the minor security hole). 2. If you find something you think might be a security hole but needs an experiment to verify, you consult us FIRST. One problem is your experiment might succeed. If we should happen to catch you (and there are various hooks and tasks out there that watch for certain things) before you get a chance to tell us, you may find yourself in the unenviable position of having to PROVE that you actually were intending to tell us about it; if you are someone we only know as an ascii byte stream, we won't be in a very good position to judge your intentions. Another problem is your experiment might fail but manage to leave some kind of mess behind which we'd have to clean up in which case we're not going to be terribly happy. Also if it looks to us like you were trying to take advantage of a security hole and weren't going to tell us if you had succeeded, then you'll be in a situation roughly similar to that of the previous paragraph, albeit better for not having succeeded, but it could still mark you as someone not to be trusted. 3. If you do a particularly simple experiment to break security, something that you didn't seriously think would work (and thus didn't think was worth bothering us with), but find that, against all odds, it does, you should TELL us IMMEDIATELY. Okay, so you did something silly like `;player.wizard = 1' and it worked! You might infer from (2) that you're already screwed no matter what you do. The bottom line, however, is that if you tell us immediately, then you're in a much BETTER position than if you DON'T tell us. Chances are, if you can manage to tell us BEFORE we catch you, and you're careful not to give us any reason to believe you took advantage of the hole, you'll emerge unscathed. No promises, though. ===== help @create ======[GENERAL]============================================== 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, the 'kind' of object you're creating. is one of the four standard classes 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 object isn't one of these, you may use the parent's name (if it's in the same room as you) or else its object number (e.g., #4562). The are given in the same format as in the @rename command: ,,..., [preferred] :,..., [not preferred] See 'help @rename' for a discussion of the difference between a name and an alias. ===== help creation ======[GENERAL]============================================== The primary means for players to extend the MOO is for them to create new objects with interesting behavior. There are convenient commands for creating and recycling objects and for keeping track of the objects you've created. Help is available 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 ===== help @cspell ======[LAMBDA]=============================================== Syntax: @cspell @cspell object.property @cspell object:verb Like @spell, but attempts to guess at correct spellings for words it believes are spelled incorrectly. This verb can be quite slow, so correcting large chunks of text may not be a good idea. Refer to help spelling and help @spell for more information. ===== help @dbsize ======[PROGRAMMER]=========================================== Syntax: @dbsize @dbsize goes through the entire database, counting the valid and invalid objects, giving a summary at the end. This information can be useful, but because this command is cpu intensive, it should be used sparingly. ===== help decrypt ======[GENERAL]============================================== Syntax: decrypt Removes any restriction on who may read the named note or letter. Only the owner of a note may do this. ===== help defense ======[LAMBDA]=============================================== Unfortunately, not everyone is nice, and it is sometimes necessary to take action to protect oneself from the destructive actions of others. Here is a quick summary of the things you can do to protect yourself. @gag: Some people delight in saying nasty things, or just saying so much that your screen fills up and you can't do anything. @gag prevents you from seeing any text that the person is producing. See help @gag for details. @refuse: This is a fairly general facility with lots of options. See help @refuse for details. Here are a couple of common examples (these aren't exact commands: see help @refuse!) @refuse move: Some people delight in moving you from place to place without your consent. This can be terribly confusing, and also makes it difficult to do anything. @refuse mail: After someone notices you've gagged them, they might start sending you lots of mail. This will help you avoid that problem. @refuse page: @refuse whisper: Sometimes you only want to refuse a little bit; someone is mostly OK, but they're paging you too much. This will help with that. Hopefully you won't come in contact with people who force you to use the above commands, but just in case you do, they're here to help. ===== help delete ======[GENERAL]============================================== Syntax: delete from Removes a single line of text from a note. The first line of text is numbered 1, the second is 2, and so on. Only the owner of a note may do this. ===== help delete ======[EDITOR]=============================================== Syntax: del*ete [] (EDITOR) Deletes the specified range of lines defaults to the line *before* the current insertion point. ===== help @denewt ======[WIZARD]=============================================== Syntax: @denewt [commentary] Synonyms: @unnewt @get-better @denewt reverses the effects of @newt, moving a player's :denewt_confunc back to :confunc, but checking first that :confunc is the same as $wiz_utils:newt_confunc (if not, we save :confunc as :newt_confunc and complain). Mail is sent to $newt_log including any commentary you provide. E.g., @denewt Twit He promises not to do it again. ===== help depublish ======[EDITOR]=============================================== SEE unpublish ===== help @describe ======[GENERAL]============================================== Syntax: @describe as Sets the description string of to . This is the string that is printed out whenever someone uses the 'look' command on . To describe yourself, use 'me' as the . Example: Munchkin types this: @describe me as "A very fine fellow, if a bit on the short side." People who type 'look Munchkin' now see this: A very fine fellow, if a bit on the short side. Note for programmers: The description of an object is kept in its .description property. For descriptions of more than one paragraph, .description can be a list of strings. ===== help descriptions ======[GENERAL]============================================== Most objects have one or more descriptive pieces of text associated with them; these texts are printed under various circumstances depending on the kind of text. For example, every object has a 'description' text that is printed whenever a player looks at the object. The following help topics discuss the commands for manipulating these descriptive texts on your objects: @rename -- setting the name and aliases of your objects @describe -- setting what others see when they look at your objects messages -- listing and setting the other descriptive texts on an object ===== help @detoad ======[WIZARD]=============================================== SEE @untoad ===== help @dig ======[GENERAL]============================================== Syntax: @dig "" @dig to "" @dig to This is the basic building tool. The first form of the command creates a new room with the given name. The new room is not connected to anywhere else; it is floating 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 linking your current location to (and possibly from) the new room. An has one of the following two forms: | where the first form is used when you only want to create one exit, from your current 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 piece is just a list of names for the exit, separated by commas; these are the names of the commands 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 are useless in MOO. The third form of the command is just like the second form except that no new room 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 creating 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 room. 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 (via 'east', 'e', or 'out'). @dig up,u to #7164 creates an exit leading from the player's current room to #7164, which must be an existing room. ===== help @disinherit ======[PROGRAMMER]=========================================== Syntax: @disinherit @disinherit [from ] 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 case, namely where you don't own the child. Both forms of this command chparent to its grandparent, provided you own the parent. The second form matches the string you supply for against the list of children of the given . Turning off the fertile bit (.f) for a particular object prevents others from creating children of it or chparenting to it (see `help @chmod'). Note also that, though the name might seem to indicate otherwise, this command does not change the ownership of any object. ===== help @disown ======[PROGRAMMER]=========================================== SEE @disinherit ===== help @display ======[PROGRAMMER]=========================================== Syntax: @display .[property] ,[inherited_property] :[verb] ;[inherited_verb] @display is a fancy version of @show. As @show, it can select individual verbs or properties to display. In addition, it can display all the verbs or properties defined on an object, or all the verbs or properties defined on any of the object's ancestors. Don't specify a property or verbname after the punctuation mark to get the "all" feature. Its display is more compact than that of @show (it uses a one-line format, and truncates values that don't fit in the value field). You may mix properties and verbs on the command line, but the parser may become confused. (E.g. @display object,: displays all properties including inherited ones plus all locally defined verbs on the object.) Examples: Individual property: @display poolsweep.count .count yduJ (#68) r c 8 Individual verb: @display poolsweep:tell #3560:tell yduJ (#68) rxd this none this All properties, including one truncated value: @display poolsweep. poolsweep (#3560) [ readable ] Owned by yduJ (#68). Child of generic thing (#5). Location The Pool (#1428). .gagged yduJ (#68) r c 0 .count yduJ (#68) r c 8 .messages yduJ (#68) r c {"The poolsweep stir.. .index yduJ (#68) r c 2 .quantum yduJ (#68) r c 20 Inherited verbs, edited for brevity, showing verbs from various parents, with owners, permissions, and argument lists. @d poolsweep; poolsweep (#3560) [ readable ] #3560:tell yduJ (#68) rxd this none this #3560:description yduJ (#68) rxd this none this #5:"g*et t*ake" Haakon (#2) rxd this none none #5:"d*rop th*row" Haakon (#2) rxd this none none #5:moveto Haakon (#2) rxd this none this #1:description Haakon (#2) rxd this none this #1:look_self Haakon (#2) rxd this none this Some aspects of @display can be customized (see `help @display-options'). ===== help @display-options ======[PROGRAMMER]=========================================== Syntax: @display-option @display-option