Muck Manual (warning: long)
Tanith_Tyrr
WARNING: do not reply to this post directly. In order to find my real
email address, you'll have to get out the scalpels and perform an
emergency appendectomy.
TinyMUCK Manual - Hacked together and edited by Tanith Tyrr
Written by all the wizards, Muckers and friends of FurryMUCK
Warning: this version may contain outdated information; it was compiled
many years ago and has not been updated since.
Table of Contents:
1. What is a MUCK?
2. How to get started on FurryMUCK
2.1 Where to go: email, telnet and ftp information
2.2 Basic Commands: Looking, moving, getting, talking
2.3 Basic Commands Defined
2.4 Getting Around On The MUCK: Finding Helpstaff
3. Character Set-Up
3.1 How-to: @desc, @lock me, @set me, #whatis, pinfo
3.2 Character set-up commands: Setting Your Properties
4. Object Creation
4.1 Object Types And Attributes
4.2 Commands: @create, @desc, @idesc, @chown, @lock, @name,
@succ, @fail, @osucc and @ofail, substitution strings,
@drop, @recycle, lookat, throw, @change and editing
objects, lsedit, @link, @set and setting
properties/flags, vehicle creation, zombies
4.3 $Desc program: complex descriptions
4.4 Creating "pets": PetHack
4.5 Making a vehicle: Boingdragon's Vehicle Tutorial
5. Room Building
5.1 Commands: @dig, @desc, @chown, @open, exit description,
@succ and @fail messages for exits, @backlink
5.2 Linking & Locking: @link, @breaklink, @relink, @unparent,
@lock, editroom
5.3 Setting Special Actions In A Room: @action, @attach
5.4 Flags: the @set command
5.5 Etiquette of Room Building
5.6 Parent rooms and environment settings
5.7 Transparent exits and broadcasting exits
5.8 Scents: setting smells in rooms
5.9 Look-trap: describing bogus objects
5.10 Permissions and Settings: vehicles, throwing, parrots,
knocking on doors.
5.11 Map building
6. More Commands
6.1 Program Commands: @archive, @program, @edit, @ps, @kill
6.2 Database Search/Information Commands: @find, @owned,
@entrances, @stats, @list, @when
6.3 Complex Navigation And Moving: nav, run, @tel, dests
6.4 Misc: Sweep, Banish, Spoof
6.5 Wizard Commands: @wall, @dump, @force, @toad, @pcreate,
@shutdown, @usage, *Quell
7. Program Listings And Help
8. MUF Tutorial
9. MPI Introduction
Appendix A: Propdirs and Propcp
Appendix B: Global Command Listings
Appendix C: Help Topics And News
***FurryMUCK Help Manual****
This is TinyMUCK ver 2.2fb5.0, a user-extendible, multi-user adventure game.
[1]-----WHAT IS A MUCK?-----
A MUCK is a variation on what is known as a "MUD" -- a Multi-User Database.
MUDs are run like huge text adventure games (along the lines of Infocom's
ZORK series or the old Scott Adams adventures) that are capable of running in
realtime and of handling a multitude (sometimes hundreds) of players at one
time. In many of these games, you are given a character, with which you can
explore the MUD environment, fight monsters, get treasure, buy better
equipment, and so forth.
MUCKs are a variation on this, in that the phenomenon of being able to have
several players online at once, interacting in realtime, can be valuable for
social purposes. MUCKs essentially drop the gaming environment in favor of
open "roleplaying" and social interaction between "players". FurryMUCK is a
particular MUCK that has been set up to cater towards members of "furry
fandom" -- i.e. people who happen to enjoy cartoons, comics, etc. that
feature "anthropomorphized animals". (Examples of popular "furry" or "morph"
characters might include Bugs Bunny, the Teenage Mutant Ninja Turtles, Usagi
Yojimbo ... essentially animal characters that, in one way or another, have
human attributes.)
[2]-----HOW TO GET ON FURRYMUCK-----
If you have telnet access, you can connect with the FurryMUCK site by typing:
>telnet 138.74.0.10 8888
On some VMS systems, you may have to type:
>telnet 138.74.0.10 /port=8888
or some variation thereof.
{Note -- At this writing, this is a recent change of address.}
Once you are connected, you should see the "title screen", and you will be
asked to enter your character name and password. Since you do not yet have
a character, you would type:
>connect guest guest
This allows you to use the "guest" character so you can get a chance to
explore a bit.
One problem about telnetting is that, since this is in realtime, what you are
typing on the screen may apparently be "interrupted" by incoming data from
the MUCK. This can be rather distracting and frustrating. What you will
need (to preserve sanity) is a client program such as TinyFugue. ftp to
avatar.snc.edu and look in the /pub/furry directories for more information on
available client programs and help files.
[2.2] Basic Commands:
Move/go <direction> Takes you out an exit, if the exit exists.
Gohome - Takes you home. Default home for new players is the Bandstand.
Taxi -- Summons a taxi for you to travel around the MUCK.
Get/take <thing>; drop/throw <thing>
Look; look <thing>; look <direction>
inventory -- Shows what you are carrying.
Say <message>; "<message> -- Talks to everyone in the room.
:<action pose> -- Shows your action to everyone in the room.
whisper <player> = <message> -- Whispers to one player alone.
page <player> = <message> --- gives the player the message long-distance.
WHO -- Find out who's online. Type in all caps.
Wizzes -- Find out what helpstaff/wizards are online.
News -- "News" or information files available online.
Help -- Lists help topics you can ask for.
Globals --- See a list of many other useful commands.
@describe me = <description> -- Sets your description.
@password <oldpassword>=<newpassword> -- Changes your password.
For help on a specific command, type 'help <subject>'.
For a list of subjects, try 'help index1','help index2', 'help index3'.
There is also help for PROPDIRS and a PROPDIRS-EXAMPLE section.
Remember, no matter how bad it gets, you can always go home.
All sorts of commands are available to players. Common ones are listed
by typing 'help'; you can get a listing of all commands by typing 'help
index' and learn about each one with 'help <command>' as needed. Since exits
can be given the same name as commands, this can be confusing to beginners.
All @ commands are caught before exits are checked, however, as well as WHO,
QUIT, OUTPUTPREFIX, OUTPUTSUFFIX, and home. Also, some areas may have more
commands available in them.
Getting killed is no big deal. If you are killed, you return to your
home, and all things you carry return to their homes. You also collect 50
pennies in insurance money (unless you have >= 10000 pennies).
On FurryMUCK, if you are courteous and well-behaved, the chances are
that no one will kill you. You might get a virtual hug or a playful pounce,
but the general Furry population is quite friendly to people who return their
courtesy.
COMMANDS:
drop gripe look page score
examine help move QUIT take
get home news read throw
give inventory outputprefix rob whisper
go kill outputsuffix say WHO
help move who
Peeking Around Online:
where whereis
whereare whospe
dests
[2.3] Basic Commands Explained:
MOVE/GO:
go[to] <direction>; go[to] home. Goes in the specified direction. 'go home'
is a special command that returns you to your starting location. The word
'go' may be omitted. You may also just type an exit name to leave via that
exit. Move is the same as go.
GET:
get <object>. If object is gettable, lets you pick it up and adds it to your
inventory. Warning - player owned objects usually cannot be kept
permanently; they will "go home" of their own accord, unless you can claim
ownership of them by the @chown command.
DROP:
drop <object>. Drops the <object> if you are holding it. It moves
the object to the room you are in, unless its STICKY flag is set, or
the room has a drop-to. Programs are much like objects but are not
affected by room droptos or STICKY flags. A 'drop' message can be set, which
will be shown to the player dropping the object, and an 'odrop', which will
be shown to the other players in the room. (see @drop, @odrop) throw and put
are aliased to drop.
HAND
hand {item} to {character}
Allows you to "hand" an item to another player. Also try "throw".
LOOK:
Looks at an item, a room or a person. Also try examine, smell and read on
appropriate items.
SMELL:
Smell <person or object> to see if there's any scent.
READ:
If you are in a room with a "bulletin board" (such as West Corner of the
Park), typing this command will show a listing of all the postings
currently on the bulletin board in the room. To read a particular entry,
type: >read {entry#} To see a listing of all the new entries, type: >read
new
SAY/POSE
To say something, preface what you want said with a ".
Example: >"Hello, everyone.
If your name is Joe, this will print on the screen: Joe says, "Hello,
everyone." Note lack of end quotation marks; this is not a typo. To pose
(perform an action), preface your action with :
Example: >:looks around and smiles.
This prints Joe looks around and smiles.
Note that your name gets prefaced to your actions; you don't type it.
WHISPER/PAGE
To say something only one player will hear, use whisper if s/he is in the
same room, and page if s/he is not. You can abbreviate to w and p.
Format: w (playername) = (message) or p (playername) = (message)
w John = Hello there! prints Joe whispers to you, Hello there! on John's
screen. That is, it does if your name is Joe....
SPOOF: Spoof v2.5
This annoying program allows you to say things semi anonymously. Wizards and
some programmers/hackers can still ID you. Don't abuse it.
usage: spoof <message>
anonymously show message to all in the room.
Note: to spoof a message beginning with #, you must double the #.
spoof ## This is a message beginning with one #.
Type 'spoof #install' for help on installing spoof exits in rooms.
Type 'spoof #examples' for examples of how you might install spoofs.
Type 'spoof #commands' for a list of additional #keywords.
Type 'spoof #changes' to see new changes in spoof.
SCORE:
Score. Displays how many pennies you are carrying. Some programs use other
money objects, such as pebbles.
INVENTORY:
Can be abbreviated inv; shows you what you are carrying.
HELP:
One of the most important commands. Type "help" to list help topics
available.
HUG:
Hug {character} -- An amusing "global" command.
PAGE #MAIL:
page #mail {character}={text}
This may not be done when using the Guest character, but it allows you to
leave "mail" for another character. In order to check your own mail, simply
type "page #mail" alone.
HOME:
A last resort if you are lost. Typing this will send you to your "home", and
all items in your possession back to their prospective "homes". If you are
the Guest, this will send you back to the Guest Room.
WHOSPE:
Whospe shows a listing of all the characters in the room, whether they are
"awake" or not, and what gender and species applies to them. May be
abbreviated "ws".
STAFF:
Staff lists any online members of the FurryMUCK Help Staff. These people
have expressed their interest in helping out newcomers to the MUCK, so if you
are stumped, you might try paging one of these people.
MAP:
In certain areas of FurryMUCK, typing 'map' will call up an ASCII graphics
display of your location marked by an 'X' on the map.
[2.4] -----GETTING AROUND-----
As the Guest, your use of commands is rather limited, but you still have the
use of some rather important commands that will allow you to communicate with
other online players. An important note is that the MUCK is case-sensitive,
so it *does* matter whether or not you capitalize. First off, in order to
see what other characters are currently online, type:
>WHO {Note -- all caps}
Also, there are certain "players" online known as "wizards". These are
essentially the "dungeon-masters" for FurryMUCK, and are capable of getting
you a new character. In order to see what wizards are online, type:
>wizzes
In order to contact someone who is online, you may use the "page" command.
For example, if you happen to spot the character Greywolf on the WHO list,
you could greet him by typing: >page Greywolf=Hi there! If you saw that
Riss (a wizard) was online on the wizzes list, you could contact him about
getting a new character by typing something like:
>page Riss=Hi there! I'm new here, and would like to get a character. What
do I do next?
You may also try to get one of the wizzes to transport the Guest out of the
"Guest Room", so you can roam around a bit. Guests are restricted from
performing some commands; so get your character set up by emailing
fma...@sncils.snc.edu with your character name and the initial password you
want to use.
[3] Setting Up Your Character:
[3.1] -----SETTING INFORMATION ON YOURSELF-----
Once you get your own character, there are a number of things that should be
set in order to get you started. There are several special commands preceded
by a "@" that can be used to customize your character (and, later, your
"home".) The following are a number of commands to type in to get you
started.
>@set me=!k -- This turns off the "k" or "kill_ok" flag so that you can't
be "killed".
>@set me=j -- Sets you "jump_ok", allowing you to utilize certain
programs that require this bit to be set.
>hand #ok -- This is required in order for players to be able to hand
objects to you.
>@desc me={description} -- This sets the description that others will see
if they look at you. For instructions on more
detailed descriptions, see the section on "The
@6800 Program".
>@set me=gender:{gender} -- Either set yourself "male", "female" or
"neuter".
>@set me=sex:{gender} -- Identical, but some programs will check for
your 'sex' property rather than 'gender', so both
should be set.
>@set me=species:{your species} -- For use with the whospe command. i.e.
you might be a cat, wolf, dog, ferret,
dragon... It's merely informative.
>@set me=_scent:{text} -- This allows you to set your "scent" in case
others smell you. Objects and even rooms may have
scents as well.
>@lock me=me -- This prevents others from "robbing" pennies from you.
Setting Your Gender: Specifics
@set me=sex:unassigned|male|female|neuter.
Default unassigned. If a player's sex is set, %-substitutions will use the
appropriate pronoun for that player. Only meaningful for players.
Password Options:
Change your password.
@password <old password>=<new password>.
This changes your password.
There are a few programs which are used to give further information
about your character, and which you may want to set up.
Pinfo -- For help, type "pinfo #help". The purpose of this program is
so that you can store information about your character and/or player, such
as address, email address, your "character profile", your personal
interests, etc., for anyone who cares to look. Of course, if you don't want
to set this information, you don't have to.
Whatis -- For help, type "whatis #help". This program allows you to set
a few "flags" on yourself to give someone using the "whatis" command a quick
idea of what your character is.
[3.2] Character Set-Up Commands: Setting Your Properties
Morph Hammer V1.2 (C) 1994 by Triggur
This program lets you easily change your description and other attributes.
MORPH #ADD - Add current description as a new morph
MORPH #HELP - this text
MORPH #LIST - list all the morphs you have and their commands
MORPH #REMOVE - Delete one of your morphs
MORPH <command> - change to a morph (see morph #list for commands)
QMORPH <command> - change to a morph quietly
To use this program, edit your current attributes (by hand or
with EDITPLAYER) to get exactly the form you want. Type MORPH #ADD
and your current description, sex, species, scent, say and osay
will be copied as a new morph. You will be expected to answer
a few questions. First, the 'command' associated with this
morph. This should be one word like '2leg' or 'mwolf' or somesuch.
Next the name of the morph. Only you will see this in MORPH #LIST.
Finally, the text it should print when you change to that new morph.
To add another morph, simply edit your current description again
and MORPH #ADD again. Lather, rinse, repeat. :)
WARNING: If your description is currently using @$desc (@6800 on Furry),
the whole description will be _converted_ to a single MPI list.
NOTE: Be aware that when you change to a morph, your description
will be overwritten. If you have multiple descriptions you want
to make morphs for, be sure to MORPH #ADD them all *before*
trying to test one of the new morphs. PLEASE DELETE YOUR OLD
MORPHS! Also, please keep the number of morphs you have to under 10.
Doing Ver 1.1 by Riss
This program will allow you to set your 'I'm doing this now...' property and
display these properties for those players in the same room as you.
Usage:
do <text...text....text....text...> will set your TEMP Doing to the text.
do will display the names and doing property of those around you.
do : will clear your TEMP Doing.
do s: <text...text....text...> will set your STICKY Doing.
do s: will clear your STICKY Doing.
A TEMP Doing will automatically clear itself when you move out of a
room, and will overide the STICKY Doing while it is available. A STICKY
Doing will display in DO or WhoSpe if there is no TEMP Doing. If a player is
asleep, the property will display [asleep]
If DO interferes with a DOWN command, use DOING as the command. Thanks
to Jet for suggesting the TEMP Doing idea. Comments and questions to Riss.
Setting Throw Messages:
Sets the text others see when you hand or throw something.
Hand/Throw by Mystique@AlteredStates July 10, 1994 Use but don't Abuse!
@set me/object=_hand/succ:You hand %obj to &n.
@set me/object=_hand/osucc:%n hands %obj to &n.
@set me/object=_hand/drop:%n hands %obj to you.
@set me/object=_hand/odrop:%n hands %obj over to &n.
@set me/object=_throw/succ:You throw %obj off to see &n.
@set me/object=_throw/osucc:%n throws %obj off to see &n.
@set me/object=_throw/drop:%n threw %obj to you.
@set me/object=_throw/odrop:%n threw %obj to &n.
@set me/object=_throw/osame:%n throws %obj to &n.
Pronoun substitutions using %'s are for the hand/thrower, &'s are used for
the target [who's getting the object]. %obj is the object name.
Objects setup with the above messages [all or any], they're used instead of
the person's messages.
@set me/object=_hand_ok:n disallows that player/object of being
involved in a throw.
@set me/object=_throw_ok:n same as above, but for throws.
Wizards can have extra messages [succ, osucc, etc] by merely adding `-player'
onto them, where you can have messages for moving players.
This version has been updated to support the old FurryMUCK throw functions,
listed from the original docs by Darkfox for the props to be set are:
Restrictions:
<object> must be jump_ok ** NO Zombie objects! **
<person> must be jump_ok
<person> must have a property "_receive_ok?:" set
to "yes"
<person> must not be haven
the room /environment must not have a property
"_throw_allowed?" set to "no"
<person> may also have a "_sleep_throw" property that
contains a list of player names or dbrefs of people who
can throw to you, while you're asleep.
<person> may have a "_throw_allowed" property that
contains a list of player names or dbrefs, and only
those players will be allowed to throw to <person>.
If the first character of _throw_allowed is "!" only
players *not* contained in the list will be allowed to
throw to <person>.
If <person> is not in the same room as the thrower, then:
<object> must not have a property "_throw_far?"
set to "no".
the room / environment must not have a property
"_throw_far?" set to "no".
the trigger must not be set STICKY.
Messages:
Messages may be both on the object and on the trigger;
and may be general or action-specific; the action-
specific messages will have "_" and the first name in
the action preceding the general message names.
The messages are put through pronoun substitution for
both the catcher and the thrower, in that order. So,
for a pronoun_sub on the thrower, you must double the
'%' in the message. [See the default messages below for
examples of this.] In addition to the normal pronoun
substitutions, a '%t' or '%T' will be replaced by the
true name of the thrower, a '%c' or '%C' will be
replaced by the true name of the catcher, and a '%w' or
'%W' will be replaced by the name of the object being
thrown.
_same This is the message that is given when both the
thrower and the catcher are in the same room.
DEFAULT: %%n throws %w to %n.
[%%n == name of thrower, %n = name of catcher]
_throw This is the message given to the thrower when
the thrower and the catcher are in different
rooms.
DEFAULT: %%n throws %w into the air towards %c.
_catch This is the message given to the catcher when
the thrower and the catcher are in different
rooms.
DEFAULT: %w flies into the room from %T and is
caught by %n.
[4] Object Creation:
[4.1] There are 5 types of objects: things, players, exits, rooms, and
programs. The first letter following an object's ID number indicates the
type: P(layer), E(xit), R(oom), otherwise, thing. Things are inanimate
objects that can be carried. Players are animate objects that can move and
carry. Exits are the means by which objects move. Rooms are locations that
contain objects and linked exits. Programs are player-written extensions to
the game.
There are 5 rules to controlling objects:
1) You control anything you own.
2) A wizard or God controls everything.
3) Anybody controls an unlinked exit, even if it is locked. Builders should
beware of this, lest their exits be linked or stolen.
4) Players control all exits which are linked to their areas, to better
facilitate border control.
5) If an object is set CHOWN_OK, anyone may @chown <object>=me and gain
control of the object. (set chown_ok).
Objects have several standard strings:
1) a name.
2) a description. (stored in _/de property) 2)
an inside description (for vehicles). (stored in _/ide property)
3) a success message (seen by the player). (stored in _/sc property) 4)
a fail message (seen by the player). (stored in _/fl property)
5) an osuccess message (seen by others). (stored in _/osc property)
6) an ofail message (seen by others). (stored in _/ofl property)
7) a drop message (seen by the player). (stored in _/dr property) 8)
an odrop message (seen by others). (stored in _/ofl property)
Using Objects: Failure And Success Messages:
Properties (usually text messages or flags that indicate whether or not
you can use an item in a particular way) should be set on every object. For
instance, a Car object would probably have properties set on it so that you
could not pick it up and carry it away, but you could enter it and possibly
drive it away.
When you do a command that affects an object, a player, a room or an
exit, you will get back success or failure messages that tell you whether
(and why) you have failed or succeeded to use it.
You fail to use a thing when you cannot take it (because it's lock
fails). You fail to use an exit when you cannot go through it (because it's
unlinked or locked). You fail to use a person when you fail to rob them. You
fail to use a room when you fail to look around (because it's locked).
You successfully use an object when you take it. You use an exit
successfully when you go through it. You use a person successfully
when you successfully rob them. You successfully use a room when you
look around.
When you rob someone, you succeed or fail to use them (See SUCCESS and
FAILURE). You can protect yourself from being robbed by entering "@lock
me=me" (See ME and @LOCK). If you lock yourself to yourself, you can rob
yourself and set off your @success and @osuccess messages.
When you create an object, you need to set its properties. Create it,
describe it, lock it, chown it and set success and failure messages that you
and other players will see when they succeed or fail at using your object.
You may also set flags on the object to determine whether or not players can
use it in a particular manner.
You can specify objects (things, players, exits, and rooms) by name if
they're in your inventory or in the same room as you. You need only type
enough letters of the name to be unambiguous. You can also specify objects
anywhere by their ID numbers, in the form #<number>. Players in other rooms
may be specified in the form *<player name>. The keywords 'me' can be used
for yourself, and 'here' for the room you're in.
[4.2] Commands:
Create Object Command:
@create <object> [=<cost>[=<regname>]].
Creates a new object and places it in your inventory. This costs at least
ten pennies. If <cost> is specified, you are charged that many pennies, and
in return, the object is endowed with a value according to the formula:
((cost / 5) - 1). Usually the maximum value of an object is 100 pennies,
which would cost 505 pennies to create. If a <regname> is specified, then
the _reg/<regname> property on the player is set to the dbref of the new
object. This lets players refer to the object as $<regname> (ie: $mybutton)
in @locks, @sets, etc. Only a builder may use this command. Don't forget,
once an object is created, to describe it using the @desc command (@desc
<object or object's dbref#> = <text>. You can set other properties and flags
on an object as well.
Describe Object Command:
Sets object/player description.
@describe <object> [=<text>].
Sets the description field of <object> to <text>. If <text> is not
specified, the description field is cleared. This is the same as '@set
<object>=_/de:[text]' A description is what is seen when a player looks at
something.
Idescribe Command:
Describes the inside of an object or vehicle; optional.
@idescribe <object> [=<text>].
Sets the idescription field of <object> to <text>. If <text> is not
specified, the description field is cleared. This is the same as '@set
<object>=_/ide:[text]' An idescription is what is seen on the inside of a
vehicle, when a player inside it looks around.
Lock Command:
Locks objects, exits you own to/against others.
@lock <object>=<key>. Locks <object> to a specific key(s). <object> can be h
specified as <name> or #<number>, or as 'me' or 'here'. Boolean expressions
are allowed, using '&' (and), '|' (or), '!' (not), and parentheses ('(' and
')') for grouping. To lock to a player, prefix their name with '*' (ex.
'*Igor'). A key may be a player, an object, or 'property:value'.
Unlock Command:
Removes locks.
@unlock <object>.
Removes the lock on <object>. See @LOCK.
Chown Command:
Takes control of an object.
@chown <object> [=<player>].
Changes the ownership of <object> to <player>, or if no player is given, to
yourself. If the MUCK is compiled with PLAYER_CHOWN, all players are
allowed to take possession of objects, rooms, and actions, provided the
CHOWN_OK flag is set. Mortals cannot take ownership of a room unless they
are standing in it, and may not take ownership of an object unless they are
holding it. Wizards have absolute power over all ownership.
Name Command:
Names an object or room you own.
@name <object>=<name> [<password>].
Sets the name field of <object> to <name>. <name> cannot be empty;
a null name is illegal. <password> must be supplied to rename a
player, not needed for an object. Wizards can rename any player but still
must include the password.
Fail Message Set:
Sets fail message text.
@fail <object> [=<message>].
<object> can be a thing, player, exit, or room, el specified as <name> or
#<number> or 'me' or 'here'. Sets the fail message for <object>. The message
is displayed when a player fails to use <object>. Without a message
argument, it clears the message. This is the same as: '@set
<object>=_/fl:[text]' See also @OFAIL, and @DESC.
Ofail Message Set:
Sets ofail text.
@ofail <object> [=<message>].
The @ofail message, prefixed by the player's name, is shown to others when
the player fails to use <object>. Without a message argument, it clears the
message. <object> can be specified as <name> or #<number>, or as 'me' or
'here'. This is the same as: '@set <object>=_/ofl:[text]'.
Osuccess Message Set:
Sets osuccess message text.
@osuccess <object> [=<message>].
The @osuccess message, prefixed by the player's name, is shown to others
when the player successfully uses <object>. Without a message argument, it
clears the @osuccess message. It can be abbreviated @osucc. <object> can be
specified as <name> or #<number>, or as 'me' or 'here'. This is the same as
'@set <object>=_/osc:[text]' See also @SUCCESS.
Success Message Set:
@success <object> [=<message>].
Sets the success message for <object>. The message is displayed when a
player successfully uses <object>. Without a message argument, it clears the
message. It can be abbreviated @succ. <object> can be specified as <name> or
#<number>, or as 'me' or 'here'. This is the same as '@set
<object>=_/dr:[text]' See also @OSUCCESS.
Strings And Substitutions:
@osuccess, @ofail, and @odrop messages may contain %-substitutions,
which evaluate to gender-specific pronouns if the player's sex is
set. They are:
%a (absolute) = Name's, his, hers, its.
%s (subjective) = Name, he, she, it.
%o (objective) = Name, him, her, it.
%p (possessive) = Name's, his, her, its.
%r (reflexive) = Name, himself, herself, itself.
%n (player's name) = Name.
Capitalized pronouns are also available with %A, %S, %O, %P, and %R.
If you need a '%', use %%.
Ex. '@ofail teapot=burns %p hand on the hot teapot.' will return, if Lynx
tries to use the hot teapot, "Lynx burns her hand on the hot teapot."
Drop Global:
Not the drop command. Sets drop message on object.
@drop <object> [=<text>].
Sets the drop field of <object> to <text>. h If <text> is not specified,
the drop field is cleared. The drop message on an object is displayed when
you drop it. On an exit, it is displayed upon entering the destination
room. On a player it is displayed to whoever kills them. On a room, it is
displayed when an object is dropped there. This is the same as '@set
<object>=_/dr:[text]'
Drop Command:
Used without a @, it drops the specified object in your inventory.
drop <object>.
Drops the <object> if you are holding it, and displays the text set by the
@drop global. It moves the object to the room you are in, unless its STICKY
flag is set, or the room has a drop-to. Programs are much like objects but
are not affected by room droptos or STICKY flags. A 'drop' message can be
set, which will be shown to the player dropping the object, and an 'odrop',
which will be shown to the other players in the room. (see @drop, @odrop)
throw and put are aliased to drop.
Recycle Command:
Destroys/erases an object or action.
@recycle <object>. Destroy an object and remove all references to it he
within the database. The object is then added to a free list, and newly
created objects are assigned from the pool of recycled objects first. You
*must* own the object being recycled, even wizards must use the @chown
command to recycle someone else's belongings.
MUFlookat v1.30 by Foxen Updated 2/7/94 Page1
Syntax: lookat <player>'s <object>
or: lookat <player> <object>
Lets you look at an object that a player is carrying, and see its @desc.
You can set these properties on objects:
_remote_desc:<desc> Shown instead of the objects @desc. If this (or
the @desc if this doesn't exist) uses a program
like @6800, it will handle it properly.
_remote_look?:yes Allows lookat'ing for that object. On a player,
allows looking at anything they carry unless the
object is set _remote_look?:no
Throw Command/Flag:
Throws an object; is also a settable flag for your character.
throw <object> to/at <player>
@set me/object=_throw_ok:n stops anyone from throw something to you.
You cannot throw any object @set <object>=_throw_ok:n.
@set me=Jump_OK, @set object=Jump_OK AND the receiver must be set Jump_OK or
the throw will fail.
throw #ok sets you so you can receive throws.
throw #!ok sets you so you can't receive throws.
@view $throw for more help.
Change v1.04 Written by Tygryss/Revar Last updated 6/15/94
Desc: Lets you replace some text in a message or property with
new text. Useful for fixing typos in a long message.
Syntax: change <object>=<propname>:/<old>/<new> or
change <object>=<mesgtype>;/<old>/<new>
<mesgtype> can be name/desc/succ/osucc/fail/ofail/drop/odrop
The first character after the : or ; is the delimiter character,
in this case a '/'.
Lsedit Command:
lsedit
Edits object properties.
This program lets you edit lists that are used for the @6800 longdesc
program and a few others. A list is a set of ordered properties that
contain strings. ie:
mylist1:This is
mylist2:an example of
mylist3:a simple list.
To edit one of these lists, use the syntax: lsedit <object>=<listname>
where <object> is the object that you want to edit the property list
of, and <listname> is the base name of the list to edit. In the above
example, the listname was 'mylist'. You can get more help about how to use
the editor itself by entering '.h' on a line by itself while you are in the
editor.
Set:
Sets flags and properties on an object.
@set <object> = [!] <flag> -or- @set <object> = <property> : [ <string> ]
-or- @set <object> = :
@set does one of three things on TinyMUCK, it can modify flags, add
properties to an object, or remove properties from an object.
Using the first format, you may set flags, which are: WIZARD, LINK_OK,
DARK [DEBUG], FILTER, STICKY [SETUID], JUMP_OK, BUILDER [BOUND], QUELL,
CHOWN_OK, HAVEN [HARDUID], ABODE [AUTOSTART], VEHICLE, ZOMBIE, or MUCKER.
You can also set the MUCKER (or Priority) Level of an object by using 0, 1,
2, or 3 as the flag name. An optional flag which may or may not be on a
given site is KILL_OK.
The second format sets <property> on <object> to <string>, or if
<string> is not given, removes <property>. The third format removes all
properties from an object. See Flags (5.4) for more information.
Link Objects Command:
Linking objects, actions and rooms.
@link <object1>=<object2> [; <object3>; ... <objectn> ].
Links <object1> to <object2>, provided you control <object1>, and <object2>
is either controlled by you or linkable. Actions may be linked to
more than one thing, specified in a list separated by semi-colons.
Vehicle Creation
Makes an object you own into a vehicle.
@set <thing>=vehicle
Objects of TYPE_THING, that have the VEHICLE flag set, can contain players.
To enter a vehicle, you can either use a MUF program to teleport you to it
via MOVETO, you can get a wizard to @teleport you into it, or else you an
use an action that is both attached and linked to the vehicle to enter it.
This means that you can only enter a vehicle from the same room that it is
in, and you cannot use far links to enter it. This prevents the use of
vehicles to get around locks. Inside the vehicle, you will see it's
@idesc, instead of it's @desc, and you will not be shown it's @succ or
@fail. Objects dropped in a vehicle will not go away to the their homes, as
a vehicle cannot have a dropto set in it. Things with the VEHICLE flag
set cannot enter rooms or use exits that have the VEHICLE flag set. This
allows a way to prevent vehicles from entering areas where it would be
illogical for them to be. See the chapter on Vehicle Tutorial.
Zombie Creation:
Makes an object a remotely controlled zombie.
@set <object> = zombie
@force and the FORCE muf primitive can be used on objects of type
THING, if they have the ZOMBIE flag set. Objects act as if they have the
permissions of their owner. If an object is locked against a player, it
will also be locked against anything that that player owns, that tries to
test the lock.
Things with the ZOMBIE flag set cannot enter rooms or use exits that
have the ZOMBIE flag set. This allows a way to prevent zombies from
entering areas where they are not wanted. If you try to run a program
that you control, that has its ZOMBIE flag set, it will drop you into the
MUF debugger. This lets you step line by line, or instruction by
instruction through a muf program, setting breakpoints to stop at, and other
nice things. There is help available within the debugger, via the 'help'
command. See the Pet program documentation chapter.
[4.3] $Desc Program: Complex Object Descriptions
Quick Usage Summary of $desc (gen-desc v2.0)
August 2, 1992 by Conrad Wong
How to use:
$desc is a program that you can use to make more complex messages on
descriptions, success, fail, and drop messages. To do so, do this:
@desc object = @$desc (description here)
(or @succ, @fail, @drop)
The description is a normal text message, but may include special
'tokens' which are translated by the $desc program to normal text. For
example, you might write this:
@desc me = @$desc A cute little fox with %sub[color] eyes.
@set me = color:green
Then when someone looked at you, they would see:
A cute little fox with green eyes.
All tokens are of the form %token-name[parameters] and you may nest
tokens, so that you may have descriptions which look like this:
@desc me = @$desc %sub[%sub[morph] %sub[clothes]
Which would take the property name that you had stored in the property
'morph' and substitute the contents of that property. It would also take
whatever you had in 'clothes' and add that into the description.
You should also bear in mind that lists, when mentioned below, are
created by doing this:
lsedit object = listname
(first line of the list)
(second line of the list)
....
(last line of the list)
.end
The lsedit program is very useful for editing lists.
Tokens:
%sub[<match,>property]
Example: %sub[color]
%sub[me,species]
%sub[here,night]
%sub[#321,small]
%sub[] is used to take the contents of a property. It normally takes the
property from the object that is looked at (or which has the @succ or @fail
message) but can be set to use properties from other objects as shown above.
%rand[<match,>listname]
Example: %rand[buttons]
%rand[here,songs]
%rand[] takes one of the lines in a list at random. As with %sub[], it
normally takes this from the object that is looked at, but can take
properties from other objects. %rand[] differs in that it expects the name
given to be the name of a list created with lsedit, not a property name.
%time[<match,>listname]
Table: one item in list -- full day
two items in list -- midnight to noon, noon to midnight
three items -- midnight to 8 AM, 8 AM to 4 PM, 4 PM to
midnight
four items -- midnight to 6 AM, 6 AM to noon, noon to 6
PM, 6 PM to midnight
six items -- midnight to 4 AM, 4 AM to 8 AM, 8 AM to noon,
noon to 4 PM, 4 PM to 8 PM, 8 PM to midnight
%date[<match,>listname]
Table: one item in list -- full year
two items in list -- January to July, August to December
three items in list -- Jan. to Apr., May to Aug., Sept. to
Dec.
four items in list -- winter, spring, summer, fall
twelve items in list -- monthly
%time[] selects one of the lines in a list, based on the time of the day.
That is, the first line corresponds to just after midnight, the last line is
before midnight, and all the lines in between are mapped over the day.
%date[] is similar, but it does this over the year so that you can have
descriptions which vary with the season.
%concat[<match,>listname]
Rather than taking one item, %concat[] takes each of the items in the
list and strings them together into your description. However no spaces are
inserted between elements so you must include that, or commas, if you want
something to be put in between list elements.
%select[<match,>listname,value]
Example: %select[here,weather,%sub[me,climate]]
This selects one item in a list, given the value. This can be useful in
such cases as where you have a number on some object and want to give a
description keyed to it. Also, if there is no entry in the list that
corresponds, it will take the closest entry less than or equal to that number
given. (for instance, you could set only some entries in a list)
%select[] was written to allow people to write descriptions that would
vary with the size of the people looking. This is generally defined as an
implementation-specific macro such as %+size[listname]
%if[condition,true<,false>]
Example: %if[%sub[me,fly],You fly up into the air,You can't fly!]
%if[%sub[light],In the flickering glow you see a trapdoor.]
If the condition given (i.e. a substituted property) is not a null string
(blank), or FALSE, then it will return the "true" message. Otherwise, it will
return either a blank or a "false" message if one is provided.
Note that you may combine substitution of properties with %yes[] and
%no[] which are described below.
%yes[parameter]
%no[parameter]
Example: %yes[%sub[me,fly]]
If the parameter given is either 'Yes' or 'No' for %yes[] and %no[]
respectively, then it will return YES. Otherwise, it will return a blank
string. These are non-case-sensitive so you may use 'yes', 'Yes', or 'YES',
or even 'y'.
These may be useful with %if[] where you may require that a property be
set specifically to 'yes' or 'no'.
%@progname[<arguments>]
%#prognum[<arguments>]
Example: %@$foo[bar]
%#321[baz]
These allow you to call programs, which must take one string parameter
(whatever is given as <arguments>) and will return one string. This will
then be inserted into your description like any other token would.
%+<macroname>[<arguments>]
Example: %+size[listname]
This looks for a macro on the object, the current room, or environments
thereof up to #0. A macro is set as a property named _macros/macroname so
for instance, you might do this:
@set #0 = _macros/size:%select[%0,%sub[me,size]]
In a macro definition (which is simply inserted like another token) %0,
%1, %2, and so on may be used for arguments, which are separated with commas.
So %0 here refers to the first argument given, and all other arguments would
be ignored.
%prog#num[arg1,arg2,arg3,...]
%prog$name[arg1,arg2,arg3,...]
Example: %prog#321[foo,bar]
%prog$baz[gum]
These are like %$prog[] and %#prog[] but they split the arguments so you
can call programs that need several different arguments.
%char[num]
Example: \\[
\\,
%%token[parameter]
Escaped characters such as \c (i.e. any character prefaced with \) and %%
(which is translated to %) will be translated into %char[num] which should
not be used directly. This allows you to substitute special characters which
would otherwise be interpreted by $desc.
%otell[<room,>message]
Example: %otell[stares out the window at the passing fishes.]
This sends a message to everyone else which can be useful if you want to
simulate a randomly changing osucc or ofail. You would leave the @osucc
blank and instead, use $desc to create the @osucc message. The message will
be preceded by the name of the person looking. You may use this to display
a message in some other room as long as the owner of the object also owns
that room.
Note: you cannot use %otell[] on a message that is on a player, so you
cannot make %otell[] to simulate @odescs on players. Please do not abuse
%otell[].
%prand[listname<,mins>]
Example: %prand[fishtype]
This chooses one of the elements at random, based on both the trigger's
dbref (object number) and the current time, within a period. So you may have
it cycle through all the objects in the number of minutes you want, and it
will be like a random message that will not change if you look at it
immediately.
%prand[] defaults to a cycle time of 1 minute through each element in the
list.
%list[listname]
Example: %list[desc]
This prints out the first part of the description before the %list[],
then prints each element of the list on its own line, then resumes printing
the rest of the description. This can be useful when you want to print
pictures or lists of items.
Note that %list[] cannot be used as an argument so something like
%sub[%list[]] will simply look for a property named "%list[]"
%call[prognum<,arguments>]
Example: %call[#321,foobarbaz]
This prints out the first part of the description before the %call[],
then calls the program, which may do whatever it wishes including printing
out messages and taking input from the user. (programs that need to take
input cannot be called from descriptions) It then resumes with the rest of
the description.
Like %list[], you may not use %call[] as an argument to another token.
%nl[]
This simply prints whatever comes before this and starts the rest of the
description on a new line. Like %list[], you may not use %nl[] as an
argument to another token.
Proplocs and Property Searches:
Normally a property is looked for on the trigger object, i.e. where the
@description, @succ, or @fail is set. With many commands you can specify
another object such as the looker or the current room.
The program can normally only read properties on the looker, or anything
that the owner of the trigger object owns.
The program will automatically search environments for properties where
appropiate. So you may set a list on a parent room and each of the rooms
inside will be able to use that list.
You may set a _proploc:(object number without the #) property on
objects and the $desc program will look on the 'property location' given for
the property asked for _after_ it checks the environment. You may even
create chains of _proploc properties so that several proplocs can inherit
from one.
However you can only use a proploc owned by someone else if it is set
_proploc_ok?:yes
[4.4] Making Pet Objects:
PET v2.15 Hacked together by Vision 1/26/93
------------------------------------------
Table o' Contents:
1) Introduction
2) Usage
3) Commands
4) Message Properties
5) Room Property: pets_allowed? (Room owners read this.)
6) Changes, BugFixes, etc.
Please page #mail all bug reports, Suggestions, Comments, and
personal rantings to Vision.
Simply put, this program sets up an object that will follow you into
any room that will allow it. This is useful for pets, bodyguards,
robot butlers, slaves, little tykes, or those strange things that stalk
you at night. :)
Normally, the room you walk into must be JUMP_OK (and STICKY if the
room has a drop-to) for the object to follow you. If the room doesn't
meet these conditions, and you do not own the room, then the object will
be quietly placed into your inventory, you will be told why the check
failed, and the pet object will go to sleep. (See Page 5.)
The program will also fail if the room is set '_puppet_ok?:no'
Usage:
Enter 'pmake <object>', object being the object you wish to have follow
you. You must own the object, and it must be JUMP_OK. The PetDriver
will set up all the necessary props on yourself as well as the object,
if they aren't there already. (pmake will also re-activate an already
existing pet object.) You may have as many pet objects as you want, but
only one can be active at a time. (This may change in the future.
Dropping the object, or calling it from home will awaken the pet.
Picking it up or sending it home will make it go to sleep.
It will also sleep if it is sent to you by a room fail.
Commands:
pmake <object> : Turns an object into a follower or re-activates one.
pcall : Awakens and summons your pet to your location
(or your inventory if the room-check fails.)
phome : Sends your pet to it's home (_pet/pet_home)
and makes it go to sleep.
pstat : Current pet name and it's status.
preset : Returns your pet status to inactive.
pet #help : This here help file!
Properties:
On the pet object:
pet/move : What you see when the object follows you.
(default : <objname> bounds in after you.)
pet/omove : What everyone sees in the room the object enters.
(default : <objname> bounds in after %m.)
pet/amove : What everyone sees in the room the object leaves.
This message is displayed regardless of success or failure
(default : <objname> bounds out after %m.)
pet/home :Messages seen when pet is sent home.
pet/ohome (default for both: <objname> bounds off to home.)
Normal pronoun substitutions work in these messages; also, %p gives
the object's name, and %m gives your Username (as opposed to your %n)
alias. The object's name is always tacked onto the front of the message.
pet/pet_home: This is the location the pet is sent to when you do a
'phome'. It is originally set to your HOME location.
Room Properties:
pets_allowed?:yes
no
This is a property Room owners can set on a room if they want to
allow/disallow pet objects to follow their owners in, yet do not
wish to alter the JUMP_OK/drop-to/STICKY status of the room.
Setting this prop to 'yes' allows objects to follow their owners
inside a room that would normally cause the program to fail.
Setting this prop to 'no' causes the room to not accept pets
PERIOD, even if the Room owner and pet owner are the same.
This property is optional; it's absence will simply make the
program check the JUMP_OK/drop-to/STICKY status of the room.
Changes:
2.0 - initial global release
2.01 - changed propdirs from _pet/ to pet/.
( kept getting permission errors with _pet/ )
2.02 - couple of bug fixes, pets_allowed?:yes now overrides
_puppet_ok?:no for movement.
2.1 - more bug fixes, added 'preset' command.
2.11 - Made 'preset' a bit more complete, and HOPEFULLY
fixed that dreaded 'double message' bug...
2.12 - Bugfixed the bugfix. Should werk now. :)
2.13 - Forgot to put the bugfix in 'phome'. I corrected this.
2.15 - Relaxed some of the checking on pet movement. Now Pets can go
anywhere puppets can. :)
[4.5] Creating Vehicles:
Vehicle Tutorial (by BoingDragon)
Topics:
1) Creating the vehicle
2) Vehicle exits and windows with ObjExit.muf
3) Drive action with DriveTo.muf
4) Miscellaneous
Part 1: Creating The Vehicle
A vehicle consists of two main parts, an OBJECT to serve as the 'outside' of
the vehicle, and a ROOM to serve as the inside. Start by creating the object:
@create Omni Car
This will return a database reference number which you need to note, as it
is used later by the vehicle actions. For this example, the db# of Omni Car
will be #12345.
Vehicle objects must be JUMP_OK in order for the driveto program to move them
around, so the next step will be:
@set Omni Car=J
Now we can @dig the room to be the inside. We'll use the parent and register
options of @dig in order to save time and make things more convenient.
@dig Omni Car Cabin=#78722=inside
This creates the room 'Omni Car Cabin' and parents it to room #78722, which
is a room containing many vehicle destinations and a handy navigation action,
as well as Greywolf's Vehicle Environment Room, #28616, which includes both
a 'drive' action and an 'out' action (convenient if you only plan on a
one-room land-based vehicle). It has default messages you can change by
setting props on the room (listed later in this tutorial). The word 'inside'
will let you reference this room with '$inside' instead of having to remember
its db number.
The last step for this phase of vehicle creation is to make an entry action
for the vehicle. The entry action should be both obvious and unique, since
other vehicles may be in the same area and like-named actions will be chosen
at random.
@act enter omni;enter car=Omni Car
@link enter omni=$inside
The @osucc, @succ, and @odrop messages for this action work as they do for
any other exit, as do the transparent-exit programs.
You can now enter the vehicle for the next part of the tutorial.
Part 2: Vehicle Exits and Windows
Normally, you can't have an exit to an object that will take someone to that
object. To do this for vehicles, a special program called Object-Exit is
used. To create an exit from the inside room of the vehicle to the vehicle
object, use:
@open out;exit=#32153 (NOTE: Parents #78722 and #28616 come with this.)
This action now needs to know the db # of the vehicle object. For the Omni
Car example, that number was #12345:
@set out=goto:12345
Because this 'exit' is actually a program call, the standard @drop and @odrop
type messages can't be used. These messages are instead stored on the action
as the following properties: (For the built-in exit, these messages can be
set on the room as well, just use 'here' instead of 'out')
@set out=exit_osucc:climbs out of the cabin.
@set out=exit_drop:You climb out of the Omni Car's cabin.
@set out=exit_odrop:climbs out of the Omni Car.
If the vehicle happens to be in an area that is not _vok?:yes or is set to
noexit:yes, the following messages are used:
@set out=exit_fail:You can't get out here!
@set out=exit_ofail:tries to leave to cabin.
Vehicle windows that let you view the area the vehicle object is in use the
Window.muf program, #36002. They can be added to Objexit actions by simply
setting the @desc of the action to that number:
@desc out=@36002 You look out through the bubble-canopy and see:
Now when a person does 'look out' they will see the description of the room
that the vehicle object is currently in. This view can be modified using the
standard transparent-exit control flags and the 'show' property. Those flags
are N (room name), D (description), C (contents), and P (programs run from
the room's @succ, like Obvious-Exits). To display use all of these viewing
options:
@set out=show:ndcp
Not all windows need to be exits, especially in the case of a vehicle with
multiple interior rooms such as an airplane or spaceship, where the exit is
in a seperate room from the control area. The simplest way to implement a
window in this case is to set the 'goto' property on the room itself, and use
look-traps for the windows:
@set here=goto:12345
@set here=show:ndcp
look #add window view outside=@36002 You see through the window:
Part 3: The Drive Action
Driveto.muf, #32249, is the program used to 'move' your vehicle object from
room to room. It has certain necessary restrictions, however. A room must
be set _vok?:yes in order for a vehicle object to be moved there. Exits can
be driven through if both the source and destination rooms allow vehicles, or
if the exit itself is _vok?:yes. Exits can also be set to only allow
vehicles that use a certain 'dmode' to pass through them (so cars don't end
up in the lake, or in the sky). Driveto.muf does not require that a vehicle
has an 'inside' room. There is a special '_bike' mode for it that allows the
action to be attached to an object, which the user then carries to use. (For
info on _bike vehicles, look at the driveto docs with @view #32249. This
tutorial focuses on vehicles that use a room, although the settings for the
driveto action are the same.)
This example is for the Omni Car, which can travel in any drive mode, so the
the mode would be set with:
@set Omni Car=dmode:any
Other drive modes are: air, water, land. Setting a dmode on a _vok?:yes exit
will lock that exit to only allow vehicle objects with the matching dmode to
pass.
To create the action in the vehicle's inside room, just use:
@open drive;fly;pilot=#32249 ('drive' alone is in the vehicle environment
room)
Driveto properties can be set on the action itself, or on the room if you're
using an environment action. The following message properties can be set:
(Note: In drive_osucc and drive_odrop, %vehicle will be substituted by the
name of the vehicle object.)
@set here=drive_osucc:pilots the Omni Car out of the area.
This message is seen by the room the vehicle object is leaving.
@set here=drive_odrop:zooms the %vehicle into the area!
This is the message seen in the room the vehicle object enters.
@set here=drive/window?:yes
This will cause the name and contents of a room to be displayed when the
vehicle drives into it.
If you created a drive action instead of using the environment one, you can
use the @succ and @osucc of the action for messages also.
The drive action needs to know the db number of the vehicle object. For the
Omni Car, #12345, it would be set with:
@set here=object:12345
If you don't want the vehicle to be able to drive through exits, and just use
preset destinations:
@set here=_drive_compass?:no
Destinations can be added to the vehicle with:
@set here=_drive_<destination>:<db ref of that room>
For example: @set here=_drive_garage=98765 Where the garage room's db ref
is #98765. Destination names should be kept to one word for convenience
(That doesn't mean the name of the actual room needs to be one word, just
the destination name). Destinations must be rooms, and must be _vok?:yes.
Destinations can also have custom messages that are displayed when you drive
to them:
@set here=_drivemsg_garage:The Omni Car slips smoothly into its garage.
These messages are displayed to the room the drive action is in, or to any
rooms with their db #'s listed in the _drivein property:
@set here=_drivein:23456 34567 45678 <etc>
Miscellaneous
@set here=drive/window?:yes >
This will display the name of the room and its contents to all the _drivein
rooms when driven into.
@set here=_map/ref:nnnnn >
Where nnnnn is the db # of the vehicle object. Allows
the global 'map' command to work within the vehicle,
using the vehicle object as a map location reference.
%call[46956] or {muf:#46956,} >
Fidget's Look-Item. Include this in the desc of the
inside room to show the vehicle's location. @list
#46956=1-23 for settings.
nav;navigate >
(only in the #78722 vehicle environment) Handy action to list the vehicle
destinations in a given region, covers all the preset environment
destinations.
[5] Room Building:
Every thing or player has a home. This is where things go when sacrificed,
players when they go home, or things with the STICKY flag set go when dropped
(See Flags, 5.4 for sticky and drop_to information). Homes are set with the
@link command. A thing's home defaults to the room where it was created, if
you control that room, or your home. You can link an exit to send players
home (with their inventory) by "@link <dir>=home". Drop-tos can also be set
to 'home' @teleport accepts home as an argument, so you can @teleport
things (and players if you are a wizard) to their home. See Navigation 6.3.
The word 'here' refers to the room you are in. For example, to rename the
room you're in (if you control it), you could enter "@name here=<new name>".
Some muds restrict building commands to players whose builder flag is set.
The builder flag, BUILDER, is only meaningful for players. On such systems,
only builders can @create, @dig, @link, @open, or pick up unlinked exits.
Only a wizard can set this flag. When BUILDER is set on a program, it is
called "BOUND" and it causes any functions within the program to run in
preempt mode, regardless of the multitasking mode that the process had
before calling this program. When the execution exits this program, the
multitasking mode returns to what it was before the function was called.
This lets libraries of atomic functions be written.
Building and some other actions cost money. How to get money:
1) find pennies.
2) sacrifice (drop) things in the temple, or @recycle objects.
3) get killed.
4) be given money.
5) rob someone. Once you reach 10000 pennies, it becomes difficult to acquire
more. See COSTS and SACRIFICING. Wizards don't need money to do anything.
Costs:
kill: 10p (or more, up to 100p).
@dig: 10p. @create: 10p (or more, up to 505p), sacrifice value=(cost-5)/5.
@find, @owned: 100p.
@link: 1p (if you didn't already own it, +1p to the previous owner). @open:
1p (2p if linked at the same time).
Wizards don't need money to do anything.
Each object has an ID number (the 'dbref'), which appears after the name of
an object, and is followed by any flags on the object; i.e. foo(#3672PM) is
a Player, Male, named foo, with #3672. This number is a database reference,
and is used to specify objects at a distance; i.e. ex #<room ID number>. You
will only see the ID number of objects you own, or which are set LINK_OK,
ABODE, or CHOWN_OK. Wizards can see the numbers and flags on all objects.
See FLAGS 5.4.
[5.1] Room Building Commands:
Dig Command:
Builds a room.
@dig <room> [=<parent> [=<regname>]].
Creates a new room, sets its parent, and gives it a personal registered
name. If no parent is given, it defaults to the first ABODE room down the
environment tree from the current room. If it fails to find one, it sets
the parent to the global environment, which is typically room #0. If no
regname is given, then it doesn't register the object. If one is given,
then the object's dbref is recorded in the player's _reg/<regname> property,
so that they can refer to the object later as $<regname>. Digging a room
costs 10 pennies, and you must be able to link to the parent room if
specified. Only a builder may use this command. Setting a parent for a
room is optional. ALWAYS write down the dbref number that the program
assigns to your room after you execute a successful dig command.
Example: @dig My Room
This will create a room called My Room, and give you a dbref # for it.
Describe Room Command:
Sets room description text.
@describe <room name> =<text>.
Sets the description field of <object> to <text>. If <text> is not
specified, the description field is cleared. This is the same as '@set
<object>=_/de:[text]' A description is what is seen when a player looks at
something.
Chown Your Room:
Takes control of a room you have built.
@chown <room> [=<player>].
Changes the ownership of <object> to <player>, or if no player is given, to
yourself. If the MUCK is compiled with PLAYER_CHOWN, all players are
allowed to take possession of objects, rooms, and actions, provided the
CHOWN_OK flag is set. Mortals cannot take ownership of a room unless they
are standing in it, and may not take ownership of an object unless they are
holding it. Wizards have absolute power over all ownership.
Open Command:
Builds room exits; use while in your newly created room.
@open <exit> [=<object> [; <object2>; ... <objectn> ] [=<regname>]]. Opens
an exit in the current room, optionally attempting to link it
simultaneously. If a <regname> is specified, then the _reg/<regname>
property on the player is set to the dbref of the new object. This lets
players refer to the object as $<regname> (ie: $mybutton) in @locks, @sets,
etc. Opening an exit costs a penny, and an extra penny to link it, and you
must control the room where it is being opened.
Example:
@open east;e;cave;cavern = #12345
This opens an exit from the room you are in to the room whose dbref number is
12345. You may in some cases use the name of the room rather than the dbref
number; but the dbref number is better to use to avoid confusion. This exit
can be accessed now by typing any of the synonyms you listed in the open
command for the exit. You would put the exit description in the room
description text, or in the exit description text, or both.
Exit Description:
Describes exits.
@desc <exitname> = <text>
Use any of the exit synonyms you have already defined in the @open command to
describe the exit. This message is what a user will see when looking at the
exit. Example: @desc east = You see a dark cave to the east.
Success and Fail Messages
See the @fail, @succ, @ofail and @osucc commands in the Object Creation
segment, 4.2. Basically, you need to set messages the user and other player
in the room will see if s/he succeeds or fails to pass an exit.
Example: @succ east = You walk into the dark cave. @osucc east = walks
into the dark cave. @fail west = There is no exit that way! @ofail west =
tries to walk into a wall, and bangs %p nose.
The osucc and ofail messages prepend the player's name. %p is a
substitution string, and returns the possessive pronoun in lower case.
@Backlink Global
Opens an exit from the room you are in to another room.
{ #<DB> [,<return_exitname] }
Usage: @backlink <exitname> [ = { here } ]
{ me }
{ <name> }
Follows standard permissions for opening and linking exits.
Opens an exit from a room to a place or person. In the case
of opening an exit to another room, it has the option to open an
exit back to the location you are opening the first exit from.
[5.2] Setting Your Home
The abode flag sets a place as OK for players to set as their homes.
@set here=abode.
To set a location as your home: @link me = here
If a room is set ABODE, players can set their homes there, and can set the
homes of objects there. (LINK_OK is now used only for exits, and ABODE is
for players and objects.) When set on a program, it means AUTOSTART. This
means that when the game is first started up, the program will automatically
be run with a trigger of #-1 and a 'me @' of the owner of the program. This
is useful to restart processes that run in the background periodically. You
can only set a location to ABODE if you own it and are currently in it; but
you can link yourself to any ABODE location that you are at. When you start
building rooms, you can set your room to ABODE and then link yourself to it.
Linking:
When the @link command is used on a room, it sets a drop-to location. Any
object dropped in the room (if it isn't STICKY) will go to that location. If
the room is STICKY, the drop-to will be delayed until the last person in the
room has left.
You can link to a room if you control it, or if it is set LINK_OK or ABODE.
Being able to link means you can set the homes of objects or yourself to that
room if it is set ABODE, and can set the destination of exits to that room if
it is LINK_OK. See Flags 5.4. If a room is LINK_OK, anyone can link exits
to it (but still not from it). It has no meaning for people, things, or
exits. A program that is link_ok can be called by any other program, and can
be run from actions and propqueues not owned by the owner of the program.
Link Objects Command:
Linking objects, actions and rooms.
@link <object1>=<object2> [; <object3>; ... <objectn> ].
Links <object1> to <object2>, provided you control <object1>, and <object2>
is either controlled by you or linkable. Actions may be linked to
more than one thing, specified in a list separated by semi-colons.
Unlink Command:
@unlink <dir>; @unlink here.
Removes the link on the exit in the specified direction, or removes the
drop-to on the room. Unlinked exits may be picked up and dropped elsewhere.
Be careful, anyone can relink an unlinked exit,
becoming its new owner (but you will be reimbursed your 1 penny).
Breaklink Global:
Breaks a set link.
Usage: @breaklink <object|exit|player>
@breaklink is used to break the link of an object, player, or
exit which is linked to you (or, in the case of a player, a room
which is owned by you), but is not owned by you. If the target
object is of type thing, it is relinked to its owner's home. If
it is an exit, it is simply unlinked. If it is a player, it is
relinked to a default location and sent there.
Relink Global:
Relinks an exit to another room.
If you mess up and put an exit where you don't want it, relink it.
Syntax: @relink <exit> = <newdest>
Unparent Global:
If you've set a room parent, re-sets it back to the default.
Usage: @unparent {<room> | here}. Sets the parent of a room to be #0.
Locking Your Room
Locks objects, rooms and exits you own to/against others.
@lock <object>=<key>. Locks <object> to a specific key(s). <object> can be h
specified as <name> or #<number>, or as 'me' or 'here'. Boolean expressions
are allowed, using '&' (and), '|' (or), '!' (not), and parentheses ('(' and
')') for grouping. To lock to a player, prefix their name with '*' (ex.
'*Igor'). A key may be a player, an object, or 'property:value'.
@lock here = <Boolean string> @unlock removes a lock on a room.
Room Hammer V1.4 (C) 1994 by Triggur
This program lets you edit attributes of the room you
are in, provided you own it. Type 'editroom' to use it,
or 'editroom <room name>' to create a new room from anywhere.
EXITS LISTER V2.0 written 11-03-91 by: Bunny
This program is designed to show the exits on an object owned by
the player using the program. The Program will show the exit name,
database number, destination and its number. It will work on objects,
rooms, and yourself.
The valid parameters are "here" or "" for the room you are in
"me" for yourself, an object name, or partial name. For the name search
the object must be in your inventory or in the room. You can also
give a database number in the format #<integer> ex: #1234. This will
find the exits from that object regardless of where it is.
[5.3] Creating Customized Actions Inside A Room:
Action Global:
@action <name>=<source> [=<regname>].
Creates a new action and attaches it to the thing, room, or player
specified. If a <regname> is specified, then the _reg/<regname> property on
the player is set to the dbref of the new object. This lets players refer
to the object as $<regname> (ie: $mybutton) in @locks, @sets, etc. You may
only attach actions you control to things you control. Creating an action
costs 1 penny. The action can then be linked with the command @LINK.
Attach Command:
Relinks an action.
@attach <action>=<new source>.
Removes the action from where it was and attaches it to the new source. You
must control the action in question.
Many builders install "quasi-global" exits or actions in their areas: In
other words, they set up "globals" that are usable throughout their
particular environment(s) by installing the actions in their parent room(s).
It is also a common practice to stick a "hints" or "?" command in such an
area so that a player may be aware of the various special commands, shortcuts
or other actions available there.
However, the "commands" global makes it much easier for you to make these
commands available to users. It's essentially a supplement to the "globals"
command. If you type "commands", the com-list program will produce a list,
starting with your present room and working up the environment "tree", of all
actions that are marked "_global?:yes". It will also display information
stored in "_global/info" on the action.
Sample uses of this would be, in adventure area, commands such as "dig" or
"open" and "close" set up for the adventure. An example setup would be:
In the environment room for a treasure hunt adventure game, set an action
called "Dig;excavate" in the room, linked to dig.muf.
@set dig=_global?:yes
@set dig=_global/info:format "dig {where} with {what}"
So, when someone types "commands", they will see, along with any other
"globals" found,
Commands Description
:
Dig format "dig {where} with {what}"
Note that the commands list will only display the first "alias" in the exit
name.
Bogus commands can be made using exits. For example, to make a 'sit' command,
one could "@open sit", then "@link sit=here" (because unlinked exits can be
stolen), "@lock sit=me&!me" (impossible to be both at once, therefore always
fails), and "@fail sit=You sit on the chair."; "@ofail=sits on the chair.".
Since nobody can go through it, it always fails. The @fail message is
displayed to the player, and the @ofail message (preceded by the player's
name) to everyone else.
help drop-to
Action Hammer V1.0 (C) 1994 by Triggur
--------------------------------------
This program lets you edit attributes of the actions of the room you
are in, provided you own it. Type 'editaction' to use it.
[5.4] Flags:
Flags:
abode builder chown_ok dark haven
jump_ok kill_ok link_ok mucker quell*
sticky wizard vehicle zombie
***** Setting Flags on Rooms *****
Setting flags on rooms have different (and often useful) results. To set a
particular flag on a room, type it in the format of:
@set here={flag}
For example, to set the Abode flag on a room, you would type:
@set here=a
To *unset* the flag, you would type:
@set here=!a
Flag Settings:
A -- Abode -- Allows others to @link themselves, objects or even rooms (set
parents) to this room.
C -- Chown_ok -- Allows others to take ownership of this room with the @chown
command. However, to limit who may @chown the room, you may @lock the room.
(For instance, if you only want yourself, Joe and Sally to be able to @chown
the room, you could type: @lock here=me|*Joe|*Sally ... Note the * -- This
is necessary when the item/player being referred to in the @lock is not
currently present in the room at the time you are setting the @lock.)
D -- Dark -- Objects in the room will not be visible.
H -- Haven -- Characters cannot be killed in this room.
J -- Jump_ok -- Required for characters to be able to be "teleported" to/from
the room via programs, etc.
K -- Kill_ok -- Honestly, I'm not sure what this would do!
S -- Sticky -- If the drop-to on your room is set (c.f.), items will not be
"dropped" until all players (sleeping players included) have left.
***** Drop-to's
If you wish, you may prevent "litter" in your room by setting a "drop-to" for
objects to be sent to from your room, via the @link command. To do so, type:
@link here=#{number of room you wish dropped objects to be sent to}
If the room is not set Sticky, items will immediately go to the "holding"
room. If, when setting the drop-to, you type:
@link here=home
...then all objects dropped here will be sent to their respective homes
instead.
The flags are displayed as letters following an object's ID number.
Debug is the same flag as Dark, Silent as Sticky, and Bound as Builder. F
refers to a Muck Forth program. An M followed by a 1, 2, or 3 gives the
Mucker Level. (Priority Level for exits.)
DARK flag: If a room is DARK, then when people besides the owner 'look'
there, they only see things they own. If a thing or player is DARK, then
"look" does not list that object in the room's Contents:. Players can set
rooms they own dark, and may also set objects they own dark, but they cannot
drop dark objects in rooms they don't control. Wizards can set players dark.
When a program is set DARK, it is called DEBUG, and a running stack trace is
printed out to any users of the program for each instruction executes.
MUCKER flag: The mucker level of a player or program specifies whether
or not a player can make MUF programs, and what permissions they will have
when the programs are run. (See 'man mucker levels') Only a wizard may set
the mucker level of a player, and a normal player may only set the mucker
level of programs they own to less than their current mucker level. A
program cannot be set to mucker level 0, since it doesn't mean anything.
When the mucker level of an exit is set, is it called the exit's priority
level. The priority levels let you specify that certain exits are not
overidable by local actions. When an exit is searched for, in the matching
*routines, it will match like it used to, except that if it finds an exit,
later in the search order, that has a higher priority level, it
will choose that exit instead.
You can set the priority level of an exit by setting its Mucker Level.
(ie: @set exit=2) A level of 0 is the lowest priority, and a level of 3 is
the highest priority. Only a Wizard can set the priority level of an action
or exit. When the server looks for the standard "connect", "disconnect", or
"look" actions, it will ignore any actions with a priority Level of 0. When
an action is @attached to another object, @named to something else, or
@unlinked, its Priority Level is reset to 0. If COMPATIBLE_PRIORITIES is
#defined on your system, then exits that are on room or player objects will
never act as if they have an effective priority level of less than 1.
[5.5] ***** Building "Etiquette" for Areas
When building an area (your home, an adventure, an area to explore, etc.)
that others may go through, there are a few conventions to keep in mind:
- Use standard compass directions and abbreviations, plus out/exit/leave.
For example, if a "north" exit is used, the name may include "n" in the name
as well. If the exit leads out of a room, adding out;exit;leave to the name
is standard.
Ex:
@open east;e;enter;cave;in;opening=#12345
- Naming an exit after a player can cause complications, particularly if that
player is in the same room! A common practice in "apartment building" setups
is to name the room exits after the occupants, but you can run into some
weird situations if anyone tries to chat in the hallway...
- @describe your exits. It is much preferable to be able to look in a
direction and see a short description of what may lie in that direction,
rather than a "You see nothing special."
Ex: @desc east=To the east, you see the opening of a dark cave.
- Use @succ, @osucc, @odrop on exits. For @osucc and @odrop, the message
should indicate which way the character has gone or come from, respectively.
Remember that the @osucc and @odrop messages always have the name of the
character prepended.
Ex:
@succ east=You enter the dark cave.
@osucc east=enters the dark cave to the east.
@odrop east=comes into the cave, from the west.
- Once you have set the @osucc and @odrop messages on an exit, the "-- has
arrived." and "-- has left." standard messages are unneeded. To remove these
messages from an exit, type:
@set {exit}=d
This makes the exit "dark" (no default messages when using the exit) Make
sure that you have @osucc and @odrop exits set for dark exits, or nobody will
be able to see you come or go at all when you use one!
- Keeping things "map-sensible" is a bonus. If a passage to the east leads
to a room, then a passage from that room to the west should (in most case)
lead back to the first position.
- In most cases, exits from a room should be evident in the room description.
If nothing else, it should be at least easy to leave the area (i.e. typing
"out", "exit" or "leave" several times in succession should allow a player to
get out of the area.)
- The @succ set on a *room* can be useful for additional room information.
In most areas where the stepdiscs are set up, this message ("A glossy white
stepdisc is set in the pavement.") is usually in the @succ on a room. It is
also common to put "Visible Exits: " in the @succ on a room, though not
required.
Example:
@succ here=Visible Exits: Out, East, Northwest
- It's a nice courtesy, if you have a large area, to make use of the "map"
global to set up a "map" for your room. For more information on this
program, type "map #help" while on the MUCK. Maps are compatible with
vehicle code.
- The Wizards frown upon "jumprooms". These are basically rooms where some
clever person has decided to create a long list of exits linking to various
places on the MUCK as "shortcuts". Exits are not regulated under building
quotas (yet) but take up just as much memory as rooms or objects. Several
players each having their own "jumprooms" to the various interesting parts of
Furry add up quickly to a lot of database eaten up by "shortcuts".
[5.6] ***** Parent Rooms
By default, every room's "parent" is #0, "Furry Nothingness". This is the
room in which all global actions/commands as well as the default "fail
messages" (i.e. what happens if you try to go north/south/east/west/etc. if
there is no exit in that direction) are set up.
To set a room's parent, enter that room and type:
@tel here=#{parentroomnumber}
A parent room (also referred to as an environment room) allows you to set
defaults for an area. Whenever you try to use an action/exit (or look at
one), the program will first check for the longest match to be found on the
room. Failing that, it will check for actions/exits stored on the person
that fit the match. And then, after that, it will check for the room's
environment -- i.e., it will check for a match in the room's parent room,
and, if *that* room has a parent, then in that one, and so on and so forth.
So, if you type "north" in a room that does not have a "north" exit attached
to it, in most cases you will get "You cannot go that way.", because a match
has been found in room #0 (Furry Nothingness) -- an exit named
north;south;east;west;northeast;southeast;southwest;northwest;
n;s;e;w;ne;se;sw;nw, which happens to be @locked so that it is impossible to
successfully use the exit. It also has the default "up" and "down" false
exits. (i.e. Have you ever typed "up" and get the message that you have just
jumped? Or, have you tried "look up" and you see a ceiling, even though
you're supposedly "outside"? Try "look down" on most of the roads of Furry,
and you will notice a "rug on the floor". =) )
To create your own parent room, simply @dig a room, and create a personal
exit to get there. For example:
@dig My Environment Room
{You will receive a db # for the room, which you should write down. For this
example, I will pretend that it is #12345.}
@action goparent=me
@link goparent=#12345
{this creates a personal action attached to yourself and linked to the
environment room, so that if you type "goparent", you will be sent there.}
goparent
{Now, let us say that you wish to set up an environment room that has default
messages that suggest a generic forest area...}
@open north;south;east;west;n;s;e;w;northeast;southeast;southwest;northwest;
ne;se;sw;nw=here
@lock north=me&!me
{the exit is impossible to successfully use, since you can not be "me" and
"not me" at the same time.} @fail north=The undergrowth is too thick in that
direction to permit passage.
@desc north=You see that you cannot go that way, for the undergrowth is too
thick.
@open climb;up;u;sky;ceiling=here
@lock up=me&!me
@fail up=There is nothing suitable to climb up here.
@desc up=You look up and see the sky above.
@open down;d;sit=here
@lock down=me&!me
@fail down=You take a seat on a nearby log.
@ofail down=sits down on a log.
@desc down=You look down at the ground and see nothing special.
{Then, to set the parent for any room to your new environment room, simply go
to each room, and type:}
@tel here=#12345...
Currently, I have a few environment rooms that have already been set up,
which I will refer to later. These include:
Outdoors Environment Room -- #20846 This is my "master parent room", and is
set up for an outdoors/forested setting. It also includes some special
commands/exits that are included in my
other parent rooms:
* look -- linked to ErmaFelna's look-trap (c.f.)
* nex;nexus -- shortcut to the Underground Nexus
* commands -- lists other special commands installed in the environment
Indoors Environment Room -- #7720
My generic "indoors" environment room.
In each of these rooms, you can reset the "fail messages" by setting the
following props:
updesc: {description when one looks up}
upfail: {message when one tries to go up}
upofail: {message displayed to others (if any) when up attempt fails}
downdesc, downfail, downofail, exitdesc, exitfail, exitofail work similarly.
Program calls (such as to @6800) ARE allowed in these prop settings.
[5.7] ***** Transparent Exits
There are a couple of programs currently available that allow for
"transparent" exits, so that one can "look" into another room.
@5020 -- When @describing the room, insert a @5020 at the start of the text.
Whenever anyone looks at the exit, they will see the contents of the adjoined
room. This will *not* work with exits that are attached to objects or
players.
Ex:
@desc east=@5020 You peer into the dark cave, and see a stone chamber
inside.
When Sally types "look east", and Joe is inside the cave, Sally will see:
You peer into the dark cave, and see a stone chamber inside. There you see:
Joe.
@14490 -- This program can be used on exits regardless of where they are
attached. Also, you can specify how much/little you want to be shown. For
more information, @list #14490 to see the help at the start of the listing.
A "show" property on the exit defines what will be shown. For example, the
default is nd (name and description). To set an exit to show the name,
description, contents and @succ message in the room, you could type:
@desc east=@14490 You peer into the dark cave, and see a stone chamber
inside.
@set east=show:ndcs
***** Broadcasting Exits
With the advent of the new global Say action by Warwick, it is possible to
set up exits such that, if someone is talking in a room with a "broadcast"
exit, someone in the adjoining room may hear them. To set an exit so that
any speech will be "broadcast" through it, type:
@set {exit}=_broadcast?:yes
[5.8] ***** Scents on Rooms
If you want to set a "smell" for a room or environment, then use: @set
here=_scent:{text of what person gets if they smell the room} This message
will be displayed to the user if he/she/it does a "smell here". It can be a
nice way to add extra detail to a room, possibly additional clues for an
adventure game, etc.
[5.9] ***** ErmaFelna's Property-Look ("Look-Trap") Program
A "look" global is currently installed in my environment rooms, and you can
install one in your rooms by creating a "look;loo;lo;l" action and linking it
to Erma's program (for the program #, check the Library), or else @tel'ing
your environment room(s) to one of mine to "inherit" the action. This
program, for the most part, works transparently, though there is some trouble
with using @fail messages on a room while this is in operation.
Instead of creating "false exits" to add extra detail to a room, you can
create "false objects" via this program much more cheaply. In a room that
you own that has the "look" action set up or inherited, type "look #help" for
a built-in help info. This program can be used to add extra 'details' to a
room.
Ex:
@desc here=You are in a rather drab room, except for a painting that hangs
on one wall. The only obvious exit is out to the east.
look #add painting picture portrait
{program asks for one-line description}
It is a colorful ink drawing of a pretty female unicorn standing on a
balcony with a small songbird perched on her outstretched hand.
When someone types:
look picture
...they will see the appropriate message, even though there is not
necessarily a "picture" object or exit present.
[5.10] ***** Permissions And Settings
There are various programs that require certain props to be set on the room
or environment for them to work / not work in that area. While these are
covered in the docs for each program, here is an assortment of more common
ones which may be of interest:
Vehicles:
If you want to set up your room so that vehicles may pass through it, the
room (or environment) must be set "_vok?:yes". If you want vehicles to be
able to pass through exits in the room, each exit must be set "_vok?:yes" as
well.
Throw:
To ban "throwing" of objects to/from your areas, set the following:
_throw_allowed?: no _throw_far?: no
Parrots:
"Parrots" are a primitive type of "puppet" created with Parrot-hack.muf
which randomly spout off lines they've "learned". To put a clamp on
annoying "parrots" in your area, set: _parrot/shutup?:yes
Knocking:
Lynn_Onyx's "Knock" program is installed in my parent rooms, and more info
can be found on it (and how to install a "knock" action in your own
environment rooms, if you are not using mine) in the Library. Although
customization via properties is possible, you can very simply set up an exit
so that it is possible to "knock" on the exit by typing:
@set {exit}=k
{technically, this means "kill_ok", but killing an exit is nonsense, so the
program uses it to mean "knock_ok".}
So, one could type "knock {exit}" to "knock" on the exit, so that a person in
the adjoining room will receive an appropriate message.
[5.12] Making Maps:
*---------------------------------*
| CMD-MAP2.MUF |
| Created by: Neikrad |
| Updated by: Foxx Fox |
| Version: 2.1 |
| Last update: 6 APR 93 |
*---------------------------------*
INDEX
Page 1: Intro and Example Map
Page 2: Properties
Page 3: Advice on Making a Map
Page 4: Example Property Setup
< These help screens are displayed with 'help-pager.muf' by Neikrad >
---< Page 1: Introduction and Example Map >---
Map is a program which allows you to create an ASCII map which indicates a
player's current position with an 'X'.
To make your own map, create an ASCII graphic of an area, and place markers
in each room. Markers are in the form %A%, %B%, %C%, etc. Only 26 markers
%A%-%Z% can be put in a room (no lower case, %a%)
> Example ASCII Map Below Player in Engine Room would see..
| Shuttle Craft | Shuttle Craft
| >==---. .-----. .---. | >==---. .-----. .---.
| ]%A%|==| %B% |=|%C% > | ] X |==| |=| >
| >==---' `-----' `---' | >==---' `-----' `---'
| Engine rm Dock Bridge | Engine rm Dock Bridge
---< Page 2: Property Usage >---
>> _map/symbol property
- This property indicates which '%X%' marker a room should use.
- Set this property to a SINGLE CAPITAL letter
( e.g. @set here=_map/symbol:B -- this replaces %B% with ' X ' on a map )
- If this property is not set, then 'map' simply won't show an 'X'anywhere.
>> _map/room property
- This property is set to the dbref number of a room containing the ASCII
map description. ( e.g. @set here=_map/room:12345 )
- The property IS NOT NEEDED if the map is in an environment, or parent
room.
>> _map/disable property - Set this to: _map/disable:yes in any room which
you don't wish a map to be displayed. ( only useful if a map normally would
be seen otherwise ) - This property works down the environment tree. If a
map is disabled in a parent room, you can re-enable it in a specific child
room by setting
_map/disable:no
>> _map/ref property
- This property is mainly for use inside vehicles. It is set to the dbref#
of a vehicle object ( @set <vehicle interior>=_map/ref:<db of vehicle> )
- With this property, map will indicate the position of the vehicle, not
the user.
- This ONLY works if <db> is set to an object.
---< Page 3: Advice on Making a Map >---
1> Make sure the first character in each line of your map begins with the
same number of leading spaces. Some client programs eat leading spaces
and your map could end up looking obscured, as below, to some..
>==---. .-----. .---.
] X |==| |=| >
>==---' `-----' `---'
Engine rm Dock Bridge
2> Try to make maps less than 25 lines long. If you're area is too big to
fit in 25 lines.. break it up into multiple maps. (The program will only
show the first 100 lines of a map)
3> Use the 'lsedit' list editor to put your ASCII map in your 'map room'
This will create the _map# property the program requires. In your map room,
type: lsedit here=_map
---< Page 4: Example Property Setup >---
In parent room: (you can use: lsedit here=_map to make this easily)
_map#: 5 <<-- Note: This is REQUIRED.. lsedit adds it automatically
_map#/1: | Shuttle Craft
_map#/2: | >==---. .-----. .---.
_map#/3: | ]%A%|==| %B% |=|%C% >
_map#/4: | >==---' `-----' `---'
_map#/5: | Engine rm Dock Bridge
In the Engine room:
_map/symbol: A
( the Dock and Bridge would have this set to B and C respectively )
If you didn't build these rooms in a single parent room.. you can choose
any of these room as a 'map room'. For example, if you chose the Engine
room as your map room (assume Engine room, dbref #1234 ) then set the Dock
and Bridge with:
_map/room: (string) 1234
[6] ***MORE COMMANDS***
[6.1] Programmer's Commands:
@Archive Command:
>@archive = help
Syntax: @archive <object>[=1acefil]
@archive <object>=1 Archive only that object.
@archive <object>=a Archive all, regardless of owner. (wizards only)
@archive <object>=c Don't archive contents.
@archive <object>=e Archive objects not in this room's environment.
@archive <object>=f Don't archive floater child rooms unless linked to.
@archive <object>=i Archive, including globally registered objects.
@archive <object>=l Don't follow links or droptos in archiving.
NOTE: Turn off your client's wordwrap before logging an @archive output.
Also, remove the 'X lines displayed.' line listed at the end of programs.
Program Command:
Create/edit MUF programs.
@program <program>.
Create a new program, or enter edit mode on an existing one. See @EDIT and
Programmer's Reference.
Edit Command:
Edit MUF programs.
@edit <program>.
Searches for a program and if a match is found, puts the player into edit
mode. Programs must be created with @PROGRAM.
Ps Command:
Lists queue status.
@ps. Lists the status of the currently running MUF program processes.
This lists all processes for a Wizard. Non-Wizards only see the muf
processes that they can @kill. See @KILL.
Kill Command:
Halts a program.
@kill <processid|playername|programdbref|"all">
If passed a processid (a number without a '#' preceeding it), it will kill
the given process, if the player controls it. If passed a player name, it
will kill all the processes controlled by that player. If passed a program
dbref, it will kill all processes that that program is running in. If the
argument passed is "all", and the player is a wizard, it will kill all
processes on the timequeue.
[6.2] Database Search Commands:
Find Command:
@find [<name>] [= <flags/types> = [<output type>]]
Searches through the database for items that you control matching <name>.
Players control only objects they own; wizards control all objects, so @find
searches the entire database when they use it. Because the command is
computationally expensive, this costs 100 pennies.
Flags or types can be specified to check for or against certain ones. (A "!"
before the flag indicates that it is to be excluded.) A "U" in the flags
list indicates an unlinked item. An "@" matches only objects unused for
more than 90 days. The output types that can be specified are owners, links
(which outputs either *UNLINKED*, the object to which the item is linked, or
*METALINK* for exits linked to more than one thing), and location.
The matching on names is as follows:
Individual words can be matched as {word1|word2|...}
Individual characters can be matched as [abc...]
A ? matches any character.
A * matches any number of characters, including none.
These special charcters can be matched by putting a \ before it.
Examples of use:
"@find north = EU = location" will find all of your unlinked exits
named "north" and print them along with their locations.
"@find {big|little} = R!L" finds all your rooms whose names contain
"big" or "little" and are not LINK_OK.
"@find w[ei]ll" will find everything you control whose name contains
"will" or "well."
"@find =E=links" will list all exits that you control, and display
where they are linked to.
"@find button==locations" will list all objects you control with
'button' in the name, and it will display where thay are located at.
See also @owned, @entrances, @contents
Owned Global:
Checks for items owned by a player
@owned <name> [= <flags/types> = [<output type>]] Searches through the
database for items that <name> controls. Flags or types can be specified to
check for or against certain ones. (A ! before the flag indicates that it
is to be excluded.) A "U" in the flags list indicates an unlinked item.
The output types that can be specified are owners, links (which outputs
either *UNLINKED*, the object to which the item is linked, or *METALINK* for
exits linked to more than one thing), count, and location.
Valid flags: ABCDHJKLMQSW
Flags of E, F, G, P, R, and T will match Exits, programs, Garbage, Players,
Rooms, and Things, respectively. U will match unlinked objects. 0, 1, 2,
or 3 will match Mucker Levels
Example: @owned Revar=f!l3=location
Will list all Mucker Level 3 (3) programs (F) owned by revar, that are
NOT set Link_OK (!L), and it will give the location of each one.
Note that only wizards can get information for <name> not their own. See
also @ENTRANCES, @FIND, @CONTENTS help @entrances
Entrances Global:
Searches for items linked to objects.
@entrances [<object>] [= <flags/types> = [<output type>]] Searches through
the database for items that you control linked to <object>. Flags or types
can be specified to check for or against certain ones. (A "!" before the
flag indicates that it is to be excluded.) A "U" in the flags list
indicates an unlinked item. An "@" will match only objects that have been
unused for more than 90 days. The output types that can be specified are
owners, links (which outputs either *UNLINKED*, the object to which the item
is linked, or *METALINK* for exits linked to more than one thing), location
and count.
Valid flags: ABCDHJKLMQSW Flags of E, F, G, P, R, and T will match Exits,
programs, Garbage, Players, Rooms, and Things, respectively. U will match
unlinked objects. O will match Old objects unused for longer than 90 days.
0, 1, 2, or 3 will match Mucker or Priority Levels
Example: @entrances here=ED=location
Will list all Dark Exits that are linked to your current location,
giving the location of each one.
See also @find, @owned, @contents
Contents Global:
Item search
@contents [<object>] [= <flags/types> = [<output type>]] Searches the given
object for items & exits that match the given flag string. Flags or types
can be specified to check for or against certain ones. (A ! before the
flag indicates that it is to be excluded.) A "U" in the flags list
indicates an unlinked item. An "@" matches only Old objects, unused for
more than 90 days. The output types that can be specified are owners, links
(which outputs either *UNLINKED*, the object to which the item is linked, or
*METALINK* for exits linked to more than one thing), location and count.
Valid flags: ABCDHJKLMQSW Flags of E, F, G, P, R, and T will match Exits,
programs, Garbage, Players, Rooms, and Things, respectively. U will match
unlinked objects. O will match Old objects, unused for more than 90 days.
0, 1, 2, or 3 will match Mucker Levels or Priority Levels.
Example: @contents here=DE=owner Will list all Dark Exits who's source is
your current location, giving the owner of each one.
See also @find, @owned, @entrances
Stats Command:
Check how much space your character takes up.
@stats [<player>].
For mortal players, returns the highest number in @ the database, which
includes garbage that has been generated with @recycle. For Wizards, gives
this number as well as a breakdown of each type of object: rooms, exits,
things, programs, players, and garbage. Wizards may also specify <player>
which returns a similar display limited to the possessions of <player>.
List Command:
>look list
This command displays a list of the sort created by 'cmd-lsedit' and used by
@6800 (longdesc). The syntax for it's use is:
list <object>=<listname>
Owned Command:
Checks a player's owned items.
@owned <name> [= <flags/types> = [<output type>]] he Searches through the
database for items that <name> controls. Flags or types can be specified to
check for or against certain ones. (A ! before the flag indicates that it
is to be excluded.) A "U" in the flags list indicates an unlinked item.
The output types that can be specified are owners, links (which outputs
either *UNLINKED*, the object to which the item is linked, or *METALINK* for
exits linked to more than one thing), count, and location.
Valid flags: ABCDHJKLMQSW lp Flags of E, F, G, P, R, and T will match
Exits, programs, Garbage, Players, Rooms, and Things, respectively. U will
match unlinked objects. 0, 1, 2, or 3 will match Mucker Levels
Example: @owned Revar=f!l3=location
Will list all Mucker Level 3 (3) programs (F) owned by revar, that are
NOT set Link_OK (!L), and it will give the location of each one.
Note that only wizards can get information for <name> not their own.
See also @ENTRANCES, @FIND, @CONTENTS
Show command:
Shows properties set into objects.
Format: show <object> <proptery name>
The following additional commands are available
using this format: show <object> <command>
@desc - display the object's desc
@succ, @fail, @ofail, @osucc, @drop, @odrop
- display the appropriate message.
@help - help information. This message.
@link - display what the object is linked to. This has
different meanings depending on what the object is.
@loc - the location of the object.
@name - the object's name.
@num - the object's database number.
@version - show version number.
NOTE: show was written before '/' was used in properties.
It does not work with properties that need '/'. You will get an error. I
don't have time to correct this problem right now. sorry for the
inconvenience
When Search:
Searches for information on when an object was created.
@when <object>.
If you control the object, this will display the flags, ownership, and
timestamps associated with that object. If you do not control it, you are
only told the object type and ownership information. This command works with
either a dbref or an object name. help @purge
[6.3] Navigating And Moving Around:
Navigation System Help Screen
----------------------------
Type 'navigate {searchstring}'.
...where {searchstring} is the name of the desired room, or a fragment of
its name. If the path can be found through standard exits, and within 6
steps, the shortest path found will be displayed. For technical information
on setting up Nav.muf for your area, or disabling it, type '@view #76780' to
see program documents.
Run Command:
run <direction>
Ever wanted to go somewhere with Ride, but didn't like all the lag and spam
involved in moving someone 5 or 6 exits away? Or having to go back because
lag burned someone from showing up at the required room when you moved
again? Well, now you can Run!
Simply pile up the exit names separated by commas:
run north,left,up,south
Exits like a `nexus' work as well. Though, the exits MUST be attached to a
room, and can ALSO be personal exits. 3 properties you can set on
yourself to customize your Run!, are:
@set me=_running/stop:%n pants heavily from %p long run.
@set me=_running/in:%n runs through the room, kicking up a dust storm.
@set me=_running/out:%n's feet blast off into a fast run out of the area.
%n must be there, or it'll look rather funny.
@set here=_run/stop:y to stop runners in that room. Useful with Banishers.
@set here=_run/off:y to stop anyone from using run FROM that room.
Teleport Command:
Teleports you to another location on the MUCK.
@teleport <arg1> [=<destination>].
Moves <arg1> to <destination>, if <destination> is not given, moves you to
<arg1>. Wizards may teleport anything to anywhere, provided it makes sense,
and mortals are allowed to do two things: teleport rooms to change their
parent fields, and the may teleport things to a room they can link to,
provided they control either the thing or its location. On some MU's you
can only tport if you have an enabling flag or object.
Destinations:
Dests
This command will list teleport destinations.
[6.4] Miscellaneous Neat Stuff
Sweep Command:
__Propname_ _where_ _What_it_does___
_sweep you message shown when you sweep a room.
_swept or _osweep you message shown when you are swept.
_sweep_player you message shown if you sweep an individual player.
_sweep_to room dbref of where players swept in the room go to.
_sweep_authorized room space seperated dbrefs of players allowed to
sweep the room. ex. #1234 #465 #12 #8
_sweep_immune room space seperated dbrefs of players immune
to being swept from here. ex. #567 #12 #8
_sweep_public? room if 'yes' means this room in sweepable by
anyone.
_sweep_immune? item If 'yes', means this THING doesn't get sent
home when the player holding it is swept.
@/sweepable? player If 'yes', player is sweepable by anyone, and
gets sent home always when swept.
_sweep, _swept, and _sweep_player messages can also be set on a room as the
default messages if a player sweeping there does not have them set. Different
formats for specific player sweeps can be had by setting props with the
prefix '_sweep_', containing the format, then specifying them at sweep
time. ie: if you have a _sweep_nasty format set, you can use it by
typing 'sweep <player>=nasty'
Banish 1.1 by Riss
-------------------------------------------------------------------
This routine will allow an owner of a room or area to banish one or more
characters from the area. If a character attempts to enter an area they are
banished from they will be swept home.
-------------------------------------------------------------------
Banish [#dbref_of_room] chracter_name -Banishes character
Unbanish [#dbref_of_room] chracter_name -Unbanishes the character
Banlist [#dbref_of_room] -Shows who is banished
Banish #help -This text.
The #dbref_of_room is optional, and if not provided will use the list of
your present location. If the list for an environment room is set, then
character will be banned from all daughter rooms. If a character is in a
room when they are banished from it, they are swept home. You may only
banish characters from rooms you own. Example: Banish #12345 keylime -
keylime banished from room #12345
Banish keylime - keylime banished from current room
Unbanish #12345 Guest - Sure let the guest come and play.
Banlist #12345 - Show me whos on my list there.
Another wonderful global by that swishy tail centaur! :)
Spoofing And Setting Spoof Conditions:
Spoof v2.4 installation:
Exits may be linked to the spoof program ($spoof) from a player,
object, or room, by doing this:
@action spoof = <object>
@link spoof = $spoof
Unless a spoof action is on a room, it is always restricted.
A restricted spoof can never begin with the name of a player and
is enclosed in parentheses.
A spoof exit on a room can be set as follows:
spoof #free
spoof #restricted
spoof #message (some message with %m)
A free spoof lets the players spoof whatever they like, whether or
not it is the name of a player. A restricted spoof is like a free
spoof except that it will not let people spoof other people's names.
And a message spoof, which is any string with %m in it, will substitute
the spoofed message for %m.
Action Spoof:
Type 'spoof #action' to format your spoof to allow free-style actions. The
spoof must be on a room, and you must own the spoof to set it. A
free-style action will let you have your name in it anywhere, or %n,
and will perform pronoun substitutions. (use %%n for your %n property)
Example: spoof In a flash of fur, Lynx disappears.
Puppet Spoof:
Type 'spoof #puppet' to format your spoof to allow puppet actions.
The spoof must be on an object, and you must own the spoof to set it.
Also, the room or an environment of the room must be set _puppet_ok?:yes
to allow you to use puppets. A puppet spoof will put the name of the object
in front of all spoofs, allowing you to simulate a puppet.
Example: @action spoof = fire-lizard
@link spoof = $spoof
spoof #puppet
spoof chirps and looks around hopefully for food.
fire-lizard chirps and looks around hopefully for food.
You may set a spoof to reveal who spoofed to a few select people.
They will be told only if they are in the same room.
spoof #tattletale player1
(this will tell them even if they change names later)
You may prevent certain people from using your spoof program.
spoof #lock player1
(this will work even if they change names later)
For examples, type 'spoof #examples'
Spoof v2.3 examples:
Example of a spoof message on yourself:
> @action spoof = me
> @link spoof = $spoof
> spoof This is a test.
( This is a test. )
> spoof Wizard jumps up and down.
Error: spoofs cannot begin with player names!
> @recycle spoof
Example of spoof formats on a room:
> @open spoof = $spoof
> spoof This is the default restricted form.
( This is the default restricted form.
> spoof #message On the stage, %m
> spoof Romeo carols praises to Juliet's virtues.
On the stage, Romeo carols praises to Juliet's virtues.
> spoof #free
> spoof Wizard toads you.
Wizard toads you.
Examples of spoof tattletale:
> spoof #tattletale Lynx
> @set spoof = _spoof:free
> spoof You have been booted off the system!
You have been booted off the system!
# spoofed by Lynx #
Note that only Lynx sees the line in #'s.
Examples of spoof locks:
> spoof #lock Lynx
> spoof This is a test.
Error: you are not allowed to spoof here!
Spoof v2.5 changes:
Owners may now set _spoof_tattletale:(list of names and numbers) on rooms
to allow them to see who did *all* spoofs including personal spoofs or
puppets. The same applies to _spoof_lock. However this must be done
manually.
spoof #check will now work for any spoof and will tell you what tattletales
and locks there are on the spoof, the room or its environments, and the
global spoof tattletale and locks.
Also, set an environment _puppet_ok?:no if you do not want puppets to be
used in it.
Spoof v2.5 commands:
Type 'spoof #free' to let people spoof any message.
Type 'spoof #restricted' to prevent people from spoofing messages starting
with player names.
Type 'spoof #action' to allow people to make free-style spoofs.
Type 'spoof #puppet' to make an NPC object.
Type 'spoof #message <format> to set a special format with %m for the
message.
Type 'spoof #tattletale <name>' to add someone to the spoof's tattletale.
Type 'spoof #lock <name>' to add someone to the spoof's lock list.
Type 'spoof #check' to see who is on the spoof's tattletale and lock lists.
The above commands all require you to own the spoof.
#tattletale and #lock let you type !name to remove a name.
Type 'spoof #feep' to... Well, it's a feep. Find out for yourself.
[6.5] Wizard Commands:
On most mu*s, #1 is the system maintainer and God. Only #1 can set a player
Wizard. Wizards cannot affect #1.
Wall Wizard Command:
Shouts to everybody connected.
@wall <message>.
Only wizards may use this command. Shouts something to every player
connected. Must be typed in full.
Dump Wizard Command:
Saves database.
@dump [filename].
Only wizards may use this command. Saves the database from memory to disk.
Automatically occurs every three hours, and when @shutdown is used. It does
slow down the server, so only use if you fear a server crash is iminent. If
a filename is given, it will save the db to that file, and save any
subsequent dumps to it as well.
Force Wizard Command:
Takes control of a player. When used by a mortal, works on objects.
@force <player>=<command>. Causes the game to process <command> as if s
typed by <player>. With the compile option GOD_PRIV, God cannot be forced
by his/her sub-wizards.
Wizard Password Options:
@newpassword <player> [=<password>].
Only wizards may use this command. Changes <player>'s password, informing
<player> that you changed it. Must be typed in full. If GOD_PRIV was
defined, nobody can change god's password.
Toading By Wizard:
Toads a naughty player.
@toad <player1> = <player2>.
Only wizards may use this command. Turns <player1> into a slimy toad,
destroying their character. All possessions of <player1> are @chowned to
<player2>. Must be typed in full.
Pcreate Wizard Global:
@pcreate <player>=<password>.
Only wizards can use this command. This command creates a new player. It may
only be used if REGISTRATION is enabled.
Shutdown Wizard Command:
@shutdown.
Only wizards may use this command. Shuts down the game. Must be typed in
full.
Boot Command:
Dumps hackers using your account; wizards can dump anybody.
@boot <player>.
Disconnects a player from the game. If a player is connected more than once
it affects the most recent connection. Only a wizard may use this command on
some MU's. (Note-For the FurryMUCK boot policy, check the policy file under
news--'news policies'.)
Usage Wizard Command:
Wizard; system stats listing.
@usage.
A Wizard only command that gives system resource usage stats for p the muck
server process.
Quell Wizard Command:
Removes wizardly powers; set as a flag.
A wizard set QUELL is effectively a normal player with no wizardly powers.
Programs that test to see if a player is wizard will get a false response
from '"wizard" flag?' when the player is QUELLed. Wiz-bitted programs will
still act wizbitted whether or not the owner is QUELLED. help bogus
Purge Wizard Command:
Trashes a player's stuff. All of it.
@purge <player>=yes.
Recycles all objects owned by that player, but leaves the player. You must
specify 'yes' in order for this to take. WARNING: Make sure the player owns
no public rooms or areas. Only a wizard may use this command.
[7] Programs:
**Public Programs Help**
The following commands allow access to help on indexed public programs.
> programs #(program number) -- shows notes on program.
> programs (searchstring) -- shows all programs with name or keywords
containing the searchstring.
> programs #list -- shows listing of indexed programs.
> programs #list (x) -- shows listing of (x)th indexed program.
> programs #list (x)-(y) -- shows partial list of indexed programs.
> programs #page (x) -- shows a 'page' of listing.
Programmers can add their programs to this listing. For more information,
type 'programs #commands'.
Programs List:
# Program Name Owner Docs
1) #24822 mirror.muf ______ Bunny __________ @list #24822=2-14
2) #70451 odrop.muf _______ Bunny __________ @list #70451=1-30
3) #976 autolock.m ______ Charity ________ @list #976=1-10
4) #74762 cmd-race.m ______ Charity ________ @list #74762=1-4
5) #10112 comb-lock.m _____ Charity ________ @list #10112=1-8
6) #80178 disc_dswp.m _____ Charity ________ @list #80178=1-16
7) #86235 duty.staff ______ Charity ________ @list #86235=1-14
8) #75103 feed.m __________ Charity ________ @list #75103=1-8
9) #50577 idle.user.m _____ Charity ________ @list #50577=1-10
10) #87850 privacy _________ Charity ________ @list #87850=1-9
11) #8898 rot-exit.m ______ Charity ________ @list #8898 = 1-18
12) #9480 transporter.muf _ Charity ________ @list #9480= 1-9
13) #54062 multi-action ____ Corwyn _________ (none)
14) #229 ListEditor ______ darkfox ________ (none)
15) #14490 TransExit _______ darkfox ________ (none)
16) #13747 simple-lock _____ Corwyn _________ (none)
17) #59828 LightLock _______ Dragon _________ @list #59828=1-55
18) #11683 improved_morph.pgm ______ Drew ___________ (none)
19) #3146 container-shell _____ Jenora __________________ (none)
20) #29292 Puzzle 'Inspect' program. __ Jenora _________ (none)
21) #31686 Invite Command __ Jenora _________ @list #31686=1-22
22) #29549 Property Look-trap _________ Jenora _________ (none)
23) #27837 Potion dosage counter ______ Jenora _________ (none)
24) #46956 lookitem ________ Wiz-Daemon ________________ (none)
25) #46186 extrude-item2.muf _______Foxx_Fox __@list #46186=1-80
26) #37200 Adv-Reset.muf ___ Greywolf _______ @list #37200=1-53
27) #12562 Com.muf _________ Greywolf _______ @list #12562=1-5
28) #37258 Delay-Lock.muf __ Greywolf _______ @list #37258=1-18
29) #37505 Dig.muf _________ Greywolf _______ @list #37505=1-34
30) #32249 DriveTo.muf _____ Greywolf _______ @list #32249=1-66
31) #45886 Echo-Say.muf ____ Greywolf _______ @list #45886=1-17
32) #35858 Event.muf _______ Greywolf _______ @list #35858=1-67
33) #36215 Event-Shell-Lock.muf ___ Greywolf ___@list #36215=1-60
34) #52097 Index.muf _______ Greywolf _______ @list #52097=1-24
35) #28771 Intercom.muf ____ Greywolf _______ @list #28771=1-26
36) #35719 Mirror-Hack.muf _ Greywolf _______ @list #35719=1-9
37) #42833 Multi-Command.muf _____ Greywolf ___ @list #42833=1-32
38) #32153 ObjExit.muf _____ Greywolf _______ @list #32153=1-15
39) #11145 Option.muf ______ Greywolf _______ @list #11145=1-107
40) #44926 Parrot-Hack.muf _ Greywolf _______ @list #44926=1-62
41) #41241 Rand-Exit.muf ___ Greywolf _______ @list #41241=1-33
42) #58411 Route.muf _______ Greywolf _______ @list #58411=1-43
43) #67396 Riddle.muf ______ Greywolf _______ @list #67396=1-28
44) #25984 Runaway.muf _____ Greywolf _______ @list #25984=1-44
45) #52356 Score.muf _______ Greywolf _______ @list #52356=1-50
46) #67962 Treasure-Thief.muf _ Greywolf _______ @list #67962=1-13
47) #36002 Window.muf ______ Greywolf _______ @list #36002=1-43
48) #26749 WolfAction.muf __ Greywolf _______ @list #26749=1-58
49) #3839 chessboard-program _________ Jeremy _________ (none)
50) #4567 look-simulation-program ____ Jeremy _________ (none)
51) #3694 object-name-program ________ Jeremy _________ (none)
52) #8274 descer __________ Karrejanshi ____ (none)
53) #19944 exit-use-notify _ Karrejanshi ____ (none)
54) #19999 showwho _________ Karrejanshi ____ (none)
55) #20060 OnlyFemales.MUF _ Lanya __________ (none)
56) #19683 OnlyMales.MUF ___ Lanya __________ (none)
57) #13071 capacity-lock.disk _________ Lynn_Onyx ______ (none)
58) #11293 knock.disk ______ Lynn_Onyx ______ (none)
59) #13485 random-lock.disk Lynn_Onyx ______ (none)
60) #8004 cmd-say-filter __ Lynx (none)
61) #10979 copy-prop-to-proploc _______ Lynx (none)
62) #9576 do-nothing ______ Lynx (none)
63) #355 tmp-die-roll ____ Lynx (none)
64) #6800 gen-desc (Revenge of Look-No Lynx @list $desc-docs
65) #7125 cmd-spoof _______ Lynx (none)
66) #24709 record.muf ______ Foxx_Fox _______ @list #24709=1-52
67) #3933 Dice-Roller _____ Revar __________ (none)
68) #10522 gen-crowdlock ___ Revar __________ (none)
69) #6435 gen-mesgboard ___ Wizard _________ (none)
70) #10746 gen-multilock ___ Revar __________ (none)
71) #8452 gen-playerlist __ Revar __________ (none)
72) #15046 gen-setit _______ Revar __________ (none)
73) #4958 gen-timedesc ____ Revar __________ (none)
74) #5020 gen-trans-exit __ Revar __________ (none)
75) #6875 gen-broadcaster _ Lynx (none)
76) #14118 ObvExits ________ Shaterri _______ (none)
77) #5137 gen-proglock ____ Lynx (none)
78) #8813 pdc-morph.muf ___ Slate __________ @list #8813=1-97
79) #60904 pdc-time.muf ____ Slate __________ @list #60904=1-32
80) #22998 desc-area.muf ___ Verin __________ @list #22998 = 1-40
81) #75482 obv-area.muf ____ Verin __________ @list #75482 = 1-35
82) #27531 gen-change ______ Lynx (none)
83) #4708 ed.muf __________ WhiteFire ______ (none)
84) #41107 lockmgr.muf _____ Wizard _________ (none)
85) #17812 morph.muf _______ WhiteFire ______ @list #17812=1-115
86) #43157 nag2.muf ________ Vision _________ @list #43157=2-28
87) #70367 lingo.muf _______ Vision _________ @list #70367=2-42
88) #60782 narc.muf ________ Vision _________ @list #60782=2-44
89) #94523 Passenger-List.muf __Greywolf ____ @list #94523=1-17
90) #26889 foodquery.muf ___ BoingDragon ____ @list #26889=1-58
91) #101765 Super-Indexer.muf ____ Greywolf ______@list #101765=1-9
92) #57190 GlobalSayRedirect.MUF ______ Warwick ________ (none)
93) #44626 teleport.muf ____ Squirrelly _____ @list #44626=1-41
94) #42958 movie.muf _______ Squirrelly _____ @list #42958=1-158
95) #58343 move_along.muf __ Squirrelly _____ @list #58343=1-21
96) #27854 visible_room.muf Squirrelly _____ @list #27854=1-43
97) #12547 arrive_notify.muf______ Squirrelly __ @list #12547=1-8
98) #58220 clist.muf _______ Squirrelly _____ @list #58220=1-18
99) #32245 sign_up.muf _____ Squirrelly _____ (none)
100) #7140 propload.muf ____ Squirrelly _____ @list #7140=1-14
101) #21736 pause_run.muf ___ Squirrelly _____ @list #21736=1-6
102) #29776 desc.muf ________ Squirrelly _____ @list #29776=1-19
103) #12143 pwhosize.muf ____ Squirrelly _____ (none)
104) #39890 depart_mon.muf __ Squirrelly _____ @list #39890=1-8
105) #63995 remote_puppet.muf ___ Squirrelly __ @list #63995=1-61
106) #78900 carrysafe.muf ___ Squirrelly _____ @list #78900=1-5
107) #78215 summon.muf ______ Squirrelly _____ @list #78215=1-32
108) #81365 move.muf ________ Squirrelly _____ @list #81365=1-31
109) #85060 sleepmsg.muf ____ Squirrelly _____ @list #85060=1-8
110) #74655 date.muf ________ Squirrelly _____ @list #74655=1-12
111) #20894 lag-o-meter.muf _ Squirrelly _____ @list #20894=1-5
112) #66397 pinfolook.muf ___ Squirrelly _____ @list #66397=1-16
113) #86023 sq-action.muf ___ Squirrelly _____ @list #86023=1-44
114) #913 PubProg.txt _____ Squirrelly _____ @list #913
115) #31440 veh-only.muf ____ Murphy _________ (none)
116) #69214 envlock.muf _____ Murphy _________ @list #69214 = 1-17
117) #82576 sensor.muf ______ Murphy _________ @list #82576 =1-13
118) #109227 direxits.muf ____ Murphy _________ (none)
119) #43781 aibot-stub ______ Triggur ________ (none)
120) #28640 wumpus.muf __ Ruffin __ Link action to this for help.
121) #108596 Exit-Use-Log.muf Wind-Dancer ____ @list #108596=1-43
[8] MUF: Introduction And Tutorial
[ Updated August 10th, 1990, by ChupChup for the release of TinyMUCK 2.2. ]
Zen in the Art of the Towers of Hanoi
(or The Basics of MUF in 10 megs or less.)
This is an introduction to MUF, a dialect/subset of forth used to do really
really neat things with TinyMuck 2.2. This intro was designed to be read
before any of the other MUF information; it (hopefully) should supply you
with a fair idea of what MUF is all about. It's written at a
non-programming- stud level, all the better for understanding.
All MUF programs work by performing operations on a stack. For all you
non-programmer types, a stack is just a tool used to store information.
Information is manipulated by "pushing" things onto the stack and "popping"
things off. The last thing you've placed on a stack is always the next thing
you would take off if you tried; it's like piling objects on top of each
other, when the only thing you can remove >from the pile is the thing on top.
For example, if you were to push the number 23, then push the number 42, and
then pop a value off the stack, you would get 42. If you were to pop another
value off the stack after this, you would get 23. If you were to try and pop
another value, you would get an error, since the stack would now be empty.
(This is a "stack underflow.")
The basic procedural unit in MUF is called the word. A word is simply a
sequence of instructions. In program text, a word always starts with a
colon, then the word's name. A semicolon marks the end of a word. For
example:
: detonate_explosives
(text of word here) ;
would define a word called detonate_explosives.
Parentheses are used to delineate program comments; everything inside
comments is ignored by the computer. The detonate_explosives word above, if
run as shown, would do absolutely nothing. Indentation in MUF is arbitrary
and serves to make the program more readable to people.
In MUF, there are three types of constant values: integers, strings, and
database references. Each of these types is stored and retrieved from the
stack as a single unit (The string "Hello, Sailor!", for example, would be
stored on the stack in its entirety: "Hello, Sailor!"; it would not be
stored byte-by-byte or word-by-word or in any other such silly way.) To push
a constant onto the stack, you only need to state its value. The following
is a completely legitimate procedure:
: pointless_word
"Old Man"
"I'm"
37
"What?"
37
"Not old!"
;
However, run by itself, it wouldn't do anything visible to the user. It
would, however, create a stack which looks like this:
("Old Man" "I'm" 37 "What?" 37 "Not old!")
In the above stack, "Old Man" is the value on the bottom. "Not old!" is the
value on top of the stack, and would be the next value retrieved.
Placement of values on the same line of a program is arbitrary. Since each
value represents something being put on a stack, the word
: example
"Semprini?"
"All right, wot's all this then!"
;
is the same as:
:example
"Semprini?" "All right, wot's all this then!"
;
Functions which are available in the standard MUF library take values from
the top of the stack, do things with them, and usually leave something new
back on top of the stack. The words +, -, swap, pop, and random provide good
examples of this and are discussed here.
The + routine takes the top two integers from the stack, adds them together,
and leaves the result on top of the stack. In order to easily describe what
functions like this do, a certain stack notation is used: for +, this would
be (i1 i2 -- z). What's inside those parenthesis is a sort of "Before and
After" synopsis; the things to the left of the double-dash are the "before",
and those to the right are the "after". (i1 i2 -- i) says that the function
in question takes two integers away and leaves one. The letters used here to
tell what kind of data a stack object can be are: i for integer, d for
database object, s for string, v for variable, and x or y to mean something
that can be more than one type.
Here are short descriptions of the procedures listed above so you can get the
hang of how they work:
+ (i1 i2 -- i)
Adds i1 and i2 together. The word
: add_some_stuff
2 3 +
;
will return 5. The word
: add_some_more_stuff
2 3 4
5
+ + +
;
will return 14. When add_some_more_stuff first reaches the "+ + +" line, the
stack looks like:
(2 3 4 5).
The first + changes the stack to look like:
(2 3 9).
The next causes:
(2 12).
The final plus returns:
(14).
- (i1 i2 -- i)
Subtracts i2 from i1.
: subtract_arbitrary_things
10 7 -
;
will return 3 on top of the stack.
swap (x y -- y x)
Switches the top two things on the stack. This is useful for when you want
to know the value of x but want to save y for later use.
: swap_stuff_around
1 5
2 swap
3
"Three, sir!"
swap
"Boom!"
;
will, before it gets to the first swap, create a stack of (1 5 2).
After the swap, the stack looks like (1 2 5). It then accumulates another 3
and a string constant, to look like (1 2 5 3 "Three, sir!") It swaps the
last two again and adds another string, so the stack looks like:
(1 2 5 "Three, sir!" 3 "Boom!").
pop (x --) Throws away the value on top of the stack. As shown in the stack
diagram, it returns nothing but takes something, and so decreases the stack's
total size. Useful when you really really want to get to the next thing on
the stack so bad you don't care what's on top. The word:
: needless_popping_waste
"Immanuel Kant"
"Heideggar"
pop
"David Hume"
"Schoppenhauer"
"Hegel"
pop pop
;
would leave the stack looking like ("Immanuel Kant" "David Hume").
random (-- i)
Doesn't even look at the stack, but piles a really really random integer on
top. The word:
: feel_lucky_punkP
random
random
random
;
would return a stack of three random numbers.
Because of the way the stack works, variables aren't as necessary in MUF as
they are in other languages, but they can be used to simplify stack-handling
operations. To declare a variable, you simply add the line "var <name>" at
the beginning of your program. Variables are of no specific type; a variable
which holds an integer can turn around the next second and hold a string if
it's feeling haughty enough.
The following words are important when dealing with variables:
! (x v --)
Set variable v to hold value x. The program:
var answer
: multiply-and-store
6 9 *
answer
!
;
will give the variable "answer" the value 42. This is the same as:
: multiply-and-store
6 9 * answer !
;
@ (v -- x)
This word (pronounced "fetch") retrieves the value of a variable and puts it
on the stack. You should remember this since a common mistake among
beginning MUF programmers is to forget to put fetch symbols in their
programs. The word
garply
by itself stands for the variable "garply", while the expression
garply @
stands for the value of that same variable. If you're familiar with Lisp,
this is analogous to the difference between garply and (garply).
The program:
var biggles
var fang
: more_silly_manipulation
10 biggles !
24 fang !
biggles @ fang @
+
;
will return the value 34 on top of the stack. The program:
var biggles
var fang
: more_silly_manipulation
10 biggles !
24 fang !
biggles fang +
;
is *wrong*. For reasons I won't go into now, since this guide was written at
the last moment and at great expense, the above word will return the value 7
on top of the stack.
In MUF, there are two variables which are predefined and available for use at
all times. These variables are "me" and "loc", where "me" holds the player's
database reference, and loc holds the player's location's database reference.
(Database references were mentioned before as the third type of constant,
then sort of ignored till now. For the sake of completeness, I will
introduce the word
dbref (i -- d)
Where i is an integer and d is a database reference, dbref converts between
the two types. The line
2032 dbref
will return item #2032 in the Muck database. This is useful since there are
lots of functions that operate on database references that won't work on
integers. [If you want to declare something in one of your programs as being
a dbref instead of an integer, you should just put a # in front. For
example, 69 means the integer 69, while #69 means object number 69. You
could say '69 dbref' instead of '#69', but it would be a little slower and a
little harder to read.]
Me @ will return the player's item reference, while loc @ will return the
room they are in. Trigger @ returns the item that triggered the current
program, whether it is a player, exit, room, whatever. A useful word to know
is:
name (d -- s)
Where d is a db reference and s is a string, name returns the name of item
x.
Now that you know about me @, another Muck function becomes useful. Its
synopsis is:
notify (d s --)
When d is a player, notify prints string s out to user d. The program
: warn me @
"There is someone behind the next column waiting to jump you."
notify
;
would print said message on the user's screen.
Before you can really start writing neat stuff in Muck, there are two more
things you should know about. One is = and the other is the "if/then" setup.
= (i1 i2 -- i)
Returns 1 if integer i1 is equal to integer i2, otherwise returns 0.
: nonequals
2 3 =
;
returns 0.
If/then could be written up with a synopsis, but it would be sort of
complicated and probably a lie also. The way it works is this: If pulls an
item off the stack. If the item is 0, it skips over the program after the IF
and resumes execution at the THEN. If the item is not 0, the program will
execute everything in between.
The naming of this construction as if/then can be somewhat confusing. It
certainly doesn't work quite like the if/then of normal languages, and the
THEN actually being called THEN is sort of confusing. As nearly as I can
tell, if/then is a sort of forth-creators' joke. It does not mean "IF the
previous is true THEN do this." like it does in most languages. Rather, it
means "IF the previous is true do this; THEN go on with the rest of the
program." Remarkably silly. The word:
: word
2 3 =
if me @ "Your computer is broken!" notify
then me @ "Done executing this word." notify
;
will always print "Done executing this word." to the user, and will print
"Your computer is broken!" if something is really screwy with the math and it
actually thinks 2 = 3. Getting a bit more sophisticated, one can write
something like:
: word_up
"Your computer works fine."
2 3 =
if pop
"Your computer is broken. Sorry. Truth hurts."
then
me @ swap notify
;
When word_up is called, "Your computer works fine." gets put on the stack. If
your computer actually works, 2 is *not* equal to 3, so that right after the
= the stack looks like:
("Your computer works fine." 0)
The IF reads the 0 and skips all the way down to the THEN. The SWAP in the
last line is used since the NOTIFY word wants its parameters in the opposite
order of where they would be.
If your computer is broken, right after the =, the stack looks like:
("Your computer works fine." 1)
The IF reads this 1 and decides to keep executing. It then gets to the POP
which gets rid of the filthy lie about well-working computers and replaces it
with the painful truth.
*SAMPLE PROGRAM*
Ok, so you've been reading this whole thing so far, and you really want to
use this stuff to do something interesting. The following program does
something interesting, and uses the function
strcat (s1 s2 -- s)
Concatenate strings s1 and s2, returning the result.
it also uses
location (d -- d')
Takes db reference d and returns d', the db reference for its location.
and
dup (x -- x x)
Duplicate the top of the stack.
and
dbcmp (d1 d2 -- )
Works just like =, except operates on db references instead of integers.
: far_vision
#2032 (2032 is Celia's object number)
dup (Make 2 copies; we're about to use 1.)
name (Celia might change her name in thefuture,so)
(instead of using "Celia" here we just look
up her name.)
" is currently in "
strcat (Attach name to sentence so far) swap
(Flip the sentence back so we can get at)
(Celia's dbref again. )
(Celia's dbref is now at top of stack. )
location (Where is Celia? )
name (What is the name of the place she is in?)
"." strcat strcat
me @ swap notify (Tell the player where Celia is.)
#2055 (Celia's hardsuit is #2055. )
location
#2032 (Celia again )
dbcmp (Has she got her hardsuit with her?)
if me @ "Watch out-- she's wearing her hardsuit!" notify then
;
Note that this program uses no variables (except for the universally
defined ME variable.)
In Muck, this program would be attached to, say, a homing device or a magic
staff. Now, if Boomer ever wants to find Celia, he can, and he'll even know
if she's defenseless or she's got her armor.
Without the comments and spaced out like you might see normally, this program
looks like:
: far_vision
#2032 dup
name " is currently in " strcat
swap location name
"." strcat strcat (Now we know where she is.)
me @ swap notify
#2055 location
#2032 dbcmp
if me @ "Watch out-- she's wearing her hardsuit!" notify
then
;
Words can also be called by other words; to do this, you treat your other
words just like library functions when you use them. When you have more than
one word in the same program, the word which is listed *last* is the one
executed, and all the ones listed before it are subroutines. The above
program could be rewritten:
: celia-identity
#2032
;
: far_vision
celia-identity dup
name " is currently in " strcat
swap location name
"." strcat strcat (Now we know where she is.)
me @ swap notify
#2055
location celia-identity dbcmp (Using celia-identity and
spacing the )
(commands like this makes
this bit a )
(little easier to
understand.)
if me @ "Watch out-- she's wearing her hardsuit!" notify
then
;
Oodles and oodles of other neat MUF library routines are available, too
numerous to be detailed in an introduction such as this. A complete list, as
well as sample code, is available from such spiffy ftp sites as
prince.white.toronto.edu and belch.berkeley.edu.
If you're interested in seeing more sample code, write to me for program
listings for the Pan Galactic Gargle Blaster, walkie-talkies, and several
useful library routines.
Stinglai "Two Sheds" Ka'abi
Mail to: bl...@ocf.berkeley.edu
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
"We are too proud to fight." --Woodrow Wilson 1856-1924
"Violence never settles anything." --Genghis Khan 1162-1227
"The mice voted to bell the cat." --Aesop c. 620-c. 560 B.C.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[9] Introduction To MPI
SECTION I: "What is MPI, and why should I use it?"
So, you've heard about this thing called MPI and you've been told that
it can do all sorts of neat things, but you still wonder what it is? Well,
I'll tell you..
MPI is My Personal Insanity. That's my unofficial name for it. I must
have been crazy for having written 3500 lines of C code to implement it. The
official name for it, is Message Parsing Interpreter. That sounds a lot
more ostentatious, and looks better on a resume'. =)
MPI is a script language that lets you embed commands within plain text,
to do things like substitute in the text value of a property. It's used in
messages like @descs, @succs, @fails, @drops, @osuccs, @ofails, @odrops, and
your 'sex' property. Those of you who use the $desc, $wf-desc,or @6800
programs are likely familiar with this sort of idea. MPI works like those
programs, only much faster, and with many more possibilities.
So, what's in it for you to use MPI? Well, you can make descriptions
longer than the 512 character input limit, by splitting them up into
sections that are in different properties, and substituting them into your
main @desc. This also makes it easier to update only one part of the
description, such as what you are wearing, by changing only the property that
has your clothes described. You can also make multiple line descriptions,
by making a list with lsedit, or another list editor, and using the MPI
command to display a list in your @desc. For those of you who want to get
fancy, you can make your description depend on what you are carrying. For
example, you can make your description mention that you are wearing
sunglasses, only if you are actually carrying them. The possibilities are
endless.
Because the commands are read and interpreted by the game itself, they
run quickly, producing less lag for the game than the MUF description
programs like @6800. Also, you can port your descriptions for objects
between fb5.0 MUCKs, without having to worry if the other muck has the right
MUF programs, or uses the same list styles. You can also get much fancier
with MPI than you can with @6800, since there are many more commands
available to you.
Okay, okay, that's enough evangelizing.. Lets get onto the next section.
SECTION II: "So what does MPI look like?"
MPI has a fairly simple structure, mostly. It goes like this:
{command:arg1,arg2,arg3...}
The open-brace { says that the text until the matching close-brace } is
going to be an MPI command that the game should interpret. The first word
inside the braces, before the colon, is the name of the MPI command that you
want it to run. The rest, after the colon, are the arguments, seperated by
commas. MPI commands often take two or three arguments, though some take
many more, one, or none at all. In fact, a lot of MPI commands can each
take multiple different numbers of arguments, using default values for any
arguments that aren't given. If an MPI command takes no arguments, you can
omit the colon. Here's some examples of MPI commands:
{prop:_clothes,me}
This example runs the MPI command "prop" with the two arguments
"_clothes", and "me".
{nl}
This runs the MPI command named "nl" with no arguments.
If you want to pass a comma as part of an argument, you have to mark it
to say that you really mean for the comma to get passed to the function, and
that it isn't there to seperate arguments. To mark it this way, you put a
backslash \ in front of it. The backslash means that the next character
following it has no special meaning, and that it is to be copied literally.
This makes a comma look like part of an argument, instead of like an
argument seperator. This is called 'escaping' a character. You can also
escape an open-brace { to keep it from trying to interpret the text after it
as an MPI command. Also, you can escape backslashes. In fact, to include
a backslash in text, you HAVE to escape it. Almost any character after a
backslash will be copied literally.
The only exception is \r which is replaced by a carriage return
character. A carriage return character tells the game to split the text into
two lines at that place, when the text is displayed to the player.
Example:
{store:\{Here\\now\}\, she thought.,_when}
This will run "store" with the two arguments "{Here\now}, she thought.",
and "_when". The first backslash \ escapes the open-brace {, copying it
into the argument literally. The next backslash escapes the backslash that
follows it, making the backslash copy into the argument literally. The
close-brace has to be escaped, also, or else the game would think that you
are trying to run the "store" command with only the argument "{Here\now".
The comma is escaped to say that it is part of the argument, and not an
argument seperator. The NEXT comma, however, is not escaped. The game sees
this and goes, "Aha! A second argument follows!" Then it gets to the last
close brace }, and sees that it has gotten all the arguments. At this
point, it calls "store" with the two arguments that you passed.
Note that several backslashes in a row will escape each other, alternating
between escaping and escaped characters. What this means is that the game
will take a look at "\\\{" and see an escaped backslash and an escaped
open-brace. Literally: "\{". However, it will see "\\\\{" as two escaped
backslashes and a NON-escaped open-brace. It would try parsing anything
after the non-escaped open-brace as an MPI command.
MPI commands can have MPI commands nested within them, so they can take
the output of other commands and use them as inputs. Example:
{count:{contents:here}}
This would first run the MPI command "contents" with the argument
"here". Then the "count" command would be run with the string returned from
the "contents" command as its single argument. Commas and other characters
inside strings returned from nested commands will all act like they have
been escaped. If they didn't, they would cause unexpected problems, as your
commands would find more arguments than they expect! Luckily, you won't have
to worry about that problem.
SECTION III:
"Now that I know what MPI looks like, how do I use it?"
MPI commands are run from within messages like your @description, your
@success, or your @ofail, to name just three. You just set the message like
you always used to, but you also include some commands within the text of
the message. When the message is displayed by the game, it sees the
commands in the text, and runs them. It takes whatever text they may
return, and puts that in the text to be displayed, in the place where the
command was.
Example:
@desc me=You see a pretty young girl with {prop:_haircolor) hair.
When someone looks at you, with that description set, the game will run
the "prop" command with the argument "_haircolor". The "prop" command will
then look for a property named "_haircolor" on the object the command is on.
It then replaces the call to itself, in the output text, with the string
value of the property. If the "_haircolor" property was set to "golden",
then the looking player will see "You see a pretty young girl with golden
hair."
Unlike the various MUF description programs such as @6800 and $wf-desc,
MPI commands can be inside of omessages, such as @ofail, @osucc, and @odrop.
This lets you do things like make an @osuccess message properly reflect a
varying @succ message.
SECTION IV: "Right, so what are the commands?"
There are a lot of MPI commands that you can use. Over a hundred of
them, in fact, so I'm not going to list them all right now. I'll just give
you a run-through of a few of the most useful and popular ones.
{prop:propname,object}
This command looks for a property with the name 'propname' on the given
object. If it doesn't find it there, it looks down the environment from the
given object. If no property by than name exists on that object, or in its
environment, then this returns an empty string. Otherwise, it returns the
string value of the property. If no 'object' argument is give, then it
assumes that the given object is the trigger object. The trigger object is
the object that has the MPI commands in a message on it.
An example of the use of {prop} is:
@desc me=You see a young woman who is wearing {prop:_clothes}.
@set me=_clothes:a blue blouse and a short green skirt
{exec:propname,object}
This command is almost exactly like {prop}, except that any MPI commands
within the string value of the property are executed, and for their running,
the trigger object will be the object that the property is on. This lets
you have MPI commands embedded within the properties that store various
parts of your @desc, if your @desc is split up into multiple properties. An
example of the use of {exec} is:
@desc me=You see a young woman who is wearing {exec:_clothes}.
@set me=_clothes:{prop:_clothes/top} and {prop:_clothes/bottom}
@set me=_clothes/top:a blue blouse
@set me=_clothes/bottom:a short green skirt
{list:listname,object}
This will load in a property list with the given listname, from the
given object. It loads the list as a single string, with each list item
seperated from the next by a carriage return character. These carriage
return chars will each start a new line, seperating the text into multple
lines, when they are displayed to the user. A property list is a set of
numbered properties with string values. For example, a set of properties
named "list1", "list2", "list3", etc is a list named "list". The {list}
command understands several styles of lists, so "list#/1", "list#/2", etc,
and "list/1", "list/2", etc, are both also recognized by the listname
"list". This means that almost every known MUF list editor should be able
to make a list that {list} can read. If no object argument is given, this
command will assume that the given object is the trigger object. The
environmental searching for the list is the same as for {prop}.
{concat:listname,object}
This is almost exactly like {list}, except that instead of seperating list
items with carriage returns, it seperates them with spaces. The number of
spaces depends on how the previous line ends. If it ends in a period,
question mark, or exclamation mark, it seperates the lines with two spaces,
otherwise, it uses only one.
{rand:listname,object}
This is sort of like {list}, except that it will randomly pick a line from
the given named property list and return it, instead of returning the whole
property list.
{timesub:period,offset,listname,object}
This is sort of like {list}, except that it will only return one line of the
given named property list. The line it chooses depends on the time. The
period is the length of time, in seconds, that it takes for {timesub} to
cycle through the entire list. The offset is the number of seconds to
offset into the time period, if you actually need to synchronize the
{timesub} with something. The offset usually is just left at zero. What
this all means, is that if you have, for example, a period of 3600 (one
hour), an offset of zero, and a property list that has six items in it, then
{timesub} will return the first line of the property list during the first
ten minutes of the hour, the second line during the next ten minutes, and so
on, until it returns the last line during the last ten minutes of the hour.
Then it returns the first line for the beginning --More--
of the next hour.
Here's an example:
{timesub:86400,0,_sunmoon}
This example will show different property list lines, depending on the
time of day. The period is 86400 seconds, which is one day. If the
property list has 24 items in it, then a different line will be returned for
each hour of the day.
SECTION V: "And just how do I refer to objects?"
Okay, you can reference objects in basically the same ways that you can in
user typed commands such as @desc, or @lock. You can refer to obj- ects by
name, if they are in the same room as you, or in your inventory. You can
refer to objects by dbref or registered name, if you need to be able to
refer to the object if it is not in your vicinity. And you can refer to
players by name, with a * in front, no matter where they are.
The following are examples of the accepted ways to refer to objects.
object Referencing by name.
#1234 Referencing by dbref.
$regname Referencing by registered name.
*playername Referencing by player name.
When an MPI command returns a reference to an object, (we'll discuss some of
these commands in the intermediate guide) it will refer to nonplayers by
dbref, and to players by starred name. ("*playername")
SECTION VI: "Cool. So how what stuff can I run mpi from?"
There's lots of things that'll parse MPI commands. To start with, the
@desc, @succ, @osucc, @fail, @ofail, @drop, and @odrop messages will all
parse whatever MPI code you put in them. Also, when a player connects to
the muck, or disconnects, you can run MPI. Also, when a player moves from
room to room. You can even have MPI code that hears whatever is going on in
the room.
To run MPI commands when a player logs in, you need to make a special
property on the player, or on the room where the player resides. To do
this, just simply do:
@set <object>=_connect/XXX:&<mpi goes here>
The XXX can be anything. The properties will be evaluated in alphabetical
order. The result of the mpi code is displayed to the connecting user. The
ampersand (&) that starts the property value tells the server that it has
MPI commands in that property that it should evaluate. As an example:
@set here=_connect/room_motd:&{list:_room_motd,here}
This example will show the room's message of the day, that is stored in
the _room_motd property list on the room, to the player logging in. There
is a different set of properties, with names starting with "_oconnect/",
that also runs when a player connects, but the results of the MPI code will
be shown to the other people in the room, and not the player. For example:
@set here=_oconnect/herald:&Hear ye, hear ye! {name:me} has connected!
Will tell everyone in the room that someone just connected in the room,
in a somewhat heraldic fashion. =)
When a player logs off from the muck, the properties under the _disconnect
and _odisconnect propdirs are evaluated in a similar fashion. When a player
leaves a room, the properties under the _depart and _odepart propdirs are
evaluated. When a player enters a room, the properties under the _arrive
and _oarrive propdirs are evaluated. Here's some examples:
@set here=_odisconnect/elvis:&{name:me} has left the muck!
@set here=_arrive/enter-details:&{list:_entry_details,here}
@set here=_odepart/cabbie:&The cabbie watches {name:me} storm out.
When something is heard in the room, properties in the ~listen and
~olisten propdirs are run, from all things in the room. The {&arg} variable
holds the message that was heard. For example:
@set here=~listen/echo:&You hear an echo: {&arg}
That will echo whatever it hears in that room, to the player who made
the noise. You can also make listeners be restricted to only hearing
certain patterns of words. To do this, you need to put in a matching
pattern at the beginning of the property value. The syntax is: @set
<obj>=~listen/XXX:<pattern>=&<mpicode>
For example:
@set here=~listen/aod:*Klaatu barada nicto*=&The sky rumbles at You!
@set here=~olisten/aod:*Klaatu barada nicto*=&The sky rumbles at {name:me}!
This example would have the skies rumbling at any player who said or
posed the words "Klaatu barada nicto" in the room.
You can use MPI in locks, too, but only indirectly. The way you do it, is
you lock to a property and the result you want, then you make that property
contain the MPI code. For example, to have a room display its fail message
when there are more than ten people in the room, do this:
@fail here=The room's rather crowded at the moment.
@succ here=The room's not so crowded at the moment.
@lock here=_crowdedroom?:no
@set here=_crowdedroom?:{if:{gt:{count:{contents:here}},10},yes,no}
In this example, the MPI code in the _crowdedroom? property will return
"yes" if there are more than ten items in the room. Otherwise, it will
return "no". The lock on the room evaluates that MPI code, and checks to
see if it returned "no". If it did, then the success is shown to the player
looking at the room. Otherwise, the @fail is shown to the looker.
GLOSSARY: "What does that mean, again?"
@6800: A popular MUF program written by Lynx, for making long or somewhat
elaborate descriptions. It gets its name from its dbref, #6800, and its
invocation via the string "@6800" at the beginning of an @desc. This is the
same program as $desc, but is not related to $wf-desc, except in concept and
function.
$desc: See @6800.
$wf-desc: Another popular muf description program, conceptually based on the
$desc program, but written from scratch and reverse engineered by
Whitefire. It has some minor functionality differences, and a more
efficient design.
Message: Any one of the various standard strings on objects, including the
@desc, @succ, @fail, @drop, @osucc, @ofail, and @odrop.
Omessage: Any one of the standard object strings that are to be shown to
other players, including @osucc, @ofail, and @odrop.
Trigger: The trigger is the object that was used that caused the MPI
commands to be evaluated. If you use an exit, and it runs some MPI
commands that are in its @desc, then for those commands, the trigger
object is that exit. The {exec:} command will evaluate the MPI code in a
property on another object, and it will tell that code that the trigger
object is the object that that property is on.
User: This is the player who is running the MPI commands. If the MPI
commands are in the @description of an object, then the player looking at the
object is the user.
Appendix A: Propdirs And Propcp
Propdirs:
Properties are stored in AVL trees, and organized into directories of
properties. This speeds things up, and keeps you from being spammed on
examines. To examine the properties on an object, use
'ex <obj>=<propdir>'.
where to examine the base properties in an object, <propdir> would be '/'.
You can see the value of a single property with
'ex <object>=<propname>'.
Propdirs are a method of storing and organizing properties to speed
access and to provide a sort of built-in organization. The basic idea
is to make something similar to a 'filesystem' for properties. In this
analogy, each person would be a filesystem, with a root directory and
(theoretically) an infinite number of properties beneath that.
A property has been expanded with the idea that each property may now
contain a new property list -- the 'propdir'. properties can both have a
value (either integer or string as before) _and_ contain other
properties.
The actual directory entries may ALSO contain data. Propdirs' only
real 'visible' changes are in the names of properties -- '/' is used as
the property directory separator, and so will not appear in the names of
the properties when listed through 'examine' or MUF programs. Property
protections have also been expanded -- the . and _ may appear either at
the beginning of the property name or immediately following a
'/', and that property will have the appropriate protections.
For example, the property '/mail/.inbox/mesg/#' would have the same
protections as '.mesg#' would now. There are two ways to remove a property
list:
* First, and most straight forward, is to remove the property that
contains it. so, in the previous example, removing the property
'/mail/.inbox' would (recursively) remove all properties under
.inbox before removing .inbox itself.
* The second way is to remove all properties within the property list
yourself. When the last property is removed, the parent property
(the one that contained the property list) is examined to see if
contains data. If it does, then the property list only is
removed. If the property doesn't contain data then it is removed
also.
Because of the first method of removing propdirs, the ability to have a
property list and value in the same property should be used sparingly.
If you try to access a property ending in '/', in MUF, it will give a
programmer error, except in NEXTPROP, in which it will give the name of
the first property in that propdir. The last visible, non-MUF change
that propdirs bring is that 'examine'will no longer show properties
_directly_. Instead, where the properties would normally be shown, it
will say:
"[ Use 'examine <object>=/' to list root properties. ]"
Examine now can take an argument which is the property or propdir to
view. If the property name given ends with a '/', all properties in
property directory will be listed, otherwise the single property named
will be shown.
Internally, a few things changed. property lists are now stored as AVL
trees instead of straight lists, so there is a speed increase even if
propdirs are not directly used. This also means properties are kept in
sorted order and will be displayed that way.
'addprop' will no longer allow a ":" in the property name. To clear a
propdir's value without deleting the proptree below it, from MUF do a '"" 0
addprop' to it. A property can *not* have both a string and integer stored
at the same time anymore. The old property.c was lax and allowed this, even
though the integer value would be lost on dbload. See also
PROPDIRS-EXAMPLE.
Property and Propdir Usage Examples:
Lines indented only 2 spaces are what the user is typing.
Lines indented 6 spaces are what the MUCK is returning to the user.
Lines in []'s are comments on what's going on.
[first, lets set up a bunch of properties]
@set me=first:a property.
@set me=second:another property.
@set me=first/one:A property in a propdir
@set me=first/two:Another property in a propdir
@set me=third/prime:three
[Okay, now lets see what properties we have. We use the examine command to
do that, with a second argument, to tell it what we want to list in the
way of properties. In this case, since we want to list the base level
properties, we use '/'.]
ex me=/
first/: (string) a property.
second: (string) another property.
third/: (no value)
[Okay, it has a few properties with the first part of the names of the
properties that we set. The /'s at the end of some of the property names
means that there are sub-properties that we can list. When we set a
property like 'first/one', it's actually creating a sub-property named
'one' beneath a property named 'first'. If 'first' doesn't already
exist, then it will create that property. Let's list what sub-properties
we created under 'first'.]
ex me=first/
first/one: (string) A property in a propdir.
first/two: (string) Another property in a propdir.
[Here we see the properties that we set as sub-properties under 'first'.
We examined for 'first/' to list the sub-properties. The / at the end
of the name tells the game that we want it to list the sub-properties of
that property, and not that property's value itself. Lets see what value
the property 'first' has, itself. To do this we leave off the '/']
ex me=first
first/: (string) a property.
[Okay, lets say that we just want to see the value of the sub-property
named 'one', under the property 'first'. We can list it as follows:]
ex me=first/one
first/one: (string) A property in a propdir.
[If the property or sub-property that you specify does not exist, it
will complain about it.]
ex me=first/three
No property found.
[if a property was created to contain a sub-property, but was never given
a value itself, it is listed as having no value. It has sub-properties,
however.]
ex me=third
third/: (no value)
[Let's list those sub-properties.]
ex me=third/third/prime: (string) three
[Okay, let's delete the sub-property 'prime', from under the property
'third'. To do this, we act like we are setting the variable again,
except that we are giving it no value this time.]
@set me=third/prime:
ex me=third/
No properties listed.
[There. It's gone. Now let's list the bottom level properties again.]
ex me=/
first/: (string) a property.
second: (string) another property.
[Whoops! The property 'third' is gone too! This is because properties
with no values are automatically deleted when their last sub-property is
deleted. Let's delete a subproperty from 'first', now.]
@set me=first/one:
ex me=/
first/: (string) a property.
second: (string) another property.
[The property 'first' still exists, with it's string value, and it still
has sub-properties. Lets list those.]
ex me=first/
first/two: (string) Another property in a propdir.
[Here we see that the sub-property 'one' is gone, as we expected. Let's
see what happens when you erase a property that has sub-properties.]
@set me=first:
ex me=/
second: (string) another property.
[The property 'first' is gone.]
ex me=first/
No properties listed.
[And the subproperty it had is gone too! Let's remake the 'first' prop.]
@set me=first:again, a property.
ex me=/
first: (string) again, a property.
second: (string) another property.
[We have two properties again, and no sub-properties. It should be
noted that sub-properties can have sub-sub-properties, and they can
contain even subbier properties, and so on and so forth.]
@set me=first/one:uno
@set me=first/one/example:dos
@set me=first/two/example:tres
@set me=first/one/example/cat:meow
ex me=first/
first/one/: (string) uno
first/two/: (no value)
ex me=first/one/
first/one/example/: (string) dos
ex me=first/one/example/
first/one/example/cat: (string) meow
[There is a special case in examine to let us list ALL the properties and
sub-properties of a prop. To use it, we just specify '**' as a propdir.
For example, to list all sub-properties and sub-sub-properties, etc.,
under 'first', you would do the following:]
ex me=first/**
first/one/: (string) uno
first/one/example/: (string) dos
first/one/example/cat: (string) meow
first/two/: (no value)
first/two/example/: (string) tres
[Let's delete all the properties on the object, now. To do that, we
specify no property name or value when we use @set. Nothing but a
colon.]
@set me=:
ex me=/
No properties listed.
Property Copying:
Propcp Global:
Copies properties of objects onto other objects.
General info: ( ----- cp/mv: copy/move prop ---- )
cp [origobj][=prop],[destobj][=destprop]
Copies prop from origobj to destobj, renaming it to destprop.
mv [origobj][=prop],[destobj][=destprop]
Moves prop from origobj to destobj, renaming it to destprop.
Arguments in []s are optional.
if origobj is omitted, it assumes a property on the user.
if destobj is omitten, it assumes destobj is the same as origobj.
if destprop is omitted, it assumes the same name as prop.
if prop is omitted, it prompts for it.
if both prop and origobj are omitted, it prompts for both.
if both destobj and destprop are omitted, it prompts for them.
NOTE1: 'virtual props' such as @desc, @succ, can be copied/moved.
NOTE2: 'prop' may be a unix-style pattern. ( See page 1 and 2 )
Page 1: Pattern matching ( * ? [] {} )
Page 2: Virtual properties ( @desc, @succ, @fail... )
Page 3: Using cp and mv in your MUF programs
Page 4: More routines usable for MUF programs
Page 5: Program bugs and quirks
Page 1: ( ----- Pattern matching ----- )
A pattern matching feature has been added to the program to allow matching
unix-style patterns (when copying and moving properties. The unix-style
wildcards *, ?, [], and {} are available. Examples should be helpful...
Examples:
cp me = *hug* , object ---> This copies all properties on the user (me) to
an object such as 'malehug' 'hugmesg' 'chuga'. Note this would include all
properties in propdirs as well such as 'hug/fox' 'alpha/test/hug3'
NOTICE: The DESTINATION property name is NOT pattern matched.
mv item = d-* , = desc_* ---> This would take properties such as
'd-cabinet' and rename them to 'desc_*/d-cabinet' so watch out for this.
You can however, match items in a propdir and put those items in a different
propdir .
mv thing = tax/o* , widget = irs ---> This will match properties such as
'tax/osucc' and 'tax/over' on "thing" and name them to 'irs/osucc' and
'irs/over' on "widget".
cp me = * , storage ---> This will copy EVERY property on the user,
(including @desc, @lock, @osucc...) and put them on an object, "storage".
If your property contains one of the wildcard characters (e.g. 'star*time')
you can escape ANY wildcard by preceeding it with a backslash ('star\*time').
You can escape a backslash by using 2 backslashes.
Page 2: ( ----- Virtual properties ----- )
Virtual properties ( @desc, @succ, @osucc, @fail, @ofail, @drop, @odrop ) are
supported by this program.
NEW FEATURE: @LOCK and @IDESC have recently been added )
These only work if pattern matching ISN'T being used.
Example: cp push=succ-list5,=@succ
Copy the property 'succ-list5' to the @succ on 'push'.
In FB Muck, what we see as '@desc', '@succ'... is really stored as standard
properties '_/de', '_/su'... Keep this in mind if you try something silly
like copying an entire propdir to '@succ'.
In addition to the 9 virtual props mentioned, you can copy all of the
virtual props by specifying '@all' (this copies the propdir '_/') This also
copies/moves anything else that happens to be in the propdir '_/' as well.
Page 3: ( ----- Using cp and mv in your MUF programs ----- )
The routines used for cp and mv have been made public.
cp-prop ( d1 s1 d2 s2 -- count )
Copies prop/propdir 's1' from item d1 to item 'd2' renaming it to 's2'.
mv-prop ( d1 s1 d2 s2 -- count )
Moves prop/propdir from item d1 to item 'd2' renaming it to 's2'.
For both of these, 'count' the number of properties moved (integer).
Virtual properties and pattern matching can be used with both routines.
For further info on these features, see pages 1 - 2 --More--
These routines are set 'public'. If this program isn't @registerd, ask the
owner for the dbref# so you can use 'call' or '$include.'
Page 4: ( ----- More routines usable for MUF programs ----- )
cp-1 ( d1 s1 d2 s2 -- b )
Copy one property 's1' from 'd1' to 'd2' naming it 's2'.
mv-1 ( d1 s1 d2 s2 -- b )
Move one property 's1' from 'd1' to 'd2' naming it 's2'.
For both of these routines, 'b'=1 if successful, 0 if not. These
routines are designed to be MUCH quicker than 'cp-prop' or 'mv-prop' and
are good if you're only copying or moving one property with no pattern
matching or propdir copying. To increase speed, these routines don't check
the validity of the objects or property names.
confirm-cpmv ( d1 s1 d2 s2 -- d1 s1 d2 s2 b )
Confirm existance of 'd1' and 'd2' ( print error message if bad ) and clean
up 's1' and 's2' ( remove extra '/'s and spaces. Also turn a blank string
into '/' {root} ). b = 1 if 'd1' and 'd2' are okay, 0 if not.
This routine can be used immediatly before a cp-1 or mv-1 like this. [
.... confirm-cpmv if cp-1 then ]
Page 5: ( ----- Bugs and other Quirks ----- )
Pattern matching doesn't work in the destination property (think about it..
how CAN it). Something like> cp me=a*,object=b* will simply copy all
properties on you beginning with 'a' into a propdir 'b*' on 'object' This is
stated on page 1, but restated here because I've heard of this happening to
too many people.
The recursive bug where if you put a directory in one of its subdirectories
( eg. cp me = dir , me = dir/alpha ) has been fixed. YAY :)
If you find any bugs in this program, please contact me (Foxx Fox) via page
#mail or e-mail (fir...@cae.wisc.edu) if I'm not around. PLEASE tell me
as much about the situation as possible, especially the exact thing you typed
to get the error. This will greatly improve bug-detection. -----
/\ ----- signed .-o_ \ ----- `-/ / Foxx Fox -----
Appendix B: Globals
Globals Listing Utility
-----------------------
This program lists global commands available on this MUCK.
> globals #help -- shows this screen
> globals #list -- complete alphabetized global listing
> globals #page -- lists pages available
> globals #page {n} -- lists indicated page
> globals {name} -- shows info on indicated global
globals #list
Complete Globals Listing
Global Description Help Info
---------------------------------------------------
. set up a private talk session. #help
3who as "WHO", but formatted in 3 columns look 3who
@Archive to make archives of constructed areas @archive =help
@Backlink make an exit back to current location look @backlink
@Bootme boots off duplicate character connections look @bootme
@Breaklink remove links to your character/property @breaklink #help
@Bulletin show messages of general importance (none)
@Image Find a .gif of character on 'net. @image #help
@Quota shows your building quotas and totals (none)
@Recycle! recycle an item or room remotely by dbref # (none)
@Relink unlinks, attempts to relink action/room look @relink
@Shout for public general-interest announcements @shout #help
@Size "@size {item}" calculates memory taken up (none)
@Sizeall calculates your entire memory usage (none)
@Unparent set parent of room to default (#0) look @unparent
Antivirus for detecting "viruses" antivirus #help
AutoSweep send you home when disconnected as
Banish to keep out pesky players banish #help
Change make small changes to messages/properties change
Commands shows locally-available "globals" commands #help
Contents show contents of a room look contents
Doing set "doing"/ see what others are doing do #help
Eat eat or drink "food" or beverages eat #help
Edit edit messages/properties (needs TinyFugue) edit
Editaction utility to aid in editing actions editaction #help
Editroom utility to aid in editing rooms editroom #help
Exits show the exits from a room exits #help
Globals lists actions available MUCK-wide globals #help
Goband global exit shortcut to Under the Bandstand (none)
Gohome global exit shortcut to your home (none)
Hand hand an object to someone hand #help
Helpstaff shows helpstaff members online (none)
Hug hug something or someone hug
List displays a list of properties look list
Lookat look at objects people are carrying lookat #help
Lsedit edit a list of properties look lsedit
Map shows a map of area and your position map #help
Morph (Poly)morph into different forms morph #help
Muckers shows programmers online (none)
Mumble garbled "whisper" for roleplaying look mumble
Navigate shows path to destination in certain areas nav #help
Nexus global exit shortcut to Underground Nexus (none)
Page send messages to players wherever they are page #help
Pet allows creation of a "pet" to follow you pet #help
Pinfo IC/OOC player/character information pinfo #help
Pose action message look pose
Programs lists publicly usable programs programs #help
Propcp copy properties from one object to another propcp #help
Propmv move properties from one object to another propmv #help
Pupcheck detects any puppets in area pupcheck #help
Pwho allows you to maintain a personal "WHO" listing pwho #help
Ride for riding other characters to other rooms ride #help
Roll to "roll dice" for online gaming look roll
Run moves between several rooms quickly look run
Say say something sayhelp
Show display properties/messages on an object show @help
Smell smell something or someone smell #help
Spoof anonymous messages for special effects spoof #help
Sweep send sleeping characters home sweep #help
Taxi take the taxi to various locations (none)
Think send customized messages to players in same room think
Throw throw something to someone throw #help
Watchfor notifies you when a player logs on/off watchfor #help
Whatis special information utility whatis #help
WhereAre See players located in certain popular rooms wa #help
Whereis shows locations of players specified whereis #help
Whisper send messages to players in same room whisper #help Who
show awake and sleeping players in the same room (none)
Whodo "WHO" listing with "doing" entries wd #help
Whospe shows the species and gender of players in room ws #help
Wizzes shows Wizards online (none)
>globals #page
1) Informational Globals
2) Player Information Globals
3) Communications Globals
4) Roleplaying Globals
5) Room Building and Maintenance
6) Other Toolkit Globals
7) Travel Globals
8) Miscellaneous Globals
Page 1 -- Informational Globals
Global Description Help Info
-------------------------------------------------------------------------
@Bulletin show messages of general importance (none)
Commands shows locally-available "globals" commands #help
Globals lists actions available MUCK-wide globals #help
Hand hand an object to someone hand #help
Helpstaff shows helpstaff members online (none)
Muckers shows programmers online (none)
Programs lists publicly usable programs programs #help
Pupcheck detects any puppets in area pupcheck #help
Wizzes shows Wizards online (none)
Page 2 -- Player Information Globals
Global Description Help Info
---------------------------------------------------------------------------
3who as "WHO", but formatted in 3 columns look 3who
@Image Shows where to find a .gif of character on 'net. @image #help
Doing set "doing" prop / see what others are doing do #help
Pinfo IC/OOC player/character information pinfo #help
Pwho allows you to maintain a personal "WHO" listing pwho #help
Watchfor notifies you when a player logs on/off watchfor #help
Whatis special information utility whatis #help
WhereAre See players located in certain popular rooms wa #help
Whereis shows locations of players specified whereis #help
Who show awake and sleeping players in the same room (none)
Whodo "WHO" listing with "doing" entries wd #help
Whospe shows the species and gender of players in room ws #help
Page 3 -- Communications Globals
Global Description Help Info
-------------------------------------------------------------------------
. set up a private talk session to another player . #help
@Shout for public general-interest announcements @shout #help
Page send messages to players wherever they are page #help
Say say something sayhelp
Think send customized messages to players in same room think
Whisper send messages to players in same room whisper #help
Page 4 -- Roleplaying Globals
Global Description Help Info
-----------------------------------------------------------------------
Eat eat or drink "food" or beverages eat #help
Hug hug something or someone hug
Lookat look at objects people are carrying lookat #help
Morph (Poly)morph into different forms morph #help
Mumble garbled "whisper" for roleplaying look mumble
Pet allows creation of a "pet" to follow you pet #help
Pose action message look pose
Ride for riding other characters to other rooms ride #help
Roll to "roll dice" for online gaming look roll
Smell smell something or someone smell #help
Spoof anonymous messages for special effects spoof #help
Throw throw something to someone throw #help
Page 5 -- Room Building and Maintenance
Global Description Help Info
------------------------------------------------------------------------
@Archive to make archives of constructed areas @archive =help
@Backlink make an exit back to current location look @backlink
@Unparent set parent of room to default (#0) look @unparent
Contents show contents of a room look contents
Editroom utility to aid in editing rooms editroom #help
Exits show the exits from a room exits #help
Page 6 -- Other Toolkit Globals
Global Description Help Info
-----------------------------------------------------------------------
@Breaklink remove links to your character/property @breaklink #help
@Recycle! recycle an item or room remotely by dbref # (none)
@Relink unlinks, attempts to relink action/room look @relink
Change make small changes to messages/properties change
Edit edit messages/properties (needs TinyFugue) edit
Editaction utility to aid in editing actions editaction #help
List displays a list of properties look list
Lsedit edit a list of properties look lsedit
Propcp copy properties from one object to another propcp #help
Propmv move properties from one object to another propmv #help
Show display properties/messages on anject show @help
Page 7 -- Travel Globals
Global Description Help Info
-------------------------------------------------------------------------
Goband global exit shortcut to Under the Bandstand (none)
Gohome global exit shortcut to your home (none)
Map shows a map of area and your position map #help
Navigate shows path to destination in certain areas nav #help
Nexus global exit shortcut to Underground Nexus (none)
Taxi take the taxi to various locations (none)
Page 8 -- Miscellaneous Globals
Global Description Help Info
------------------------------------------------------------------------
@Bootme boots off duplicate character connections look @bootme
@Quota shows your building quotas and totals (none)
@Size "@size {item}" calculates memory taken up (none)
@Sizeall calculates your entire memory usage (none)
Antivirus for detecting "viruses" antivirus #help
AutoSweep send your character home when disconnected as
Banish to keep out pesky players banish #help
Run moves between several rooms quickly look run
Sweep send sleeping characters home sweep #help
Appendix C: Help Indexes And Topics
Help Index1
@action @attach @boot @chown @contents
@create @describe @dig @drop @dump
@edit @entrances @fail @find @force
@link @lock @kill @name @newpassword
@ofail @open @osuccess @owned @password
@pcreate @program @ps @recycle @set
@shutdown @stats @success @teleport @toad
@unlink @unlock @usage @wall @idescribe
Local MUF additions
@exits @purge @when
Help Index2
(type help <topic> to see help on these topics.)
bogus commands control costs drop
drop-to failure flags gender goal
god here homes killing linking
me money new number objects
robbery strings substitutions success timestamps
types
For news on a subject, type 'news [subject]'.
Current Subjects:
aup toading
wizards changes motd configuration
muckers policies getcharacter zombies
staff glossary mpi principles