MUSH Manual Version 2.008: Copyright 1993, 1994, 1995, Lydia Leong (lwl@netcom.com / Amberyl) Last revised 5/22/95. Section IV: Wizard's supplement 8. Owning and seeing everything 8.1 Special privileges, ROYALTY, and Powers 8.2 Attribute ownership - @atrchown and @atrlock 8.3 Object ownership - @chown and @chownall 8.4 The queue - @ps and @allhalt 8.5 The database - @entrances, @find, @search, and @stats 8.6 A note about security and privacy 8.7 The Master Room and command processing 9. Wiz-specific commands 9.1 Talking to other wizards: @wizwall and @wizemit 9.2 Messages: @wall, @listmotd, @motd, and @wizmotd 9.3 Locking out players: @login and @rejectmotd 9.4 Dealing with players: @newpassword, @pcreate, @boot, @toad, and @destroy 9.5 Dumping the database: @dump and @shutdown 10. Database control 10.1 Quota system: limited object creation - @allquota, @quota, and @squota 10.2 Money control: give and @poor 10.3 Consistency checking: @dbck and @purge, @dump/paranoid, @cut, @fixdb 11. Zones 11.1 Object zones 11.2 Parent room zones 11.3 ZoneMaster players 11.4 Some notes on local wizard control 12. The Fundamental Laws of Wizarding 12.1 Wizard Etiquette 12.2 The Five-Step Method of player management warning - nasty warning - gag - boot - newpassword 12.3 Wizard commands and when they ought to be used This section was written with the 1.50 wizard in mind. If something is mentioned that doesn't exist in 2.0, and you're only interested in 2.0, ignore it. If you're going to play with the 2.0 wizard commands that aren't covered in this section, you probably know what you're doing and therefore don't really need those commands covered in this manual anyway. All wizards, however, will probably find something useful in section 12, which provides general rules for wizarding. Mortals may find it interesting reading. 8. Owning and seeing everything 8.1 Special Privileges, ROYALTY, and Powers A wizard, by definition, owns and controls everything except for God. A wizard may manipulate any object by using its dbref number, or by using *player. Remote get, look, and examine work, and a wizard may bypass the HAVEN flag by using "w *=" to whisper a message. A wizard may look at anything by looking at the dbref number, or by looking at *player. Warning: in 2.0 this triggers the odesc and adesc messages. The format of "look" for wizards is somewhat different: the object's name and dbref number is displayed on the line above the description. When looking at exits, the full exit name - including aliases - is displayed. Wizards can teleport to anywhere. In 1.50, the NO_TEL flag and teleport locks do not have any effect at all on wizards; in 2.0, however, wizards ARE affected by teleport locks. In 2.2, this is configurable. The UNFINDABLE flag does not prevent wizards from locating a player. A wizard can also obtain a player's location by using loc(*player), and get any attribute. There is _nothing_ in the database that a wizard cannot see, except for things like the password attribute and other "internal" dark-to-all attributes. The LWHO() function allows wizards to obtain a list of dbrefs of connected players. Also, in 1.50, wizards may watch connects and disconnects by setting the MONITOR flag on themselves, or grant the ability to do the same to another player. (NOTE: the 1.50 MONITOR flag is NOT like 2.0 MONITOR; the equivalent of 2.0 MONITOR is 1.50 LISTENER. 2.0 has no equivalent of 1.50 MONITOR). In both 1.50 and 2.0, WHO for wizards shows an extended listing with connect sites and other special information; to see the listing that mortals get, use the command DOING instead. * * * * * Pern version 1.14 introduced a ROYALTY flag (which can optionally be turned off at compile-time). This flag is settable by wizards. Objects ROYALTY can examine and teleport like wizards, but have no other wizard powers; all of the statements about wizards above also apply to ROYALTY. This flag does not exist in 2.0. PennMUSH 1.50 patchlevel 7 introduced a powers system. This enables wizards to grant specific objects, including players, the power to accomplish certain tasks that previous were restricted to wizards. Also, since the BUILDER and IMMORTAL flags from previous patchlevels are, intuitively, powers rather than real flag toggles, they were changed to powers in patchlevel 7. The powers include "teleport anywhere", "teleport anything", "examine anything", "boot", and most of the other useful wizard powers, save the ability to @force/control anything. Players who receive such powers should exercise them with the same caution a wizard should use, and they should not be given out lightly. A player granted all the powers has all the abilities of a ROYALTY, and more, except for the @rwall command. Therefore, prudence should be exercised in granting special powers. 8.2 Attribute ownership - @atrchown and @atrlock Attributes may be owned independently of objects. An unlocked attribute can be changed by the owner of the object. A locked attribute may only be changed by the owner of that attribute. Locked and unlocked attributes are, for the purpose of triggers and similar evaluation, exactly the same. Only wizards may set attributes on things that they do not own. The most recent player to change an attribute is its owner. Please note that it does not do any harm for someone else to own one of your attributes. If the attribute is locked, however, you will not be able to remove it _even if you are a wizard. A wizard may, however, unlock the attribute and then remove it. In 1.50, two commands are used to handle attributes. @atrchown changes the ownership. The syntax is @atrchown /= @atrlock governs attribute locks: @atrlock /= @atrlock / by itself returns the status of the lock. The 2.0 syntax (which also works in 1.50) is "@lock /", "@unlock /", and "@chown /=". A normal "examine" shows the owner and lock status of attributes. 8.3 Object ownership - @chown and @chownall The @chown command is somewhat different for wizards. A wizard may @chown any object he is carrying, or any object by dbref number. The syntax is @chown =. Not that * is _not_ used in @chown. @chownall transfers the ownership of everything a player owns to another player. @chownall transfers ownership to the wizard who executes this command. @chownall =* transfers ownership to another player. Note the use of the pointer. A @chownall should NEVER be done without the consent of both parties involved, since it is usually difficult to reverse, especially if the recipient owns a lot of objects himself. 8.4 The queue - @ps and @allhalt Wizards can use @ps all to see the contents of the entire queue, or @ps * to see the queue for one specific player. When the queue is very full, or a machine is looping so badly or triggering so many objects that simply halting it is not feasible, the command @allhalt can be executed. This clears out the entire queue - player, object, and wait, and displays to all connected players the message, "Your objects have been globally halted by ." @allhalt should be used sparingly; if the server is slow, the queue may be full, but it may not necessitate an @allhalt. In 2.0, this is "@halt/all" rather than "@allhalt". 8.5 The database - @entrances, @find, @search, and @stats @entrances will work on "here" or on any room number, for a wizard. @stats can be broken down by player, using "@stats " Note the absence of a pointer. Wizards need to be careful with @find, since @find with no arguments outputs the list of all objects that the wizard controls - i.e., the entire database. @search with no arguments, however, only does a @search on the wizard, printing out all the objects he owns. @search with any arguments, however, looks through the entire database, not just the wizard's objects. If you are looking for something, always try to do a @search instead of a @find, especially if you are on a 2.0 MUSH. @search which is restricted to a player is _considerably_ faster than @find. 8.6 A note about security and privacy. DARK. Wizards have enormous power. No notes on a MUSH are private; a wizard can examine them. Wizards can set themselves DARK, disappearing from the WHO list. In 1.50, any actions taken by a dark wizard show up as "Someone" rather than the wizard's name, if the game is so configured. Wizards cannot listen to whispers or pages, and always show up on a @sweep, whether or not they are dark. A wizard owns everything; he can change, destroy, or force it to do whatever he wants (unless it is God). Because of this, wizards must be VERY careful to make sure that there are no programming loopholes in their objects which would enable the objects to @force them to perform certain actions. Wizards should also be careful to announce their presence, if they are entering a room and are DARK. There is virtually no justification for spying on a private conversation (the exception may be listening to two players plotting how to crash the mud, or something similar). A wizard should _always_ check the location of a player before he teleports to that player. Being paged by a player does NOT mean that the player presently wishes for company. In general, the wizard should also ask permission to enter the room. A wizard should also never teleport a player anywhere without asking permission first - this is extremely rude. Occasionally, one tends to act before thinking, but a wizard should try to act with courtesy. Also, remember that in 2.0, wizards who exceed the idle time normally granted to mortals before an inactivity-timeout boot are set DARK. Wizards are also booted for inactivity, but can set their @timeout attribute to an arbitrarily high value; they will not be booted until that @timeout has expired. Wizards who are DARK from inactivity have a "d" next to their time instead of a "D", in the WHO list. In 1.50, wizards are never booted for inactivity. They are, however, set DARK at the mortal inactivity limit, if they are already set UNFINDABLE. If you are the sort of person who tends to forget that he is set DARK, you might want an automatic reminder given to you when you move. The following is useful for this: @move me=[switch(hasflag(%!,Dark),1,WARNING: You are set DARK.)] 8.7 The Master Room and Command Processing In both 1.50 and 2.0, the command parser goes through the steps shown here looking for a match on the command. If it finds one at a particular step, it stops and performs it. If more than one match (say, multiple south exits from a room), one is picked at random. $-commands are an exception to this rule, in that ALL $-commands that match are executed, except that the master room is only checked for $-commands if none are matched in the check around the player. The 2.0 evaluation order: - Uppercase commands (WHO, QUIT, etc) if typed at a terminal. - Prefix-character commands (", :, ;, etc) - The 'home' command. - Exits in the current room. - Exits in the master room - Internal commands. - $-commands in the following places, all checked in parallel: - Objects in your inventory. - Objects in your current location. - Your location (the room itself) - You (optionally) - $-commands in the ZONE chain of the player's location - $-commands in the ZONE chain of the player himself - $-commands in the following places, all checked in parallel: - Objects in the master room. - The master room itself. The 1.50 evaluation order: - Uppercase commands (WHO, QUIT, etc) if typed at a terminal. - The 'home' command. - Prefix-character commands (", :, ;, etc) - Exits in the current room. - Internal commands. - Enter aliases on objects in the current room. - Leave aliases on the object you are in, if applicable. - $-commands in the following places, all checked in parallel: - Objects in your current location. - Your location (the room itself) - Objects in your inventory. - If nothing has been matched: - If the zone of the player's location is a parent room, - Parent room exits - All $-commands on objects in the parent room - Else, - All $-commands on the zone object of the player's location - If still nothing has been matched: - All $-commands on the player's personal zone - As a last resort, when matching still fails, - Global exits (Master Room exits) - All global $-commands ($-commands on objects in the Master Room) In both 1.50 and 2.0, the Master Room contains exits and commands which are global to the entire MUSH. This should be used with caution, as having a lot of global commands slow down the MUSH. Make sure something is really necessary before adding it to the Master Room. If it's only useful in some specific area of building, consider using a Zone instead (see the later section of this manual). Also, because it is necessary to check every attribute on every object in the Master Room for commands which don't match anything, the number of attributes on objects in the Master Room should be kept to an absolute minimum. It is also a good idea to keep the number of objects in the Master Room down, since every object represents an additional UseLock which must be checked. As a general rule of thumb, if an attribute doesn't contain a $command, it shouldn't be on a Master Room object. For convenience, some data attributes can be kept on Master Room objects, but this should be avoided whenever possible, even if the data attributes are set No_Command. Note that the parents of objects in the Master Room, and, in 2.2, parents of objects which are contained by a ZONE chain, are not checked for $commands. This allows you to place data attributes on the parent, for easy reference, thus leaving you with little excuse for ever having non-essential attributes on the object itself. 9. Wiz-specific commands 9.1 Talking with other wizards MUSH code provides the commands @wizwall, @wizpose, and @wizemit. (In 2.0, these are @wall/wiz, @wall/wiz/pose, and @wall/wiz/emit). Note that none of these use an = sign. @wizwall and @wizpose are really the same command; "@wizwall :" is equivalent to "@wizpose " In the case of @wizwall , it is "Broadcast: says, """ In the case of @wizwall : or @wizpose , the format is, "Broadcast: ". @wizemit shows the other wizards "Broadcast []: " 1.50 provides @rwall, @rwallpose, and @rwallemit. They work identically to the @wiz variants, except they send messages to both royalty and wizards, prefixed with "Admin:" instead of "Broadcast:". Only connected players may hear these messages. 9.2 Public messages Wizards can shout using @wall . There is no way of blocking out shouts; therefore, this should be used sparingly. It sends the message to every connected player. Wizards can set the Message of the Day using @motd . The message stays up until another wizard resets it, or the MUSH goes down. The MOTD is shown to players when they connect, and when they use @listmotd. Wizards also have a @wizmotd, which is shown to all connecting wizards. For wizards, @listmotd displays all MOTD messages. 2.0 refers to these commands as @motd, @motd/wizard, and @motd/list. 9.3 Locking out players In certain situations, there may be a need to disable all non-wizard logins. 1.50 code provides the @login command. When @login is off, all player connections will be refused - after the welcome screen, the message set by using @rejectmotd is displayed and the player is disconnected. In 2.0, the command to use is "@enable logins" or "@disable logins". The @enable and @disable commands may be used to tweak other things as well; this is probably the most commonly used of the options. The message displayed to players who cannot connect may be set using @motd/down. 9.4 Dealing with players There is no easy way to retrieve the lost password of a player. Therefore, it is simpler to simply use @newpassword =. The player is informed that the wizard has changed his password. The player should then log in and change his password to something else that the wizard doesn't know. Never @newpassword a player without his knowledge, unless it's an emergency. @pcreate is a command which only works if the MUSH is compiled under registration. @preate = creates a player with the name and password. You may not create two players with the same name. * * * * * @boot * can be used to force a player to disconnect from the MUSH. This is the general punishment for being obnoxious, or for idling for too long. If you are @booting someone for idling, you should, in general, page them with a warning five minutes before doing the @boot. @boot has another use -- killing off sessions of players who are unable to disconnect, due to network problems. Generally, in this case it is best to use "@boot/port", which allows you to boot a specific question. In 1.50, the wizard WHO shows descriptor numbers; in 2.0, you must use the SESSION command to get the descriptor number of a connection. "@boot/port " then closes that specific connection. Players will often request to have "frozen", dead, connections @booted. In 1.50, players will be booted with a message notifying them that they have been booted off the game. In 2.0, players will also be told who booted them off, unless "@boot/quiet" is used, in which case the player will simply be abruptly disconnected without any kind of notification. * * * * * @toad turns a player into an ordinary object, called "A wart toad named " (1.50), or "A slimy toad named " (2.0) and @chowns all his objects to the wizard doing the @toad. The player will be booted off the game, prior to being turned into an object. @toad is actually somewhat redundant. @dest *player will @boot the player, @chown all his objects to the executing wizard, and @destroy the player itself. If possible, use this instead of @toad (TIM code and MUSE, however, may be somewhat different.) Be careful with @destroy #. There is no check to see who the object belongs to or what it is - be _very_ certain that you have the right object number, or you may end up irretrievably blowing up an object which represents hours of programming. There is no way to retrieve @destroyed objects other than rooms (which may be set !GOING). 1.50 prevents this somewhat by forcing wizards to use @nuke to destroy objects which do not belong to them; please don't use @nuke as your standard command for destruction, or you'll defeat the purpose of this safeguard! The wizard command "slay" is a "kill" which always works. There's generally no reason to use it, unless programming a puzzle or something similar; all it does is give the player some money and send him home. 9.5 Dumping the database The command @dump writes the database to disk. In 1.50, this can take anywhere from a minute or two to half an hour - make sure not to do overlapping @dumps. Overlapping dumps can cause crashes, incomplete database writes, and other assorted undesired effects. In 2.0, you don't generally need to worry about doing dumps, as the disk database is saved fairly often and loss from crashes tends to be minimal. The command "@shutdown" shuts down the MUSH. It first does a @dump, gives all connected players the name of the wizard who did the @shutdown, and the message "Going down - Bye", then drops all connections. Don't do this without a very good reason. Note: if you have database damage and are shutting down because the game will crash or doing something else equally nasty in a few moments, DON'T! The straight @shutdown will save the database and your damage will be permanent. In such a dire situation, you have two options: find the God (or other person with direct access to the MUSH account) and have him "kill -9" the process, or do a "@shutdown/abort". This will cause the MUSH to dump core and die, allowing for the damage to be assessed later by someone skliled with a debugger. 10. Database control 10.1 Quotas - limited object creation If quotas are turned on, the command @allquota displays the current quotas and objects owned by all players, and then resets their quotas to the new limit minus the number of objects they currently own. @quota reports the number of objects a player owns, and his quota still available. @squota = reports the number of objects the player owns and his remaining quota, and then sets his quota to minus the current number of objects he owns. If the limit is 0, then @squota works identically to @quota. 10.2 Money control Wizards have unlimited money, and can freely give out money to players using give *player=. Wizards can also take away money from players by giving them negative money. It is generally not a good idea to give players vast amounts of money. The command @poor resets the money of every player on the MUSH to . This command should be used sparingly, if at all. 10.3 Consistency checking The commands @purge and @dbck will probably not be used by most wizards. They check the database for corruption: @purge checks the destroyed object list and makes sure that all the objects on that list are really there; @dbck forces the database to run an internal cleanup and consistency check every ten minutes. @dbck automatically executes @purge. In 1.50, if, for some reason, your database is corrupted but the game is still up (usually through a bug in the internal compression routines), you will find that an attempt to dump the database will cause a segmentation fault and core dump (i.e. a nasty crash). You can generally get a clean database write by using the "@dump/paranoid" command, which very thoroughly scans the database before writing it to disk, checking for non-printable characters and the like. Someone with access to the game's account should then log in, back up the paranoid dump, and then kill off the game process in some manner. 2.0 provides the ability to do some database repair within the game. The first of the db repair commands is "@cut"; this cuts off the object or exit chain at the wizard's location by setting the "next" field of the object to NOTHING. The objects or exits beyond the cut retain their location, but are not accessible except via dbref number. They can be pasted back into their proper places via the @fixdb command. This command allows you to more or less arbitrarily set the fields of an object -- the contents, exits, location, and next pointers, as well as the owner, value, and name. These commands are NOT to be used unless you are CERTAIN you know what you are doing, as it is possible (and indeed rather easy) to produce database inconsistencies/loops which can hang or crash the server. 11. Zones This section only applies to PennMUSH 1.50. Please see a later section of this manual for a description of Zones in TinyMUSH 2.2. 11.1 Object zones A Zone Object (or, alternatively, ZMO - Zone Master Object) is simply an object that other objects have their zones set to. Objects that have their zone field set to a ZMO are referred to as being in that ZMO's zone. There's nothing at all special about a zone object, aside from that property. Anyone who passes the enter lock of a ZMO has control over objects in that zone. Someone who has control of an object via passing the enter lock on the ZMO can do many things that the object's real owner can do, including examining the object, changing its attributes, and setting flags on it. Two notable exceptions are the @chown and @destroy commands, which are reserved to the object's real owner. Also, players NEVER control other players. This control property of zones makes it possible for two or more people to work on a project together. A wizard is needed to @chzone a player to a zone; henceforth, everything that player builds is automatically part of that zone. The wizard-only @chzoneall command changes the zone of everything a player owns. Wizards should not change the zone of a player without first obtaining the approval of all other players in that zone. For example, if I, Amberyl, wished to work on a project together with Annalyn and Tavella, I would @create an object (let's call it MyZone), and then "@elock MyZone=*Amberyl|*Annalyn|*Tavella". This would allow myself, Annalyn, and Tavella to control all objects in the zone. (PLEASE NOTE: wizards should never be in a zone with anyone! It's far too easy for a regular player to abuse an item belonging to that wizard). Players may @chzone their own objects to a ZMO that they own, or are in the enter lock of. It isn't necessary to be personally zoned to a ZMO in order to be able to control objects in it (the only criterion is the enter lock of the ZMO); it is perfectly possible to be zoned to something else (or Nothing), and @chzone the stuff you build to the desired zone. Zones have several other nifty features. First of all, $-commands on the ZMO are "global" to rooms that are part of that ZMO, and to things which are personally part of that ZMO. Also, objects can perform a "@zemit = " to emit a message to all rooms in that zone. This command is computationally expensive and costs 100 coins, but it can be very useful if you have, for example, a space station which uses an intercom system for announcements. 11.2 Parent room zones Parent rooms are a slightly more complex version of zones. The main difference is that, instead of the ZMO being a thing, the ZMO is a room. All information above about object zones also applies to parent rooms. Parent rooms have several more useful properties. First, a parent room is a bit like the Master Room. It is treated as "global" by objects which are zoned to it. If you are in a room zoned to a parent room, you can use exits in that parent room. You can also use $-commands defined on objects placed in the parent room. This essentially allows you to create small areas on the MUSH with their own local "global" commands and exits, without cluttering up the Master Room. Since local commands take precedence over global ones, you don't have to worry about global commands interfering with your local parent room ones. Unless you want to use parent room exits, you should use object zones. Object zones are faster, and cause less overhead for the server to worry about; this is an important consideration if the MUSH is big. 11.3 ZoneMaster players One final type of zone control is possible, using a player with the ZONE flag set. Such players, called ZoneMasters, behave like ordinary players, but any object that they own is controlled by whomever passes the ZoneMaster's enter lock. For convenience, objects which pass the ZoneMaster's enter lock are referred to here as "zone controllers". Zone controllers are able to @chown objects to the ZoneMaster. However, such objects count against the original owner's quota, and the object's creation cost remains charged to the original owner, not to the ZoneMaster. This enables quotas to be set on individual players, while still allowing a "builder character" to own all the objects. The ZoneMaster is more secure than a ZMO, since INHERIT objects may be placed within the zone without any abnormal danger; since all objects within the zone have the same owner, there is no danger of having one's unzoned objects @forced through a security hole. Unlike a standard ZMO, however, the ZoneMaster does not act as a master object; $commands are not inherited off it. Note that this is different from standard zoning in that the "zoned" objects are actually owned by the ZoneMaster; thus, it is possible to use @chzone to place the object in yet another zone, for the purpose of inherit $commands, and so forth. 11.4 Local wizard control It is possible, through use of zones, to have "local wizards". This is accomplished by @chzone'ing all players that you want the local wiz to control, to a ZMO (or parent room; ZMO will be used in this discussion to refer to both). This ZMO should be @elock'ed to just that local wiz. That player will then have control over all objects created by players in that zone. Unlike a real wizard, however, he may not @force players. This may or may not be desirable, depending on your philosophy of administration (assuming you are a god). Local wizards have almost all the powers of normal wizards, without the accountability and expected responsibility of full wizards. Although certain systems, such as MUSE, have used player ranks in a way similar to local wizards, they do not give such complete control to non-wizard (or wizard-equivalent) players. It is the recommendation of this writer that local wizard control only be used if the MUSH is extremely large, and organized into big, but mostly self-contained, groups which require an administrator who must be able to control the objects of his underlings. 12. The Fundamental Laws of Wizarding The section below comes from a "lecture" that I've given new wizards on MUSHes that I'm a "senior" wizard on. I've had several requests for it in printed form, so it appears here, as kind of a summary to this section of the manual. It summarizes rules for wizard conduct, and gives a nutshell guide to wizard commands. The full lecture is available via ftp from the same site where you obtained this manual; it will probably be called "wiz-ethics" or something similar. All administrators are highly encouraged to read the full lecture; this manual only hits the highlights. 12.1 Wizard Etiquette There are three things that players REALLY hate, and which generally constitute abuse of wizard powers. The first is @forcing a player to do something. There's really never a reason to do this. You can almost always duplicate the effect of a command that a player issues by just doing it yourself. Forcing a player to say or pose something is obviously unethical. Forcing a player's objects is also generally a bad idea. Always ask permission before @teleporting a player, or teleporting to a non-public location, even if the location is JUMP_OK. The first is just courtesy; the only reason to ever teleport a player is if he refuses to come of his own free will. It has the potential to mess up some command the player is trying to execute; waiting a moment or two for the player to come on his own isn't going to kill you. Following the second rule will prevent you from teleporting into potentially embarrassing situations. Just because someone is paging you doesn't mean that he necessarily wants to talk to you in person. Don't wander around DARK. If you're going to hang around dark because you don't want people bothering you, stay in one of your rooms. If you encounter another player, announce your presence. The same thing applies to puppets who are DARK. Some people believe that the best way to handle player discipline is to teleport to their location, DARK, and spy on them. This is a breach of ethics, in most cases. Unless you believe that players are deliberately conspiring to destroy the MUSH, do not use DARK for anything other than hanging around without getting bothered by player pages. Two other brief points: don't examine private objects unless you need to, and ESPECIALLY, do not use wizard powers to take code or code segments without permission. In addition, never, ever, wiz while intoxicated! Your judgement isn't steady, and you are also very likely to accidentally mistype a command and cause some sort of minor (or major) disaster. 12.2 The Five-Step Method of Player Management If a player is behaving inappropriately, start with warnings and move up to more direct action. The exception are spammers and those who are being destructive towards the database; @boot and/or @destroy those players immediately. For players who are simply being obnoxious, breaking some of the MUSH rules, etc., page them and politely tell them that their behavior is unacceptable. If they don't respond to this "nice" warning within five or ten minutes, page them again with a more strongly worded warning. If they continue to misbehave, try a threat: "Do that one more time and you're going to be @booted." The next thing to try, if the twink is being stubborn, is setting the twink GAG. Most people will disconnect of their own accord if they're gagged. For really obnoxious, stubborn people, you can then resort to @boot. If the twink returns, do a @newpassword. Note that if you are planning on doing a @newpassword to lock out a twink, you should @newpassword _before_ you @boot, since otherwise, the player can log right back in before you have a chance to type the @newpassword command. The reason for using @newpassword instead of @toad or @destroy is that @newpassword is reversible. You should never use @toad or @destroy on a player who owns stuff; that is a decision for God to make. Just do a @newpassword and send mail to the other wizards. Summary: 1. Nice warning 2. Not nice warning / threat 3. Gag 4. Boot 5. Newpassword 12.3 When to use wiz commands @allhalt: This is an emergency-only command. It will halt all commands on all objects, and clears out the wait queue. If there are any objects which need to run continuously, this command should be used as a last resort. Try to be considerate and retrigger objects that need to run continuously, if you do an allhalt. @boot: Never @boot without a good reason. If a player is on twice and he can't kill one of his connections, he will generally page you and ask for a @boot; don't do one unless he gives you permission. The other use for @boot is detailed in the previous section. @chownall: Never, ever, do one of these without the explicit permissions of both of the parties involved. It's not a bad idea to send mail to God (or at least make sure he knows) if you do one of these. @dbck: The @dbck command is used to force a database consistency check. All GOING objects get recycled. Unless you know what you're doing, there's no real point to doing one. @purge: This checks the destroyed object list for corruption. It's normally done as part of a @dbck. @dump: In 1.x, you don't want to do overlapping dumps. If you don't have FORK enabled, you want to shout before doing one, because it will probably cause quite a bit of lag. Otherwise, @wizwall that you're doing a dump, so the other wizards know not to do one right after you do. @login: You can turn MUSH logins on and off with this command. Unless you've got some kind of emergency which necessitates locking out all players, don't use this. More importantly, don't forget to turn logins back on after the emergency is over. @daytime: This turns on or off computationally expensive commands. God generally makes the decision when these commands should be enabled. Turning them off when they should be turned on probably won't hurt anything, but turning them on when they need to be off has the potential to get God very upset with you. Only 1.50 has this command. @shutdown: In general, only wizards with access to the MUSH account should do @shutdowns, so they can bring the MUSH back up afterwards. The exception is if the MUSH is not autorestarted, and needs to be taken down for a machine reboot or something similar. If the database has somehow been corrupted, a @shutdown may or may not be a good idea -- this command automatically does a @dump, and you might be making your problem semi-permanent. When in doubt, contact God; to shut down the game without doing a @dump, use @shutdown/abort. The most important thing to remember: USE COMMON SENSE. ------ That's it for wizard commands and advice. Comments, corrections, and suggestions should be emailed to Amberyl, at lwl@netcom.com