on-the-fly guest creation

• Date: Fri, 25 Aug 1995 15:02:34 PDT
• From:
  dave@ipac.caltech.edu
• Content-Length: 3993
• Content-Type: text

On the fly creation of guests sounds like an interesting idea and I don't 
want to poo-poo it.  On the contrary, it is a much more OO way to handle
guests, which ought to be different objects when used by different people.

Here's a way to do it (stolen from how we do web connections).  The basic
idea is you want #0:do_login_command to return the object number of a newly
created guest object.  The server will then hook that up to the actual 
network connection behind the scenes.  How the server causes connections to
be made to player objects is documented in the programmer's manual and in 
the installation notes.

1 -- Modify $login:connect so if a guest is connecting it returns the object
     number of a newly created guest object:

          if the connection is as a guest
            create new guest object 
            return objnum of new guest object
          else
           do the usual thing
          endif

     Before modifying this verb @copy $login:connect to $login:connect(old) 
     in case you need to restore it.  Then if you goof you can always log 
     back in using a line like

          connect(old) Me MyPassword

     Its a good idea to keep original copies of important core verbs lying 
     around in case you ever need to go back to them.

2 -- creating the new guest object is easy

          new_guest = create($guest,$hacker);

     when it is created, its initialize verb is run, code that to do any
     special setup you want.  For example, you could assign it a color name
     here (and remove the name from a name depository).

3 -- Now when a connection is made as guest, a new guest object is formed
     and handed to the user.  At the time the hand-off takes place, the
     new guest's confunc verb is run.  Code in there any special stuff you
     want related to connecting.  For example, you may want to maintain a 
     list of currently connected guests.

4 -- When the guest disconnects, its disfunc is run.  Code this to reflect
     any actions you want to take place when a guest disconnects (in our
     example, you would remove it from the currently connected guest list).

5 -- As part of the disfunc (actually it is probably best to fork it off of
     the disfunc) recycle the guest object so you don't get a kazillion 
     defunct guests rotting in $limbo.  When it is recycled, its recycle verb 
     is run.  Code this to do anything dealing with destroying a guest object,
     in this example you would return its name to the name depository.

6 -- For peace of mind, you may want to put some code in $guest:disfunc that
     disallows recycling $guest itself, ie:

          guest disfunc verb code
          if (this != $guest)
            fork(0) 
              recycle(this);
            endfork
          endif

     This is just in case somewiz gets silly and succeeds in logging in as 
     $guest, forgetting that disconnecting will destroy the object.

You may want to think a little bit about object numbers of guests.  If you
do create guests on the fly you can use the recycler to give you old used
object numbers.  In this case, if those objnums are already living as property
values etc in the database, strange results could happen from time to time.
On the other hand, if you use the built-in create to get a new object number,
you will (depending on your guest usage) build up a lot of empty object 
slots and drive max_object() through the roof.  This would, though, be a
cleaner approach and is what is usually done with ordinary users (players).

Hope this helps.  We use this method to handle web connections to our moo,
except instead of making children of $guest, we make children of the new 
player class $web_user (and instead of connect, the verb to login is GET/POST).

On the fly object creation is a nice method for many things, it's too bad to
some extent that many programmers are faced with object or byte quota and
have not turned their attention to the possibilities it enables.

• Re: on-the-fly guest creation
• From: brandon@avon.declab.usu.edu

• Prev: RE: numbers for new players
• Next: on-the-fly Guest creation
• Index: MOO-cows
• Thread: MOO-cows