How To Add IRCd Support
-----------------------

1) Files to Edit
2) The Code
3) The IRCDVar struct
4) Modes
5) Functions / Events
6) CAPAB/PROTOCTL 
7) IRCDProto Class

1) Files to Edit

    When preparing to add supprt to Anope for your IRCd, you need to edit
    the following files

    A) Make a copy of the .cpp file of the IRCd that matches the IRCd that
       you are attempting to add support for best.
    B) Add your IRCd into the supported IRCds in example.conf

2) The Code

    Here is where the code of the .cpp file comes in. Be prepared to spend at
    least an hour, if not longer, going over the code and getting it right;
    Especially if you are setting up an ircd that is completely different
    than the one you used as a base. This section covers the majority of the
    code that is in use. 

    The first bit of code you will face is the IRCDVar structure, This is one
    of two structs which holds your IRCd information; This allows you to quickly
    setup your specific ircd.

        IRCDVar myIrcd[] = { };

    This struct contains your basic IRCd functions. Your base source file has
    the list of all available variables; note that you should not swap any
    around, or you will break stuff. Here is a brief description of the usage
    of each.

    1) Name: This member tells Anope about the IRCD's name. It may contain
             text about it's name and version. This is used to identify the
             build on startup.

    2) Pseudo Client Mode: This is the user mode set by Anope on all BotServ
                           bots. Normally you want this to be a some form of
                           service or bot flag; you can use + for no mode at
                           all.

    3) Max Channelmode Symbols: This is the total number of possible channel
                                 modes that can appear before a nick. Do
                                 remember to count each possible mode, so +ov
                                 is 2.

    4) SVSNICK: Can the ircd use SVSNICK to change some ones nick? Otherwise,
                 KILL is used. Use 1 for yes, 0 for no.

    5) VHOST: Can a user's host be changed on the fly? Enabling this allow
               HostServ online. Use 1 for yes, 0 for no.

    6) SNLINE: Does the IRCd support realname (geocs) bans? Use 1 for yes,
                0 for no.

    7) SQLINE: Does the IRCd support nick bans? Use 1 for yes, 0 for no.

    8) SZLINE: Does the IRCd support SZLINES? Use 1 for yes, 0 for no.

    10) Join to Message: Services must join a channel to send any message to
                         that channel (cannot override +n). Use 1 for yes,
                         0 for no.

    11) SQline Channels: The IRCd's supports banning channel names via
                         SQLINES. Use 1 for yes, 0 for no.

    12) Quit On Kill: When we (SVS)KILL a user, does the IRCd send back a
                      QUIT message for that user? Use 1 for yes, 0 for no.

    13) SVSMODE UNBAN: We can use SVSMODE to unban hosts from a channel. Use
                    1 for yes, 0 for no.

    14) Reverse: We can do a reverse check when unbanning. For use with 
                 DreamForge based IRCd's. Use 1 for yes, 0 for no.

    15) vIdent: Support for including a user's ident in their vHost. Use
                1 for yes, 0 for no.

    16) SVSHOLD: Support for temporarily 'holding' a nick, instead of using
                 a nick enforcer client. Use 1 for yes, 0 for no.

    17) TS on MODE: We need to send a timestamp when modes are being changed.
                    Use 1 for yes, 0 for no.

    18) Umode: We can use OperServ to change a user's mode. Use 1 for yes,
               0 for no.

    19) OMODE: We can use OperServ to give some user a temporary O:LINE.
               Use 1 for yes, 0 for no.

    20) No Knock Requires +i: Does the No Knock channel mode require invite
                              only channels? Use 1 for yes, 0 for no.
    
    21) SVSMODE UCMODE: Can we clear user channel modes with SVSMODE? Use
                        1 for yes, 0 for no.

    22) SGline Enforce: Does the IRCd enforce SNLINES for us or do we need to
                        do so? Use 1 for yes, 0 for no.

    23) TS6: Does the IRCd support TS6? Use 1 for yes, 0 for no.

    24) Global TLD Prefix: Prefix used to send global messages, should probably
                           be "$"

    25) Max Modes: The max number of mode changes we can send in one line

3) Modes 

   Anope is told about modes in the protocol module.
   For the most part, the syntax for adding channel and user modes are:
   
   ModeManager::AddUserMode(new UserMode(UMODE_NETADMIN, "UMODE_NETADMIN", 'N'));
   Where 'N' is the char for the mode, and UMODE_NETADMIN shows what the
   mode does. Or:

   ModeManager::AddChannelMode(new ChannelMode(CMODE_BLOCKCOLOR, "CMODE_BLOCKCOLOR", 'c'));
   Where 'c' is the char for the mode and CMODE_BLOCKCOLOR shows what
   the mode does

   A full list of valid mode names for the second param can be found
   in services.h in the enum for ChannelModeName and UserModeName
   If necessary, you can add additional modes to this list.

   Adding simple modes with parameters is similar, instead adding a
   'new ChannelMode', use 'new ChannelModeParam', set the third optional
   arg of ChannelModeParam to false if the param should NOT be sent when unsetting
   it. Eg:

   ModeManager::AddChannelMode(new ChannelModeParam(CMODE_JOINFLOOD, "CMODE_JOINFLOOD", 'j', true));

   Anope will internally track the params, and they can be retrieved through
   Channel::GetParam();

   If you want to make param validity checking for a mode, you must create a new
   class which inherits from ChannelModeParam and overload the IsValid function.
   Modes CMODE_OPERONLY, CMODE_ADMINONLY, and CMODE_REGISTERED already exist
   internally as classes, to overload the CanSet function to disable non opers
   from mlocking (or in CMODE_REGISTERED's case, anyone) from setting them.
   This should be added like:

   ModeManager::AddChannelMode(new ChannelModeOper('O'));

4) Functions and Events

    A brief word about functions and events. All events are captured by creating a Message struct
    with the name of the message and the callback function:

    Message my_message("MESSAGE", do_my_messsage);

    Each message should have a message handler if its important enough to be
    processed by services. All event functions should be formed like this:

	bool do_my_message(const Anope::string &source, const std::vector<Anope::string> &params)
        {
		return true;
        }

    They will receive the source; this can be empty at times depending on the
    event. Next, params holds the arguments for the event. Events are likely to
    pass to various upper level event handlers; see the previous ircd source for
    how they handle these events.

5) CAPAB/PROTOCTL

    Most IRCDs send a CAPAB or PROTOCTL line so that they can work out what
    the other end of the connection is capable of doing. The protocol module should
    handle all of these without the cores knowledge with the exception of the following:
    
       --------------------------------------------------------------------------
       Define          |  Description
       ----------------|---------------------------------------------------------
       CAPAB_NOQUIT    |  NOQUIT protocol support
       CAPAB_TSMODE    |  Chanmodes are timestamped
       CAPAB_UNCONNECT |  UNCONNECT protocol support
       CAPAB_QS        |  Quitstorm - same as NOQUIT

   You can override the default OnCapab method in IRCdMessage if required.

6) IRCDProto Class

    The IRCDProto class is set up like:

    class MyIRCdProto : public IRCDProto { } ircdproto;

    And told to Anope through the

    pmodule_ircd_proto(&ircd_proto);

    function.

    This is used for sending out specific messages from Anope to your IRCd.
    A list of all of the valid function names to overload and their args
    are in services.h. If the protocol module you are editing is similar enough
    to the IRCd you are adding support for, many of these probably won't need to
    be changed.
