Anope Stable Branch

git-svn-id: http://anope.svn.sourceforge.net/svnroot/anope/stable@1902 5417fbe8-f217-4b02-8779-1006273d7864

1 files changed, 601 insertions, 0 deletions

diff --git a/docs/IRCD b/docs/IRCD
new file mode 100644
index 000000000..c99f2558a
--- /dev/null
+++ b/docs/IRCD
@@ -0,0 +1,601 @@
+How To Add IRCd Support
+-----------------------
+
+1) Files to Edit
+2) Modifing the Header File
+3) The Code
+4) Modes
+5) Functions / Events
+6) CAPAB/PROTOCTL 
+
+1) Files to Edit
+
+    When preparing to add support to Anope for your ircd, you need to edit
+    the following files. 
+
+    A) Make a copy of the .c and .h file of the IRCd that matches the ircd
+       that you are attempting to add support for best.
+    B) Make a backup copy of include/services.h, include/sysconf.h.in
+    C) Make a backup copy of Config and configure.in
+
+    First step in this process is to rename the .c and .h file after the IRCd
+    that you are going to be adding support for. Its recommended that you come
+    up with a name that is clear and easy to understand.
+
+    Now that you have the files that you will need to create your own ircd
+    support, starting with Config. This file is a shell script file; scroll
+    down until you find the list of ircs for the user to select. Indicate
+    the based ircd version which is supported such as a series 1.x or 2.2.x,
+    placing in the comment side an exact version that the support is for or
+    "experimental" if you are not the ircd developer. The next step is to
+    decide how the IRCd will be defined, following the existing examples edit
+    'IRCTYPE_DEF="IRC_RATBOX"' to be the descriptive define for your ircd. 
+
+    With the Config file ready to go, edit configure.in and find in there the
+    reference to --with-ircd. You should see the various other ircds, and
+    you will want to add yours in there using the same IRC_ name you came up
+    with above. Important in this step is to make sure that you set the
+    IRCDFILE to the name of the .c file you set in step 1. Once you have the
+    configure.in created you can remove the old configure and at the command
+    prompt type "autconf"; this will generate the new configure file.
+
+    Getting close to actually modify code. Open sysconf.h.in and add two
+    lines for your given ircd, which is similar to this:
+
+        /* "First IRCD type" */
+        #undef IRC_RATBOX
+
+    Open services.h and add a line with the rest of the ircd include files to
+    match the name of the .h file you set in step 1. 
+
+        #include "ratbox.h"
+
+    Taking the .c and .h file open them and replace the #ifdef IRC_* with the
+    IRC_ name you set in step two. Ensure that the code comments at the top
+    of the file match the ircd that the code will be for.
+
+    You are now ready to start getting into the code.
+
+2) Modifying the Header File
+
+    Now that you have gotten past the first part of the creation process, you
+    are into the code. This part is the harder and more complex part. You
+    will need a general understanding of C code to continue. Here are the
+    step by step instructions required to make this work.
+
+    Open the .h file and find the section of code with
+
+        #define PROTECT_SET_MODE "+"
+        #define PROTECT_UNSET_MODE "-"
+        #define CS_CMD_PROTECT "PROTECT"
+        #define CS_CMD_DEPROTECT "DEPROTECT"
+        #define FANT_PROTECT_ADD "!protect"
+        #define FANT_PROTECT_DEL "!deprotect"
+        #define LEVEL_PROTECT_WORD "AUTOPROTECT"
+        #define LEVELINFO_PROTECT_WORD "PROTECT"
+        #define LEVELINFO_PROTECTME_WORD "PROTECTME"
+
+    If the ircd supports a protective/admin (not owner) mode, set the
+    PROTECT_SET_MODE and PROTECT_UNSET_MODE to be that mode. On most ircds
+    it's usermode "a" so you will be setting it to "+a" and "-a". The next
+    two are based more on what this mode is called. When you message ChanServ
+    to get this mode, this is the command you will be using. After this are
+    the fantasy commands which can be used in channel to get these modes. The
+    next three relate to the ACCESS LEVEL list system. Again these are the
+    words to gain these levels in the ACCESS LEVEL system. If your ircd does
+    not have these functions, leave them at what ever value is currently set;
+    the core code will ignore the request of the user.
+
+    Now that this is set, you can define the MODES. All user modes are stored
+    with UMODE_ followed by a letter matching the modes case; be careful to
+    use the correct case as this will make it clear when you setup MODES in
+    the .c in a few. Use hex values for the modes so starting at 0x00000001
+    to 0x8000000. In most cases you want to list all modes. If you run out of
+    values look at removing any modes that do not impact services.
+
+    Channel modes are done much like user modes, with the exception that
+    bans, exceptions, invites, and modes that are applied to a user such as
+    op and voice are not defined here. All other modes are defined in here.
+    Again be clear and use the correct case and use hex values as done with
+    user modes.
+
+    Finally we come to DEFAULT_MLOCK; this is the mode that services will set
+    by default on channels when they are registered. In general you want this
+    to be what is acceptable by the ircd; in most cases this is "+nt"
+
+3) The Code
+
+    Here is where the code of the .c 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:
+
+        const char version_protocol[] = "Ratbox IRCD";
+
+    This the protocol name which will appear in various places; especially
+    when you do -version at the command prompt, this is where you state the
+    server name. The version is not always needed unless you are showing that
+    the support is for one branch of a ircd family, such as Unreal 3.1 and
+    Unreal 3.2.
+
+    Once you have decided on this little piece of code, you will come to
+    flood mode characters being used for setting and removing. If your IRCd
+    does not support flood modes, you can just use ""; we will be setting if
+    your IRCD supports flooding or not in a little bit.
+
+        const char flood_mode_char_set[] = "+f";
+        const char flood_mode_char_remove[] = "-f";
+
+    The next task that you will face is setting whether the IRCD sends time
+    stamps on modes but does not tell us that it will do so. If it does, set
+    UseTSMODE to 1; if it does not set it to be 0. If you're not sure refer
+    to your IRCd's documentation on how MODE is sent.
+
+        int UseTSMODE = 0;
+
+    Now you've come to the part where you setup your ircd. There are two
+    structs which hold this information; This allows you to quickly setup
+    your specific ircd.
+
+        IRCDVar ircd[] = { }
+
+    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) NickServ Mode: This is the user mode set by Anope on NickServ.
+                      Normally you want this to be some form of oper flag,
+                      or a services flag. 
+
+    3) ChanServ Mode: This is the user mode set by Anope on ChanServ.
+                      Normally you want this to be some form of oper flag,
+                      or a services flag. 
+
+    4) MemoServ Mode: This is the user mode set by Anope on MemoServ.
+                      Normally you want this to be some form of oper flag,
+                      or a services flag. 
+
+    5) HostServ Mode: This is the user mode set by Anope on HostServ.
+                      Normally you want this to be some form of oper flag,
+                      or a services flag. Note that if your ircd does not
+                      support HostServ, you can safely make this NULL or +,
+                      as there is a check before bringing HostServ online.
+
+    6) OperServ Mode: This is the user mode set by Anope on OperServ.
+                      Normally you want this to be some form of oper flag,
+                      or a services flag. 
+
+    7) BotServ Mode: This is the user mode set by Anope on BotServ.
+                     Normally you want this to be some form of oper flag,
+                     or a services flag. 
+
+    8) HelpServ Mode: This is the user mode set by Anope on HelpServ.
+                      Normally you want this to be some form of oper flag,
+                      or a services flag. 
+
+    9) DevNull Mode: This is the user mode set by Anope on DevNull.
+                     Normally you want this to be some form of oper flag,
+                     or a services flag.
+
+    10) Global Mode: This is the user mode set by Anope on Global.
+                     Normally you want this to be some form of oper flag,
+                     or a services flag. 
+
+    11) NickServ Alias Mode: This is the user mode set by Anope on the alias
+                             of NickServ. Normally you want this to be some
+                             form of oper flag, or a services flag. 
+
+    12) ChanServ Alias Mode: This is the user mode set by Anope on the alias
+                             of ChanServ. Normally you want this to be some
+                             form of oper flag, or a services flag. 
+
+    13) MemoServ Alias Mode: This is the user mode set by Anope on the alias
+                             of MemoServ. Normally you want this to be some
+                             form of oper flag, or a services flag. 
+
+    14) HostServ Alias Mode: This is the user mode set by Anope on the alias
+                             of MemoServ. Normally you want this to be some
+                             form of oper flag, or a services flag. Note that
+                             if your ircd does not support HostServ, you can
+                             safely make this NULL or +, as there is a check
+                             before bringing HostServ online.
+
+    15) OperServ Alias Mode: This is the user mode set by Anope on the alias
+                             of OperServ. Normally you want this to be some
+                             form of oper flag, or a services flag. 
+
+    16) BotServ Alias Mode: This is the user mode set by Anope on the alias
+                            of BotServ. Normally you want this to be some
+                            form of oper flag, or a services flag. 
+
+    17) HelpServ Alias Mode: This is the user mode set by Anope on the alias
+                             of HelpServ. Normally you want this to be some
+                             form of oper flag, or a services flag. 
+
+    18) DevNull Alias Mode: This is the user mode set by Anope on the alias
+                            of DevNull. Normally you want this to be some
+                            form of oper flag, or a services flag. 
+
+    19) Global Alias Mode: This is the user mode set by Anope on the alias
+                           of Global. Normally you want this to be some form
+                           of oper flag, or a services flag. 
+
+    20) BotServ Bots 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.
+
+    21) 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.
+
+    22) Modes to Remove: This is every mode that Anope should remove when
+                         stripping channel modes.
+
+    23) Channelmode for bots: When a BotServ bot joins a channel, this is the
+                              mode set on them. Normally you will want them
+                              opped (+o), and protected (+a) on IRCd's that
+                              support it.
+
+    24) SVSNICK: Can the ircd use SVSNICK to change some ones nick? Otherwise,
+                 KILL is used. Use 1 for yes, 0 for no.
+
+    25) VHOST: Can a user's host be changed on the fly? Enabling this allow
+               HostServ online. Use 1 for yes, 0 for no.
+
+    26) OWNER: Has a channel umode for being the channel owner. For example,
+               UnrealIRCd has mode +q. Use 1 for yes, 0 for no.
+
+    27) OWNER MODE SET: What mode to set to make someone the owner. If the
+                        IRCd doesn't support owners, set this to NULL.
+
+    28) OWNER MODE UNSET: What mode to unset to take away someone's channel
+                          owner status. If the IRCd doesn't support owners,
+                          set this to NULL.
+
+    29) ADMIN MODE SET: What mode to set to make someone a channel admin.
+                        If the IRCd dosn't support admins, set to NULL.
+
+    30) ADMIN MODE UNSET: What mode to unset to take away channel admin.
+                          If the IRCd dosn't support admins, set to NULL.
+
+    31) Mode on Nick Register: What mode to give users when they register
+                               with NickServ. If your ircd doesn't set expect
+                               a mode to be set on registration, you should
+                               set this to NULL.
+
+    32) Mode on Nick Unregister: What mode to set give users when they cancel
+                                 their registration with NickServ. If your
+                                 IRCd doesn't set a mode for registered users
+                                 you should set this to NULL.
+
+    33) Mode on Nick Change: What mode to give users when they change their
+                             nick. If your ircd doesn't set a mode, you
+                             should set this to NULL.
+
+    34) SGLINE: Does the IRCd support realname (geocs) bans? Use 1 for yes,
+                0 for no.
+
+    35) SQLINE: Does the IRCd support nick bans? Use 1 for yes, 0 for no.
+
+    36) SZLINE: Does the IRCd support SZLINES? Use 1 for yes, 0 for no.
+
+    37) HALFOP: Is channel mode +h for halfop supported by the IRCd? Use 1 for
+                yes, 0 for no.
+
+    38) Number of Server Args: When an IRCd connects, this is the number of
+                               parameters that are passed.
+
+    39) Join to Set: Services must join a channel to set any modes on that
+                     channel. Use 1 for yes, 0 for no.
+
+    40) 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.
+
+    41) Exceptions: Support for channel exceptions (mode +e). Use 1 for yes,
+                    0 for no.
+
+    42) TS Topic Forward: Some IRCd's (like UnrealIRCd) like their topic TS
+                          set forward by +1. Use 1 for yes, 0 for no.
+
+    43) TS Topic Backward: Some IRCd's (mainly older DreamForge-like ones)
+                           like their topic TS set back by -1. Use 1 for yes,
+                           0 for no.
+
+    44) Protected Umode: UMODE_ define that defines the protected usermod.
+                         Use 0 for no support, or enter the UMODE_ define.
+
+    45) Admin: Support for channel admins (Mainly used by UltimateIRCd). Use
+               1 for yes, 0 for no.
+
+    46) SQline Channels: The IRCd's supports banning channel names via
+                         SQLINES. Use 1 for yes, 0 for no.
+
+    47) 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.
+
+    48) SVSMODE -b: We can use SVSMODE to unban hosts from a channel. Use
+                    1 for yes, 0 for no.
+
+    49) Protect: Support for channel protect (mode +a, mainly being used by
+                 UnrealIRCd and ViagraIRCd). Use 1 for yes, 0 for no.
+
+    50) Reverse: We can do a reverse check when unbanning. For use with 
+                 DreamForge based IRCd's. Use 1 for yes, 0 for no.
+
+    51) Register Channels: Supports sending a channelmode for registered
+                           channels. Use 1 for yes, 0 for no.
+
+    52) Registered Mode: Channelmode to set on registered channels, see the
+                         option above. Use 1 for yes, 0 for no.
+
+    53) vIdent: Support for including a user's ident in their vHost. Use
+                1 for yes, 0 for no.
+
+    54) SVSHOLD: Support for temporarily 'holding' a nick, instead of using
+                 a nick enforcer client. Use 1 for yes, 0 for no.
+
+    55) TS on MODE: We need to send a timestamp when modes are being changed.
+                    Use 1 for yes, 0 for no.
+
+    56) NICKIP: The IP address of new users is being sent along with their
+                hostname when new users are being introduced on the network.
+                Use 1 for yes, 0 for no.
+
+    57) Umode: We can use OperServ to change a user's mode. Use 1 for yes,
+               0 for no.
+
+    58) O:LINE: We can use OperServ to give some user a temporary O:LINE.
+                Use 1 for yes, 0 for no.
+
+    59) Vhost On Nick: On NICK the IRCd sends the VHOST. Use 1 for yes,
+                       0 for no.
+
+    60) Change Realname: Change real name. Use 1 for yes, 0 for no.
+
+    61) Extra Help: If the IRCd has more help for functions in ChanServ than
+                    the default help, you should put the language string
+                    identifier here. Use 0 for no extra help.
+
+    62) No Knock: CMODE_ that defines NO KNOCK. Use 0 for no support.
+
+    63) Admin Only: CMODE_ that defines Admin Only. Use 0 for no support.
+
+    64) Default MLock: Default channelmodes for MLOCK. Use 0 for no modes.
+
+    65) Vhost Umode: UMODE_ that indicates if the user currently has a vHost.
+                     Use 0 for no support.
+
+    66) Flood Mode: The IRCd has a channelmode for blocking floods. Use 1 for
+                    yes, 0 for no.
+
+    67) Link Mode: The IRCd has a channelmode for linking a channel to some
+                   other channel. Use 1 for yes, 0 for no.
+
+    68) CMode F: CMODE_ that defines flood mode. Use 0 for no support.
+
+    69) CMode L: CMODE_ that defines link mode. Use 0 for no support.
+
+    70) Check Nick ID: Should we check if a user should remain identified when
+                       changing their nick? This is for IRCd's that remove
+                       their registered-user mode when someone changes their
+                       nick (like Bahamut does).
+                       Use 1 for yes, 0 for no.
+
+    71) No Knock Requires +i: Does the No Knock channel mode require invite
+                              only channels? Use 1 for yes, 0 for no.
+
+    72) Chan Modes: If sent in CAPAB/PROTOCOL, we store it in here. This is
+                    NULL by default.
+
+    73) Tokens: Can we use tokens to talk to the IRCd? Use 1 for yes,
+                0 for no.
+
+    74) Token Case Senstive: Are the IRCd's TOKENS/COMMANDS case sensitive?
+                             Use 1 for yes, 0 for no.
+
+    75) base64 SJOIN TS: Are the timestamps sent with a SJOIN in base64? Use
+                         1 for yes, 0 for no.
+
+    76) Supports +I: Does the IRCd support channelmode +I? Use 1 for yes,
+                     0 for no.
+
+    77) SJOIN Ban Char: Character used to identify bans. Use ''.
+
+    78) SJOIN Except Char: Character used to identify exceptions. use ''.
+
+    79) SVSMODE UCMODE: Can we clear user channel modes with SVSMODE? Use
+                        1 for yes, 0 for no.
+
+    80) SGline Enforce: Does the IRCd enforce SGLINES for us or do we need to
+                        do so? Use 1 for yes, 0 for no.
+
+    81) Vhost Character: The character used to represent the vHost mode, if
+                         this is supported by the IRCd.
+
+    82) TS6: Does the IRCd support TS6? Use 1 for yes, 0 for no.
+
+    83) UMode +h: Does the IRCd support usermode +h for helpers?
+                  Use 1 for yes, 0 for no.
+
+    84) P10: Is this IRCd a P10-style IRCd? Use 1 for yes, 0 for no.
+
+    85) Character Set: Unreal passes the character set during PROTOCTL,
+                       the value is stored here. Set this NULL to start.
+
+    86) Reports sync: Does the IRCd report when it's in sync (or done bursting,
+                      depending on how you want to say it)? Remember to set
+                      the sync state for servers correctly if it does.
+                      Use 1 for yes, 0 for no.
+
+    87) Channel CIDR: Set to 1 if channel bans, excepts and invites
+                      support CIDR masks. Expected syntax: *!*@ip/mask.
+                      When set to 1, anope will only parse strict CIDR masks.
+                      IRCd's that try to correct invalid CIDR's (like nefarious)
+                      will need a custom implementation in the core.
+                      Contact the anope Dev Team if this is the case.
+                      Set to 0 if CIDR's are not supported by your IRCd.
+
+    So we've had this long list. Now there's a second struct to fill. This
+    struct isn't as long as the previous one though, so we'll handle it quite
+    quick compared to the previous one.
+
+        IRCDCAPAB ircdcap[] = { }
+
+    This struct is based on the CAPAB defines. You should review the CAPAB
+    table below to see how this should be done.
+
+        Define Table
+    --------------------------------------------------------------------------
+    Define          | Value      | Token     | Description
+    ----------------|------------|-----------|--------------------------------
+    CAPAB_NOQUIT    | 0x00000001 | NOQUIT    | NOQUIT protocol support
+    CAPAB_TSMODE    | 0x00000002 | TS        | Chanmodes are timestamped
+    CAPAB_UNCONNECT | 0x00000004 | UNCONNECT | UNCONNECT protocol support
+    CAPAB_NICKIP    | 0x00000008 | NICKIP    | IP sent in the NICK line
+    CAPAB_NSJOIN    | 0x00000010 | SSJOIN    | Smart SJOIN support
+    CAPAB_ZIP       | 0x00000020 | ZIP       | Support for gzipped links
+    CAPAB_BURST     | 0x00000040 | BURST     | Supports BURST command
+    CAPAB_TS3       | 0x00000080 | TS3       | Support for TS3 protocol
+    CAPAB_TS5       | 0x00000100 | TS5       | Support for TS5 protocol
+    CAPAB_DKEY      | 0x00000200 | DKEY      | DH-Key exchange using DKEY
+    CAPAB_DOZIP     | 0x00000400 | ZIP       | Link traffic will be gzipped
+    CAPAB_DODKEY    | 0x00000800 | DKEY      | Do DKEY with this link
+    CAPAB_QS        | 0x00001000 | QS        | Supports quit storm removal
+    CAPAB_SCS       | 0x00002000 | SCS       | String Cache System support
+    CAPAB_PT4       | 0x00004000 | PT4       | Support for PT4 protocol
+    CAPAB_UID       | 0x00008000 | UID       | Support for UIDs
+    CAPAB_KNOCK     | 0x00010000 | KNOCK     | Supports KNOCK
+    CAPAB_CLIENT    | 0x00020000 | CLIENT    | Supports CLIENT
+    CAPAB_IPV6      | 0x00040000 | IPV6      | Support for IPv6 addresses
+    CAPAB_SSJ5      | 0x00080000 | SSJ5      | Smart Join protocol 5 support
+    CAPAB_SN2       | 0x00100000 | SN2       | Support for SN2 protocol
+    CAPAB_VHOST     | 0x00200000 | VHOST     | Supports VHOST protocol
+    CAPAB_TOKEN     | 0x00400000 | TOKEN     | Supports s2s tokens
+    CAPAB_SSJ3      | 0x00800000 | SSJ3      | Smart Join protocol 3 support
+    CAPAB_NICK2     | 0x01000000 | NICK2     | Support for extended NICK (v2)
+    CAPAB_UMODE2    | 0x02000000 | UMODE2    | Supports UMODE2 command
+    CAPAB_VL        | 0x04000000 | VL        | VLine information in info field
+    CAPAB_TLKEXT    | 0x08000000 | TLKEXT    | Not 8, but 10 params in TKL's
+    CAPAB_CHANMODE  | 0x10000000 | CHANMODE  | Channel modes are passed here
+    CAPAB_SJB64     | 0x20000000 | SJB64     | SJOIN timestamps are base64 encoded
+    CAPAB_NICKCHARS | 0x40000000 | NICKCHARS | Character set used by the IRCD for nicks
+
+
+4) Modes 
+
+    The next thing you should do is defining the user modes. You will want to
+    have your .h file handy for this part.
+
+        unsigned long umodes[128] = { }
+
+    This array goes from 0 to 127 in the ASCII character set. Insert the user
+    modes at the slot where the mode fits. If you are adding a the user mode
+    of +i find the 105th (ASCII code of 'i') character slot in the array, and
+    place the UMODE_i into this slot. Your base .c file should contain a good
+    start for this, as well as a little help locating the characters.
+
+	The following mode set is for the channel symbols. During a SJOIN event 
+    the modes are sent usually before the nick. These normally are @, +, %
+    etc.. depending on the ircd. Starting at ASCII 0 and running to 127. 
+    Replace the 0 with the character (o = @, h = %) for the given mode. In the
+    case of halfop which is usually sent as % replace the 37th character with
+    'h', do this until all modes that are possible be received in this manor 
+    have been inserted into the array.
+
+	Now that you have that complete, the following array is ready to be dealt
+    with. This is the cmmodes array, like the others it is a ASCII array
+	starting at 0 and going to 127. However at the given letter you will want
+    to enter the add, and delete function for the given mode. In the case of
+    bans (+b) there is add_ban, and del_ban. Anope provides functions for 
+    bans, exceptions and invites, should your ircd have more then these please
+    contact Anope to discuss what can be done to add this mode.
+
+5) Functions and Events
+
+    A brief word about functions and events. All events are captured using:
+
+        void moduleAddIRCDMsgs(void)
+        {
+            m = createMessage("NICK", anope_event_nick); 
+            addCoreMessage(IRCD,m);
+        }
+
+    Each event should have a event handler if its important enough to be
+    processed by services. All event functions should be formed like this:
+
+        int anope_event_capab(char *source, int ac, char **av)
+        {
+            return MOD_CONT;
+        }
+
+    They will receive the source; this can be NULL at times depending on the
+    event. Next, ac is the number of arguments that are in the event, and av
+    holds the values for each; so av[0] is the first variable, av[1] will be
+    the second one, and so on. Events are likely to pass to various upper
+    level event handlers; see the previous ircd source for how they handle
+    these events.
+
+    All commands are formed like this:
+
+        void anope_cmd_svsnoop(char *server, int set)
+        {
+            send_cmd(NULL, "SVSNOOP %s %s", server, (set ? "+" : "-"));
+        }
+
+    They may take any number of arguments, depending on the command. They
+    should eventually come to a send_cmd(); this root function is how
+    commands are sent to the IRCd.
+
+6) CAPAB/PROTOCTL
+
+    Most IRCD send a CAPAB or PROTOCTL line so that they can work out what
+    the other end of the connection is capable of doing. Anope has a function
+    to read these lines and set itself up to to handle these events better.
+    When adding support for your ircd, take the following steps.
+
+    1) In the ircd.c find the function anope_cmd_capab(); this function will
+       send the CAPAB/PROTOCTL line (consult your ircd documentation for
+       which to send). In a single line type in the tokens that anope must
+       send. Here is an example of Hybrid's capab line:
+
+        /* CAPAB */
+        void anope_cmd_capab()
+        {
+            send_cmd(NULL, "CAPAB TS5 EX IE HOPS HUB AOPS");
+        }
+
+    2) In the ircd.h file make sure to place the defines (see below) that
+       match your IRCd's tokens; only use the ones that matter to your ircd.
+       Should your IRCd add new features not covered in the defined, please
+       contact the Anope Dev team before doing so. See README for information
+       on how to contact the Anope team.
+
+    3) Ensure that the CAPAB/PROTOCTL event his handled correctly. 
+
+        A) In the function "moduleAddIRCDMsgs" making sure that you have the
+           following two lines:
+   
+            m = createMessage("CAPAB", anope_event_capab); 
+            addCoreMessage(IRCD,m);
+
+        B) Add the function to handle the event
+
+            int anope_event_capab(char *source, int ac, char **av)
+            {
+                capab_parse(ac, av);
+                return MOD_CONT;
+            }
+
+           This function should call the capab_parse function which parses
+           the received CAPAB/PROTOCTL line.