Remove docs/IRCD, it is very outdated and no longer correct at all

1 files changed, 0 insertions, 202 deletions

diff --git a/docs/IRCD b/docs/IRCD
deleted file mode 100644
index 7a3effbb3..000000000
--- a/docs/IRCD
+++ /dev/null
@@ -1,202 +0,0 @@
-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.