MOO-cows Mailing List Archive
on-the-fly guest creation
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
do the usual thing
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)
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.
Subject Index |