MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: @lock

Here are the LambdaCore (Feburary Extration) help texts on Locking.
Please forgive any screwed up formatting, I justified this all in Pine.
(And on a screwy terminal.)

--[snip][snip]--
--- Help on @Lock ---
Syntax:  @lock <object> with <key expression>

Set a lock on <object> to restrict its use.  See 'help locking' for
general information about locking and 'help keys' for the syntax and
semantics of key expressions. 

N.B.  In the case of rooms, you are actually better off setting
room.free_entry to 0 thus preventing teleportation and then @locking the
various entrances.  The problem with @locking the room itself is that this
can make it impossible to drop objects in t he room. 

--- Help on @Unlock ---
Syntax:  @unlock <object>

Clear any lock that might exist on the given object.  See 'help locking'
for general information about locking. 

--- Help on Locking ---
It is frequently useful to restrict the use of
some object.  For example, one might want to keep people from using a
particular exit unless they're carrying a bell, a book, and a candle. 
Alternatively, one might allow anyone to use the exit unless they'r e
carrying that huge golden coffin in the corner.  LambdaMOO supports a
general locking mechanism designed to make such restrictions easy to
implement, usually without any programming. 

Every object supports a notion of being 'locked' with respect to certain
other objects.  For example, the exit above might be locked for any object
that was carrying the coffin object but unlocked for all other objects. 
In general, if some object 'A' is locked for another object, 'B', then 'B'
is usually prevented from using 'A'.  Of course, the meaning of 'use' in
this context depends upon the kind of object. 

The various standard classes of objects use locking as follows:

  + Rooms and containers refuse to allow any object inside them if they're
locked for it. 
  + Exits refuse to transport any object that they're locked for.
  + Things (including notes and letters) cannot be moved to locations
that they're locked for.

There are two sides to locking:
  + How is it specified whether one object is locked for another one?
  + What is the effect of an object being locked?
Note that these two questions are entirely independent: one could invent a
brand-new way to specify locking, but the effect of an exit being locked
would be unchanged. 

[Note to programmers: the interface between these two sides is the verb
x:is_unlocked_for(y), which is called by x to determine if it is locked
for the object y.  The way in which 'is_unlocked_for' is implemented is
entirely independent of the ways in whi ch x uses its results.  Note that
you can play on either side of this interface with your own objects,
either defining new implementations of 'is_unlocked_for' that match your
particular circumstances or having your objects interpret their being
locked in new ways.]

There is a default way to specify locks on objects; the following help
topics cover the relevant commands: 

@lock -- setting a lock on an object
@unlock -- clearing the lock on an object
keys -- describes the language used to describe lock keys

--- Help on Keys --- 
LambdaMOO supports a simple but powerful notation for
specifying locks on objects, encryption on notes, and other applications. 
The idea is to describe a constraint that must be satisfied concerning
what some object must be or contain in order to use som e other object. 

The constraint is given in the form of a logical expression, made up of
object numbers connected with the operators 'and', 'or', and 'not'
(written '&&', '||', and '!', for compatibility with the MOO programming
language).  When writing such expressions, though, one usually does not
use object numbers directly, but rather gives their names, as with most
MOO commands. 

These logical expressions (called 'key expressions') are always evaluated
in the context of some particular 'candidate' object, to see if that
object meets the constraint.  To do so, we consider the candidate object,
along with every object it contains (a nd the ones those objects contain,
and so on), to be 'true' and all other objects to be 'false'. 

As an example, suppose the player Munchkin wanted to lock the exit leading
to his home so that only he and the holder of his magic wand could use it. 
Further, suppose that Munchkin was object #999 and the wand was #1001. 
Munchkin would use the '@lock' c ommand to lock the exit with the
following key expression: 
        me || magic wand
and the system would understand this to mean
        #999 || #1001
That is, players could only use the exit if they were (or were carrying)
either #999 or #1001. 

To encrypt a note so that it could only be read by Munchkin or someone
carrying his book, his bell, and his candle, Munchkin would use the
'encrypt' command with the key expression
        me || (bell && book && candle)

Finally, to keep players from taking a large gold coffin through a
particularly narrow exit, Munchkin would use this key expression: 
        ! coffin
That is, the expression would be false for any object that was or was
carrying the coffin. 

There is one other kind of clause that can appear in a key expression:
        ? <object>
This is evaluated by testing whether the given object is unlocked for the
candidate object; if so, this clause is true, and otherwise, it is false. 
This allows you to have several locks all sharing some single other one;
when the other one is changed, al l of the locks change their behavior
simultaneously. 

[Note to programmers: The internal representation of key expressions, as
stored in .key on every object, for example, is very simple and easy to
construct on the fly.  For details, see 'help key-representation'.]

--- Help on Key-Representation ---
The representation of key expressions is very simple and makes it easy to
construct new keys on the fly. 

Objects are represented by their object numbers and all other kinds of key
expressions are represented by lists.  These lists have as their first
element a string drawn from the following set: 
        "&&"     "||"     "!"     "?"
For the first two of these, the list should be three elements long; the
second and third elements are the representations of the key expressions
on the left- and right-hand sides of the appropriate operator.  In the
third case, "!", the list should be two
 elements long; the second element is again a representation of the operand.  Finally, in the "?" case, the list is also two elements long but the second element must be an object number.

As an example, the key expression
        #45  &&  ?#46  &&  (#47  ||  !#48)
would be represented as follows:
        {"&&", {"&&", #45, {"?", #46}}, {"||", #47, {"!", #48}}}

--- End o' the Help texts. ---

Scott Robinson
-Dan! I can't get my E-Mail too you, if you got a account on Lambda or
RiverMOO, send MOOMail there.-
Home | Subject Index | Thread Index