MOO-cows Mailing List Archive
Date: Mon, 15 Jan 1996 18:58:00 PST
From: PILOSOF AVI <firstname.lastname@example.org>
Posting-date: Tue, 16 Jan 1996 13:58 +1100
> 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,
> can only be owned by one person) rather than controlling access to the
> 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
Yep, although I don't forsee that problem.....yet :)
Subject Index |