This section provides a quick reference for user-created commands
supplied in the standard start-up database (std-db.db). On many
MUCKS, several or many of these programs will have been
modified or replaced with versions that are either more recent or more
specifically attuned to the needs of the MUCK. So syntax
may very slightly, but you can reasonably expect to find a command that
offers similar functionality. An established MUCK will
have many other user-created commands besides these.
@ARCHIVE | @ARC
@archive <object>
The archive command essentially `decompiles' an object, outputting
all commands and settings that would be necessary to recreate the
object. The output is simply printed to your screen: it is not saved in
some archive on the MUCK. In order to use an
@archive dump, you will need to capture the output, by
cutting and pasting, logging with a client, or some other means, and
save it to a file on your own computer.
The archived object can then be recreated by quoting or pasting the
file into a MUCK window. The most common uses of archive
dumps are porting objects between MUCKs or keeping a
back-up copy offline to safeguard against loss or corruption of the
MUCK's dbase.
The @archive command is recursive:
<object> and anything contained by
<object> will be archived. Thus, for example, an
entire area can be dumped to an archive file by archiving the parent
room: all rooms, exits, things, and programs in the area that are owned
by the archiving player will become part of the dump.
For non-wizzes, @ wiz props will not be part of the
dump. Restricted props (props that begin with a ~ tilde)
will be included in the dump, but will not be recreated when the archive
is quoted, unless the player is a wizard at that time. Also, exits
leading to and from archived rooms or areas cannot be linked when the
archive is quoted (though exits within an archived area can). It is
normal to see various `Huh?' and `Permission
denied' messages when recreating an object from an archive
dump.
MPI and MUF that contains hard-coded dbrefs
create another portability concern. A dbref, naturally, refers to a
specific object on a specific MUCK. The corresponding
object on a different MUCK will have a different dbref. To
some extent, this problem can be reduced by using pointers and
registered names when building, describing, coding, etc. For example,
if you (player #123) used a personal version of
{look-notify} ...
{null:{tell:[ {name,me} looked at you. ],#123}}
... the code would result in a `Permission denied' error
if you recreated yourself on another MUCK via an archive
dump. This could be avoided with either of the following versions:
{null:{tell:[ {name,me} looked at you. ],this}}
{null:{tell:[ {name,me} looked at you. ],*Jessy}}
Recreating objects from archive dumps usually sets temporary
registered name values on your character, in propdir
_reg/tmp. It is not necessary to do anything with this
directory, but to conserve dbase space, you might want to remove it
after doing a large dump: @set me = _reg/tmp: [top]
@BANSITE
@bansite sitename (Prevents logins from the given site)
@bansite !sitename (Re-allows logins from the given site)
@bansite #list (Lists all the sites that are banned)
This command prevents anyone from logging onto the MUCK
from a banned site. Along with @toad, it is used to prevent
problematic players from connecting to the MUCK. For
example, a player might be toaded for violations of the
MUCK's acceptable use policy, but continue to log on via
guest and alternate characters. @Bansite prevents this by
locking out connections from a given site regardless of the character.
Sites may be specified by host name or numeric address. Wildcards may
be used in the site name and address. Wildcards are frequently
necessary, since many ISP's use dynamic host names for
customer's connected via SLIP or PPP
connections. For example, an examination of a problematic player's
@/ directory might show that the last host used was:
user12.vnn.luser.com
Doing @bansite user12.vnn.luser.com would be
ineffective: in all likelihood, the first one or two sections of the
hostname would different the next time the player logged on. In lieu
of...
@bansite user12.vnn.luser.com
... one should do:
@bansite *vnn.luser.com - or -
@bansite *luser.com
@Bansite has two disadvantages: it locks out other
players who connect from the same site, and it offers no protection
against players who you want to ban but can log on from alternate sites.
(Wizard only) [top]
CHANGE
change <object>=<propname>:/<old>/<new>
- or -
change
<object>=<mesgtype>;/<old>/<new>
Edits a property or message, replacing string
<old> with string <new>. The
syntax varies slightly — that is, it uses either a : colon or ;
semi-colon delimiter — for messages and properties. `Messages'
are `name', `desc', `succ', `osucc', `fail', `ofail', `drop', and
`odrop'. Examples:
change here=_arrive/check:/444/445
change me=desc;/top hat/beret
[top]
EDIT
edit <object> = <prop> or,
edit <object> = @<mesgtype>
This unusual and useful command is works only with the TinyFugue
UNIX client. Entering the command and parameters pulls the
value of <prop> or <mesgtype> into
your client window, with the cursor positioned for editing. You can then
use arrow keys, backspace, etc., to edit the property value. Pressing
`enter' stores the new property value. <Mesgtype> can
be `name', `desc', `succ', `osucc', `fail', `ofail', `drop', or
`odrop'.
Before using edit, you must define the following
TinyFugue macro:
/def -fg -p100 -t"##edit> *" = /grab %-1
Like most TinyFugue settings, this setting is `volatile'... It is not
retained between TinyFugue sessions. To avoid having to redefine it each
time, put the definition line in TinyFugue's resource file, .tfrc, so
that it will be defined each time you start the client. [top]
PROPCP | CP
cp <object 1>=<prop 1>,<object 2>=<prop
2>
Copies <prop 1> and its value from
<object 1> to <prop 2> on
<object 2>. This example copies the @succ of exit
`out' to another exit:
cp out=_/sc,#1344=_/sc
Propcp handles partial input well. If <object
1> is omitted, it assumes <prop 1> is on
the user. If <object 2> is omitted, it assumes the
destination object is the same as <object 1>...
i.e., that you are copying from one prop to another on the same object.
If <prop 2> is omitted, is assumes that it is the
same as <prop 1>... i.e., that you are copying a
property on one object to the same property on a different object. If
more information is omitted, the program will ask for it. Rather than
providing all — or even any — of the information on the
command line, one can simply type cp, and respond to prompts. You must
control both objects. See also propmv,
below. [top]
PROPMV | MV
mv <object 1>=<prop 1>,<object 2>=<prop
2>
Moves <prop 1> and its value from <object
1> to <prop 2> on <object
2>, erasing <prop 1>. This example moves
the fail message on `out' to the ofail:
mv out=_/fl,out=_/ofl
Propmv handles partial input well. If <object 1>
is omitted, it assumes <prop 1> is on the user. If
<object 2> is omitted, it assumes the destination
object is the same as <object 1>... i.e., that you
are moving a value from one prop to another on the same object. If
<prop 2> is omitted, is assumes that it is the same
as <prop 1>... i.e., that you are moving a property
on one object to the same property on a different object. If more
information is omitted, the program will ask for it. Rather than
providing all — or even any — of the information on the
command line, one can simply to mv, and respond to prompts.
You must control both objects. See also propcp, above. [top]
read | Show the headers of all posted messages.
|
read new | Show headers of all messages less than 2 days old.
|
read recent | Show headers of all messages after last read messages.
|
read <keyword> | Show headers of all messages with matching <keyword>.
|
read -<days> | Show headers of all messages fewer than <days> old.
|
read <mesgnum> | Read the message referred to by the given message number.
|
read - | Read the next message, after the last one you read.
|
read -recent | Read all messages after last read message, in one continuous stream.
|
write | Post a message. Prompts for subject and keywords.
|
write <subject> | Post a message with given <subject>. Prompts for keywords.
|
write <subject>=<keywords> | Post a message with given <subject> and <keywords>.
|
erase <message num> | Lets message owner erase a previously written message.
|
editmesg <message num> | Lets message owner edit a previously written message.
|
protect <message num> | Lets a wizard protect a message from auto-expiration.
|
[
@REGISTER | @REG
@reg <object> = <registered name>
@reg #me <object> = <registered name>
@reg #prop <target object>:<propdir> <object> =
<registered name>
Sets a registered name for <object>. (See Section 2.1.5 for more information on
registered names).
The default format, @reg <object> = <registered name>, creates a global registered name by setting property _reg/<reg name> on room #0 with the value of <object's> dbref. Because a property is being set on room #0, this will result in a `Permission denied' error for a mortal player (unless she happens to own room #0). The following example, which would be typed by a wizard, gives the gen-nothing program the registered name of nothing; players would then be able to link actions to it by typing @link <action> = $nothing
@reg gen-nothing = nothing
Registered names can be set on your character rather than on room #0,
in which case they will be be meaningful only for you, by using the
#me argument. The following example, which could be typed
by a mortal, or by a wizard who wants to create a personal registered
name, gives a puppet object the registered name `pup'. It could then be
specified by $pup, rather than its dbref, as in @tel
$pup = me.
@reg #me squiggy = pup
You can over-ride the target propdir, from _reg/ to
anything else, by using the #prop argument. If the target
propdir does not begin with _reg/ , the setting will not be
usable as a registered name; this would simply be a way to set a
property with data type dbref rather than string (which could also be
accomplished with @propset). The following example sets
property _disconnect/cleanup in the current room with the
dbref of program gen-sweeproom.
@register #prop here:_disconnect gen-sweeproom=cleanup
The same thing could be accomplished by typing:
@propset here=dbref:_disconnect/cleanup:<#dbref of gen-sweeproom>
This example makes a setting in sub-propdir _reg/lib,
giving the lib-strings library program the registered name
$lib/strings.
@register #prop #0:_reg/lib lib-strings = strings
The same thing could be accomplished by typing:
@register lib-strings = lib/strings - or
-
@propset #0 = dbref:_reg/lib/strings:<#dbref of lib-strings>
[
SWEEP
sweep (sweeps all sleepers in the room)
sweep <player> (sweeps <player>)
Sends home all players in a room who are sleeping, and who
are not owners of the room. It also sends their contents
that they do not own home when it homes them. If you control the room,
you may also sweep online players who do not control the room.
The following prop settings, on either yourself or a room, as
appropriate, are used to configure the command: