Welcome to Building 101 at Los Angeles: A House Divided. A brief summary of
  our process here is as follows:
	Most players will be granted use of a single room linked off some central
  housing area (like a building development or apartment building), though a 
  few will inhabit larger structures, usually with other PCs, which will be 
  owned by a building character. Names of all rooms and exits are expected to 
  follow standard conventions outlined in the other +news Building files. No 
  room is to be linked to the grid without first being inspected by our 
  building staff.
	This MUSH makes use of dynamic maps that require coordinates, local domain
  commands that require proper @parenting, and quota restrictions (that 
  determine how much 'stuff' you can own.) We also have available places, 
  +view, +compass and other commands which work to make our built environment 
  more meaningful, and which builders can capitalize on. Finally, there is a 
  +build command (see '+help ooc/build') to assist some portions of building.
	Please read the rest of the +news Building topics for more information.

	Builder Characters are non-Player-Character 'player' objects given out to a
  player or group of players. They need to be registered with building staff, 
  and must have the words 'BLDR' or 'Builder' in their @name. 
	Generally, builder characters will be used for public buildings and for
  larger residential buildings. They may be maintained by either staff or 
  private players. 
	Periodically (about every 60 days), a +mail will go out to all Builder
  characters that have not been logged in in that time period, asking for a 
  return +feedback (see +help ooc/feedback) to verify that the building is 
  still being maintained. If no word is received within a week, the staff 
  reserves the right to @recycle or reassign the builder character, and 
  either @destroy (usually but not always with @decompiles) the building, or 
  hand it over to someone else.

	 To apply for a Builder Character, please +feedback/request with the
  following information: who you are, why you feel you should be granted a 
  larger building (elevated resources of 4 or 5, a residence in which many 
  characters are living and/or actively RPing with a need for spacial 
  separation, etc.), exactly what is being requested (we are more likely to 
  grant requests for smaller amounts of rooms), and where on the grid you 
  want it linked (by grid reference).
	 It is essential that your +feedback/requesth have as the subject: Builder
  Request <Name of Project>, and that the text of your 
  +feedback/request include, towards to the top, a simple sentence with the 
  number of room @quota being requested. Not following these two requests may 
  greatly slow down the ability to process a request.

	 Your RegArch will work with the Building staff to see that you get set up
  and assigned a proper amount of @quota. Once your building is complete, 
  please contact the building staff to request an inspection. 
	 It is strongly recommended that all builder character objects have a
  &contacts attribute set on themselves listing several characters to 
  contact (including the primary contact) in the case of a building's 
  possible demise.

	This MUSH makes use of a +compass command. This command is useful for
  getting a quick, visual layout of the exits off a given room. Oftentimes, 
  you will want to heavily customize what a given room 'looks' like. You are 
  therefore encouraged to draw simple ascii art to show the layout of exits 
  in our space, and to incorporate this as the custom compass option for your 
  room. See '+help ic/compass' for details.

	An example of this might be three doors in a row along the south wall, which
  you have labelled SW, S, and SE. A custom +compass could be used to show 
  that these really all take one 'wall', but that the different cardinal 
  directions are being used to differentiate them from each other. A visual 
  example might look like this:

 |____________________________________|
 / | \
 Blue Door (SW) Purple Door (S) Red Door (SE)

	Every room should have a series of attributes set on it that make use of the
  MUSH's dynamic maps. See '+help ic/map' for context. These attributes will 
  link every In Character venue to our +map system.
	There is &GRID, which should be set the same as the nearest outdoor
  room's +map coordinate. For example, if you are building a restaurant on 
  the Sunset Strip, which has a +map coordinate of O2, every room in your 
  restaurant would have set '&GRID <room>=O2'. Similarly, a 
  &HOOD attribute would be set in every room of the restaurant. In the 
  case of this example, each room would have set '&HOOD <room>=West 
  Hollywood'. Please do not set a &DOMAIN or &AREA attribute on your 
  rooms; if they are properly parented, these are unnecessary.
	Please note, setting these attributes is vital for our +map code to function
  correctly. Any room in which these attributes are not set correctly will be 
  considered OOC and not allowed to connect to the In Character grid.

	Exits should show their cardinal direction aliases in parentheses after
  their name, with the letters in bold (see 'help ansi'); in addition, they 
  should have the following as further aliases: the full name of the exit, 
  the logical initials of that name, the full word for the cardinal 
  direction, and the letter abbreviation for that direction. An example of 
  creating this would be:

@name <exit>=Library Doors ([ansi(h,N)]);library
  doors;library;doors;ld;north;n

	Which displays like this in game:

Library Doors (N)

	Alternately, it can be created with:

@name <exit>=Library Doors (%xhN%xn);library
  doors;library;doors;ld;north;n

	For convenience's sake, the above example should also take the 'lib' alias.
  Use common sense for other exits. Additionally, at least one exit in each 
  room should be designated as 'out', with the following aliases: 
  out;ou;o;back;exit;x;leave. Each building complex should have a path of 
  travel with 'out' that will ultimately lead characters to the nearest 
  outdoor grid room.

	Our MUSH also makes use of +door code, which makes the two matching sides of
  an exit function as a cohesive door. All doors should make use of this 
  code, and are, by default, created with it (@parented to #25), which allows 
  for the globally coded +lock system. 

	The exit parent has a default @succ, @osucc and @odrop, but these do not
  make sense syntactically in all cases. Please check your doors and 
  individualize them where advisable. All doors should also have a @desc and, 
  if they could logically be locked or blocked in character, a @fail and 
  @ofail.

	Also note that the @decompile command used on an exit will show any ANSI
  code used in the name, which the examine command will not. This is very 
  useful when copying and pasting in order to rename the exit or add any 
  missing aliases to it.

Usage:	+builder/gimme

This command will make it so a room will be dug for you in the building
  nexus. You can only use this command once.

	Most characters will inhabit apartments or residential buildings that take
  up a single room for @quota purposes and which are are pre-built and 
  provided by building staff. Please check the Housing +bboard for available 
  rooms and contact the staffer listed. Generally, code will be provided for 
  maintaining these spaces. 
	In some cases, where In Character resources and/or Role-Play needs permit, a
  player or group of players may be granted a building character to own a 
  larger structure comprising more rooms. These building characters will be 
  permitted to build custom dwellings and Role-Play venues. See '+news 
  Building/builder characters' for details.

	If you are not familiar with the concept of room @parenting, please refer to
  'help parent objects' and 'help @parent'. Each domain has an indoor parent 
  and an outdoor parent room, and every room on the grid should be @parented 
  to one of these rooms. It is okay to "nest" parents -- in other 
  words, to make a local parent room (if @quota allows) and then to @parent 
  that room to the appropriate domain parent; however, it is recommended that 
  you make use of a zone (see 'help zone') for this instead, so that you can 
  encompass both indoor and outdoor space in your local area without 
  conflicting with the domain parents.

	The Master/Parent rooms to use are:

	Downtown Indoor Master - #1063
	Downtown Outdoor Master - #144
	Santa Monica Indoor Master - #1064
	Santa Monica Outdoor Master - #221
	South Central Indoor Master - #1065
	South Central Outdoor Master - #222.

	In general, any room where weather or the outdoor environment might be a
  consideration should be set to the outdoor parent, i.e. parks, gardens, 
  courtyards, etc. Any room or area which is fully enclosed and roofed should 
  be set to the indoor parent.

	Note that while we do not have code distinguishing between indoor and
  outdoor rooms at this time, we may in future, and thus we ask all builders 
  to pay attention to and abide by these parenting guidelines.

	In order to save on database bloat, we have restricted the amount of
  personal quota to which each player character has access. If you feel you 
  have a legitimate need for more, please appeal to your RegArch, who may 
  choose to work out an increase with the building staff. 

	All building on the MUSH should be @named using the ansi() function. (Please
  see 'help ansi'). This should be according to the following color code 
  established to distinguish domains and OOC areas:

Green - Offstage (built by staff only)
Red - Santa Monica
Magenta - Downtown
Cyan - South Central

In other words, the name of an individual room should be in color-coded
  highlight (bold), followed by its general area without highlight (if 
  applicable), followed by its neighborhood. This would be written out as:

@name here=[ansi(gh,Green)] [ansi(g,- Offstage)]

	For areas that have sub-areas, please only bold the individually named room,
  like this: 

Pretty's Room - Pretentious Manor - Hollywood

	Please see +help ooc/build for a tool that will assist in automating this. 

DESCRIPTIONS
	In this version of Los Angeles, dark things are a little darker, strange
  things are a little stranger, and all the sharp, odd angles of the real 
  world are highlighted, with the hidden, ugly truths brought into focus. 
  This is true thematically, and it should be borne out in the way we 
  describe our space. 
	 A room's @description should not be so long that it takes too long to read
  it, nor so long that it scrolls off the screen. Usually about 8-12 solid 
  lines of text (with an 80 character width) is sufficient to say all that 
  needs saying. THERE IS AN ABSOLUTE LIMIT OF 13 LINES FOR THE DESCRIPTION OF 
  ANY ROOM INTENDED FOR PUBLIC USE. 
	 Additional flavor and detail can and should be added to a room by making
  use of our +view code. Please see '+help ic/view' for more.

FORMAT
	We generally follow the format of a %r (line break) at the beginning and end
  of a room's description and a %t or [space(8)] (eight-space tab indent) at 
  the beginning of each paragraph. Departures from this convention should be 
  used sparingly, and for a punctuated reason. We reserve the right not to 
  approve an inspection if we feel the format is sloppy. 

PLACES
	 Places code (See +help ic/places) can be used to distinguish sub-areas or
  tables within a larger space. Examples might be different exhibit areas 
  inside a museum gallery, or different tables inside a restaurant. Some 
  people may use this to delineate space in their private rooms as well, such 
  as distinguishing a bathroom from a living room from a kitchen. Note that 
  any room in which places have been installed should be @set !halt so that 
  the code can function properly. Please also note that the existence of 
  places and +views will be noted in a room's default @success attribute (see 
  'help @success').

DAY/NIGHT
	 This MUSH does not use day/night code for the simple reason that, for RP
  purposes, it is always night, and this should be reflected in 
  @descriptions. If you are building a space designed for private, 
  mortal-oriented daytime RP, please seek your RegArch's blessing first.

	Please be sparing in the @creation of 'thing' objects. It is understandable
  that players may want one to hold personal code, and one for each statted 
  ghoul or other retainer to which they are entitled, but please refrain from 
  the creation of things to represent objects such as beds or musical 
  instruments. 
	Weapons will be represented by coded objects made and owned and issued by
  the Weapons staff only. Please do not @create objects on your own that are 
  meant to represent weapons of any kind. See +news combat/weapons. 
	Also note that vehicles such as cars and motorcycles should not be @created.
  They should be emulated by use of the +drive command. See +help ic/drive.

HANGOUTS
	 A room can be designated as a hangout for the purposes of the +hangouts
  command by setting '&public here=1' on the room. See '+help 
  ooc/hangouts' for more information on this command.

NETWORK STRENGTH
	 A room's network strength can be set using +phone/networkstrength <0 -
  100> , with 0 meaning no reception at all. Rooms such as underground 
  vaults should almost certainly lack reception. See '+help ic/phone' for 
  more info.