FURSCAPE BUILDERS GUIDE

Updated May 1, 2000

BUILDER BITS

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. Just ask a wizard for help.


BASIC ROOM CREATION

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

Once you have gotten into your room, try running the EDITROOM program! This program is menu-driven and allows you to adjust many properties on your room. 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.

There is a more advanced program called NEWEDITROOM or NEW-EDITROOM. It has all the same functions as the regular program, plus some new ones. Some people like it, all are welcome to try it.


FINDING LOST ROOMS

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 @tel or tel commands to reach them, and proceed from there.


MAKING PATHS VISIBLE

If you are new to building, one of the first things you should do in your room is make paths (and exits) visible. That can be done with EDITROOM. This is not required, but it makes building easier when you can see what you are doing. If you want to make the paths invisible later (so that other players don't know what they are), you can toggle them off again. Leaving the paths 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 paths are practically a requirement.

Also note... If you want most paths (or exits) in a room to be visible, but want to hide a particular one, you can set it dark:

@set <exit>=DARK or... @pdark <path>


HIDDEN EXITS POLICY

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 common sense.


LINKING ROOMS WITH PATHS

Paths are the usual way of moving from one room to another. They are created using the @path command. The general form is:

@path <direction>=<#dbref>,<exitname>

For example...

@path north=#2345=North Beach

Please note that the direction "north" is what the player will type to go that way. The name "North Beach" is only for looks. It will appear in the exit list as: North Beach (N)

There is a list of *suggested* directions you can use with @path. These are:

north, south, east, west, up, down, in, out, nw, sw, ne, se, or a number from 1 to 10

If your path uses a direction from this list, the path will automatically try to match abbreviations. For example... If your direction is NW, the path will automatically understand that NORTHWEST should also work when a player types it. It understands that O equals OUT, I equals IN, and so forth.

You are not required to use directions from the standard list. You can do something like this:

@path k=#2345=Kitchen

If you do this, the player can type "k" to enter the kitchen. However, the path won't automatically understand that "kitchen" is the same thing. To make it understand your own abbreviations, you can separate them with semicolons (;) like this:

@path k;ki;kitchen=#2345=Kitchen

Using this example, the user could type "k" or "ki" or "kitchen" to enter the room! When using semicolons this way, the first direction listed is the one shown in the rooms visible exits list. So, it would look to the players like this: Kitchen (K)

The other matches for "ki" and "kitchen" aren't visible, but they will still work.

Note that exits can also be used to link rooms together, but paths are preferred because they consume much less RAM in the system. Exits may be used for special purposes, such as linking to programs.


USING @PDIG

With @pdig you can create a room, create a path to it, and create a path back from it, all in one command. It looks like this:

@pdig <room name>=<path name>/<direction>=<path name>/<direction>

Here's an example...

@pdig Inside the Cage=Enter Cage/in=Exit Cage/out

If you use cardinal directions, the direction and the pathname can be the same value. For example...

@pdig Sandy Beach=North=South

When doing this, it's best to type the direction names in full rather than try to abbreviate them.


DESCRIPTIONS AND FORMATTED TEXT

Some players may use client programs with text displays of greatly varying si
ze. On older computers this was often determined by their screen display res
olution. On newer ones it tends to vary even more because they can be operat
ed with various sizes of windows and fonts. As a result, it's hard to presen
t text in descriptions that fits neatly on their display without getting word
s clipped at the ends of lines, just like in this paragraph you are reading r
ight now.

Fortunately, we have some guidelines to reduce this problem. Basically, we want everything to be word-wrapped or formatted to the size of the user's display. This can be done three different ways. First, it can be done by the user's own client software. The more advanced clients now have options to word-wrap text. Secondly, those who don't have word-wrap software can use the @wrap command which tells our MUCK how to word-wrap text for them. Thirdly, you can format your descs manually to 78 columns width. This last is the *least* preferred option.

If you type your descs straight into the MUCK using lsedit, the easiest way to get flowed text is to simply type it that way -- don't press return at the end of each line.

However, there is a limit to the size of paragraphs you can create this way. Also, if you are creating your text with a text editor on your home computer and then pasting it into lsedit, your software might not let you paste flowed text. Here's another way of getting the same result...

First put your text into a proplist using:

lsedit here=redesc
<paste your lines of text in here>
.end

Enter the text in whatever format width is convenient for you, it won't matter. Then put this MPI code onto your room or object:

@desc here={concat:redesc}

It will be flowed into one long string, which can then be word-wrapped either by the user's client software or by the MUCK using @wrap.

If you want to break your description into paragraphs (I tend to do this), you can use the MPI code {nl} to put in newlines. For example...

lsedit here=redesc
This is paragraph one.
{nl}
{nl}This is paragraph two.
.end
@desc here={eval:{concat:redesc}}

Descriptions produced in this way will be automagically adapted to the user's display, whether it is wide or small. That is what we prefer for descriptions on Furscape. However, there may be some times when you need hard-formatted descriptions.

If you are presenting information in a chart or table, or if you are presenting ASCII art or some sort of map, then you should limit the width to 78 characters. We assume that most (if not all) players have software that can display 78 column width. Here is how you might enter such a desc:

lsedit here=redesc
<paste your 78-column lines of text>
.end
@desc here={list:redesc}

Note that the {list:} function doesn't flow the lines together the way {concat:} does.

We also have a {format:} macro on Furscape, which lets you auto-format text into whatever width you specify. However, it should be needed only for very ususual purposes. It also has some quirks when trying to work with ANSI color, because the line-breaks it inserts into text tend to kill ANSI codes. Text wrapped by @wrap shows no such problem.


CONTAINERS

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.


FAKE CONTENTS

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.


LOCKS

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. 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 character. 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... 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 exits and paths. Let's assume you have a path leading into your closet, and you want to lock out other characters.

@plock closet=me

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

@plock 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 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.


ENVIRONMENT ROOMS

If you are building an area with more than two or three rooms, you can benefit a lot from setting up a "parent" or "environment" room. It's a room that contains your other rooms. Why? It allows you to set actions that will affect all your sub-rooms, so that you don't have to set up the same actions in each one. Many programs also 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 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 @pdig 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

We do not require, but do strongly encourage, the use of environment rooms.


FAKE OBJECTS AND LOOK-TRAPS

The @object command is used to manage fake objects and look-traps. You can enter "@object #help" for a summary of the options. The only difference between a fake object and a look-trap is that the fake object is listed in the room contents, while a look-trap is not. With either kind of fake, the description can include MPI code. Take note... When looking at your own room, you will see fake objects listed in the room contents, but they have a "(fake)" tag beside them, and look-traps 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.



@CHOWN PERMISSIONS

The MUCK keeps track of the owner of each object. Objects can only be modified or deleted by someone who "controls" the object, which 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 @chown.

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. How do we really make it his?

@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.


SPECIAL RULES FOR EXITS, ACTIONS, AND PATHS

There are special rules for control of paths, 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 C. 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 POLICY

MPI 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.yiff.org/services/mpi.html


MUF POLICY

MUF 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 few 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://mufden.pkunk.net/


AREA THEMES

Furscape is intended to have both a social, OOC-friendly environment for chatting plus specially themed areas where role-playing is encouraged. Our central theme is science-fiction oriented. That doesn't mean magical or mythical characters and areas are banned, but it does mean they should be kept apart from the hard-SF stuff. For example... If you want to build a high-fantasy gaming environment with swords and sorcery, that is fine, but please talk to a building wiz and figure out where it belongs in the MUCK. Don't simply link it into Alpha Dome or part of the lunar surface! We want the MUCK's layout to make some kind of sense, not turn into a hodgepodge of stuff randomly kludged together.

Owners of RP areas can post special rules for visitors. For example, if the owner of a cyberpunk themed area tells you magic doesn't work there, then it doesn't work. If you have a magical character and want to visit the area, you should be prepared to make some concessions. The converse would also be true, if a high-tech character went to a place where high technology isn't allowed. (If you want to play in the area very much, it could be an even better idea to create an appropriate character or zombie for that purpose.)

1 AUG 2000 - UPDATE: We now have a special command to help you post information about your area. The command is 'realm', and you can get information on how to use it by typing:

@view #3699

There are special rules for "adult" or erotic-themed areas. If you want to build such an area, you MUST speak with a building wiz and get it linked into an approved zone. Our policy on these areas is still evolving, but you should be prepared for some reasonable restrictions on players accessing your area. Furscape is not primarily an adult-oriented MUCK, so we are simply interested in keeping these areas from degrading our general theme and atmosphere, not stepping on your fun.

1 AUG 2000 - UPDATE: We have a new program to help control access to these areas. If you are building such an area, just ask a wizard to help you set it up.