If you have a private building project, you might like to set locks exits. When you create locks then subsequently you need to create and configure keys to control who can lock and unlock these exits.
Setting Locks on exits
Seting a lock on an exit limits its use the objects specified in the @lock command.
Since an exit-object only supports one direction, you should set @locks on both, the exit in and the exit out if you want your lock to work both ways (for example, when setting a lock on a door). You must own an object before you can set a @lock on it.
Various types of @locks exits. An exit can for example be locked to a setting (locked or unlocked - that subsequently can be controled by another object such as a key), a person (a name), an attribute of a person (such as a clan or a statistic), something they carry etc.
Examples:
@lock <exit name>=me
Locks the exit to you, so only you may use it.
Creating Locks
Although a door appears to be one thing, with one lock, in MUSH-code it is represented by 2 exits with 2 independant lock-settings, which in turn would require you to lock or unlock the door from both sides. To avoid such sillyness you can also create a lock-object that can be applied to several exits at the same time.
| +lock/config <exit>=<lock> | Creates a lock-object that will entertain the specified <lock>-setting and sets it to <exit>. Exit: is the name or number of the exit that you want to put the lock on. Lock: is the object that the exit will be to: I.e. able to use the exit. This can i.e. be a person, a dead-bolt or a key. |
| &other <other exit>=<lock> | is a command that allows you to use the same lock on another exit (for example the exit back). Other Exit: is the name or number of the other exit that you want to put the lock on. Lock: is the name of the lock that was created earlier. |
Creating Keys
The lock-objects you create above can be controled by keys. A ‘parent key object’ can be used to facilitate this system. This parent object has been created to simplify the setup of such locks, and to allow key-controllers to keep an active list of people with keys.
Set up your own keys with:
@create My Key (A copy of keys for you - see Note below)
@parent My Key=#150 (Set parent to get all the commands)
@set My Key=COMMANDS
+keyinit (Initialize your set of keys)
Commands:
+setlock mydoor=my key Configures lock 'mydoor' to be locked by 'my key'.
+keylist Lists people who "have a copy" of My Key.
+givekey joe Gives Joe access to rooms locked with My Key.
+takekey joe Removes Joe's acccess to rooms locked with My Key.
You may have multiple sets of keys, but be very careful to keep them apart when using them, lest you confuse yourself.
Emit-messages for closed doors
If doors could logically be locked or blocked in character, a @fail and @ofail.
@fail <- What the person trying to use the locked exit sees
@ofail <- What the people in the room the person was trying to leave see (Always preceeded by the person's name)
@fail Exitname=Message
Example:
@fail Kitchen=You try to push open the swinging door, but Mom rushes out and whacks you with a wooden spoon. "You can't come in here until the food's done!"
@ofail Exitname=Message
Example:
@ofail kitchen=tries to slip into the kitchen, but Mom catches him/her and whacks him/herwith a wooden spoon. "You can't come in until the food's done!"
A better way to @ofail this exit is:
@ofail kitchen=tries to slip into the kitchen, but Mom catches %o and whacks %o with a wooden spoon. "You can't come in until the food's done!"
(%o is short for 'object'…him or her. The MUSH checks the sex of the person trying to use the exit and evaluates %o to the object form(him, her, it). It can also substitute %s for subject (he, she, it)..and so on. More on this in Substitutions.)
