[Prev][Next][Index][Thread]

# Re: Conferences

- Date: Tue, 16 Jan 1996 08:35:31 PST
- From:
- Reply-To:
- Comments: Authenticated sender is <klk@[165.113.1.22]>
- Content-Transfer-Encoding: 7BIT
- Content-Type: text/plain; charset=US-ASCII
- Organization: PEI Programming
- Priority: normal

    Couldn't you just create a master scheduler object that gives a
    particular person controlling rights on a room or rooms for a given
    period of time?

    The verbs in the conference room check the master scheduler and if
    PLAYER# fits the date and time slot specified (an array), then the
    command is executed...if not, they are apprised of their lack of
    control.

    Commands could be:

    OPEN DOOR (which allows free access into and out of the conference
    room).

    CLOSE DOOR (which prevents the same).

    ONEWAY DOOR (allows exit, but not enter).

    REMOVE <person> (allows the controlling person to evict unwanted
    parties from the conference room during the period).  No blacklisting
    needed, just set the door to CLOSE or ONEWAY and they cannot
    re-enter.

    The same concerns have surfaced in RP MOO's.  A character with access
    to an area should be able to "hold open" a door (exit) to allow
    passage.  Also, BLOCKing a door is a necessity to prevent another
    player from leaving, unless they are strong enought to overpower the
    blocking player.

    Kevin

    >
    > > Not really, since the booking is keyed to the list,
    > > all that is really needed is some way of permitting him to edit the list.
    > > if he is granted a feature object when he is booking the room, the feature
    > > object could have permission, rather than the booker.
    >
    > That's similar to the original idea I had:
    > I thought of having a basket of keys, one for each room. A person who wanted
    > a room would take the key (which would be the only way to use the room's
    > exit), and use it. There were two problems:
    >
    >      a) What if people don't return keys?
    >      b) It only allows ONE person to go thru - not his/her whole party.
    >
    > I like your system, since the key itself will have the permissions.
    >
    > > Thus, it becomes a matter of controling acess to the feature object,
    > (which
    > > can only be owned by one person) rather than controlling access to the
    > room
    > > which can be used by many. As long as the person gives the feature object
    > > to some active player, the room remains open. If the feature object is
    > > relinquished, or all the players sign off, the room is returned to its
    > > original state, and the feature object reverts to storage.
    >
    > This is the complex bit - ensuring that the feature object is not "lost" by
    > being stuck with one player. Would I be correct in saying that in the
    > player's exit function, I'd move the object back to its original spot?
    >
    > Also - what happens when two parties want to book two separate rooms - who
    > uses the object? One for each room?
    >
    > > If you find you are running out of conference rooms, simply have it
    > > automatically revert if the room stays empty of players for an extended
    > > period.
    >
    > Yep, although I don't forsee that problem.....yet :)
    >
    > Avi
    >
    >
    >
    -----------------------------------------------------------------------------
    Kevin L. Kitchens                                   Internet: klk@crl.com
    PEI Programming - Stone Mountain, Georgia                CIS: 76614,2161
    -----------------------------------------------------------------------------
      "The comments contained within ARE those of my employer...myself!"
    -----------------------------------------------------------------------------

- Prev: Re: Conferences
- Next: Corrupted $server_options
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index