MOO-cows Mailing List Archive


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 

Commands could be:

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

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 

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.


> > 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:
PEI Programming - Stone Mountain, Georgia                CIS: 76614,2161
  "The comments contained within ARE those of my employer...myself!"

Home | Subject Index | Thread Index