prev| toc| next
 

5.2.6 Toading

The command for getting rid of players is @toad. The syntax is:

  @toad <player1> [ = <player2> ]

This turns the Player object for player1 into an object of type Thing, and transfers ownership of all objects owned by player1 to player2. If player2 is not supplied, all objects owned by player1 will be @chowned to the wizard issuing the @toad command.

The Thing object will retain all properties that were set on the player.

Occassionally you will need to toad players: sometimes for particularly grave violations of the AUP, more often because the player wants to leave the world or has simply stopped showing up and you want to reclaim unused dbase space.

Some considerations:

As discussed in Section 5.1.4, Security Concerns , Wizards should examine the properties of objects they @chown. If you are @toading a large number of players, or @toading a player with a large number of objects, it's a very good idea to supply a non-wiz player for objects to be @chowned to when @toading (perhaps an NPC player object used just for this purpose). This is of course espcially important if the player is being @toaded as a disciplinary measure for security violations.

If you are @toading idle players to reclaim database space, you will probably want to @recycle objects they own as well. It is advisable to proceed cautiously here. The player may have created rooms, actions, or things that are in public use. So, examine objects as you proceed. It will be much easier to keep track of which objects should be checked and potentially recycled if — again — you use a dedicated NPC character to @chown objects too when @toading. If you are consistent about supplying this character as the second argument to the @toad command, you can periodically review objects owned by this player (@owned <player name>), and @recycle private objects previously owned by @toaded players.

Players often ask to be @toaded when something online upsets them. And, such players often change their minds. And, such players aren't likely to be in a receptive frame of mind if you grill them about whether they really want to leave. So... You can make your life and theirs easier if you institute a "silent grace period" policy. When players ask to be @toaded, just say "OK", and let them leave with a minimum of fuss. But, instead of actually @toading them at that point, give them a new password and new name, and move them to a holding area. This way, if they change their minds, they can come back easily... all you will need to do is rename and repassword the character object. And, you can take care of the database-related details of @toading at your leisure. Periodically, you can review characters in the holding area, and do an actual @toad on those who have been gone for an appreciable period.

Fixing a mistake:

It is not all that hard to accidently @toad someone. If you do, you can recreate the character exactly as it was, except for one thing: You'll have to give it a new password. Hopefully, you have access to the player's email address (see Record Keeping), in which case, you can simply recreate the character and send email letting the player know what happened and telling him or her the new password. If you don't have their email address, recreate the character and wait for a grumpy Guest to show up, demanding to know what happened to his or her character.

To recreate an accidentally slain character, copy all properties from the slimy toad object to a temporary holding object (so that you can reapply them to the new character), then recycle the slimy toad object and immediately @pcreate a new character with the same name (so that the new player will have the same dbref, which might be used in props and programs). Then, copy the properties back from the holding object to the new character.

The `cp' and `mv' commands are the easiest way to shift the properties around, but, be aware that they will not move wizard or restricted properties unless the program is set Wizard... And, be aware that if you are using the `stock' version of cmd-mv-cp, you should not leave it set Wizard: doing so creates a significant security hole. Two options: You can temporarily set cmd-mv-cp Wizard, make your changes, and then set cmd-mv-cp not-Wizard, or... you can install a modified version of cmd-mv-cp (available here) that can safely be left at a Wizard setting.

prev| toc| top| next