# @lock

Scott Robinson (quad@host.scbbs.com)
Mon, 24 Feb 1997 11:46:00 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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.-