Our primary means by which players should communicate with staff with       
requests, questions, complaints, suggestions, and bug reports is through our    
+feedback code. See '+help ooc/feedback' and '+help ooc/myjobs' for details of  
the code.

This +feedback code should be used for anything you need:      
questions answered (both of an IC and OOC nature), building, weapons, pitches,  
et cetera. (The only exceptions are that you should use +approve code in Chargen
for approval and +xp/feedback for XP expenditures.) In other words, we ask that 
you use +feedback if you need any form of assistance from staff, unless of      
course your need is urgent (e.g. arbitration is needed in an active scene). The 
+feedback code is meant to replace page and +mail as the primary means of       
communication between players and staff. These restrictions do not apply to     
Guests or to new players in Chargen. Guests and new players should not hesitate 
to page staff if they need any type of help.
                                

The reason we use this code is because staff is, frankly, busy. We have a   
lot of players and a lot of plots, and unfortunately player feedbacks in the    
past have sometimes fallen between the cracks. This +feedback code is the best  
way available to us to prevent your feedbacks from being lost or forgotten. When
a feedback comes in via +feedback, it can be delegated to someone who a) has    
time, b) has authority, and/or c) is most qualified. Yes, that means it may take
a day or two to get back to you. However, this code and our policy ensures that 
you will get a response. As staff, we commit to try our best to provide some    
form of response to +feedback within at most 3 days. If staff fail to respond in
this time frame, adding to the original feedback is the best way to get the     
attention of staff.

By cooperating with this policy, you will help this  
game run smoothly because staff will have an easier time in helping you.
    

This MUSH is just a game, and we are under no illusions that players will   
invest time here because they have a policy obligation. Accordingly, we strive  
to make this MUSH a place where all will enjoy themselves as much as they make  
the effort to do so. Nevertheless, some characters (e.g. feature characters and 
characters with territory) require some minimal amount of activity to keep the  
broader stories and dynamics of the MUSH on track, and to conform to their      
chosen roles. We therefore have one, minimal activity requirement, as follows:  
All players have just 1 Real Life week to respond to any @mail sent to          
them.

For non-feature characters, the only consequence for not responding
to a @mail within one week is that the player or staffer who sent it is entitled
to assume in game that the recipient's character is not around or else is       
purposely ignoring the @mail. This has its most serious implications if the     
non-feature character has territory or a title, for the character may risk      
losing the territory or title to more active characters.
                    

For feature characters, generally the consequences for not responding are   
the same as for non-feature characters. However, if the feature's RegArch sends 
a @mail to which a timely response is not provided, the RegArch has the         
discretion to take control of the character for the greater good of the         
MUSH.

Of course, this policy has room for broad exceptions. If a player  
posts on a public Bulletin Board that they will be away for a short period of   
time, we will endeavor to respect the absence and other players should try to be
accommodating. We also have code to help in this regard. See '+help ooc/vac' for
more details. Nevertheless, if a player (especially of a feature) anticipates an
extended absence and/or wants to obtain certainty that their character obtains  
an exception to this policy, they should check in with their RegArch in advance 
to negotiate what accommodations can be provided.
                           

 If, for some reason, you are not able to resolve an issue with another     
player (such as Advantage on a test, or whether your enemy could locate your    
secret haven), you should do the following, in order:

(1) See if you and 
the player can agree to resolution by an uninvolved player. This is known in    
professional circles as "getting a second opinion." If you can agree, 
then all is well.

(2) If you cannot agree, any player may unilaterally   
contact an Arbiter to resolve the dispute. The Arbiter's ruling is final and    
will not be overruled. If you feel the Arbiter's ruling is grossly unfair or    
OOCly biased, contact your RegArch or a ThemeArch, and if it truly is, we will  
take measures to prevent such rulings in the future. But the ruling will not be 
reversed unless the Arbiter egregiously violated MUSH policy.

(3) If an  
Arbiter is not available, you may contact the RegArch for the area in which the 
dispute is taking place. If that RegArch is not online, it is suggested that you
table the scene until an Arbiter or that RegArch is available. If the scene is  
of crucial importance, you may contact another RegArch or a                     
ThemeArch.

Please remember that almost every dispute can be resolved by  
simply talking to the other party. The code here is designed to minimize staff  
interference: you should be able to run combats and prove your statistics       
without having to call for assistance.
                                      

Introduction:
The architect style of administration on MUSHs is not often    
used. Originally it was formed in connection with TaeisMUSH, and has since been 
used by a small number of MUSHes, including Sanguinis Nobilis.

We've     
adapted this system for Los Angeles: A House Divided to cover the sorts of jobs 
we think need to be done, and to cover the way we want the administration to    
function.

The key to the architect style of MU* administration is to keep
in mind that its basic structure is basically horizontal at the admin level with
heavy division of power. Each architect is supreme in their own area, and except
in a few, very narrowly specified circumstances, they are only accountable to   
the other architects of their class.

There are four different classes of 
Architects; Theme Architects, Regional Architects, Technical Architects, and    
Arbiters. These are described in detail in the following pages (or see +news    
<type>). You will note that there are no "sphere" wizards,      
because there are no spheres on this MUSH. Play a vampire. Have fun.

You 
can find out who the Architects are using the +staff command.                   

THEME ARCHITECTS (ThemeArchs) are the people who have ultimate say on           
determining what is in theme and what is not. We have four ThemeArchs, each of  
which is independent of the others. For major decisions and long-term theme     
issues, the ThemeArchs work together..

Note that while ThemeArchs        
determine theme, it is down to the Regional and Technical Architects to enforce 
and implement it.                                                               

REGIONAL ARCHITECTS (RegArchs) really are the most vital to the MUSH's          
operation, and have the most demanding jobs. Each geographical region (each     
Camarilla Domain) has a single RegArch in charge of it. The RegArch's job within
that area is threefold.

First, they coordinate building in that area, and
enforce the domain's theme. Second, they approve and coordinate characters for  
their domain. Third, they should be available to answer questions and resolve   
disputes when there are no Arbiters available. Finally, they oversee and        
implement or coordinate domain-specific plots. Although ThemeArchs have the     
final word on whether something is "in theme", this is a decision     
making authority limited solely to Theme matters. RegArchs are not subordinate  
to ThemeArchs.                                                                  

TECHNICAL ARCHITECTS (TechArchs) are the code hackers, in one form or another.  
Each TechArch is in charge of one or more coded systems such as economy,        
languages, character generation powers and such forth. Alternatively they may be
in charge of WWW support, site support or any other technical area.

They 
are also the only Architects who tend to have wizard bits, as it is needed for  
their position.                                                                 

ARBITERS arbitrate disputes, whether in character or out of character, when the 
players involved are unable to do so. They're also the first line for looking   
into complaints - although complaints about an architect are ultimately looked  
at by the other architects of their class.

 Although most Arbiters are   
not specific to an IC domain, each RegArch sometimes has a single               
"Assistant" Arbiter who serves as a deputy RegArch in addition to     
normal Arbiter duties.                                                          

Code Modifications:
In order to support the architect system, Architects are 
set ROYALTY (Z), which allows all architects to examine any object, and teleport
freely. See 'help ROYALTY'

The Architect status however is administative,
not technical. All Architects are equal in seniority, whether or not they have  
wizbits, BACKSTAGE bits, or whatever.                                           

The following ethics document is an edited version of Amberyl's Wizard Lecture. 
Many thanks to her for setting the ground rules that have made many MUSH admin  
structures pleasant places to live within.

Administrators on a MUSH have 
a considerable amount of power. With that power comes the responsibility to use 
it wisely, for the actions of an administrator reflect not only on himself, but 
on the MUSH as a whole. Because an admin is in a position of power, he should   
attempt to set a positive example in all dealings, whether in-character or      
out-of-character. Common sense will usually suggest a decent solution to a given
problem; there are, however, some situations where the ethical and              
"correct" thing to do is not immediately obvious.

Please note  
that because of the Architect structure here at Los Angeles: A House Divided,   
you should not assume that because this document discusses some power, that all 
Architects have the ability to do this. Architects have the powers that they    
need to perform their jobs. See +news Policies/Architects.                      

Players are frequently paranoid about privacy. This is one "right"    
that Architects should _always_ attempt to respect; thus, this lecture begins   
with a discussion of the DARK flag. When you are DARK in a room, players who do 
a 'look' cannot see you, and you do not appear on the WHO list, but a @sweep of 
the room _does_ show that you are listening and connected.
Therefore, there  
is a chance that you will be noticed, and, if you are "illegally" in  
the room DARK, it is almost certain that the players in the room will be quite  
upset.

Given the setting, it is possible for players to be invisible in  
in-character areas on the MUSH, so players cannot expect their in-character     
conversations to be private from invisible characters unless they have taken    
in-character precautions. However, they can expect to have privacy in           
in-character areas, and to have in-character defenses against invisiblilty - so 
the following notes still apply to Architects.                                  

The reason why players don't like DARK Architects wandering around should be    
obvious -- they're afraid of private conversations being snooped on. Therefore, 
whenever you go _anyplace_ DARK, the first thing you should type upon entering  
the room is a "hello" or similar announcement of your presence. Make  
this a habit! If you do it regularly, even when the players in the room know    
you'll be entering DARK, there's less of a chance you will forget at some       
crucial moment. If you plan to be DARK, and wandering around, for an extended   
period of time, in order to arbitrate an RPG conflict or similar event, the     
players involved should, if possible, know of your presence, and if a private   
conversation begins, it is your ethical responsibility to inform the players of 
your presence immediately, or leave, _even if_ this lets players know that they 
are being judged. Your personal responsibility to promote privacy overrides any 
RPG mechanics.

Architects may go DARK in order to observe players whom   
are suspected of trying to harm the game, either by harming the database or     
crashing the server. They may also go DARK to observe the actions of a player   
harassing other players. In the latter case, the wizard should indicate his     
presence to the players in the room who are not "under suspicion".    

I cannot emphasize enough how important it is to obey the protocols for using   
the DARK flag. This is one of the greatest sources of player distrust in staff, 
because it is so _easy_ to abuse. Players should be able to have private        
conversations without doing a @sweep all the time. While privacy on a MUSH is   
never, ever, guaranteed, you should do your best to contribute towards it.      

The second of the frequently-abused Architect powers is @teleport. There are a  
number of rules that should be observed when @teleporting. First of all, never  
teleport a player without warning him first. If possible, the player should page
you with an acknowledgement before you do the actual @tel. This prevents, for   
example, an untimely @teleport wrecking someone's set of a @desc on a room. No  
one enjoys suddenly being yanked to another room, and it doesn't hurt you to    
page the player first.

Never teleport to a room with players without     
asking the permission of the players there first. The exception to this are     
public hangouts. A room which is merely JUMP_OK is not necessarily a public     
hangout; use some judgment when determining whether or not rooms are public.    
Unless the room is clearly public, ask first; it doesn't hurt you to be         
polite.

If permission is not likely to be granted, then notify all       
players in the room (@remit works well for this) that you are going to be coming
in, before entering the room. You should wait a moment between the time of the  
announcement and the teleport; this should prevent you from hearing something   
that you shouldn't.

Never make assumptions about whether or not it's okay
to teleport into a situation. For example, just because a player is paging you  
for help with coding some complex object _doesn't_ mean that he wants you to    
teleport into his room and help him out. Always _ask_.                          

Don't abuse "examine" or the power to see private information like    
sites. Architects can examine anything, to check for theme consistency, etc -   
but should never share or show any object, or part of an object, that is not    
theirs to another player, without getting the permission of the owner. Also,    
don't steal code. "Stealing code" includes                            
@decompiling/logging/cloning without permission, even if you're just using the  
code for your own personal edification or enjoyment. If it's that important to  
you, ask permission.

Sitenames should never be given out. If a player is 
Unfindable, you shouldn't give out his location. Some people MUSH to escape     
people they know in Real Life; some players carry vendettas cross-MUSH. Other   
people simply prefer not to let others know where they are, VR or RL. You should
respect this desire.                                                            

You should generally avoid modifying other people's objects, even if you're     
fixing code problems or typos. The only exception to this is publicly owned     
building owned by a staff-played builder character (the core landscape for the  
MUSH, the downtown area, etc.) If you encounter an object which is inefficiently
programmed or looping, and thus slowing down the game for everyone else, simply 
set it HALT and mail the owner; don't fix the problem.

Also, don't       
@destroy anything of anyone else's unless they explicitly ask you to. If it's an
item which is illegal in some way, send the owner a warning, and give him a     
certain period of time (a few days, usually, depending on how often the player  
logs in) in which to get rid of it. If it's not gone by the end of the period,  
then you can destruct it. If the illegal item is sitting in a public place, you 
should feel free to teleport it back to its owner.^                             

Never, ever, @force a player, unless it is _absolutely_ necessary. For the same 
reasons, don't use @trigger and similar commands to make a player do something  
against his will. Also, don't change the attributes on a player; for example, it
is generally considered unethical to change a player's description to something 
humiliating.

If you need to change an attribute on a player, make sure   
you copy the old attribute to a backup attribute on the player, so that they can
recover it later, if need be.

Architects with the WIZARD bit can pile    
huge numbers of things on the queue, and make use of computationally expensive  
commands like @find and @search with impunity. If you need to do something that 
will severely lag the game, do it when there aren't many players on. Also, note 
that very large @dolists cause the MUSH process size to grow, and should be     
avoided whenever possible.                                                      

Avoid annoying players with shouts. @wall cannot be blocked, and, therefore you 
should make sure that everything you shout is informative and                   
necessary.

Shouting to announce a @shutdown in five minutes is           
acceptable; shouting to announce game problems is acceptable. Shouting to       
announce that you've had a bad day and shouldn't be paged should probably be    
avoided. First of all, it makes you sound like a twit; second, it accomplishes  
nothing useful and implies, "stay out of my way or something bad will      
happen to you." If you really want to avoid player pages, go DARK and set a
pagelock. Players shouldn't be afraid of you on a "professional"      
level, and you should try to avoid actions which cause players to fear you.     

Never MUSH while intoxicated or otherwise not fully in control of your actions. 
Know when to log off or back out of a situation. If you feel like you're about  
to explode, get up, walk around for a bit, get a drink of water, and come back  
when you feel like you're ready to cope rationally with the situation. If       
possible, call in another administrator to handle the situation. Never, ever,   
perform Architect actions out of anger; it is likely that you will regret them  
later.

An Architects ability to deal with players is usually the final   
test of his skills. Troublemaking players are quick to find administrators who  
are easily provoked, and frequently enjoy pushing all the buttons they can. When
you page a player, no matter how annoyed you might be, you should try to remain 
calm and polite. Don't swear at players, or behave in a manner that would allow 
the player to focus a discussion away from his wrongdoing to a mistake _you_    
made.

Players who are spamming or exhibiting behavior detrimental to the 
server or database should be @booted; if it's a one-time-deal character like    
"You_Suck", a @destroy is also in order. Other players should receive 
warnings before any direct action is taken.                                     

If a player is being obnoxious or breaking MUSH rules, page them and politely   
let them know that their behavior is unacceptable. If the player is not idle and
does not respond to your page within a few minutes, repeat your page. If the    
player simply ignores you, or refuses to change his behavior, page with a       
stronger warning, but continue to remain polite. If this doesn't work, tell     
them, "If you don't stop that, I'm going to @boot you.

This will    
normally at least open a dialogue between yourself and the player in question.  
If the player isn't willing to discuss it, and continues the obnoxious behavior,
@boot them. If they come back and continue to be annoying, then @newpassword    
them. You should NOT @destroy a player who isn't a one-shot annoyance. @destroy 
is not reversible, but a player can be re-@newpassworded should he decide to    
come back and play by the rules.

When talking to a player, you should    
attempt to remain calm and polite, no matter how much the player is trying to   
provoke you. Ignore personal insults, obscenities, and the like, if some useful 
discussion is occurring. If the player is just continuing to be annoying, end   
the discussion and simply tell them, "Do this again and I'll @boot         
you." You're not required to be a saint or martyr.                         

Whenever you enter a major conflict with a player, you should log the situation,
if possible. You should send the other Architects, via email, a summary of the  
situation, and, if necessary, the log. This will prevent the player from        
accusing you of saying or doing things that you did not, and will give you a    
"record" of the player's behavior, in case the player claims that he  
didn't do what you claimed he did. The SUSPECT flag and @comment attribute are  
also good for letting other Architects know about suspicious players.           

These guidelines aren't here to make the task of administrating more difficult  
for you. They exist to provide some basic guidelines of ethical behavior; in    
general, if you follow these guidelines, players will find it quite difficult to
accuse you of abusing your powers. They thus work for _your_ protection, as well
as the players'. Players frequently take mistakes personally and seriously, and 
may decide, "because X did this, all other Architects probably do,         
too." Players who are paranoid tend to be more difficult to deal with;     
thus, for the sake of your sanity and that of everyone else who has to deal with
that player, try to avoid giving them a reason to be paranoid. If you           
consistently have personal problems with a player, you should also avoid dealing
with that player; have someone else handle the situation instead.

In all 
things, use common sense, and try to remain calm and impartial. When all else   
fails, log off.

[ Based on a lecture first given on TinyKrynn, 2/92, by  
Amberyl. ]                                                                      

The following policies are here for the information of architects primarily, but
in the interests of open administration, they are available for anyone to       
read.

Ethics:
 All Architects are expected to operate within the code 
of Architect Ethics (see +news policies/Architect ethics).

Abuse of      
Architect Status:
 In the case of a player-registered complaint against an   
architect, the architects of the class in question may determine, based on the  
evidence at hand, whether a full hearing is justified. A full hearing shall     
involve statements by the complainant or complainants, as well as statements by 
the architect being accused. If an Architect is found by a vote of his or her   
fellow architects of the same level to have abused his or her position, a second
vote shall determine if the penalty is loss of Architect status or banning from 
the MUSH.

Please also bear in mind that we will take complaints /very/   
seriously. To that end, we will also frown on spurious complaints. In the first 
instance, players should always talk to an Arbiter.                             

Impeachment:
 If all of the other archs of a particular class determine that 
one of their members is deserving of such a fate, that individual can be        
impeached at any time, though all architects must be informed of such an        
incident immediately upon proceedings. Note that a unanimous vote of the        
ThemeArchs will be independently sufficient to remove any Arbiter or RegArch,   
but that this only works one way -- such a vote will not override a decision to 
remove.

Meetings:

 Any architect may call a meeting either of     
their class or for all of the architects. The individual architect who calls the
meeting is also, unless they so designate it otherwise, responsible for the     
agenda.

Replacing Architects:
 In the case of resignation or          
impeachment, replacements will be selected by the ThemeArchs, subject to        
approval by a majority of the class of the position being replaced. For a       
replacement ThemeArch, the decision of the remaining ThemeArchs is subject to   
approval by a majority of the RegArchs.                                         

Holding more than one position:
Since we don't always have enough staff to   
fill all the positions, some Architects may hold more than one position. We     
would like to have enough good staff that we wouldn't have to do this, but      
them's the breaks.
RegArchs are generally expected not to hold multiple      
positions -- they have more than enough to do anyway.

Helpers:
Any    
architect can appoint helpers to handle some subset of their workload. These    
helpers are not considered architects. Each helper is accountable to a          
particular architect, and architects are accountable for their                  
helpers.
Newbie helpers - an important part of any MUSH - are generally      
accountable to Arbiters, just in case you were wondering.                       

Chief Architect:
Traffic is the Chief Architect. This means only one thing - 
in the event of irreparable breakdown of the MUSH admin structure, he reserves  
the right to deal with it. In no other way does he have any more authority than 
any other Architect.                                                            

 We're aware that occasionally in games of this sort, cheating happens.     
Mistakes happen, too. Players forget to expend willpower points, misquote       
totals, forget they are wounded etc. This game relies on trust to work, and its 
not about winning, its about having fun. So, please don't cheat, and please do  
not assume that someone is cheating if it's possible they made an honest        
mistake.

 The +prove code prevents people from misrepresenting their     
totals, but if you really think that someone else is cheating, contact an       
Arbiter (or other staff member if there are no Arbiters available). Then stay   
out of whatever happens. Arbiters will do what they deem necessary to correct   
honest mistakes and deal with cheating. 
                                    

 Every player, by creating and playing a character on this MUSH, implicitly 
agrees to abide by rules, policies, and systems of this MUSH. No one can harm   
your character or force your character to do anything without your cooperation. 


That cooperation, however, should be given at all times, so long as all 
parties involved are within the rules, policies, and systems of this MUSH and   
are acting within the restrictions set forth in +news Theme and Policies. The   
rules are here to help facilitate role play, but ultimately it is the           
responsibility of the players to ensure the smooth functioning of this MUSH.    
Remember: there weren't any rules for Cops and Robbers and we didn't have any   
problems with that. We have tried to make the Cooperative RP rules extremely    
simple. 
                                                                    

 There are only four real rules to Cooperative RP: 

(1) You have an  
unqualified right not to role play out the rest of a scene that has become      
personally disturbing to you for any reason; you may always "fade to       
black" and resolve the balance of the scene by mail or through a           
Staffer.

(2) By appearing in a public room, you are agreeing to role play
with any other player on the MUSH who comes by. Conversely, you have a right to 
privacy in a private room unless there is an IC justification for an            
interruption (i.e. one of the occupants was followed, there has been a search   
for you that was successful, etc.).
                                         

(cont'd) 

(3) You have a right not to have your character killed or  
destroyed without some IC justification, but you do not have a right not to be  
killed. The world of the vampire is a world of conflict, and you do not have a  
right to be completely free of that conflict: other characters may attack you   
first. The character application process is designed to remove "I like     
killing people" as an IC justification, and a character who kills another  
character wantonly is assuming a tremendous IC risk. If you believe that a      
character is not acting for an IC reason, and you are unable to work it out with
that character's player, place the scene on hold and contact a Staffer. That    
Staffer's first question will always be, "Why are you                      
attacking/drowning/torporing/dominating so-and-so," so please be sure to   
ask that question before contacting Staff.

(4) You have an unqualified   
duty to communicate with other players and maintain an environment of respect   
and maturity. Staff can help smooth out the bumps (see +news                    
Policies/arbitration) but we will not be pleased if we find out that we are     
having to arbitrate disputes that have resulted because the players refused to  
speak to each other. Occasionally, maintaining an environment of respect and    
maturity will call for you to keep quiet or to recognize that further argument  
will only harm matters: please use your judgment.

By following these     
rules, and by remembering that ultimately it's all a game and in the name of    
fun, we can have an enjoyable, realistic, and mature roleplaying environment.   

 This MUSH is based on White Wolf, Inc.'s game "Vampire: The           
Masquerade." This MUSH makes extensive use of a number of White Wolf's     
copyrighted and/or trademarked concepts and ideas. The administrators of this   
MUSH do not receive any profit of any kind from its operation, and no           
infringement is intended of White Wolf's intellectual property. All copyrighted 
and/or trademarked words, phrases, or ideas remain the property of White Wolf,  
Inc. If your intellectual property is being used on this MUSH and you object to 
its use here, please contact our attorney, Michael E. Lopez, Esq. at            
mlopez@mail.wesleyan.edu immediately, and appropriate corrective action will be 
taken. PLEASE CONTINUE READING THIS NEWS ITEM.
                              

 This MUSH and its administrators strongly encourage all players to remember
that this is a fantasy-based role playing game, and discourage players from     
divulging or sharing any information relating to their real-life identities.    
This MUSH will not be held responsible for events, injuries, or damages arising 
from the voluntary disclosure of any information by a player, including the     
arrangement of off-line meetings, the exchange of correspondence through any    
medium other than this MUSH, or the revelation of personal characteristics such 
as age, sex, or place of residence. Please remember that you have probably have 
no idea who the person on the other side of an online character really is.      
PLEASE CONTINUE READING THIS NEWS ITEM.
                                     

 Playing on this MUSH is completely voluntary, and by doing so, players     
waive any rights to claim damages against the administrators, staff, and server 
host of this MUSH for injuries or events arising from its use. The material on  
this MUSH is adult and disturbing in nature, and may upset some people. Any     
player who finds themselves suffering emotional or mental distress from their   
playing on this MUSH should contact Staff immediately, and should not continue  
playing until the issue is resolved. 
                                       

What is metaposing?

Metaposing is the practice of narrating others'  
actions either explicitly or by implication. It is strongly frowned upon --     
commenting on and characterizing their actions ICly is just fine, but that must 
be handled in what your character says instead of in your written narration of  
the scene. Some players feel this limits creativity, but really in most cases   
where metaposing is being used, there are easier ways around the situation that 
can come out to mean the same thing without being rude or claiming empirical    
knowledge of another's intentions. 

Please read the examples, which      
follow.
                                                                     

Examples:

Charlie Brown walks up to Linus with a menacing            
scowl.
Metapose Response: Linus retreats from Charlie Brown and his violent  
streak. 
Good Response: Linus retreats from Charlie Brown, clearly fearing   
intended violence.

In the metaposed example here, Linus was assuming     
something based on Charlie Brown's pose that is pure inference. After all,      
perhaps Charlie Brown is scowling because he is angry at the person he just got 
off the phone with and intends to vent his frustrations verbally at Linus.
  

Sally says, "<long emotional speech.>"
Lucy says,        
"Huh."
Metapose Response: Sally, hurt by Lucy's insensitivity,     
storms out of the room.
Good Response: Sally takes Lucy's response badly and 
storms out of the room. 

Here, again, Sally is drawing conclusions --    
which are at their heart IC -- about Lucy's response to her speech. Even if she 
objectively feels it was insensitive for Lucy to just say 'huh' after her long  
emotional speech, it is not really her judgment call to make or narrate that    
beyond Sally's IC perception. Lucy might just be taking a moment to process it  
all, after all, before coming out with a coherent response. 
                

Charlie Brown says, "Hi."
Metapose Response: Lucy greets       
Charlie Brown with a hug and a kiss on the cheek. "Hi."
Good       
Response: Lucy greets Charlie Brown with an offer of a hug and leans in to kiss 
Charlie Brown's cheek. "Hi."

Here we get into poses that imply 
action on the part of other people. When engaging in physical actions that      
involve others, it is best simply to pose intention and to let them pose        
response. In the good response example above, for instance, Charlie Brown's next
pose might include: Charlie Brown, accepting both the hug and the kiss, does    
<action>. Or it might be something like: Charlie Brown doesn't seem to    
want to be touched and dodges both hug and kiss. You never know until they get a
chance to respond. The one major exception to this would be when you work out   
action/response via negotiation, usually in a fight scene, where for instance   
someone might agree to get lifted off the ground, allowing you to pose that your
character lifts them rather than just posing that they intend to lift them.     


Keeping to posed intent/response tends to keep the action and posing    
flowing even in the most difficult to negotiate action scene, and should be the 
rule of thumb in all other scenes as well.
                                  

 There are three types of NPC:

 PLOT, THEME, and MAJOR

PLOT   
NPC - a character created for a specific plot. It should NOT get involved in    
issues outside its plot, and should not even be logged in if it doesnt have     
something to do specific to its plot. Plot NPC's should have a documented       
purpose (in the characters secret background), and a documented life-span       
(generally the length of a plot). The character may have a particular player,   
but will be under the control of the person Storytelling a particular plot.     
Ultimately they are accountable to the Architect monitoring that plot. Plot     
NPC's are probably of Application character power level.
                    

THEME NPC - a character created to develop a particular theme thread. It    
should not get involved in roleplay outside that thread, and should not even be 
logged in if it doesnt have something specific to do. Theme NPC's should have a 
documented purpose (in the characters secret background). The character may have
a particular player, but will be under the authority of an Architect.           
Ultimately, these characters are accountable to the Theme Architects. These     
characters are probably of minor feature level.
                             

MAJOR NPC - someone who interacts with other characters infrequently, and   
should probably be handled by +feedback, and occasional appearances. Typically, 
powerful characters so important to the power structure of Los Angeles that we  
want to keep them under staff control. Not the sort of character players        
socialise with.
                                                             

The following is our current list of Major NPCs for this MUSH, broken down  
by Domain:

GREATER DOWNTOWN SANTA MONICA
Emerson Acton
Emory       
Frederico
 Theresa
 Rachael

SOUTH CENTRAL LONG BEACH
Alvin      
Elaine
Cassius Acriella

VALLEY NORTH ORANGE COUNTY
Julian          
Davidoff
Patric Cafliaglon

SOUTH ORANGE COUNTY TORRANCE
Gillian    
Andrew
                                                                      

Registration and approval are /required/. This means that before anyone can     
start playing, their character background and stats must be approved by either a
RegArch (preferred), a RegArch Assistant, or a ThemeArch. The +request command  
(see '+help ooc/request') allows you to request a registered character          
object.

Once you enter the city in-character stats are only changeable   
through IC play. This means that staff will not raise nor lower your stats other
than what you earn from Experience or things that happen according to IC play.  
So make sure that you are happy with your stats before you start                
playing.

OOC harassment of players is not allowed and will be dealt with 
severely.

Please read +news frequently, as well as checking the bulletin 
boards. In return, the staff will do our very best to answer any questions you  
may have and help integrate you into the game.

Please do not tell friends
and other players information that they would not know IC. To preserve the      
atmosphere of mystery and suspense, such information should not be given out to 
those whose characters have not gained it through roleplay.                     

This MUSH contains adult themes including graphic and brutal violence,      
profanity, cruelty, and betrayal. It is intended for players over 18 only. If   
you are under 18, please get a parent or guardian' permission before playing. If
you are under 14, we are flattered that you thought playing here might be       
interesting, but we must ask you to go someplace else, for you may not play on  
this MUSH.

Characters made henceforth must be 18 years or older in       
game.
                                                                       

 * TRANSFER OF CHARACTERS * 

Please do not transfer characters from  
other MUSHes to Los Angeles. This is partially because the rules we are using   
are rather different to most WoD MUSHes (particularly as regards other          
supernaturals) which would mean that the character's background would have to be
so severely edited if there was any supernatural knowledge at all that it would 
be almost unrecognizable. 

The main reason, however, is that we are      
trying to create a unique and non-generic atmosphere in our virtual Los Angeles.
This is an ambition which relies on players as well as staff to make it work.   
You can help us a lot by thinking about character backgrounds and creating      
characters that meld specifically into Los Angeles, with its themes of control  
and humanity (+news theme!), rather than some random, generic US WoD city ripped
from the latest Clan Novel.
                                                 

 We believe that privacy is a two way streak. To this end, we strongly      
encourage people not to transfer characters from other MUSHes; we would like to 
allow everyone the chance at anonymity if they should want it.
 On this MUSH,
we have made it a point to hide email information (save &email voluntarily  
given) - even from staff. Only TechStaff and some ThemeStaff have access - and  
they are forbidden to share except in exigent circumstances such as legal       
compulsion or to protect this MUSH and its members from illegal activity.
 We
ask as a courtesy to other players that you restrict channel, page, and other   
OOC talk/public exposure (e.g. who you the player are) to players actively      
inviting such information. While we want to *discourage* such exchange, if you  
*must* share this information - please do not force it on another player or feel
obligated in any way to give such information to anyone requesting it (even     
staff). There is an exception for players wishing to apply for an Application   
level (e.g. vampire over 50 years old) character. For such players, staff may   
request the provision of references and a resume of experience. To clarify, no  
player wishing to play a Chargen-level character will be obligated to identify  
their OOC identity to staff in order to have their character approved.
      
MUSHing, as many people reading this are aware, can be an incestuous and        
cliquish environment. Many players have requested the return of the mystery and 
anonymity as something nostalgically missed from their early days of MUSHing. To
address this desire, this entry was created. Please address players of apparent 
unawareness of this policy to '+news policies/privacy'.
                     

 Because rape is an extremely disturbing subject to some people, and        
flat-out traumatic for others, there is to be no role-playing of rape-related   
scenes whatsoever. We hope this is perfectly, perfectly clear. 
             

 Retcons (retroactively deciding that a scene already roleplayed never      
happened) are, in our opinion, only harmful to the storyline of the MUSH. If,   
for one reason or another, a scene should not or could not have occurred the way
it did, work with all participants to create an IC justification for what       
happened, making minor changes if necessary. If the players involved cannot     
agree on how to deal with the situation, contact an Arbiter. No player has the  
right to a retcon and they will be used only as a last resort. 
             

 Characters stop getting played. Players leave, or get better ideas. Feature
PCs idle out of their spot. It happens. And when it happens, staff reserves the 
right to control the way in which the character leaves play so as to preserve   
Theme. This right will not always be exercised, and indeed it may prove a rare  
thing, depending on player maturity. Staff will *always* inform a player when a 
character's retirement is being subjected to Thematic control. So if you want to
retire your character, please +feedback your RegArch. Don't rush the National   
Guard Armory at dawn after calling the news people just to spite the Prince,    
OK?