On Thu, 7 Jun 2001, Torgny 'Artovil' Bjers wrote:
> Hey, this is a very good idea. Think I will try to do that, are you
> willing to hint a little at how you did it, as far as the process of
> character creation, what happens when, and how they get to input the
> unlock code?
It's fairly trivial if you have a system that you can interface with in
meaningful ways (oh, the power of the CLI and UNIX). The general idea
would probably be something akin to
1) Player creates new character, enters an e-mail address.
2) The e-mail address is checked against a bad e-mail address list
(so that someone can't use your Mud to spam the same person
repeatedly -- see the xnames code for the basic implementation).
If it fails, report that they can't send to that address, maybe
log a message so you know when people are trying to use your Mud
for that and where they're logged in from, and give them an
opportunity to try a better e-mail address.
3) Send an e-mail. How you do this is up to you. You can use an
SMTP library to construct the e-mail directly or open a pipe to
the sendmail program and write your e-mail through there or use
a system() call. The e-mail should include the activation code,
which you can make a random sequence of characters. It should
also include some header to inform people what to do if they
didn't request the e-mail and don't want any further messages
from your Mud. This should be common courtesy for all servers
that automatically send e-mail. Unfortunately, it's not.
4) Tell them the activation code has been sent, flag the character
in some way as inactive, and disconnect them / log them in as an
unregistered/restricted player / whatever.
5) When someone tries logging in an unregistered player, they're
asked for the activation code, if they input the right one, they
can use their character from now on.
I would probably not ask for the Password of the new character when they
first create and use that for the randomly generated activation code.
Then when they logged in with the code, you ask them to issue a new
password. I've done something very similar to this before, myself. The
only difference is that instead of recognizing that they were a newbie and
needed to change their password because it was assigned by the system, I
had a means for "expiring a password" -- you had to change your password
after a specified number of days -- this was set to zero when they were
created, so that on first login they were informed their password had
expired and that they need to change it. Much like UNIX login systems
work, in fact.
--
Daniel A. Koepke (dak), dkoepke@circlemud.org
Caveat emptor: I say what I mean and mean what I say. Listen well.
Caveat venditor: Say what you mean, mean what you say. Say it well.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST