MOO-cows Mailing List Archive

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

RE: alternative logins



>  I would like to have two different login areas: one for our younger kids
>  that leads them toward a simpler, bilingual area; and another that leads
>  out to the main part of the MOO. I imagine perhaps two kinds of guest
>  login, something like:
>
>  co guest (reg.)
>  co 5thD (kids from the 5th Dimension project).
>
>  After they have chars. they can (or we can) set a default home that is in
>  some common area of the bilingual section of th MOO. Meanwhile...help.
>  anyone? anyone? Bueller?

a (genuinely) small matter of programming.

$login:connect, if the name matches a guest object, calls that object's
:defer verb.  In general, this will either return the object itself or if
this guest object is in use, some other guest object.  You can fix
$guest:defer to do anything you want.

The other observation is that the .home properties on the various guests
are
  (1) never changed
  (2) not required to all be the same

Probably the easiest route is to set .home=5Dhome on some subset of 
your guests,
give one of these guests the alias "5thD", making sure the guest having 
the alias
"Guest" is one of those having the regular .home.

What remains is changing $guest:defer.  You need to do this since if the guest
named "5thD" happens to be in use, it will just pick another, possibly 
non-5D guest
at random.  Thus you just need to fix the loop where it searches
through all of the children of $guest looking for someone to use;
the idea is to skip all of the $guest children whose .home property != 
this.home.
E.g.,

   for g in (children($guest))
     if (!is_player(g))
       "...a toaded guest?..."
     elseif...

becomes

   for g in (children($guest))
     if (!is_player(g))
       "...a toaded guest?..."
     elseif (g.home != this.home)
       "...wrong kind of guest..."
     elseif...

One wart is that this gives you two fixed-size pools of guests (e.g.,
if you run out of 5D guests, your kids can't connect as guests even if there
are ordinary guests available).  One solution is to just make lots of guests
of both kinds; another is to have :defer actually CHANGE the home of an unused
guest and then move it to its new home before returning it.

You'll probably also want to fix $guest:@request to indicate that the request
was from a 5D guest.





Home | Subject Index | Thread Index