
----------------------------------------------------------------------------
Further Development
----------------------------------------------------------------------------

For those who wish to develop this service further I provide
a few details here so that the minimum requirements are met
to enable a command and make it usable.

For the most part you simply drop a perl file into one of the
command directories and tell operserv to rehash.  It's done.
But if want to use the command there are a few things you
may wish to know.

Some of the data/hash structure can be found in hash.txt
but it's probably not complete.  A better way to see how
things are setup is to register a few channels, change and/or
add all the features, set all the ranks, add opers and a few
users/bots/clones then dump all the data hashes which include
nicks, chans, rnicks, rchans and opers.  You might want to see
what's in temphash as well, we use it for transient data assignment
and restructuring.

- NICKSERV -
For NickServ commands there are no ranks to worry about.  Adding
commands there are easy if you only want to add an additional
element to a registered nickname.  Let's say, for instance, that
you wanted to add a birthday as an option or maybe age. The basic
requirements for adding a hash element are this...

_ PSEUDO CODE _

- Did they type enough parameters?
if not enough parameters
	show an example of correct usage
	explain how to get help
	return

- if the command requires that their nick is registered
- then the registered nick that they spoke from is
- already held in $keynick in lowercase, to match the key.
if(!$rnicks{$keynick})
	tell them that their nick isn't registered.
	tell them how to register.
	tell them how to get more help.
	return

- if we got this far then things must be ok, unless you want
- to check the type of data contained inside the parameters
- you can just go ahead and set it.

split up the parms into appropriate variables, like $mydob,
all the parms are contained in $parms

$rnicks{$keynick}{dob}{item} = $mydob;
$rnicks{$keynick}{dob}{hide} = "no";

# don't forget to include this option in the
# HIDE and SHOW commands, if you want to allow
# this feature on this setting.

_END_

- CHANSERV -
- If you wanted to add a command to chanserv then you'll need to make
- sure it auto creates the hash element if it doesn't exist. All other
- commands that change rank and usage features will automaticaly
- discover it's existance after that.  Let's say you wanted to add
- an MOTD (Message Of The Day) to the channel services for channel
- owners to use.

- parse the parameters, count, make sure there's enough
if not enough parms
	explain usage
	explain how to get more help
	return;

-split up the $parms into appropriate $variables, try to use $keychan
-for the channel.

my($chan, $message) = split /\s+/, $parms, 2;
my($keychan);

- lowercase the key
$keychan = &dcase($chan);

- auto generate hash, use this because at the time they registered
- they didn't have this option set for them and so it doesn't have
- a rank key set.

if(!$rchans{$keychan}{motd})
	{
	# only owner and 0 get to have access to new features
	# as a security measure.
	$rchans{$keychan}{motd}{rank} = 0;
	}

- now we run regular testing for this element and rank
- this will run through all their registered nicks and see
- if any have access to this channel, then it will save the 
- one with the best access and see if it's high enough for the
- rank setting.
if(!&isauthchan($rchans{$keychan}{motd}{rank}, $keynick, $keychan))
	{
	they don't have access, tell them
	return
	}

- you're at the end here, they must have access, so
- set whatever you're setting,

$rchans{$keychan}{motd}{item} = $message;

- tell them it succeeded

_END_


Don't forget to add a help command for this feature.
If you're command is called SET MOTD as in
/msg ChanServ SET MOTD #chan some message
then put it in 

$commands/$chancoms/HELP/SET/MOTD

If you have static options like ON/OFF you
may choose to have a sub structure like

./MOTD/ON
./MOTD/OFF

If you do that you'll need a base file for the directory
called DIR.DIR like so

./MOTD/DIR.DIR

The base file get's run if there's NO parameters on the line
that match existing sub commands for that feature.  For instance,
if you only had ./SET/MOTD then MOTD would have to do all the
parsing for sub commands, if there are any options like that.
However, if you make files that are the commands you wish, like
ON or OFF in ./SET/MOTD then THOSE files will be run when the
proper command is parsed.  I don't know if I'm making myself
clear, you need to check the file structure, run some tests
and see how things work.  How about this...make files
./$commands/$chancoms/SET/MOTD <- directory
./$commands/$chancoms/SET/MOTD/DIR.DIR
./$commands/$chancoms/SET/MOTD/ON
./$commands/$chancoms/SET/MOTD/OFF

If you only need ONE command, no optiosn, the MOTD "IS" the
command, instead of being a directory.  If it is as stated
above, howver, then the file DIR.DIR is loaded when the base
command is issued without commands in the parameters, like so.

/msg ChanServ SET MOTD <- runs DIR.DIR or if it's file then runs MOTD
/msg ChanServ SET MOTD ON <- runs MOTD/ON
/msg ChanServ SET MOTD hello there <- there IS no HELLO command so uses it
				as parms to MOTD, runs MOTD













