Before you can create or build anything, you need a BUILDER bit. On Furscape we encourage just about everyone to build, so if you don't have a builder bit, it's probably due to an oversight. You may also require PENNIES. Just ask a wizard for help.

Although we have a lot of tools to do building work, sometimes you will need to work with flags and properties directly.

A flag is a simple on-or-off switch applied to an object. The same flag can have different effects on different types of objects. For example, D stands for DARK when applied to rooms, things or actions. D stands for DEBUG when applied to a MUF program. You can get a full list of flags by typing: help flags

Flags are set or cleared using the @set command:

@set <object>=<flag>

. . .and cleared by adding an exclamation point (!) which stands for “not”. . .

@set <object>=!<flag>

An example may help. Let's imagine we have a mushroom that we want to make sticky, but not dark:

@set mushroom=s
@set mushroom=!d

You can see the flags on an object (and a lot of other useful information) anytime by using examine on it. (You can also use ex for short – remember that most commands can be shortened in this way!) The same command also is used for viewing properties.

A property is a piece of information assigned a name and tacked onto an object. The types of information can be numbers, text strings, dbrefs, lock values. . . but most often they are strings. Property names work similar to the filesystem in a computer, so you can organize properties into directories. Properties are also set using the @set command. Here's an example:

@set car=appearance/paintcolor:red

It sets a property named “appearance/paintcolor” with a string value of “red”. In this case “appearance/” is a directory, also called a propdir, which could contain any number of sub-properties. Unlike some other systems you might be familiar with, on the MUCK propdirs themselves can have values. So, both “appearance” and “appearance/paintcolor” could possibly have their own different values.

You can view properties using examine. It requires a wildcard to tell the MUCK which properties on the object you want to see. To see all the properties on the object youwould enter ex car=/**. To see only the contents of “appearance” you would enter ex car=appearance/**. The more you learn about the use of Unix-style wildcards, the more flexibly you can use this command.

The basic command for creating rooms is @dig. For example, let us suppose you want to create a cave for yourself. You can type:

@dig My Cave

It creates the room named “My Cave” and gives you a dbref number, which you can use to access the room. Let us say, just for example, that the number of your room was #4567. To get there, you can go two ways:

@tel me=#4567   

. . .or. . .

 tel #4567

With teleport (often shortened as tel or tport) you can move yourself to any room you control, and you can “bookmark” rooms that you visit often. With @teleport you can move any object you control, including things and rooms. In this case the thing you are moving is “me”. However, “me” can also be the destination of @teleport. That would happen when you are moving a thing into your inventory.

Once you have gotten into your room, try running the Room Hammer, or editroom, program! This program is menu-driven and allows you to adjust many properties on your room – it packs a lot of power. Everything that Editroom does could also be done with individual commands, one at a time, so the choice of using Editroom or other commands is one of personal preference and experience.

Some commands are highly useful for fixing mistakes. If an object is totally botched, you can @recycle (or @rec) it and create a new one. However, you shouldn't always rush to use @rec, because often small problems can be fixed with a command or two. If an object is in the wrong place, you can @teleport it somewhere else. If an action is linked to the wrong object, you can @unlink and then @link it to a different one. If an action is in the wrong place, you can @attach it to a different location. The more you learn about the building commands, the easier these kinds of fixes will come to you. Many of the same changes can also be made using Editroom if you are willing to dig into its menus a bit.

If you have a room that isn't linked to anything and you have forgotten the dbref number, you can find it using this command:

@find *=R

It will show a list of all rooms that you own, along with their dbrefs. Then you can use @teleport or teleport commands to reach them, and proceed from there. If you study its options, @find is a powerful command that can be used to locate all kinds of lost objects, not only rooms.

The lsedit command is one you will be using a lot. You have probably already figured out how to set a brief description on an object using the @describe command. You may also have discovered you can't add more than one line of text using @desc. The way around this is by using what we call a proplist (for “property list”). Proplists are created and editing using Lsedit. The syntax is:

lsedit <object>=<list name>

Once into Lsedit, you can get a full list of commands by entering “.h”. There are a lot of commands, but very few that you need to use most of the time. Most builders edit their code on their own computer using a text editor such as TextEdit or NotePad, then cut-and-paste the text into Lsedit. The important commands, generally speaking, are:

• .del = delete text. “.del 1-1000” would delete 1000 lines
• .l = show the text, so you can see if it was entered correctly
• .p = show the text with line numbers visible
• .end = save your work and leave the editor
• .abort = leave the editor without saving

You should know about a special quirk with Lsedit. Property lists can't store a truly blank line – if you try to paste in a line of text containing no characters, it'll be lost. You need to edit your files so each line contains at least one character, even if it's nothing more than a blank space.

So, we can edit a proplist, but how do you make it appear in a description? Here's the way to do it. . .

lsedit here=redesc
   <paste your text>
.end
@desc here={list:redesc}

Redesc is the name of your proplist. It could be named anything, but the Morph program uses “redesc”, and it has become a convention to use as the name for any description proplist. The part that reads {list:redesc} is a little bit of MPI code. It's using MPI's {list:} function to read redesc from your room and show it to the player.

ANSI colors can provide a neat optical effect for emphasis or decoration in the body of an object or room's description. ANSI color codes are shown automatically when they appear in descriptions, including fake objects. Here's an example of using ANSI color in a description:

@desc my shoe=You see a ^red^bright ruby red^normal^ slipper.

When using color in action messages (@succ, @fail, etc.) you must use the MPI functions {ansi:} or {color:} to make them appear. For example:

@succ aft={color:You move aft through the ^green^green^normal^ corridor.}

ProtoMUCK can parse many kinds of ANSI codes, but far the most convenient are NeonMUCK (or GlowMUCK) compatible codes. Type “colors” and you'll see a menu of all available Neon codes for colors and text formats. It should look roughly like this:

Unfortunately there are a lot of variations among the way client programs handle ANSI color. No two ever seem to have exactly the same color palette, so colors like yellow, for example, can range from bright yellow to amber to “yucky brown”. Some client programs do not support half-bright colors such as crimson or navy – instead they may show half-bright colors as standard text and full-bright colors as bold text. Some may have trouble displaying black or gloom. Some clients, such as the one displayed in our snapshot, may not handle inverse text. Most clients don't handle flashing text properly – some show flashing text as italic while many others simply ignore the flashing code.

Still, most of the common text colors and background colors will work in some way.

Exits are the usual way of moving from one room to another. Each exit is an object with a dbref number, flags, and its own set of properties. We say an exit is “attached” to the origin room, and “linked” to the destination room. An exit only goes one way. To go from room A to room B requires one exit, and to return from room B to room A requires a second exit. The command used to create an exit is:

@action <name>=<source>[,<destination>][=<regname>]

The destination is optional, if you don't supply one the exit will be unlinked – it has no destination, but you can add one later using @link. The regname is also optional and most often used by MUF programs. So, for example. . . Let us say you want to create an exit from where you are, going north to a room with the dbref number of #2345. Your command might look like:

@action North;n=here,#2345

When naming exits, you should understand the conventions used by the MUCK. The name of an exit can be divided up using semicolons (;). Each part of the name then can be recognized by the MUCK to trigger the action. Let's say, for example, that you create an exit going into a building and name it: North;n;enter;in. A player will be able to use it by entering north or n or enter or in. However, if you have made exits visible in your room, only the name up to the first semicolon will be shown.

We also have an often-used convention of putting abbreviations in parenthesis. A very typical kind of exit would be:

Northwest (NW);northwest;nw

In this case the player sees Northwest (NW) in the room description, and the exit is triggered by typing northwest or nw. It would also be triggered if the user entered “northwest (nw)”, but nobody is ever likely to do that.

Sometimes an abbreviation is based on two or three words, and this can cause confusion. For example, let's say we have an exit leading into a “Turbo Lift” and we want ot trigger it with TL. We might be tempted to name our exit this way:

@action (T)urbo (L)ift;tl;lift=here

This is wrong! It looks messy and can be confusing. The player may think: “Am I supposed to type T or L here?” The preferred way to name it would be like this:

@action Turbo Lift (TL);tl;lift=here

When naming exits there are some names you probably should try to avoid, especially names that conflict with commonly used MUCK commands. Some examples would be P (for page) or W (for whisper). If you have a W exit in your room, anyone who tries to use W for whisper will trigger the exit instead. This might not matter in an outdoors setting, but would be highly inconvenient in a room where players gather and socialize.

Incidentally, exits can be linked to objects other than rooms. An exit linked to a MUF program is usually referred to as an “action”, although the MUCK doesn't really treat them any differently. Instead of moving the player, trigging an action causes the MUF program to run.

When you trigger an exit or an action, you should get some feedback from the MUCK telling you what has happened. We have special commands for this purpose:

• @succ = success message seen by the player
• @osucc = success message seen by others in the room
• @fail = failure message seen by the player
• @ofail = failure message seen by others
• @drop = message seen by the player at his destination
• @odrop = message seen by others at the destination

A typical example will illustrate the use of these messages. Let us imagine I am creating an exit from my kitchen to my living room. I might do it this way:

@action Living Room (LR);lr=here,#78965
@desc lr=You can see the living room is through that doorway.
@succ lr=You wander into the living room.
@osucc lr=wanders into the living room.
@odrop lr=wanders in from the kitchen.

Since the doorway is not locked, the @fail and @ofail messages are not needed here. @drop likewise is not often used. Note that exits can have an @desc, and players can look at them. Now, when I use this exit, I will first see:

You wander into the living room.

At the same time other players in the kitchen will see:

Zobeid wanders into the living room.

My name is automatically prepended to @osucc, @ofail and @odrop messages. After these message are shown, I am moved into the living room and automatically shown the room desc. Then any other players who may be in the living room will see:

Zobeid wanders in from the kitchen.

These messages make it easier for everyone to understand what is happening around them. When building your area, you should use the @check command to see which exits are missing imporant message. Simply type @check and you will get a list of all objects in the room (including the room itself, but not including players) which are missing some of their messages, and which messages they don't have.

You should also be aware that these messages can include MPI code which will execute. Therefore, you can create an action linked to $nothing, but with MPI code in the @succ message. This is a commonly used way of creating MPI-based commands.

All messages are set as properties on the object, and in fact you can also set them using the generic @set command. For example, the following commands are equivalent:

@succ d=You go down the stairs.
@set d=_/sc:You go down the stairs.

If you are new to building, one of the first things you should do in your room is make exits visible. The easiest way is using option 2 in Editroom. It can also be set using a property:

@succ here=@$obvexits

This is not required, but it makes building easier when you can see what you are doing. If you want to make the exits invisible later (so that other players don't know what they are), you can toggle them off again using Editroom, or by clearing the property (@succ here=). Leaving the exits visible is usually a good idea, unless you have some reason in mind why other players shouldn't see them (like in a maze, maybe). For building in public areas, visible exits are practically a requirement.

Also note… If you want most exits in a room to be visible, but want to hide a particular one, you can set a DARK (D) flag on it:

@set <exit name>=dark

This can also be done using Editroom: select X to edit exits, then select the number of the exit you want to edit, then D to toggle the DARK flag or or off.

If you are a creating a role-playing or puzzle area with hidden exits, you should make them reasonably findable. A good rule of thumb is that the exit name should at least be a word appearing somewhere in the room desc, unless you have prepared some other clue for the players. If you have an exit that is really private and others are not intended to use, it is a very good idea to @lock it. The management cannot guarantee players won't be able to detect your exit by some means, so putting @lock on your private exits or paths is just good sense.

There is a convenient command, @excavate, which you can use to create a room, create an exit leading from your current location to the new room, and create another exit leading from the new room back to your location. The syntax is:

@excavate <roomname> [=<exitname> [=<returnexitname>] ]

Let's say you want to create a hut in your area. You could use a command something like this:

@excavate Inside the Hut=Enter Hut;enter;hut=Outside;out;o

It creates a room named “Inside the Hut”, creates an exit named “Enter Hut;enter;hut” leading into the room, and creates another exit named “Outside;out;o” leading back out of it. You should note that many flags and settings are copied from the room you are in and applied to the new room. You can edit a room, configure it with the settings you like, and then use @excavate repeatedly to create a whole area with the same settings.

When you are creating new rooms using the R command in Editroom, it will prompt you for the same information: first the name of the new room, then the name of an exit leading into the room, and then the name of an exit leading back out. So, you can do exactly the same kind of building as you would with @excavate.

Most players soon discover that they can @create things. Your basic object of type “thing” can be carried around by players in their inventory, or dropped in a room. You can use @desc to add a description and look at it just as you would look at a player. This is fine for simple props, but you can also do more sophisticated things with things.

A thing can contain other things, and it also can have exits or actions attached to it. That means you could carry around a portable “doorway” leading to another room, or you could carry a thing with a MUF action attached. The action is usuable when you are carrying the thing or when the thing is in the same room with you.

If you set the STICKY (or S) flag on a thing, it will return to its home location when it is dropped. The home is set using the @link command. This is useful when creating objects that other players may use temporarily. For example, in your spaceship you could have space suits set STICKY and @linked to the airlock. Other players could take and wear them, but as soon as they drop the suit it would come back to your ship.

You can also use @lock to control who is able to pick up your thing. To make an object immobile, you could use these commands:

@link mything=here
@lock mything=me

Now nobody but you can pick it up. (You could also lock it to “me&!me” – me and not me – a conditon that can never be met, which would even prevent you from accidentally picking it up.) However, you or a wizard could still move it using @teleport. Linking your thing to the room means if it ever does somehow get moved, it ought to eventually be swept back home where it belongs.

You can create container objects which are able to hold other objects in them. This could be something as simple as a backpack. Unlike some other MUCKs, you cannot use any random object as a container on Furscape. To make a thing into a container, use this command:

put #setup <thing>

You can also control who is able to put things into your container or take things out of it using the @conlock command, like this:

@conlock <container>=<lockstring>

Please see the section on locks if you aren't sure how they work.

When the DARK (D) flag is set on a room, the description of the room is still shown, but the contents of the room are not visible. When the DARK flag is set on a thing, the thing won't be seen in the content listing of the room, container or player where it's located. When DARK is set on an exit, it will not appear in the obvious exits listing of the room (as shown by $ObvExits).

You can set a property on your container:

@set <container>=_/co:<fake contents>

This will show the property value to anyone who looks at the container instead of the actual contents. Note that you can use MPI code on this property to generate your own custom contents listing. It is also possible to set this property on yourself or on a room.

A lock is really a test that a character must pass before he can do something, such as go through an exit or pick up a thing. We have special programs for setting different kinds of locks on Furscape, but they all work pretty much the same way. Let's start with the example of locking a box…

@lock box=me

After doing this, only you will be able to pick the box up. Anybody else will get a message telling them they cannot. Let's suppose you want your friend Mina to be able to pick it up also…

@lock box=me|*mina

In this example, the “|” character means OR. In other words, to pass the test and take the box, the character must be “me OR Mina”. The “*” character in front of Mina is used to make sure the lock understands Mina is a player. It tracks Mina's DBREF number, so even if Mina were to change her name, the lock would still refer to her. You can lock an object to as many different characters as you want this way.

Now let's imagine you want anybody to be able to take the box – except one character named Joel. Here's how you do it…

@lock box=!*joel

The exclamation point “!” means NOT. To pass the test, the character picking up the box must be “NOT Joel”. Note again… Even if Joel changes his name, he's still locked out.

Now… You might assume that “box” is a container, and the lock will keep people from putting things in it or taking things out. That's not so. The lock only keeps characters from picking it up. To lock a container you must do something like:

@conlock box=!*joel

It works the same way, but this time we are locking access to the contents instead of the thing itself.

You can also lock actions and exits. Let's assume you have an exit leading into your closet, and you want to lock out other characters.

@lock closet=me

It is possible to lock objects to properties instead of characters. For example:

@lock closet=closet-key?:yes

To pass this test, you must have a property “closet-key?:yes” set on your character, or set on something your character is carrying. So, you could create things to serve as keys like this:

@create gold key
@set gold key=closet-key?:yes

Then hand out the keys only to those furs who are allowed in your closet.

It is also possible to create special locks using MUF programs. However, that is an advanced technique. In such cases you should refer to the MUF's instructions to see how it must be set up.

If you are building an area with two or more rooms, you can benefit a lot from setting up a “parent” or “environment” room. It's simply a room that contains your other rooms. Why? It allows you to set actions or properties that will affect all your sub-rooms, so that you don't have to set up the same actions and properties in each one. Many programs look for environment properties. For example, if you want to prevent characters from teleporting into your area, you can go to your parent room and do:

@set here=_tel/in?:no

You only have to set this once in the parent room, you don't have to set it on each sub-room. BANISH is another program that recognizes parent rooms. So, you can banish someone from the parent, and they are automatically kept out of the sub-rooms too.

Another neat trick is your ability to enter and exit rooms. If you are in a sub-room, you can exit into the parent. There you can see your sub-rooms listed and easily enter one of them. This is very handy when building large areas and working on many rooms.

You can use Editroom to change the parent of a room you have built. When making a new room, the default parent is the same parent of the room you were already in. This means once you've created a parent room and your first sub-room, you can build with Editroom or @excavate and all the new rooms will go under the same parent.

Finally you can use ''@tel'' to change the parent of a room. For example, let's say you have created a parent room for your apartment. You already have made a kitchen and you want to set the parent for it:

@tel (dbref of kitchen)=(dbref of parent)

or if you are standing in the parent room…

@tel (dbref of kitchen)=here

It is important to emphasize that parent rooms serve merely as containers for other rooms. You should never link a parent room to the rest of the MUCK. There is no reason to put a description on a parent room, except perhaps builder's notes or notes for staffers to read. Other players won't be going there, won't be seeing it.

Environment rooms are key to organizing the structure of the MUCK, and our building wizards may become cranky if you don't use them. A wizard does not want to enter an area he's responsible for and find somebody has created a 20-room home in the middle of his stuff. Finding that you have created your home's parent room in his area, and all the other 20 rooms are neatly contained in that parent, is what the building wizard would like to see.

A fake object is something in a room that appears to be a thing, but it's really constructed from properties on the room. The look program is responsible for reading those properties and making the fake object appear in the room's contents. There is really nothing that can be done using fakes that couldn't be down using real objects. However, the advantage of fake objects is that they don't take up dbref nodes, and they can't be moved – even by accident. Fakes and details are especially useful when a room desc is growing very long. You can put a basic description on the room, and then add fake objects and details which players can look at when they are ready, instead of having to read a single, long description.

The @object command is used to create fake objects which are visible in the room's contents, as if they were real objects. The @detail command creates fakes which are not visible in the room's contents, much like DARK objects. When creating details you need to give players some clue, such as something in the room's description, so they can figure out what to look at. As with many commands, you can enter “@object #help” for a summary of the options. With either kind of fake – objects or details – the description can include MPI code. Take note… When looking at your own room, you will see fakes listed in the room contents, but they have a “(fake)” tag beside them, and details will show “(fake) [Dark]”. These tags are not seen by others who don't control your room.

And yes, you can put look-traps or fake objects on yourself, to expand on the description of your character.

The MUCK keeps track of the owner of each object. Objects can only be modified or deleted by someone who “controls” the object, which usually means the owner or a wizard. There are special rules for passing ownership of an object from one player to another. This is mostly done using the @chown command and the CHOWN_OK (C) flag.

Let's say you have a keychain you want to give to your friend. You can hand it to him… But it still belongs to you – you still control it. He can carry the object around, look at it, use it, drop it – but he can't modify it. How do we really make it his? Try this:

@set keychain=chown_ok

. . .or. . .

@set keychain=c

Then give it to your friend and have him do this:

@chown keychain

If the CHOWN_OK or C flag is set on an object, anybody may use @chown to take possession of it. It would probably be a good idea for your friend to type this too:

@set keychain=!chown_ok

. . .or. . .

@set keychain=!c

That removes the flag so the object can no longer be claimed by anyone who holds it.

What if you want to leave something for your friend Mina to claim, but nobody else? You can use a lock for this. The command is @chlock. Here's how it works:

@set keychain=c
@chlock keychain=*mina

Now, any other characters but Mina will fail the lock test and be unable to claim the thing. This can be very useful if you are cooperating with someone on a building project. Let's say for example that you are working with Mina and Joel to build an area. You could set the rooms like this:

@set here=c
@chlock here=me|*mina|*joel

Now any of you three can @chown the room and work on it, but others cannot. Keep in mind, you are extending trust to these people. Either of them could clear the C flag and simply keep the room, then you would have no way to get it back.

Using @chown and @chlock, multiple players can build an area together, cooperatively – but it can be pretty cumbersome. ProtoMUCK has some new features to make this easier. One of them is the CONTROLS (~) flag. If you set this flag on an object, and then @chlock the object, then anybody who passes the lock has control over the object. They can modify it, and basically do anything except change the @chlock value, or set or remove the CHOWN_OK or CONTROLS flags.

Another new feature is Realms Control. First you must call on a wizard to set the WIZARD (W2) flag on your environment room. Then you can set the CONTROLS (~) flag on it, and also set an @chlock value. Anybody who passes the lock test will be able to control objects in the environment. This would be perfect if you are cooperatively building a large area (perhaps the interior of a spaceship?) with several other players.

There are special rules for control of exits and actions. If you own a thing or room and it has an action attached to it that belongs to someone else, you can @echown the action – even if it wasn't set CHOWN_OK. This is helpful when passing a thing or a room to another player, so you don't have to set C and @chlock permissions on every action.

Also, if some other player has an exit linked to your room, you can @echown the exit and modify or delete it. This means you can modify the entrance to your home or even unlink it from somebody else's area without having to get help from them.

MPI (Message Parsing Interpreter) is a programming language most often used for creating complex descriptions, although it can be used for much more. Explaining how to program with MPI is beyond the scope of this guide, but there are a few policy matters to note: Anyone is allowed to use MPI code. It is possible that the wizards could forbid a player from using MPI if he has abused it, but this would be highly unusual. If any wizards have a problem with something you have created in MPI code, they can ask you to remove the offending code from service, and you will be expected to comply.

For more information about MPI programming, I suggest: http://www.furtoonia.net/mpi.html

MUF (Multi-User Forth) is a powerful Forth-based language which most of the MUCK's programs are written in. Players may be allowed to program MUF, but this involves an extension of trust. If you want to program with MUF, you must ask a MUF wizard for a special flag. You will most likely be given an M1 flag first, which allows MUF programming with restrictions similar to MPI. M1 flags are given for the purpose of learning MUF with a view toward graduating to M2 at some later date. If you are given M2, you will be able to create MUF programs with fewer restrictions. Abusing MUF to spy on other players or tamper with their possesions is a serious offense, and will result in the loss of your MUF programming flags – at the very least. Access to MUF programming higher than M2 is given only to programmers who are both trusted and have special needs.

For more information about MUF, you could start here: http://www.geocities.com/mufprogramming/ (note broken link, we need to find another MUF tutorial!)

Furscape is a roleplay-oriented MUCK with multiple planets, each of which has its own culture and conventions. The rules of accepted behavior can and do vary. You can use the realm command to see what the rules are in a local area. If you have built your own area, you can set your own local rules and RP information for the realm command.

To set up your area, you must put properties on your environment room. Here are the default values we use on room #0 at Furscape:

@set #0=_realm/name:Furscape
@set #0=_realm/manager:Furscape Wizards
@set #0=_realm/blurb:Generic Environment
@set #0=_realm/rating:R
@set #0=_realm/rcs:Not Required
@set #0=_realm/chat:Allowed
@set #0=_realm/rp:Allowed

You can use this as an example of how to set the properties on your own rooms. Just substitute your environment room's dbref number {or “here”} in place of #0, and your own value in place of the text. Such as….

@set here=_realm/name:Playfox Mansion
@set here=_realm/blurb:Where the Vixens Play
@set here=_realm/rating:X

…and so forth.

It's best not to set these properties on every room. Just put them on your environment room. You don't have to supply all the values; any you leave blank will be filled in by values taken from further down the environment tree.

Rating is usually G, PG, R, or X. Just like movies.

OOC Chat and RP should each be described on a scale:

• Forbidden
• Discouraged
• Allowed
• Encouraged
• Required

Special rules for your area are entered as a list. Go to your environment room and type:

lsedit here=_realm/rules

Then enter your rules into the list editor.

We have a program on Furscape to notify players when they enter a new realm, so they will be alerted to different information or rules there. This program is triggered by a change in the realm NAME. You can have areas within your realm using different descriptions or ratings, and it will not trigger the notification when players move between them. The name is what does it.

If you create an area that's meant to be a public gathering place – such as a cafe or bar, a park, a marketplace or plaza – then you need to help other players find it. A good way is by putting your room on the WhereAre (or wa) list. By typing wa you get to see a list of gathering places around the MUCK where players are active. To make your own rooms appear on the list, you must set the the _whereare property with a brief description. You will also want to set _wherearedir with directions on how to get there. For example, these are the settings for Busserio's Cafe:

@set here=_whereare:Fine Inarian dining with a quaint atmosphere.
@set here=_wherearedir:JR, ACCS, E, CAFE, BC

These are not environment settings, you have to set these properties on each room that you want to put on the WA list.

You don't have to be a programmer to use MUF programs from the public library. Just type plib to check out the MUCK's public programs. You can search the list using wildcards, or see the entire list with “plib *”. Most programs have instructions you can see by typing @view followed by the program's dbref number. Some require you to @list the beginning of the program for instructions. Some of the more generally useful programs for builders include:

• gen-msgboard = add a message board to your area
• cmd-map3.muf = add an ASCII map to your area
• Contents.muf = cutomizable contents
• seats-n-belts.muf = seating system for vehicles, restaurants, etc.
• extended-mirror.muf = propagates messages from room-to-room
• apt-directory.muf = set up apartments other players can claim
• splitlock.muf = send player to another room if he fails the lock
• CodeLock.muf = lock an exit with a code that must be typed in to pass
• DoorChime.muf = set up a “chime” on an exit
• TransExit = see into a room at the other end of an exit
• noises.muf = add random noise events to give an area atmosphere
• doorlock.muf = create doors that lock from inside
• imaginary-friend.muf = make zombies respond to things they hear
• deadbolt.muf = another nice door-locking program
• check18.muf = restrict area to adult players
• privateparty.muf = you can easily set a room public or private
• thing-dispenser.muf = dispenses things to players from a container object
• random-dispenser.muf = like thing-dispenser, but picks things randomly
• easy-sales.muf = easy way to sell items for credits or pennies
• guest-hotel.muf = set up a hotel where players can register their home
• eplaces.muf = simulates seating within a room, tracks where players are sitting
• proto-claim.muf = manage an apartment building with claimable rooms