# @dig (restriction)

Rich Connamacher (phantom@baymoo.sfsu.edu)
Tue, 23 Apr 1996 03:40:53 PDT

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

    On Mon, 22 Apr 1996, Isildur wrote:

    > Id like to thanks many people here helping me on all of this.
    > People on my moo wants to have "sure" homes, so nobody can dig exits to t=
    hem.
    > But @dig allow to dig exits from your rooms to anybody else one.
    > I mean, if a builder digs a room with an exit to any other one room (othe=
    r=20
    > player=EAs room) both, exit and entry are not "activated" on others room,=
     but his=20
    > exit works, so he can go to others rooms this way.
    > This sholud be done by the other player using @add-entry, isnt ?
    > If you list legal exits and entries in other=EAs  room you get nothing, b=
    ut it woks.
    > Should I edit go, moveto, add-exit or what? in $room? in $exit?
    > Many thanks again to all.

    If you want people to only be able to come in via a valid exit, try=20
    sticking in the room's :accept verb somewhere,

    if (!(caller IN this.entrances))
      return 0;
    else
    [blab]

    .  That way, going through a non-valid exit into that room would have the=
    =20
    same effect as @move me to #<that room>: it won't work.  (I haven't=20
    tested this, but it should work, since the exit calls the move(), it=20
    should be what 'caller' is set to.)

    This just brought up a question... what is 'caller' set to in the case=20
    where a bf_move() wrapper is programmed and that wrapper itself calls the=
    =20
    accept verb?  the exit that called move() or #0?  (I know i know this is a=
    =20
    dumb example but that's the general idea).  PhantomMOO's not up, so I=20
    can't run the ten second test code to find out.

    Phantom