&&& help HELP Help is available on the following topics: basic-cmd Basic commands, of interest to all. builder-cmd Topics of interest mainly to builders. mucker-cmd Topics of interest mainly to MUF programmers. maint-cmd Maintenance and adminstrative commands. names How names for things work. goal The goal of the whole thing. For more information on any of these, use help. Use "help basic-cmd", for example, to see the list of basic commands. You can then, in turn, get information about any of them with help; for example, "help say" will show you information about "say". &&& basic-cmd Basic commands: @examine OUTPUTPREFIX get look rob @password OUTPUTSUFFIX give move say @properties OUTPUTWRAP goto news score @set QUIT gripe page take @time TELNET help pose throw HOLDSHUT drop inventory put whisper OUTPUTFOLD examine kill read who Commands shown in lowercase can be entered in any mix of upper and lower case, but commands shown in uppercase must be entered in uppercase. &&& builder-cmd Commands primarily for builders: @action @describe @find @ofail @trace @attach @dig @link @open @unlink @chown @drop @lock @osuccess @unlock @contents @exits @name @recycle @create @fail @odrop @success &&& mucker-cmd Commands primarily for MUF programmers: @edit @go @kill @list @prog @ps man &&& maint-cmd Maintenance and adminstrative commands: @boot @dump @owned @stats @user @config @force @pcreate @teleport @wall @dbck @newpassword @shutdown @toad @who &&& @action @action (minimum abbreviation: @ac) @action [=] This sets up an action and attaches it to the thing, room, or player named. You will have to @link it somewhere before it's useful. (See "help actions" for more.) &&& @attach @attach (minimum abbreviation: @at) @attach = Attaches the named action to , de-attaching it from wherever it was previously attached. (See "help actions" for more.) &&& @boot @boot (minimum abbreviation: @b) @boot Forcibly disconnects the player from the game. Anyone may use @boot reflexively, but only wizards may use it on other players. &&& @chown @chown (minimum abbreviation: @ch) @chown [=] Changes the ownership of to ; if the = is omitted (or is "=me"), changes ownership to you. You can @chown something only if it's set O(wnable), or if you're royalty, a wizard, or a god; only wizards and gods can specify a to transfer ownership to someone else. (Players always own themselves; they cannot be @chowned by anyone.) &&& @config @config (minimum abbreviation: @conf) Prints compile-time configuration information about the muck. Restricted to royalty, wizards, and gods. &&& @contents @contents (minimum abbreviation: @cont) @contents [][=] Display the contents of an object which match (see "help name-prefix"). If the is omitted, "here" is used; if the = is omitted, the entire contents list is shown. &&& @create @create (minimum abbreviation: @cr) @create [=] Creates a thing with the specified name and value; if the value is omitted, 1 is used. &&& @dbck @dbck (minimum abbreviation: @db) @dbck -n @dbck -y Performs a thorough check of the database for internal consistency. If -n is given, just describes errors; if -y is given, reports errors and fixes them, describing any actions taken. This command is very restricted: it works only for gods, and only when there are no connections except for the invoking player. &&& @describe @describe (minimum abbreviation: @de) @describe [=] Sets the 's description to , or if the = part is omitted, removes the description. See "help @-messages" for more. &&& @dig @dig (minimum abbreviation: @di) @dig [=] Creates a new room with the specified name, sets its parent, and displays the number of the new room. This costs money. The amount can be tweaked when the muck is compiled; at this writing, it's $25. If the = is omitted, it defaults to the parent of the room you're in. You must be able to link to the specified parent; if you can't, #0 is used as the parent instead. The J(ump_ok) bit of the new room is set if your J bit is set. See "help environments" for more information about room parents. &&& @drop @drop (minimum abbreviation: @dr) @drop [=] Sets the drop message on to ; if the = is omitted, clears the message. See "help dropping" and "help @-messages" for more. &&& @dump @dump (minimum abbreviation: @du) @dump [] Dumps the database to disk. Restricted to wizards. If the is given, dumps to an alternate filename; this form is restricted to gods. The database is automatically dumped periodically; this command is not intended for routine use. &&& @edit @edit (minimum abbreviation: @ed) @edit Enters the editor with the specified program. The program must already exist (use @prog to create new programs). This is restricted to the program's owner, and further only if that player is set M(ucker), except that wizards can @edit any program. &&& @examine @examine (minimum abbreviation: @exa) @examine Never shows the object's properties, contents, or attached exits, but otherwise just like examine. (Useful primarily when you want some non-property information and the dbref has, or may have, a lot of properties. Similar remarks apply to contents and exits. See also @properties, @contents, and @exits.) &&& @exits @exits (minimum abbreviation: @exi) @exits [=] Display the exits attached to the object which match (see "help name-prefix"). If the is omitted, "here" is used; if the = is omitted, the entire exits list is shown. &&& @fail @fail (minimum abbreviation: @fa) @fail [=] Sets the object's failure message (or, if the = is omitted, clears the message). See "help failure" and "help @-messages" for more. &&& @find @find (minimum abbreviation: @fi) @find [] Lists everything you own that matches (see "help name-prefix"); if is omitted, everything you own is shown. (For wizards, the search extends over the entire database, regardless of ownership.) &&& @force @force (minimum abbreviation: @fo) @force = Forces the player to execute the given command. This does not work unless the player doing the forcing is also the player being forced, or the player doing the forcing is a wizard. &&& @go @go (minimum abbreviation: @g) @go Causes the daemon to run immediately, bypassing any remaining timeout. Only the daemon's owner, or a wizard, may make it @go. &&& @kill @kill (minimum abbreviation: @k) @kill Destroys the daemon, aborting its execution. Only the daemon's owner, or a wizard, may @kill it. &&& @link @link (minimum abbreviation: @lin) @link = @link =;;;... Links the to . If is a thing, must be a room or player, and 's home is set to . If is a player, must be a room, and 's home is set. (See "help homes" for more about thing and player homes.) If is a room, its drop-to is set to (see "help drop-tos"). If is an exit, multiple destinations can be specified; see "help linking" for more. If an exit is not linked anywhere, any builder may @link it and thereby gain ownership of it. Linking an exit costs $1; if the exit was previously owned by someone else, an additional $1 is charged, which goes to the previous owner. You cannot @link an exit unless it is unlinked; see @unlink. &&& @list @list (minimum abbreviation: @lis) @list [=[start][-][end]] Lists the given program, starting and ending at the specified lines. If the line numbers are omitted, the defaults are line 1 for the start and the last line for the end. You must own the program or be a wizard, or the program must be set L(ink_OK). &&& @lock @lock (minimum abbreviation: @lo) @lock = Locks to . The key is a boolean expression, using &, |, and ! as boolean operators and ( ) for grouping; the basic operations are either a dbref to lock to that dbref or : to lock to a property value. See "help locks" for more detailed information. You do not have to @unlock something first in order to re-@lock it differently. &&& @name @name (minimum abbreviation: @na) @name = @name = Changes the name of to . To change your own name, you must also give your password. &&& @newpassword @newpassword (cannot be abbreviated) @newpassword = Changes the player's password. Works only for wizards. &&& @odrop @odrop (minimum abbreviation: @od) @odrop [=] Sets 's odrop message, or if the = is omitted, clears it. See "help dropping" and "help @-messages" for more. &&& @ofail @ofail (minimum abbreviation: @of) @ofail [=] Sets 's ofail message, or if the = is omitted, clears it. See "help failure" and "help @-messages" for more. &&& @open @open (minimum abbreviation: @op) @open [=] Equivalent to "@action =here"; if = is given, followed by "@link =". &&& @osuccess @osuccess (minimum abbreviation: @os) @osuccess [=] Sets 's osuccess message, or if = is omitted, clears it. See "help success" and "help @-messages" for more. &&& @owned @owned (minimum abbreviation: @ow) @owned [][=] For players, works like @find; for wizards, works like @find for the specified player. &&& @password @password (minimum abbreviation: @pa) @password = Changes your password. You have to give the previous password. &&& @pcreate @pcreate (minimum abbreviation: @pc) @pcreate = Creates a new player with the given name and password. Restricted to wizards. &&& @prog @prog (cannot be abbreviated) @prog Creates a new program with the given name and enters the editor. Restricted to wizards and players set M(ucker). &&& @properties @properties (minimum abbreviation: @prop) @properties [=] Shows the properties on an object. Without the =, shows all properties; with a string given, shows only properties whose name match the prefix (see "help name-prefix"). &&& @ps @ps (cannot be abbreviated) @ps Lists all daemons you own, or if you're a wizard, all daemons. &&& @recycle @recycle (minimum abbreviation: @r) @recycle Destroys the , freeing the dbref for re-use. (Players cannot be recycled directly; see @toad.) &&& @set @set (minimum abbreviation: @se) @set =[!] @set =:[] @set =: The first form sets (or, with !, clears) the specified flag on the object. (See "help flags" for a list of flag names.) The second form sets the named property on the object to the value given, or if no value is given, removes the property. The third form removes all properties on the object. (The third form will not remove MUF-only or wiz-only properties; see "help properties" for more.) &&& @shutdown @shutdown (cannot be abbreviated) @shutdown Dumps the database to disk and shuts down the muck. Works only for gods. &&& @stats @stats (minimum abbreviation: @st) @stats [] With no argument, displays statistics on the whole database; this form works for anyone. If the named object is a player, displays statistics on the fraction of the database owned by that player; if the named object is a daemon, displays some time values for that daemon. In any case, displays the object's timestamps, and if the object has any proglocks, displays them. This form works only when the invoking player owns the object, or is royalty, a wizard, or a god. &&& @success @success (minimum abbreviation: @su) @success [=] Sets 's success message, or if = is omitted, clears it. See "help success" and "help @-messages" for more. &&& @teleport @teleport (minimum abbreviation: @te) @teleport [=] Teleports the object to the place. If the = is omitted, teleports the invoking player. Works only when the invoking player controls the object being teleported. When teleporting a player, the destination must a room, and the invoking player must be able to link to it; when teleporting a thing or program, the destination must be a room or player, and the invoking player must be either royalty, a wizard, a god, and must either control the destination or be able to link to it, and must control either the thing being teleported or its pre-teleport location; when teleporting a room, the invoking player must control the room being teleported and must be able to link to the new location; other types of objects cannot be teleported. (See "help control" for what it means to control an object.) &&& @time @time (minimum abbreviation: @ti) @time Executes , reporting (after it finishes) how long it took. Commands that run programs may report before they finish, and in this case they will report too small a value. &&& @toad @toad @toad [=] Turns the player into a slimy toad, converting the player object into a thing object. Everything owned by the toaded player is reset to be owned by the ; if the is not specified, #1 is used. This command is restricted to gods, and #1 is never @toadable under any circumstances. This also performs the equivalent of @boot as a side effect. &&& @trace @trace (minimum abbreviation: @tr) @trace [=] Starts with the specified object and repeatedly follows the location field, until the global-environment room is reached or the optional is exhausted. Rooms you cannot link to will be displayed as **Missing**. You must control an object to @trace it (see "help control"). &&& @unlink @unlink (minimum abbreviation: @unli) @unlink If is an exit, unlinks it; if is a room, removes its drop-to, if any. Other types of object cannot be unlinked. &&& @unlock @unlock (minimum abbreviation: @unlo) @unlock Removes the lock, if any, on . See @lock for more. &&& @user @user (minimum abbreviation: @us) &&& @user @user = Converts your connection so you're connected to the player named . 's password is normally required; wizards are exempt from this requirement. &&& @wall @wall (minimum abbreviation: @wa) @wall Shouts to all connected players. Works only for royalty, wizards, and gods. &&& @who @who (minimum abbreviation: @wh) @who [] Provides a user list somewhat like "who", but includes more internal information and is restricted to wizards. &&& OUTPUTFOLD OUTPUTFOLD (cannot be abbreviated, and must be uppercase) OUTPUTFOLD Causes the muck to fold output lines to columns. This folding takes no account of word boundaries, being strictly column-based (compare to OUTPUTWRAP). If the is less than 1, output folding is disabled. OUTPUTFOLD affects only the connection it is issued on, even if other connections to the same player exist. If OUTPUTFOLD and OUTPUTWRAP are both issued on a given connection, the last one specified takes precedence. If OUTPUTFOLD and OUTPUTWRAP are both issued on a given connection, the last one specified takes precedence. &&& OUTPUTPREFIX OUTPUTPREFIX (cannot be abbreviated, and must be uppercase) OUTPUTPREFIX The specified string is produced as an output line before the output of each subsequent command. OUTPUTPREFIX affects only the connection it is issued on, even if other connections to the same player exist. &&& OUTPUTSUFFIX OUTPUTSUFFIX (cannot be abbreviated, and must be uppercase) OUTPUTSUFFIX The specified string is produced as an output line after the output of each subsequent command. Commands that run programs may emit the OUTPUTSUFFIX before the command actually completes. OUTPUTSUFFIX affects only the connection it is issued on, even if other connections to the same player exist. &&& OUTPUTWRAP OUTPUTWRAP (cannot be abbreviated, and must be uppercase) OUTPUTWRAP Causes the muck to fold output lines to columns. This folding pays attention to word boundaries (where a "word" is defined as a maximal sequence of non-whitespace characters). Lines are broken at whitespace, with whitespace deleted when it is adjacent to a generated break. If the is less than 1, output folding is disabled. OUTPUTWRAP affects only the connection it is issued on, even if other connections to the same player exist. If OUTPUTWRAP and OUTPUTFOLD are both issued on a given connection, the last one specified takes precedence. &&& QUIT QUIT (cannot be abbreviated, and must be uppercase) QUIT Disconnects the connection it is issued on. No other connection is affected, even if the connection being disconnected is connected to a player which is also connected on some other connection. &&& TELNET TELNET (cannot be abbreviated, and must be uppercase) TELNET must begin with one of the characters y, Y, t, T, or 1, which turns on telnet protocol handling, or n, N, f, F, or 0, which turns it off. This flag is per-connection; when turned on, it causes the server to recognize and minimally interpret the TELNET protocol. This is normally left turned off, on the assumption that a real client is used to connect; if you use telnet to connect, you probably want to set "TELNET Y", because otherwise your telnet client will get very confused if it ever tries to send TELNET-protocol escapes. (For those to whom it means anything: all option negotiations are refused (DO provokes WONT, WILL provokes DONT, regardless of the option code), IAC SB ... IAC SE is ignored (it should never happen anyway), IAC IAC is taken as a single data byte, and IAC X is ignored for any other value of X, such as GA or AO. The server turns IAC data bytes into IAC IAC on output and never generates IACs otherwise except when refusing option negotiations.) &&& HOLDSHUT HOLDSHUT (cannot be abbreviated, and must be uppercase) HOLDSHUT must begin with one of the characters y, Y, t, T, or 1, which turns on hold-on-shutdown, or n, N, f, F, or 0, which turns it off. This flag is per-connection; when turned on, it means that when the server is shut down, the connection is not closed until the server process finally exits; normally, the connection is closed when the shutdown is done. (This is of little use except to site/server maintenance people; don't worry if you never have occasion to use it.) &&& drop drop (minimum abbreviation: d) drop Moves the object from your inventory to the room you're in. You have to be carrying the object already. (If the object is set S(ticky), or the room has a drop-to, this can be modified. See "help sticky" and "help drop-tos" for more.) &&& examine examine (minimum abbreviation: e) examine Prints out useful information about . If you don't own it, you will instead be told who does, and nothing more; but if you do, you will be told all available information about it. In more detail, not necessary for casual users: the above contains some slight lies. The actual test is more complicated and can be tweaked when the muck is compiled. At this writing, you can examine yourself, anything that's set V, or anything (except another player) you can link to; also, royalty, wizards, and gods can exmaine anything. &&& get get (minimum abbreviation: ge) get Picks up the object, moving it from the room to your inventory. You may not be able to pick the object up, if it's locked. &&& give give (minimum abbreviation: gi) give = Gives the specified amount of money to another player. (Wizards may create money with this command, or destroy it by specifying a negative amount, can give money to things as well as players, and do not have their own money supply affected when they "give" money.) &&& goto goto (minimum abbreviation: go) goto Takes the exit named . In most cases, this is equivalent to just typing ; the exception is when is a built-in command, like "help", in which case the "goto" command can be used to activate the exit rather than the builtin. &&& gripe gripe (minimum abbreviation: gr) gripe Saves the in a gripe file for perusal by the management. &&& help help (minimum abbreviation: h) never reached &&& inventory inventory (minimum abbreviation: i) Lists your inventory (the things you're carrying), and the amount of money you have. &&& kill kill (minimum abbreviation: k) kill [=] Attempts to kill . Costs either or $10, whichever is greater; the probability of success is percent, unless the victim is a wizard; wizards are immune to being killed. (Thus, spending $100 always works, assuming of course the victim is not a wizard.) See "help being-killed" for more information. You cannot kill anyone if you're in a room set H(aven). &&& look look (minimum abbreviation: l) look [] Shows the description of ; if no object is named, looks at the room you're in. &&& man man (minimum abbreviation: ma) man [] Shows documentation on the MUF primitives. Use "man" by itself for an introductory page. Anyone may use this command, though the information is not normally useful except to wizards and players set M(ucker). &&& move move (minimum abbreviation: mo) Same effect as "goto". &&& news news (cannot be abbreviated) news [] Shows an entry from the news file. Just like help and man except that the data file used is different. &&& page page (minimum abbreviation: pa) page [=] Sends the to the . If is omitted, sends an invitation to the to come to the room you're in. &&& pose pose (minimum abbreviation: po) pose : ; Everyone in the room with you sees prefixed with your name. For example, if you were named Igor, and you typed ':falls down.', everyone in the room would see "Igor falls down." &&& put put (minimum abbreviation: pu) Same effect as "drop". &&& read read (minimum abbreviation: re) Same effect as "look". &&& rob rob (minimum abbreviation: ro) rob Attempts to steal one dollar from . (The only thing you can steal is money. Being robbed can be prevented (see "help robbing").) &&& say say (minimum abbreviation: sa) say " ' Says to everyone in the room. For example, if you were named Igor, and you typed '"Hi everyone', everyone in the room would see 'Igor says, "Hi everyone"'. &&& score score (minimum abbreviation: sc) Shows how much money you have. &&& take take (minimum abbreviation: ta) Same effect as "get". &&& throw throw (minimum abbreviation: th) Same effect as "drop". &&& whisper whisper (minimum abbreviation: whi) whisper = Whispers to . No one else can see the message. The player you're whispering to must, of course, be connected and in the same room (except that wizards can whisper to people in other rooms). &&& who who (cannot be abbreviated) who [] List the name of every player currently logged in, and how long they have been inactive. If given a player name, it displays information for just that player. &&& flags There is a flag bit for each letter of the alphabet. Flag names vary depending on the type of the object they're set on, and in some cases, on other flag bits: Room Thing Exit Player Program Daemon Other +------------------------------------------------------------------------- A | . . (1) Author . . Abode B | * * * (2) Builder * * C | . . . . . . Chancellor D | Dark Dark Dark Dark Debug * * E | * * Exact * * * * F | * * FullName FollowStatus FinalStack * * G | . . . . . . God H | Haven * Hear Haven * * * I | InContents * Individual Interactive * Interactive * J | . . . . . . Jump_OK K | . . . . . . Keep L | . . . . . . Link_OK M | * * * (3) Mucker * * N | NoInventory * Noisy NoInventory * * * O | . . . Observe . . Ownable P | * * Prefix * * * * Q | . . . . . . Quell R | . . . . . . Royal S | Sticky Sticky Sticky Silent SetUID * * T | Tap * * Tap * * * U | * * Unconnected Unseen Unlistable Unkillable * V | . . . . . . Visual W | * * * * * * * X | * * * * * * * Y | * * * * * * * Z | * * * * * * * * means the name is formed by suffixing "Flag" to the flag letter (eg, BFlag for the B row). Such flags have no semantics defined by the server. . means "the same as the Other column". (1) A on an exit is Abode, unless the exit is set Chancellor as well, in which case A is Autostart. (2) B on a player is Builder, unless the player is set Chancellor as well, in which case it's Busy. (3) M on a player is Mucker, unless the player is set Chancellor as well, in which case it's Monitor. Each flag name has its own help entry; for example, "help dark" will describe the semantics of the D bit when it's called Dark. &&& abode The A(bode) flag on a room allows anyone to set a player's or object's home to that room, or to set rooms' parents there, with @dig or @teleport. &&& author The A(uthor) flag on a player means the player will be shown the owners of objects (such as rooms and things). For example if Pat is set A and is in a room called "Living room" and owned by Joe, Pat will see "Living room(Joe)" instead of just "Living room". If the room's dbref is #1234, and Pat can see it (because Pat's a wizard, or the room's set A(bode), or any other reason), then Pat would see, for example, "Living room(#1234R Joe)" instead of "Living room(#1234R)". &&& autostart At startup time, the server scans all exits in the db. If any exit is set both C(hancellor) and A(utostart), and its first linked-to thing is a program, the program is run. If the exit has an _autostart: property, its value is passed to the program as an argument; otherwise, "" is passed. (A on a non-C(hancellor) exit is A(bode), but has no semantics to the server.) &&& builder The B(uilder) flag on a player or program allows that player/program to use the builder operations to create new things. Specifically, the @open, @dig, @create, @action, and @attach commands do not work except when the player is set B(uilder) (or R(oyal) or C(hancellor)); the same applies to @link when used to seize an unlinked exit owned by someone else. Similarly, the MUF primitives copyobj, create, dig, open, unlink, and addlink do not work unless (a) the effective player (see "man") is set B(uilder) (or R(oyal) or C(hancellor)), or (b) the program is set C(hancellor) and not Q(uell) and its owner is set C(hancellor), or (c) the program is set B(uilder). &&& busy When a player is set C(hancellor), the meaning of that player's B bit changes from B(uilder) to B(usy). Wizards always have builder privileges, so the B bit is unnecessary to indicate B(uilder) status. B(usy) has no semantics to the server. &&& dark The D(ark) bit on a room, thing, exit, or player suppresses various messages. Specifically: - When a player connects or disconnects, if the player, or the room the player is in, is set D(ark), connection messages due to the O(bserve) bit are generated as if the player were not in the same room as the player receiving the message, even if they are actually in the same room. The " has [dis]connected." message to others in the same room is also suppressed. - When a player looks at another player or a room, if the looked-at object is set D(ark), its contents are not shown (unless the looking player controls it and is not set S(ilent) - see "help control"). - When a player moves from one room to another, the " has left" message is suppresed if the old room or the player is D(ark), or if the player left via an exit that's set D(ark). Similarly, the " has arrived" message is suppressed if the new room or the player is D(ark), or if the player moved via a D(ark) exit. (Other circumstances also control these messages; see the N(oisy) bit and "help success".) - When a player moves via an exit linked to a room or player, the exit's @odrop message, if any, is suppressed if the player being moved is set D(ark). - When a player fails to use an object (see "help failure"), the object's @ofail message, if any, is suppressed if the player is D(ark). Similarly, when a player succeeds in using an object (see "help success"), the object's @osuccess message, if any, is suppressed if the player is D(ark). - When a player looks at a player or room and would normally see the contents of the looked-at object, D(ark) objects not controlled by the looking player are not shown (see "help control"). &&& debug When a program is set D(ebug), a line of output is generated for each cycle of the MUF p-code interpreter. Normally, this output is sent directly to the player running the program, or if there is no such player, to the owner of the program. However, if the program is set M(ucker), the output is sent as if by the MUF notify primitive (in particular, it can be heard by H(ear) exits). (Output from the MUF pstack primitive is sent using the same algorithm.) &&& exact Normally, exit names are matched against command verbs in a case-insensitive way. The E(xact) bit on the exit changes this so that the match is performed in a case-sensitive way; the command input must be capitalized exactly the same as the exit name. &&& finalstack When a program is set F(inalStack), if it gets an interpreter error, one line of debug output is generated for the primitive that produced the error, just as if the program had been set D(ebug) for that one p-code interpreter cycle. &&& followstatus When a player is set F(ollowStatus), all messages written to the status log (the logs/status file) are also sent to any connections that player has active. &&& fullname When an exit is set F(ullName), semicolons in its name are simply part of the exit name, rather than having their usual meaning of delimiting alternative names for the exit. &&& god When a player is set G(od), that player has access to a few administrative functions of the muck (such as @shutdown) and immunity to a few more (such as @toad or @newpassword by players not also set G(od)). One player, dbref #1, has additional privileges. #1 always has the powers of a god, even if its G bit is not actually set, cannot be @toaded under any circumstances, and has a few other functions such as certain types of debugging output. A G(od) bit does not grant all the powers of a C(hancellor) bit, notably the implicit M(ucker) and B(uilder) powers, but since a player set G(od) can always turn hir own C(hancellor) bit on, this does not actually restrict a god's capabilities. &&& haven H(aven) has two functions: (1) no-one can use the kill command while in a room set H(aven), and (2) the page command will not send a message to a player set H(aven). &&& hear When an exit is set H(ear) and attached to a player, thing, or room, any message sent to that player, or sent to everyone in the room the thing is in, or sent to everyone in the room or any room contained therein, then any programs the exit is linked to are run with the utterance passed as the top-of-stack string. If the exit has an _delay property, the execution will be delayed by that many seconds; if the _delay property is nonexistent or gives a number less than 1, 1 second will be used. The program is always run in the context of a daemon created for the purpose. &&& incontents Normally, when looking at a room's contents, other rooms are not shown. But if one of the contained rooms is set I(nContents), it will be shown. &&& individual When an exit that is linked to multiple things is triggered, normally, all the link-tos are processed. But if the exit is set I(ndividual), one of the link-tos is chosen at random and the rest are ignored. (The name is a bit of a stretch; all the obvious bit letters for this functionality were already taken for exits.) &&& interactive The I(nteractive) flag on a player indicates that the player is currently editing or running a program. Daemons are normally set I(nteractive) all the time, since they're always running programs. This flag is automatically set and cleared by the server; it is not controllable the way other flag bits are. It exists largely so that who-list programs can test it to indicate players that are editing or running programs. &&& jump_ok The J(ump_OK) flag on a player is required for exits linked to that player to work. It also can be set on various things to relax requirements for the MUF moveto primitive; see "man moveto" for details. &&& keep The K(eep) flag on a dbref prevents that dbref from being recycled (or, if the dbref is a player, @toaded). It takes a wizard to set or unset the Keep bit on anything. (This is not absolute; for example, if a Keep exit is attached to a non-Keep object, and the object is recycled, the exit will go with it despite the Keep bit.) &&& link_ok The L(ink_OK) flag on an object allows anyone to link exits to it, or in the case of programs to @list it or use MUF call to call it. If a player is set L(ink_OK), anyone may also set a thing's home to that player. &&& monitor When a player is set C(hancellor), the M bit changes its meaning from M(ucker), which is redundant since wizards always have programmer privileges, to M(onitor). When this bit is set, the player will be informed every time the database is checkpointed and whenever anyone uses @user successfully. &&& mucker The M(ucker) bit on a program has meaning as described under the D(ebug) bit (see "help debug"). On a player, it allows the player to use the @edit and @prog commands. &&& noinventory The N(oInventory) bit on a player or room suppresses the normal contents list when someone looks at that player or room. &&& noisy The N(oisy) bit on an exit causes the " has left" message due to players taking that exit to be printed even if the exit has an @osuccess message; similarly, the " has arrived" message is printed even if the exit has an @odrop message. Also, when an exit is triggered because it is linked to by another exit, its @succ is normally ignored; if the linked-to exit is set N(oisy), the @succ works as normal. (Other messages, such as @drop and @osucc, are still ignored.) &&& observe When a player connects or disconnects, all players set O(bserve) are sent a message saying so. &&& ownable When an object is set O(wnable), anyone can use @chown or the MUF chown primitive to take ownership of it. &&& prefix Normally, an exit name must match the typed command in full in order to trigger the exit. When an exit is linked to a program, this is relaxed; the exit name must appear at the beginning of the command, but can be followed by whitespace and an argument. If the exit is set P(refix), the whitespace is not required. (This affects only exits linked to programs.) For example, an exit called "foo" and linked to a program would normally match the typed command "foo twelve", but not "food please". If the exit were set P(refix) as well, it would match either command. Note that one space character is stripped in the usual case, but not in the P(refix) case; the argument strings in the example would be " twelve" and "d please". This is intended largely for non-alphabetic exit names, such as : or +, but it is not restricted to that. &&& quell When a player's Q(uell) bit is set, any privilege that player has due to a R(oyal), C(hancellor) or G(od) bit is mostly suppressed. Some privilege still remains; for example, a program set C(hancellor) and owned by a C(hancellor) player still has wizard powers if its owning player is set Q(uell) (though the _program_ can be set Q(uell) to quell its privilege). &&& royal The R(oyal) bit grants many of the powers of a C(hancellor) bit, but not all. It does not grant automatic builder or programmer privileges, for example, nor does it permit setting or clearing flag bits that the player could not set or clear without the R(oyal) bit. What it does grant is the ability to use the # and * syntax for naming objects and players from a distance, and wizard-like ability to use several @ commands, such as @teleport and @chown. This is intended for "help-staff" use. &&& setuid When a program is set S(etUID), it runs as the owner of the program rather than as the player who invoked it. &&& silent When a player is set S(ilent), that player sees things as if someone else owned them, regardless of who actually does. (It is actually slightly more powerful than this; S(ilent) will suppress showing dbrefs and flags even for objects set V or O.) &&& sticky The S(ticky) flag on a thing means that the thing will go to its home when dropped, rather than to the room the dropping player is in. If a room is S(ticky), its drop-to, if any, will be delayed until there are no players in the room (see "help drop-tos"). If an exit is S(ticky) and is attached to an object, then when the exit is activated, the source object doesn't move; without the S(ticky) bit on the exit, the source object would be sent to its home. &&& tap If a player is set T(ap), that player sees a filtered version of the muck's command log. The filtering is controlled by the .t_filter: property on the player; this contains a list of dbrefs of players whose command output is of interest. If a room is set T(ap), nothing happens unless it's #0, in which case it controls sending the command log to disk via its .t_filter: property similarly. &&& unconnected If an exit is attached to #0 and set U(nconnected), it can be invoked by connections that have not yet connected to a player. (The only type of linked-to object that works for this mechanism is a program. The exit's lock is ignored.) &&& unkillable If a daemon is set U(nkillable), it cannot be destroyed by @kill or the MUF kill primitive, unless invoked by a wizard. &&& unlistable If a program is set U(nlistable), it cannot be listed, unless the player trying to list it is a wizard and the program owner isn't. &&& unseen When a player is set U(nseen), that player does not show up on the who-list. &&& visual When an object is set V(isual), it can be "examine"d by anyone. &&& chancellor When a player is set C(hancellor), that player is called a wizard, and has extra powers and immunities. These are too widespread to list here; they are mentioned elsewhere when appropriate (for example, how wizard status interacts with the "kill" command is described under "help kill"). &&& properties Every object has a property list. Properties are just name/value pairs, where the names and values are strings. These are manipulated with the @set command and the addprop and remove_prop MUF primitives, and can be inspected with the examine or @properties commands or the getpropstr, propfirst, propnext, and prop-exists? MUF primitives. The first character of the property name string is special; it controls permissions on the property. It can be anything, but if it's one of the five characters _ . * @ ~ then it has special meaning. If it's not one of those, the property is an ordinary one: the owner of the object or any MUF program can add/remove/inspect it as described above. These five characters have rough meanings as follows: _ read-only . private * MUF-only @ wizard-only ~ wizard-only to modify; unrestricted to read The restrictions on property use imposed are as follows: - When checking a property lock, if the property is an @ property, the lock always fails unless the object whose lock is being tested is set C(hancellor). (Q(uell) does not affect this.) - When printing property lists for the @properties or examine commands, any * or @ properties are not listed unless the examining player is a wizard. - @set cannot affect *, @, or ~ properties unless issued by a wizard. - "@set =:" will not remove *, @, or ~ properties, even when issued by a wizard. - "@set =*:", "@set =@:", and "@set =~:" will, provided the issuing player is a wizard, remove all properties of the specified kind. - @set cannot create properties named "@", "*", or "~". - MUF getpropstr does not function for @ properties except for wizard programs, and does not function for . properties unless the program is a wizard programs or the effective player owns the object. - MUF remove_prop does not function for @ or ~ properties except for wizard programs, and does not function for _ or . properties unless the program is a wizard programs or the effective player owns the object. - MUF addprop, addprop-if, and remprop-if do not function for properties named "@", "*", or "~", do not function for @ or ~ properties except for wizard programs, and do not function for _ or . properties unless the program is a wizard programs or the effective player owns the object. - MUF prop-exists? always returns 0 for @ properties, unless the program is a wizard program, and for . properties, unless the program is a wizard program or the effective player owns the object. - MUF propfirst/propnext skip any @ properties, unless the program is a wizard program, and any . properties, unless the program is a wizard program or the effective player owns the object. &&& names When referring to an object, you normally use its name. However, this works only when you are naming (a) something you are carrying, (b) something in the same room as you, (c) an exit attached to yourself, (d) an exit attached to something you're carrying, (e) an exit attached to a thing in the same room as you, or (f) an exit attached to the room you're in or any of its parents (see "help environments"). In some circumstances, you can refer to objects by dbref number, by prefixing the number with a # (as in "@link out=#1234"). In a few circumstances, you can refer to players that aren't in the same room as you by prefixing the player name with a * (as in "@lock south=*joe|*betty"). There are also two special names: "me" and "here"; "me" refers to yourself, and "here" to the room you're in. Royalty (and wizards and gods) can use the # and * syntax almost anywhere a dbref name is accepted. &&& drop-tos Rooms potentially have drop-tos. You can set a room's drop-to with @link and remove it with @unlink. When a thing is dropped in a room and the room has a drop-to, the thing actually goes to the drop-to room instead. (If the room is set S(ticky), the thing goes to the room, but when the last player in the room leaves, all things still in the room are moved to the drop-to room.) &&& robbing When you use the "rob" command on someone, you succeed or fail to use them (see "help success" and "help failure"), depending on whether you pass the victim's lock (see @lock). Thus, for example, you can prevent anyone else from robbing you with "@lock me=me". (This allows you to rob yourself, which is not useful in monetary terms but does set off your @succ and @osucc messages - see "help success".) &&& actions Actions, also called exits, are what make things happen. An exit is always attached to some object and is linked to zero or more objects. (If it's linked to no objects, it is not usable and can be linked by any builder, who gets ownership of it in the process. This is not normally used.) Since one frequently wants many different names to produce the same result ("e", "east", "out", "street", and "door", for example), an exit's name is treated specially when comparing it against typed commands. It is split at ; characters and the effect is as though each resulting piece were the name of an identical exit. (If you _want_ a ; in the verb, check out the F(ullName) flag bit.) See "help linking" for more details. &&& name-prefix When looking for something with a given name, many things use similar matching rules. These rules apply to object names for when matching things for @contents, @exits, @find, and @owned, and to property names for @properties. They also apply when referring to existing things (but not exits) for commands like "get". Given a name and the entered pattern, the rule works as follows. First, see if the pattern is a prefix of the name. If so, the pattern matches. If not, the name has any leading alphanumeric characters (letters and digits) stripped off, then any following non-alphanumeric characters, and the test is repeated. This continues until either a match is found or the name is exhausted; if the latter, the pattern does not match and the command continues looking for something else that does match. &&& @-messages An object has seven messages associated with it. They are usually referred to by the (abbreviated) names of the commands used to set/clear them: @desc, @drop, @succ, @fail, @odrop, @osucc, and @ofail. The @odrop, @osucc, and @ofail messages are all used in a very similar way: when one of these messages is to be shown, the name of the affected player is prefixed to it, and the result is shown to everyone in the destination room, except the affected player. %-sign substitutions (see "help substititions") can be used in these messages, but the @ syntax below cannot. The @desc, @drop, @succ, and @fail messages are all similar in another way: one can use them to run programs rather than simply generate messages. If the string begins with an @ sign, followed by a number which is the dbref of a program, the program is run with any following text as its argument, rather than printing the message. For example, if an exit had a message set with "@succ =You look that way", then when the exit was triggered, the triggering player would be told "You look that way". But if the message were, instead, set with "@succ =@1234 choose", then (provided #1234 is a program and it can be run), then rather than sending a message to the player, the server would run program #1234 with "choose" as its argument string. The program could then generate messages if it so chose. This facility is most often used in @desc strings. &&& environments Every room has a parent, except the global environment room #0, which has no parent. The server enforces a strict hierarchy; it is possible to change a room's parent, but it is not possible to change it in such a way as to put a room inside itself. This means that if you start from any room and successively follow the "location" pointers, you will eventually end up at #0. The server does effectively this when a player issues a command: it searches exits on the player, on everything in the player's inventory, on all things in the same room as the player, and on the room itself. If all these fail to produce a match, it then starts walking up the room hierarchy, checking the list of exits attached to each room in turn, until it finds a match (in which case that exit is triggered) or it gets all the way to #0 and still finds no match (in which case an error message is printed). This makes it possible to provide commands which work over entire areas, by putting the whole area under a common parent room and attaching the relevant exit to that parent. (This is how "global" exits are usually implemented: by attaching them to #0, they are accessible from anywhere, unless of course the name matches an exit found earlier in the search.) &&& success You use an object successfully when you pick it up (with "get" or "take"). You use an exit successfully when you trigger it (go through it). You use a person successfully when you rob hir (and it works). You use a room successfully when you look at it. Using something successfully shows you the object's @succ message and shows everyone else in the same room as you its @osucc message (see "help @-messages" for more). &&& failure You fail to use an object when you try to pick it up (with "get" or "take") but can't because its lock fails. You fail to use an exit when you try to trigger it but can't because its lock fails (or it's not linked to anything). You fail to use a person when you try to rob hir but can't because hir lock fails. You fail to use a room when you try to look at it but can't because its lock fails. Failing to use something shows you the object's @fail message and shows everyone else in the same room as you its @ofail message (see "help @-messages" for more). &&& homes Every thing or player has a home. For players, this is always a room; for things, it can be either a room or a player. This is where players go when they go home or are killed, where things set S(ticky) go when they're dropped or the player who's carrying them is killed. A thing's or player's home is changed with @link. When a player is first created, its home is #0; when a thing is first created, its home is the player who created it. You can use "home" as a place in a few contexts, such as the target of @teleport, or as somewhere to link an exit to (eg, "@link =home"). Drop-tos can also be set to "home" (see "help drop-tos"). &&& being-killed Getting killed is no big deal, unlike combat-based muds. If you are killed, you return to your home, and all things you are carrying at the time return to their homes. You also collect $50 in life insurance. &&& dropping The @drop and @odrop messages on a thing are shown when it is dropped (the @drop message to the player who dropped it, the @odrop to everyone else in the room). The @drop and @odrop messages on an exit are shown when someone goes through it (the @drop to the player taking the exit, the @odrop to everyone else in the destination room). The @drop and @odrop messages on a player are shown when the player is killed (the @drop to the player who did the killing, the @odrop to everyone else in the room at the time). The @drop and @odrop messages on a room are used when something is dropped in that room; first the thing's own @drop and @odrop messages are generated, then those for the room. &&& goal Goal? There isn't one, except to have fun. If you're not having fun, quit. Have fun. &&& substitutions @osucc/@ofail/@odrop messages may contain %-substitutions, which evaluate to gender-specific pronouns if the player's gender is set. These are as described in "man pronoun_sub". These should always be used rather than putting specific pronouns (eg, "his") into the string. &&& locks Any object can be locked. When you try to use an object, the lock controls whether you succeed or fail (see "help success" and "help failure"). (If the object is unlocked (see "help @unlock"), attempts always succeed.) There are three types of lock: (1) a dbref, (2) a property name/value pair, and (3) a boolean expression. Expressions are formed with & (and), | (or), and ! (not) as operators, with ( and ) for grouping. Arguments to the boolean operators can be of any of the three types; expressions can get arbitrarily complicated. A lock of type (1) is written as the dbref's name (see "help names"), with the # and * syntaxes accepted. A lock of type (2) is written as name:value. Neither the name nor the value can contain operator characters like &. A lock to a dbref succeeds or fails depending on the type of the dbref. If the dbref is a program, the program is run to test the lock; see "help program-locks" for details. If the dbref is any other type, the lock passes if (a) the object that's trying to pass the lock (the "passer") is the locked-to object, (b) the passer's location is the locked-to object, or (c) the passer is a room or player and it contains the locked-to object. A lock to a property succeeds if the passer has the specified property with the specified value, or if the passer is a room or player and contains an item having the specified property with the specified value. A boolean expression lock succeeds if the expression is true, where the sub-expressions are considered true if they succeed and false if they fail. &&& program-locks When a lock expression involves a program dbref, the program is run to test the relevant condition. The expression is true (the lock succeeds, for lock expressions that are just simple dbref references) if the top-of-stack value when the program exits is true; false, if false. A program can tell it is being run to test a lock because command @, which is normally a string, is instead a one-element array holding the string "lock". The program is supplied with a string onj the top of the stack; normally, this is "", but a string can be provided in the lock expression by writing a ' and the string immediately after the object reference in the lock expression. (There is no provision for escapes; this means that characters which terminate object names in a lock expression - &, |, ) - cannot appear in the parameter string; take this into account when designing lock program interfaces. Also, a ' cannot appear in a dbref name as used in a lock expression; since any dbref can be named using the #nnn syntax, this does not restrict what expressions are possible, only how they can be written.) The parameter string syntax described above is actually accepted for any dbref reference in a lock expression, but (at least as of this writing) the parameter string is ignored for non-program dbrefs. &&& control There are three rules to controlling objects: 1) You control anything you own. 2) A wizard controls anything. 3) Anybody controls an unlinked exit, even if it is locked. &&& linking Exits (also called actions) can be linked to objects (see "help actions" for an overview). What happens when the action is triggered depends on various things. There are several possibilities, classified based on what type of object the action is attached to and what type of object it's linked to. (An action can be linked to multiple objects; in this case, by default, triggering the action functions as if a separate action, attached to the same place and linked to each linked-to object, were triggered. See the Individual flag for an alternative to this.) There are some restrictions; in particular, at most one of an exit's links can be to a room or player. room->room thing->room player->room Moves the activating player to the destination room. When attached to a room, this is the commonest (and oldest) kind of exit. room->thing Brings the linked-to thing into the source room. room->player thing->player player->player Moves the activating player to the room the linked-to player is in. (The linked-to player must be set J(ump_OK) for such an exit to function.) player->thing Moves the destination object into the source player's inventory, regardless of who triggers the exit. (Normally, an exit attached to a player can be triggered only by that player, but a wizard can explicitly trigger any exit, and metalinks can lead to an exit being triggered indirectly.) thing->thing The destination thing is moved to the location the source thing is in. If the exit is set S(ticky), that's all that happens, but if not, then the source object is moved to its home. room->program thing->program player->program The program is run. room->exit thing->exit player->exit Triggers the linked-to exit, but if the linked-to exit is itself linked to a room or player, that link will be ignored (any other link destinations will function as normal). These can be chained to any depth, but an attempt to link an exit so as to create a loop will produce an error. This is called a meta-link. NOTE: the lock on the linked-to exit, if any, will be ignored, as if the linked-to exit were not locked. Also, any messages (eg, @succ) on the linked-to exit are normally ignored, though setting the linked-to exit Noisy will cause @succ (but no others) to function. Exits cannot be attached to programs, daemons, or exits, nor can they be linked to daemons. When searching for an exit to match a typed command, the server treats exits which are (directly) linked to programs as special: it does not require that the exit name match the entire command, but only that it match a prefix of it. (See "help prefix" for more details.) When a matching exit is found, any portion of the command line after the part that matches the exit name is passed to the program as its initial string. (If the program is found via a meta-link, this does not apply; the command must match the original exit in full, and the program is passed "" as its initial string.) See "link-examples" for some examples. &&& link-examples [ Extracts chosen and slightly edited by der Mouse, taken from a document written by Garrett (durrell@hus4.harvard.edu) for TinyMUCK 1.1. Still contains worthwhile information. ] Here's an example: suppose we have three objects ("egg", "eggshell a", and "eggshell b"), a room ("storage room"), and three links ("open egg", "fix egg", and "exit a"), arranged as follows: +-----+ open egg +------------+ exit a +--------------+ | egg | ------------+--> | eggshell a | <---------- | storage room | +-----+ | +------------+ ^ +--------------+ ^ | | | | +------------+ +----+ | +--> | eggshell b | -----------+--+ | +------------+ fix egg | | | +--------------------------------------------------+ That is, we have three exits, as follows: exit name source destination(s) open egg egg eggshell a, eggshell b fix egg eggshell b exit a, egg exit a storage room eggshell a Suppose also that "eggshell b" has its home set to the storage room. Then, suppose you're holding the egg and you type "open egg". Then the egg goes away (because "open egg" is not set S(ticky)) and "eggshell a" and "eggshell b" appear in your inventory (because thing->thing exits summon the destination things to the place the source thing started out). So, then, suppose you type "fix egg". Then the egg appears, because a thing->thing exit works that way. Also, eggshell b disappears, because "fix egg" is not S(ticky), so eggshell b is sent home. But "fix egg" is *also* linked to "exit a". So "exit a" is activated, and room->thing exits summon the thing into the room, so eggshell a also vanishes from your inventory into the storage room, and you're left with the original egg. How would you set all this up? Suppose you've already dug the storage room, and are standing in it. Then you might proceed as follows, where >> marks lines you type: >> @create egg egg created with number 1876. >> @create eggshell a eggshell a created with number 1890. >> @create eggshell b eggshell b created with number 1896. >> @link eggshell b=here Home set. >> @link egg=here Home set. >> @action open egg=egg Action created with number 12429 and attached. >> @link open egg=eggshell a;eggshell b Linked to eggshell a(#1890). Linked to eggshell b(#1896). >> @action exit a=here Action created with number 12436 and attached. >> @link exit a=eggshell a Linked to eggshell a(#1890). >> @action fix egg=eggshell b Action created with number 12460 and attached. >> @link fix egg=egg;exit a Linked to egg(#1876). Linked to exit a(#12436E). At this point you would be carrying all three objects. This doesn't really matter, since as soon as either "open egg" or "fix egg" is triggered, all three objects get moved to their correct positions. Note that this example has some problems. You can, for example, drop eggshell a and walk away from it and "fix egg" will still work, which it perhaps shouldn't (because you have only half the egg), and if you leave eggshell b behind, "fix egg" won't be recognized at all. These could be solved by adding more exits, with appropriate locks, but in the interest of keeping this example simple, the result isn't described here.