Locks:

Locks are expressions used to control the use of objects. The most common applications are to lock exits so that only some people can use them, and to `lock down' things that you need to leave lying about in rooms (a sign or bulletin board, for example). Just what constitutes `use' depends on the object type. To `use' a thing means to pick it up. To `use' an exit means to pass through it to another room, or to use it as a command. To `use' a room means to look at it.

If an object is locked it may be used if and only if the lock expression is `true' for the player (or other object type) attempting to use the object. `True' in this context and in rather nontechnical terms means `if the triggering player/object is or has or is owned by a result of the lock expression'.

A simple example...

====================================
> @lock closet = me
  Locked.
> ex out = _/
  lok /_/lok:Kenya(#75PBJM1)
====================================


A lock expression is stored as data type `lock' (see also Section 2.1.3), as indicated indicated by the prefix lok, and meaning that the server will evaluate the expression for `truth' in reference to the triggering player (or other triggering object type). The lock in this example evaluates to `database object #75'. If the player or other object trying to use the exit `is' #75 (that is, if it is Kenya), then the lock `passes': Kenya will be able to use the exit. Further, if the the triggering player/object `has' Kenya, the lock would pass: if Kenya were inside a vehicle object, the vehicle would be able to use the exit. And, if the triggering object `is owned by' Kenya, the lock would pass... for example, a puppet owned by Kenya would be able to use the exit. And (this is the whole point of locks) only these objects would be able to use the exit.

Property values as well as dbrefs can serve as lock expressions. The syntax for locking an object to a property value is @lock <object> = <property> : <value>

Only females can use this exit:
====================================
> @lock Powder Room = sex:female
  Locked.
> ex out = _/
  lok /_/lok:sex:female
====================================


If the triggering player/object `has' the property value `female' in her `sex' property, the lock passes: in other words, only females can use this exit. (When the system parameter lock_envcheck is tuned to `yes', the server searches rooms in the environment tree path for property matches on locks, as well as the triggering player/object. In this case, if room #0 were set sex:female, the lock in the above example would always pass.)

Wildcard characters (see Section 2.1.6) may be used in locks for property values.

This exit may be used by males and females, but not fluffs... lyve wyth yt.
====================================
> @lock Normal Folks Bar and Grill = sex:*ale
  Locked.
====================================


Lock expressions may contain or evaluate to multiple elements. The elements must be separated by an `or' operator (a | vertical bar) or by an `and' operator (an & ampersand), and may optionally be preceded by a `not' operator (an ! exclamation point). Player names may be used, provided that they are preceded by an * asterix pointer.

This exit may be used by either of two players, Passiflora or Kenya...
====================================
> @lock Den of Iniquity = *passiflora|*kenya
  Locked.
====================================


This exit may only be used by female staff members...
====================================
> @lock Wizards' GunPowder Room = ~staff:yes&sex:female
  Locked.
====================================


This exit may be used by anyone (or anything) who is not Stinker...
====================================
> @lock Jessy's House = !*stinker
  Locked.
====================================


This exit may only be used by someone who is Jessy and who is not Jessy. In other words, this lock alway fails...
====================================
> @lock chair = *jessy&!*jessy
  Locked.
====================================


The operators have the following order of precedence:

1. ! not
2. | or
3. & and

The order of precedence can be over-ridden by enclosing sub-expressions within (parentheses).

This exit may be used by all females and all others who are not Stinker...
====================================
> @lock bar = !*stinker|sex:female
  Locked.
====================================


This exit may be used by all who are not female and not Stinker...
====================================
> @lock bar = !(*stinker|sex:female)
  Locked.
====================================


An object can be locked to a MUF program, in which case the program runs when someone uses or attempts to use the object, and the lock passes if the program returns a true MUF value (that is, MUF's truth conditions over-ride the truth conditions for locks). In MUF, a "" null string, the integer 0, the floating point value 0.00000, and the dbref for `nothing', #-1, are false. If the MUF program returns any of these values, the lock fails; if it returns any other value, the lock passes.

A lock cannot include MPI (or rather, will invariably fail if set to an MPI string), but an object can be locked to a property value, and the property value on a relevant object can be set to an MPI string.

This exit may only be used on the stroke of midnight (or by someone who has figured out the lock and set his `time' property to 00:00:00)...
====================================
> @lock time machine = time:00:00:00
  Locked.
> @set time machine = time:{time}
  Property set.
====================================


Locks may be removed with the @unlock command, syntax @unlock <object>'