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

Re: Conferences

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!"
-----------------------------------------------------------------------------
Home | Subject Index | Thread Index