Being a Responsible Operator

This section contains a number of guidelines and discussions intended to help you "grow" your site and maintain a positive and effective reputation as a operator. Some of these guidelines suggest general attitudes and actions to be performed on a continual basis, while others are intended to help you recognize and deal with disruptive or abusive users, in specific circumstances. * Overview * Roles and responsibilities * Security functions * Authoring

Overview

These guidelines were developed based primarily upon the experiences of various Palace operators, and may apply differently to your site. In fact it's fairly certain that you will eventually encounter a situation in which these recommendations are ineffective or inappropriate. When this happens, you'll have to rely upon your own creative solutions, and let your own experience be your guide.

While reading this section, it is important to remember that these are guidelines and suggestions, not laws or rules of any kind. Not only is each one entirely optional, but even the ones you decide to follow will probably be "stretched" from time to time.

Roles and responsibilities

There are many common misconceptions about being an operator. One of the most common is the idea that it is a "reward" given to people who have been using The Palace software for a long time, or hanging out in a particular Palace since its opening. While familiarity with the software and knowledge of the site's culture are indeed important for every operator to possess, these traits can be picked up very quickly given a short training period. What can't be learned easily are the "softer" aspects of the operator's role. Empathy, diplomacy, charisma, wisdom, and discretion -- these are the kind of skills that are most important for successful performance of the operator's duties.

Another common misconception is that you can be an operator if you ask for it often enough. Actually, most Palace operators believe that anyone who asks to be made a operator probably shouldn't become one. Indeed, the more a person requests to be an operator the more they prove themselves incapable of handling social situations rationally and creatively, which is exactly what operators must excel at.

Operators exist for one principle reason: to help make the Palace a better place. Obviously "better" is a relative term, and each Palace site will define it differently, so we should append the phrase "for the majority of your site's users." This goal is accomplished by employing a variety of proactive and responsive techniques (in rough order of frequency):

 

• Being your usual brilliant, entertaining self.

• Talking to users.

• Reprimanding abusers.

• Gagging obnoxious abusers.

• Killing extremely obnoxious abusers.

• Occasionally making minor modifications to rooms (depending on the permissions and rules set by the local Palace owners; many Palace sites discourage use of authoring mode on the server).

   

There's one more thing all operators must possess, and that is time. Becoming a operator is a commitment, not a membership card to an exclusive club. When you are granted operator status at a Palace site you become part of an "elite team," dedicated to making sure the site runs smoothly and the party doesn't get out of hand. Depending on the popularity of the site and the hours set by your Palace operators, it can get to be a full-time job.

 

Setting an example

Every time you do something in The Palace you are defining the social order there; you are contributing to the overall conception of "the kind of things that happen at your site." This is one reason why it's a good idea to have a operator online at all times to provide quick responses to 'page commands, and why security actions must be swift and precise. If you're like most operators (and owners), you don't want people to have give the impression that your Palace is a chaotic and lawless place, but you're not trying to create a police state, either.

Due to your rank and power, your effect on the local culture is considerable; it should not be underestimated or wasted. Obviously, if you set a good example and act responsibly, "good people" will reflect your attitude and "bad people" will be quickly dealt with. New users, finding your Palace a friendly place to learn about the software, will hang around longer and your "population" will gradually increase.

However, the opposite is also true. If you act in a negative or confrontational manner, killing people without warning or using questionable language, you shouldn't be surprised to find that your users quickly begin emulating your behavior, or that those few who enjoy that sort of thing are the only visitors you have left. Soon gangs, fanatics, and guys named psykoK!LL3R will be popping up like weeds, using your site as their own personal battlefield. This kind of environment can send your site into a tailspin as attitude clashes and personal grudges develop into 24-hour-a-day flame wars.

 

Helping new users

One of the things that can add a lot to a Palace's appeal is the willingness on the part of the operators to help new users learn about The Palace software in a friendly, supportive environment. No one is born knowing all the functions in the interface, and few find the time to read the manuals thoroughly, if at all. Besides, for many people, the best way to learn something is just to jump right in and play with it, as long as they can ask questions of a more experienced person as they go. The Palace interface is simple enough that this approach works very well for most people, and as a result a lot of your visitors may be first-time users of the software.

Palace users tend to roam from site to site, depending on Internet traffic, special events and "what's hot this week," but most of them soon find a site or two that they think of as a "home base." Very often, this home base is one of the first sites they ever visited -- or the first one where the people were friendly and there was a good conversation going on. By helping new users with their problems and learning curves, you increase your chances of becoming that site for them.

 

Being a good host

The world isn't all about security and learning curves. In addition to a place where they feel safe, people want a place to have fun, and that's something The Palace can provide in great abundance. A good Palace site is something like a public park or a private club, in which a great party is always going on. Ideally, you want your users putting your address in the first slot on their bookmark list, running around talking about how much fun your Palace is, and calling up their friends, telling them to join the party!

Unless your site is extremely popular or comes with its own built-in user group, it's often a good idea to provide some kind of special reason for hanging around. Whatever your special draw is -- cool props, animated rooms, interactive scripts, funny sounds or beautiful art -- one thing you should always try to maintain is a relaxed and friendly atmosphere, a place where people feel free to be themselves (or their alternative selves), and join in a growing sense of community.

Like any party, the initial "feel" or "theme" is set by the host. Certainly, everything about your site -- from art and sounds to scripts and custom props -- contributes to the overall feel of the place, but as a operator, it's helpful to remember that you are the living part of the site. If you're a fun person to be around you'll attract good company, and people will be stopping by to visit long after the appeal of the interactive doodads has worn off.

 

Special events

Another way to increase the fun factor (and population) of your site is to hold special events of various kinds. Special events come in all shapes and sizes, and can be run on a regular or occasional basis. With the proper scripting, The Palace software can support a variety of interactive games, puzzles and "exploratory environments," as well as more free-form activities such as cooperative painting, room decorating (a common pastime in some circles) and the ever-popular "avatar contest."

The most important thing about special events is that you let people know about them. The easiest ways to do this is to list your event in the Palace Events calendar. Go to the Events Calendar page on the Palace website (www.thepalace.com), and fill out the Event submission form by clicking the button at the bottom of the page.

If your events begin drawing a real crowd, eventually they'll grow too large to hold in a single Palace room. At this point, you might want to consider beefing up your software with The PalacePresents Moderator, available from the Palace website. With the help of this plugin (and an active operator password), you can run large-scale "broadcast" events such as interviews, lectures, web tours, and multimedia presentations of all sorts. Using a companion plugin called the PalacePresents Viewer, participants can watch the event in a separate "stage" window -- from any room in your Palace site. They can even submit questions or comments to the stage, to be used or discarded by the event moderator (that's you). The PalacePresents Viewer is distributed with The Palace User Software client.

 

Palace patrol

You can pretty much accept it as a fact that -- sooner or later - someone will do something in your Palace that you'd prefer they didn't. When it comes to maintaining any type of behavioral standards, censorship, or other form of social control over your own Palace, the choices you make are entirely your own.

This is good news on the surface; after all, it guarantees your freedom to run the place the way you see fit as long as you do no one any harm, just like the owner of any other type of establishment. However, it also guarantees that you will be the one responsible for creating whatever social standards will exist in your Palace, and for communicating your goals and intentions to your users.

Unfortunately, not everyone is considerate (or even aware) of your intentions. The Internet can be a scary place for site owners in these days of "political correctness" and "communications decency," and the situation is made no better by allowing abusive individuals to waste your bandwidth and drive away your guests. The next section gives you some ideas on what you can do about this.

Security functions

One of the unfortunate aspects of the operator's duties is that once in a while it becomes necessary to exercise force when dealing with an uncooperative Palace abuser. Although as a operator you certainly possess the tools necessary to "kill" users for the least indiscretion, the fact remains that violence -- even in cyberspace -- has a tendency to escalate. Killing should therefore be considered only as a last resort (obviously, this excludes "adventure" sites and games in which dying is part of the rules).

This section provides some guidelines that can help you make such judgment calls, and learn the security tools at your disposal.

 

Make chat, not war

Some users are so clueless they'll do things that can be interpreted as being intentionally disruptive, even though they don't intend them that way. Some new users, for example, habitually hit the return key twice (which is a vestige of IRC and BBS chat). There are many similar "minor offenses" that should hardly warrant a operator's attention, except for the fact that they do. Users like this are in need of an education, not a reprimand.

In The Palace, as well as in real life, it is always better to talk than to kill. Not only does killing increase the chance of a disruptive user becoming a truly hostile one, but each kill adds a little more to your reputation as a "mean" operator (or at least a "hardcore" one). If the "kill ratio" is very high in your Palace, due to intolerant operators or deadly censor scripts, the user community will learn about it, and the decreasing flow of traffic to your site will reflect this fact.

Even an obnoxious user should generally be warned at least once before being killed, and given sufficient opportunity to amend his or her behavior. Of course, there are some cases where you might have to kill without warning. For example, an obnoxious user might be flooding the server by continually repeating the same message (using the up arrow and pressing Enter over and over again). In this case it may be difficult to warn the user, because their keypressing nonsense is using up all the available bandwidth (of course, depending on the server's sensitivity to Flood Events, the system may take care of this for you). Another case in which unannounced killing might be appropriate would be that of a previous offender who returns to your site and shows signs of continuing the same behavior.

 

Keeping a log

One rule you should always follow is this: whenever you're on duty, or at least whenever you respond to a page regarding offensive behavior, you should always make sure you're keeping a log file on your own computer. In the heat of the action, things can be said that become forgotten, confused or distorted after the dust settles. Keeping a log is a good way to back up your performance and decisions with cold, hard facts; providing you with an exact transcript of the entire event.

 

Tools of the trade

This section describes the "arsenal" of virtual tools available to operators as part of the security operations at their site.

 

The Operator Badge

At certain Palace sites, you may notice some avatars running around with an asterisk ( * ) preceding their names (e.g., " *JustBob "). This asterisk prefix is known as a operator badge,and denotes the user as an owner or operator. Only users with owner or operator privileges can prefix the asterisk to their names. Note that operator badges are in no way mandatory; some sites prefer to use them, while others prefer not to. If your site does use operator badges, remember to be consistent with them -- operators on such sites should wear their badges at all times while on duty.

Operators should consistently use the same name when on duty, unless circumstances dictate that another name would be more effective (e.g., during a "sting operation," or while observing events "incognito"). There are a number of reasons for this. First, most of the time (thankfully), operators are more like "beat cops" than detectives: their primary duty is to make life easier for everyone on the site, and part of that involves maintaining a visible presence. A lot of people just want to know directions to that room they heard about, or when the next "Wheel of Cheese" game is scheduled. The badge makes it easier for newcomers and other users to find you in the crowded User window, and reminds potential offenders that operators are present.

 

The 'list command

Use the 'list command to get fundamental information about users, in terms of their names and IP addresses (both DNS and numeric IP). You can run this command either on an individual or a whole group. This is particularly useful for identifying the return of chronic abusers. In its unmodified format ('list), the names and IP addresses of all users in the current room will be displayed in the operator's Log window. See 'list [-k | -o | -p | -w ] [ ip | name ] for more information.

The 'list command can take a number of optional arguments; here are some examples:

 

• 'list Guest 123

   

  This variant lists information for Guest 123 only. This is the preferred way to get info on a user, as it makes only one call to the nameserver, instead of one for each user in the room.

• 'list -k abuserName

   

  The -k variant adds an alphanumeric key to the end of the listing, which is based on the user's registration code. Since this key is linked to the user's copy of The Palace client, it can be used to uniquely identify a particular member regardless of IP address.

• 'list 205.23

   

  This variant lists info for all users whose IP addresses begin with "205.23." Note that you must use a numeric address (as opposed to a DNS name) for this to work. This can be used to help determine whether an apparently new abuser is or isn't the same one you killed before.

In all cases, the `list command has the following format:

*** ; g ratbot 206.17.52.5 Red Room
*** ; n Guest 679 204.87.136.14 Palace Gate
*** ; m CrashCat 206.21.38.10 Palace Gate
*** ; w Mark J 206.17.52.4 Red Room
*** ; m Lally orlfl2-6.gate.net (199.227.1.134) The Armory
*** ; n Guest 529 204.188.133.29 The Spa
*** ; m rorschach 206.17.52.6 Palace Gate

The single letter in front of the name represents the member's status:

g = owner

n = newbie (same as "guest" -- the "g" was already taken)

m = member

w = operator

You may be able to find a DNS-style address by doing an nslookup on your local ISP, if you have access to a UNIX shell account, otherwise you might try using an nslookup utility or web-based search engine.

As a general rule, NEVER PUBLICLY EXHIBIT a user's IP address. Palace servers keep this information private as a favor to users. Of course, you are encouraged to share this information with your fellow operators via the 'page command; as long as it's a matter of security, they have a right to know.

 

Gagging

You can gag a user named "Paul" by typing:

'gag Paul

If he's in the same room as you, you can target him (by clicking on his avatar) and then simply type:

'gag

Gagging a user prevents him from saying anything to anybody in any room. If you gag a member, the gag will remain in effect permanently until the member is either ungagged, or remains logged off for 2 hours. At least one Member has reported a "bug" that turned out to be a gag. If you gag a guest, however, they can simply sign off and sign back on to release themselves, which pretty much begs for the banip command to pulled out.

You would ungag Paul by typing:

'ungag Paul

It's pretty much a matter of personal discretion whether to kill or gag. Sometimes gagging an abusive user, talking to them and then ungagging them after getting a visual sign of their acquiescence is all it takes to keep the peace.

In other cases, however, this simply makes them more obnoxious than ever. In such cases, you have no choice but to issue a kill command. The following guidelines are helpful when choosing whether to gag or kill: if the user isn't using obscene or foul language, if they're simply being an obnoxious pest (repeating the same phrase over and over, etc.), gagging is probably appropriate. If the user is being obscene, the typical response should probably be issuing a warning, followed (if necessary) by a kill.

It's not as important to warn before issuing a gag command, but your next action should be to explain to the user that they have been gagged, what the effects are, and ask them to indicate visually that they understand. They can do this by donning a specified prop, or by using the number keys to nod up and down. Bear in mind that once ungagged, they may immediately resume the obnoxious behavior. Good luck.

 

Prop gagging

This command allows you to prevent a member from showing offensive props. Even if their language is non-offensive in and of itself, members who wear obscene or hateful props should be propgagged:

'propgag Sexy Sally

After propgagging them, you should talk to them about the prop, obtain their agreement not wear the prop in your Palace any more, and unpropgag them:

'unpropgag Sexy Sally

If the member continues to wear the prop, kill them.

 

Pinning

The pin and unpin commands operate similarly to gag and ungag, but have a slightly different effect:

`pin Guest 5757

This command pins the target to the lower right corner of the screen and puts a pin prop on them. By default, this is a chain, but if you are an owner, you can set it to the prop you (as the Palace owner) are wearing with the pinprop command. The target is not allowed to move, and cannot put on any props. Note however that unless the offender is also gagged, they will still be able to talk.

`unpin Guest 5757

This removes the effect.

Pinning is particularly appropriate for people who abuse the "physical space" of The Palace (these offenders are sometimes referred to as "blockers").

 

Killing

You should always perform three basic steps when killing a Palace user: these three steps are 'list, 'kill, and 'comment. In the following example, we'll assume your name is "Merlin" and you need to kill someone named "hakker".

 

1. List their IP address and regkey with the following command:

   'list -k

   The server will reply via the Log window. For instance:

   *** ; m hakker 206.17.52.5 Operator's Study {DFEF}

   Record the user's IP address (machine.somedomain.com) and regkey (DFEF) in your notebook. The regkey is only provided for members -- it gives you a unique alphanumeric key you can use to identify a user, even if they use a different IP address or name.

2. Kill them by typing:

   'kill 120 hakker

   The server will respond with:

   Page from System: hakker 206.17.52.5 killed by Merlin

   The number 120 is the death penalty, in minutes. This means that "hakker" won't be able to get back on for 120 minutes (120 is a fairly "normal" death penalty). If the person is being highly offensive, you may want to use a larger number; sometimes a penalty of a day or two is in order (for reckoning purposes, there are 1440 minutes in a day). Of course, even after the penalty wears off, it can always be extended using the 'extend command.

3. Remember to comment your kill by typing `comment followed by your message. For instance:

   'comment 206.17.52.5 Using foul language, second time killed.

   This is important for purposes of maintaining a clear transcript of events as they happened.

   NOTE: It is important to recognize that killing a member typically has more consequences than killing a guest. There are two principal reasons for this. First, when members are killed, the software keeps track of their registration code and prevents them from logging on from ANY IP address. Second, members have registered, and therefore tend to feel that they're entitled to more leeway than guests. While this is in no way true as far as abuse goes, you're more likely to hear complaints from members than guests.
   
   Regardless of their membership status, all users should understand that abuse is abuse, and that you have the right to defend your own site from it. If challenged, you can always point out that all users -- members and guests alike -- "sign" an agreement not to abuse the system when they first install The Palace on their computer.

    

Site banning

When you kill a guest, no registration code exists; this means the server can only keep track of the user's IP address. If the abusive guest switches computers or gets a new IP address from his or her ISP, they will be able to come back on. However, in such cases you will generally see a pattern to the IP addresses, like this example:

*** ; n Guest 1223 205.240.253.23 Palace Gate

*** ; n Guest 1228 205.240.253.37 Palace Gate

*** ; n Guest 1232 205.240.253.18 Palace Gate

Typically only the last part of the IP address will change. If you believe a guest is a repeat offender, you should do a banip on the entire B block of IP addresses with the banip comamnd:

'banip 120 205.240.253.*

In this example, 120 is the death penalty, and the "*" indicates a "wildcard" ban of all addresses beginning with 205.240.253. Again, you should comment the ban to indicate who you are keeping out. In this case, you should provide only the first 3 numbers in your 'comment:

'comment 205.240.253 Guest 1223 violated at least 3 of the 10 commandments.

It is important to note that a "wildcard" ban only works on guests from the IP addresses in question; not members. Also of note is the fact that this command can be easily overapplied: for instance, although the software will allow you to ban an entire ISP at one time, it's hard to imagine a case where such a broad course of action would be recommended. Keep the wildcards to a minimum, and try to restrict their use to A- and B-level IP blocks (i.e., the rightmost two numbers in the IP address).

 

The BanList

The server keeps a record of all currently-banned users, user information and comments in the banlist. See the command 'banlist for more information. To see the banlist, type:

`banlist

Note that this list can get very large, especially on a popular public site. To search the banlist for a specific person or IP address only, simply type:

'banlist name

or

'banlist ip

Whichever variant you use, the requested information will appear in your Log window. Here's an example:

*** ; Flooder 5 min (0) (205.162.99.999) user1 banned by system
*** ; Flooder 5 min (0) (205.162.99.999) user2 banned by system
*** ; Killed 0 min (0) (205.162.99.888) user3 banned by allegro
*** ; Killed 0 min (0) (205.162.99.999) user4 banned by allegro
*** ; Tracked 205 min (0) (205.162.99.999) site tracked by New Friend
*** ; comment by New Friend: killed for bad language
*** ; Site Ban 205 min (0) (205.999.99.999) site banned by allegro
*** ; comment by allegro: operator-baiter with an obscene prop

Not counting the operators' comments, each line in the banlist shows why a given user was banned, for how many minutes, how much time is remaining (in parentheses), and the user's name and IP address at the time of the kill. A few notes on reading the banlist:

 

• A Flooder is a user who was killed by the server for flooding. Flooders are killed for 5 minutes only.

• Killed indicates a user who was killed by a operator using the 'kill command.

• A Cracker is a user who was killed by the server for attempting to use an invalid Palace serial number.

• Site Ban means an entire range of IP addresses was blocked out using the `banip command. Wildcard site bans are listed with a zero in the last position of the IP address.

  NOTE: You should periodically do a 'purgebanlist command to rid your banlist of expired records.

   

The `hide, `mute, and `reject Commands

Even if things never get to the level where operator commands are called for, there are still plenty of people who take delight in being annoying, intrusive, or disgusting. Sometimes the effect is subjective: two people can simply rub each other the wrong way, or bring out the worst in each other, for no apparent reason. When both are logged on at the same time, everything seems to take a backseat to their petty personal conflict. Sometimes it's even more subtle: certain people seem to continually emit a "creepy" presence, even though no rules of conduct are actually broken. Sometimes it's hard to tell if anything happened at all: you may be called to intervene in a situation where one party claims to have been harassed by another party, who (of course) vehemently denies that any such thing occurred.

Without coming down in judgment of anyone in such a situation, it's generally helpful to mention hide and mute, two member commands allowing members to protect themselves from other users.

 

'mute

Despite what users may believe, the mute command operates locally (i.e., on the computer of the member who executes it); its effect is to screen out any cartoon balloons coming from the muted person. To mute a user called "Guest 13," for instance, a member would type:

`mute Guest 13

To cancel the effect, the user may type:'`unmute Guest 13

 

'hide

'hidefrom user

These commands allow a member to "hide" from appearing in the Find User window. The 'hide command hides you from everybody on the server, while the 'hidefrom command hides you only from a particular user. Note that neither of these commands works against operators, who always see everyone on the server. The opposite of `hide is `unhide. The opposite of 'hidefrom is 'unhidefrom. Examples:

`hide

`unhide

`hidefrom Guest 13

`unhidefrom Guest 13

 

'rejectesp

'rejectprivate

The 'rejectesp command allows members to reject all incoming "ESP" messages from other users. The 'rejectprivate command is similar but rejects all private messages (this includes ESP messages). When you turn either of these settings on, it remains in effect until you turn it off -- even if you log off. Examples:

'rejectprivate on

'rejectprivate off

'rejectesp on

'rejectesp off

 

Recommended escalation procedure

The following steps provide a standard operating procedure for handling users who exhibit consistently or increasingly disruptive behavior. This list is sequential in nature: it represents a gradual escalation of your responses to increasingly abusive actions.

While this escalation procedure may seem lenient to some operator types (warning the abuser each time a punishment is about to be meted out, for instance), it's usually better to err on the side of discretion than to "shoot first and ask questions later." After all, the only thing worse than having to deal with a Palace abuser is having to justify yourself after the fact. Since over-reacting can be as bad as under-reacting, the goal is to effectively solve the problem while using no more than the necessary and appropriate amount of force.

 

Step One: First Warning

The first step is to address the abuser directly, informing them of the house rules and asking/telling them to stop the abusive behavior. Sometimes the abuser is unaware that what they are doing is "illegal." Most of the time they're are quite aware of what they're doing, but they'll stop if they know they're being watched. At this point you may want to specifically mention the local "remedy" for the offense in question. For instance: "If you don't stop swearing you will be gagged for ten minutes."

 

Step Two: Gag/Propgag/Pin

If the initial warning doesn't succeed in halting the unwanted behavior, the abuser has effectively decided to challenge your authority. Strange as it sounds, sometimes they will even dare you to carry out your threats (i.e., "Go ahead, mister operator -- gag me!") It is important not to get personally offended by these taunts. It's not a good idea to kick people for purely personal reasons, as this may give you a reputation as a "bully" or "dictator."

This is another reason why it's important to have established local guidelines for specific offenses: when you take action in a highly-charged situation, it helps to know that any other operator on your site would have done the same thing. If the abuser continues the offensive behavior, simply move to the next step. Depending on the specifics of the situation, the appropriate response will be a gag, a propgag, or a pin, lasting for several minutes (or until the abuser logs off).

 

Step Three: Second Warning

Usually a minute or two under a gag will convince an abuser to log off and go bother someone else. It doesn't keep them from coming back, however, and sometimes it makes them worse, as some of them seem to take this as a personal challenge. In either case, if the abuser persists in acting offensively, you should inform them quite clearly that will disconnect them from the server if they don't stop immediately. While we're on the subject, you may not want to use the word "kill"; it can be taken as an idle physical threat. "Disconnect" has the advantage of meaning exactly what it says, but if you prefer a more poetic term, "kick" is always a good one.

 

Step Four: Kill

Any abuser who's willing to escalate things to step three probably isn't going to stop there. Since they've already been warned and have chosen to disregard it, it's time to be true to your word. Remember that killing on The Palace is neither painful nor permanent: it's more like batting a fly away from the picnic table. Of course the fly (being relatively ignorant of your concerns) may choose to return to the scene, often from a new IP address. If this happens, it's time to pull out the big guns.

 

Step Five: Third and Final Warning

If you find yourself at this stage, it means that a killed abuser has returned to your Palace and shows signs of resuming the offensive behavior. The abuser may have simply waited until the death period expired, but in some cases the new attack will come from a different IP address -- indicating that the abuser has access to The Palace via more than one computer. Once again, a warning is recommended; your intentions should be communicated in no uncertain terms. For instance: "Act up once more and you'll be banned from the site." At this point the smallest infraction should be enough to escalate the matter to the next step.

 

Step Six: BanIP/Ban

If the abuser is a member, the local owners can ban them by name. This is generally effective because the user's (Palace client's) registration code is used to prevent reconnecting under any name. If the abuser is a guest, however (as they often are), they may simply try to reconnect from somewhere else. Note that when abusive guests do move to another computer, it's usually within the same block of IP addresses. This indicates that the second computer is in close physical proximity to the first (they often belong to the same bank of machines located in a school computer lab, or fall within a single B block allotted for dynamic assignment by an ISP). Since in either case the abuser attains a new IP address, he or she is no longer affected by the commands you executed previously.

This is why operators have been given access to the banip command -- in case of just such emergencies. This command not only allows you to ban an individual guest from connecting, but all guests coming from the same block. That means that until the ban expires or is lifted, no guest-level users from any of the affected IP addresses will be able to log in. Obviously this is a bit of "overkill," because everyone on the subnet is forced to suffer for the infractions of a single user, but you put it off as long as you could.

 

After the event

Abusers who have been denied connection for more than a few hours tend to stay away for a very long time, if not forever. What this really means is that after a few unsuccessful attempts to reconnect to your site, the abuser eventually gives up and goes somewhere else. Once in a while, however, you'll encounter a goofball with a lot of free time (and a lot of IP addresses), who decides that their mission in life is to give you a headache.

Fighting a maniac with a vendetta is a huge waste of time and energy, and is not recommended for the sane. Certainly the local operators can ban the abuser whenever he or she shows up, but this isn't a satisfactory solution. You want to keep your cool, but you need a way to escalate your response. What should you do?

Since by this time the operators have already run through the escalation procedure, followed all established security standards, banned the abuser and maintained logs of the event, they've done all they can do. The matter should now be handed over to the local Palace owners, who will render a decision on what to do next. Often a call or email to the administrator/owner of the offender's account can put things straight in a hurry; this is another good reason operators should maintain a log for all such occurrences.

A perusal of the owner commands will show that only owners have access to the ban command (allowing them to ban a single IP address). This is because use of the ban command can be taken as an indication of "extreme prejudice" against a particular individual, and is therefore mitigated to the level of "systems administration" (in the traditional network sense). Beyond this point, matters should be handled between the administrators of the two sites involved (i.e., yours and the offender's). Most of the time, the administrators at the site of origin (the abuser's ISP, for example) will revoke the abuser's account privileges once incriminating or potentially controversial evidence is produced.

Authoring

Since the Operator menu lets you access and edit almost every line of code in the server script, authoring can be as simple or as complex as you want it to be. The owners of each Palace make their own rulings as to whether or not authoring will be allowed on the server, but in general it's not a good idea unless the operators in question are very fluent in Iptscrae. Even then, it's usually a good idea to do any major revisions on another server, or during "closed" hours. This is because it's possible to inadvertently create a snag that will effectively "hang" the whole site, causing the Palace server to crash and disconnect all users online. When this happens, the server's prop file may become corrupted as well, creating even more work for the Palace owners. In addition, sudden major changes to the script will cause lag and may be very confusing to users.

Any operator should be familiar with some of the basics of Iptscrae, if for no other reason than being able to diagnose a problem if no one else is around. The following subsections provide an overview of these scripting fundamentals.

Animation and scripting

With clever code and specially-designed graphics, you can pull off a wide variety of animation effects in The Palace. The two basic types of animation possible within the Palace environment are prop-based and spot-based. No matter what effect you're looking for, however, before you can really make things "come to life" you'll need to an introduction to Iptscrae, the Palace programming language.

Iptscrae

Iptscrae is a Forth-like, stack-based language used exclusively by The Palace software. The single most noticeable (and misunderstood) feature of the language is its syntax, which makes use of RPN (Reverse Polish Notation). Another term for RPN syntax is "postfix," since the operators (or "verbs") in RPN are placed after the operands in a statement. This is in contrast to the "infix" method most westerners are familiar with, in which the operator is placed between its operands. If you've ever worked on a Hewlett-Packard programmable calculator, you're familiar with RPN already. A few examples will illustrate the difference:

Infix:	Postfix:
2 + 3	2 3 +
(2 + 3) * 4	2 3 + 4 *
X = 4 - 3	4 3 - X =
printf("Howdy")	"Howdy" Say

Infix vs. Postfix Syntax

As you can see, the basic difference is that postfix word ordering places the effective "verb" (operator) after both "nouns" (operands): "two plus three" is phrased as "two three plus." Despite how strange it looks to most of us, to a stack-based system like The Palace this method makes a lot more sense and wastes fewer system resources. The reasoning is simple: since your computer can't add any two numbers until it knows what they are, there's little reason to make it store the "plus" operator while you're giving it the operands.

Of course, we can only begin to scratch the surface of Iptscrae's potential here. As a fully-fledged programming language including over one hundred specialized commands and keywords, the very point of Iptscrae is to allow you to create new interactive scripts "from scratch," and the only way to really get familiar with it is to use it. To give you something to start with, the following scripts illustrate a few fundamental animation effects. The first two examples cover the use of the picture list for both Windows and Macintosh users, and the third illustrates how to move a picture around dynamically. Don't worry about the commands you don't understand yet; you can always pick up a copy of The Iptscrae Language Guide online at the Palace website.

Example 1: "Tumblin' Die"

The example picture list shown here is used to create a randomized die in a hotspot. In its starting state (state 0), the die is not visible (since there is no graphic associated with the spot in this state, the background image is seen "through" it). States 1 through 6 correspond to the six GIF images used to represent possible rolls of the die. By clicking on the die (or more accurately, by clicking on the corresponding spot), the user triggers the following script:

ON SELECT {
6 RANDOM 1 + dieRoll =
dieRoll ME SETSPOTSTATE
}

The Pictures List (Windows version)

Example 2: "Sign O the Times"

The picture list shown here corresponds to the flashing neon sign in "Harry's Bar" (in the Mansion). In its starting state (state 0) no picture is displayed; the background image is seen. In state 1 the picture "BrNeon1.gif" is displayed, while state 2 displays "BrNeon2.gif". Here's the script:

ON ALARM {
{
0 ME SETSPOTSTATELOCAL
} {
ME GETSPOTSTATE 1 + ME SETSPOTSTATELOCAL
} ME GETSPOTSTATE 1 > IFELSE
180 ME SETALARM
}

The Pictures List (Macintosh version)

Example 3: Picture-Moving

This script is a simple room-level demo that can be pasted directly into your script file. It causes a picture to move across the room and back again when clicked. Be sure to change the IDs and names so they apply to your server.

ROOM
ID roomID
NAME "roomName"
PICT "pictureName.ext"
PICTURE ID 100 NAME "picture.gif" ENDPICTURE
SPOT
ID 1
NAME "Moving Picture"
OUTLINE 100,200 250,200 250,260 100,260
; The "OUTLINE" assumes the picture is 150 by 60 pixels.
; Here come all the "states" the picture could be in...
; The first "state" is state 0, followed by 1, 2, etc.
; A picture's "state" always consists of three things:
; pictureID (as above), horizontalOffset, and verticalOffset
; Notice that here we are only changing the horizontalOffset.
PICTS 100,0,0 100,10,0 100,20,0 100,30,0 100,40,0 100,50,0 100,60,0 100,70,0 100,80,0 100,90,0 100,100,0 100,110,0 100,120,0 100,130,0 100,140,0 100,150,0 100,160,0 100,170,0 100,180,0 100,190,0 100,200,0 ENDPICTS
; Also note: that's all one line, from "PICTS" to "ENDPICTS"
SCRIPT
ON SELECT {
{
; Now we move the picture across the Room
; (from state 0 to state 20)
{ 1 ME SETSPOTSTATELOCAL } 1 ALARMEXEC
{ 2 ME SETSPOTSTATELOCAL } 10 ALARMEXEC
{ 3 ME SETSPOTSTATELOCAL } 20 ALARMEXEC
{ 4 ME SETSPOTSTATELOCAL } 30 ALARMEXEC
{ 5 ME SETSPOTSTATELOCAL } 40 ALARMEXEC
{ 6 ME SETSPOTSTATELOCAL } 50 ALARMEXEC
{ 7 ME SETSPOTSTATELOCAL } 60 ALARMEXEC
{ 8 ME SETSPOTSTATELOCAL } 70 ALARMEXEC
{ 9 ME SETSPOTSTATELOCAL } 80 ALARMEXEC
{ 10 ME SETSPOTSTATELOCAL } 90 ALARMEXEC
{ 11 ME SETSPOTSTATELOCAL } 100 ALARMEXEC
{ 12 ME SETSPOTSTATELOCAL } 110 ALARMEXEC
{ 13 ME SETSPOTSTATELOCAL } 120 ALARMEXEC
{ 14 ME SETSPOTSTATELOCAL } 130 ALARMEXEC
{ 15 ME SETSPOTSTATELOCAL } 140 ALARMEXEC
{ 16 ME SETSPOTSTATELOCAL } 150 ALARMEXEC
{ 17 ME SETSPOTSTATELOCAL } 160 ALARMEXEC
{ 18 ME SETSPOTSTATELOCAL } 170 ALARMEXEC
{ 19 ME SETSPOTSTATELOCAL } 180 ALARMEXEC
{ 20 ME SETSPOTSTATELOCAL } 190 ALARMEXEC
} ME GETSPOTSTATE 0 == IF
{
; ...and back to the start again
; (from state 20 to state 0)
{ 19 ME SETSPOTSTATELOCAL } 1 ALARMEXEC
{ 18 ME SETSPOTSTATELOCAL } 10 ALARMEXEC
{ 17 ME SETSPOTSTATELOCAL } 20 ALARMEXEC
{ 16 ME SETSPOTSTATELOCAL } 30 ALARMEXEC
{ 15 ME SETSPOTSTATELOCAL } 40 ALARMEXEC
{ 14 ME SETSPOTSTATELOCAL } 50 ALARMEXEC
{ 13 ME SETSPOTSTATELOCAL } 60 ALARMEXEC
{ 12 ME SETSPOTSTATELOCAL } 70 ALARMEXEC
{ 11 ME SETSPOTSTATELOCAL } 80 ALARMEXEC
{ 10 ME SETSPOTSTATELOCAL } 90 ALARMEXEC
{ 9 ME SETSPOTSTATELOCAL } 100 ALARMEXEC
{ 8 ME SETSPOTSTATELOCAL } 110 ALARMEXEC
{ 7 ME SETSPOTSTATELOCAL } 120 ALARMEXEC
{ 6 ME SETSPOTSTATELOCAL } 130 ALARMEXEC
{ 5 ME SETSPOTSTATELOCAL } 140 ALARMEXEC
{ 4 ME SETSPOTSTATELOCAL } 150 ALARMEXEC
{ 3 ME SETSPOTSTATELOCAL } 160 ALARMEXEC
{ 2 ME SETSPOTSTATELOCAL } 170 ALARMEXEC
{ 1 ME SETSPOTSTATELOCAL } 180 ALARMEXEC
{ 0 ME SETSPOTSTATELOCAL } 190 ALARMEXEC
} ME GETSPOTSTATE 20 == IF
} ENDSCRIPT
ENDSPOT
ENDROOM