* Building guide *
 
The following is a collection of building tips for Sociopolitical 
Ramifications. Loosely based on Greywolf's FurryMUCK building guide. 
 
Some words to the absolute beginner: The MUCK consists of rooms and 
exits which allow you to get from one room to another. An exit is 
unidirectional: if you build an exit from room A to room B, in most 
cases you must build a second exit from room B to room A. 
  
*** If you need any help, please contact a Builder helpstaff or wiz.
    In case of problems that require Wiz attention, you can also leave
    pagemail to 'b-wizzes', which goes to all Builder Wizzes.
    
  
* Building rooms *
 
To create a room, you use the @dig command (see `help @dig'). Example:
  @dig Great forest = #27 = forest
Creates a room named `Great forest', sets its parent room to outdoors 
environment room (#27RJA) and registers it as $forest. For more info on 
parent rooms, see the section `parent rooms' below. You don't have to
`register' rooms or even give the parent room. If the parent room is not
given, it is set to the parent of the room that you're in.
 
* Registering *
 
Registering a room under a name is not that important, but it's useful 
if you don't want to remember a number that is displayed when the room 
is created. It can be very useful when you create rooms from an upload 
file rather than typing them in directly. After the above command you 
can set all that you want for the room from somewhere else:
  @desc $forest ={list:de}
  @succ $forest =You can go {obv-exits}.
And so on. If you don't register, you would either have to write down
the database numbers or find them out with the `@owned' command later.
 
* Building exits *
 
To create an exit between rooms you can either use @open (see `help 
@open') when you are in the source room:
  @open <name> = #<destination>
or build from a remote room with @act (see `help @act'):
  @act <name> = #<sourceroom>
  @link #<exit> = #<destinationroom>
Example:
  @open north;n;out;o = #254
opens an exit with the names `north', `n', `out' and `o' from the room
that you're in to room #254. This only works if you own the source room
and the destination is either owned by you or has the Link_OK flag set.
When the exit is built, any of these names can be typed to get from the 
source room to #254.
 
* A very brief introduction to MPI *
 
Here I only cover one thing: descriptions that are longer than one line.
Out of consideration for those whose telnet truncates lines longer than 
80 characters, descriptions should not consist of one extremely long 
line, hoping for the user's client to word-wrap. To create a description 
of multiple lines you use the list editor:
  lsedit <object> = <listname>
Let's assume you want to enter a room's description. You type
  lsedit here=de
In the list editor you enter a description, pressing Return after every 
72 characters or so. When complete, enter
  .end
on a separate line and set the room's description to that list:
  @desc here = {list:de}
This means that the list `de' stored on the room is displayed.
 
For more information about MPI type `info mpi-intro', `info mpi-intro2', 
`info mpidocs' and `info mpidocs2'. Attention: The outputs of every of 
these commands is very long, so if your client or modem program allows 
to capture the output, you best do this and read it offline. You can
also type `info mpi-intro = 1 - 100' if you only want to see its first
100 lines.
 
* Messages of rooms *
 
A room can have a @description and a @success message. When you enter a 
room or type `look', you will be shown the name of the room, the @desc, 
the @succ and (if the DARK flag of the room is not set) a list of the 
contents. 
  
* Names of exits *
 
Exits can have multiple names, separated by `;'. If a user types any one 
of these names, [s]he uses the exit and goes to its destination.
 
The first of the names is displayed in {obv-exits}, so you can use the 
first name to describe where the exit goes. 
 
Use standard compass directions and abbreviations, plus out if it is 
logical (for example, for a house, it is good to have an `out' exit for 
every room so that you can type `out' many times to get out of the 
house). So, if a `north' exit is used, the name may include `n' in the 
name as well. If the exit leads out of a room, add out;o to the name. 
Example:
  @open Cave (E);east;e;enter;cave;in;opening = #1234 
 
Naming an exit after a player can cause complications, particularly if 
that player is in the same room! You will not be able to look at that
player. Also take care that you don't give your exit the name of a 
global command unless you want to disable it in your area and replace it 
by something else. Type `help' and `globals' to see what the global 
commands are. 
 
A common practice in `apartment building' setups is to name the room 
exits after the occupants, adding 's after the name and using numbers in 
addition (to be looked up in a directory). Example:
  @open Unci's (4);4;unci's=#2345 
 
* Messages of exits *
 
Exits can have four messages: @desc, @succ, @osucc and @odrop. 
 
Describe your exits using 
  @desc <exit> = <text>
so you will be able to look in a direction and see a short description 
of what lies there. Example: 
  @desc east =To the east, you see the opening of a dark cave. 
 
For the description of exits we have MPI macros that show what is behind the exit. These work only if the
exit is owned by the owner of the destination room, so you should tell her/him to @chown the exit if it leads
to someone else's room. If you type:
  @desc east ={trans-exit}
then you will see something like `You see Dark Cave. There you see Ido.'
{trans-exit} will only work if the owner of the exit and the destination
room is the same.
You can also customize the description while still seeing the contents 
by using another macro:
  @desc east=To the east, you see the opening of a dark cave.{tuc}
The {tuc} adds the `There you see ....' line if anything is in the room. 
  
Use @succ, @osucc, @odrop on exits. The @succ message is shown to the 
user, the @osucc to those in the source room, the @odrop to those in the 
destination room.
The @succ can be used to create an illusion of a vast landscape by 
describing in detail what you walk through. It can be several lines long 
(using MPI), if you want to give an impression of a large distance.
The @osucc should indicate where the character has gone, so others can
follow. If it's not there, only `- has left' will be displayed.
The @odrop should indicate where the character comes from.
The name of the user is automatically added in front of @osucc and 
@odrop messages. You can use pronoun substitutions in these messages 
(see `help substitutions' for detail). Keep @osucc and @odrop short to 
reduce spam for other users. Example:
  @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! Some
people are annoyed when people enter or leave the room unnoticed. 
 
Other tips for exits
 
Keep things `map-sensible', or `geographically correct' (often called 
GC). If a passage to the east leads to a room, then a passage from that 
room to the west should (in most cases) lead back to the first position.
 
In most cases, exits from a room should be evident in the room 
description. To make it easy for you and others, you can use the 
{obv-exits} macro in the @succ of the room. Example:
  @succ here =[Exits:{obv-exits}]
will show something like `[Exits: east, north, south and west]' after 
the @desc of the room. The advantage of this is that you don't have to 
update the @desc every time you add an exit. 
 
If nothing else, it should be at least easy to leave the area (i e 
typing `out' several times in succession should allow a player to get 
out of the area if it makes sense to define a direction as `out'. 
 
In large areas, you can build `stepdisks' that allow you to jump several 
rooms ahead, saving time. These are simply exits to remote rooms, and 
they are usually called ee, nn, ss, ww. Normally you will find another
stepdisk at the destination. 
 
If you would like an easier access to your area for everyone, it can be 
added to the destinations of the 64-bit bus, a global taxi/jumproom. 
Send page-mail to unci telling the database number of your room, the 
desired name of the exit (up to 4 letters) and a one-line description. 
 
* Parent Rooms *
 
By default, every room's `parent' is #0, `/dev/null'. This is the room 
in which all global actions/commands as well as the default `@fail 
messages' (what happens if you try to go north/south/east/west/etc. if 
there is no exit in that direction) are installed. 
 
You can set the parent room when creating a room by typing
  @dig <name>=#<parent>
To set a room's parent or change it afterwards, enter that room and 
type:
  @tel here=#<parent> 
 
A parent room (or environment room) allows you to set actions that can 
be used in all of its `child rooms'. Whenever you type in anything, the
MUCK will check yourself for exits, then the room that you're in, its
parent room, that one's parent room, and so forth to #0. If that fails,
it will look for an inbuilt command, and if there is none, give you the
`huh' message.
 
There are some global environment rooms already installed. 
 
/dev/null (#0RJA)
indoors environment room (#682RJA)
tunnel environment room (#679RJA)
roadway environment room (#674RJA)
outdoors environment room (#27RJA)
sky environment room (#675RJA)
vehicle environment room (#632RJA)
ground vehicle env room (#635RJA)
aircraft environment room (#637RJA)
spacecraft environment room (#636RJA) 
 
To create your own parent room, simply @dig a room, and set its parent 
to one of the global environment rooms. 
  
Attention: Strange things can happen if you use a real, used room as 
parent room of another! Since the child rooms all inherit the exits of 
the parent room, you will land at rooms next to the parent room when in
a child room and using an exit that is not installed there, but in the 
parent room. This can be avoided by locking all local exits in the 
parent room to that room (by going to the parent room and typing `@lock 
n = here' and so on). But most builders prefer to have separate 
environment rooms that are not connected to the VR world and normally 
not entered. 
 
One useful purpose of a parent room in an apartment building can be a 
global `out' exit to the hallway/courtyard, so that the occupiers don't 
have to take care of building those exits themselves. 
 
* Maps *
 
Another use for an environment room is a map. Making a map of the area 
makes it a lot easier for users to find around! To create a map, draw an 
ASCII map of your area (best done in an offline editor rather than
lsedit) that is not wider than 78 columns (I use 72) and not higher than 
20 lines (for those with 24 line screens, minus input area). Mark every 
room with a different letter from %A% to %Z%. For more information on 
the map program, type `map #help'. 
 
* Weather *
 
If you want to have a realistic outdoor area, you might consider
installing weather there. You need to have one parent room for all
outdoor rooms in your area, make two objects for storing data, and set
a couple of properties on them describing the climate. Look under `news' 
for the weather documentation. When you're done, contact unci for
registering your area to the weather program.
 
* 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:
 
Flags can be abbreviated by their first letter. 
 
Abode:
      Allows others to @link themselves, objects or even rooms (set parents) to this room. 
Chown_ok:
      Allows others to take ownership of this room with the @chown command. However, to limit who may
      @chown the room, you may @chlock the room. For instance, if you only want yourself, Joe and Sally to
      be able to @chown the room, you could type:
      @chlock here = me|*Joe|*Sally
      Note the * - this is necessary when the player being referred to in the @chlock is not currently
      present in the room at the time you are setting the @chlock. 
Dark:
      Objects in the room will not be visible. 
Haven:
      Characters cannot be killed in this room. 
Jump_ok:
      Required for characters to be able to be `teleported' to/from the room via programs, etc. Also, you can
      only throw things to rooms which are Jump_ok. 
Sticky:
      If the drop-to on your room is set (see next section), things will not be `dropped' until all players
      (sleeping players included) have left. 
 
* Drop-to *
 
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 swept to their respective homes instead. 
 
* 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 when smelling 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. 
 
* Look-traps *
 
A global `look' action is installed in #0. `NewLook', the program that 
the look action is linked to, allows `false objects' (also called `look-
traps') in a room. So you can look at things mentioned in the @desc of 
the room, such as furniture or directions with no exits, without having 
to create those items. Type `look #help' for a built-in help info. 
 
* 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. 
  
* End of building guide*