|
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:
- ! not
- | or
- & 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>'
prev |
toc |
top |
next
|