From 7b4eec97480bace2621b8caa4b17f0ea50aa1f98 Mon Sep 17 00:00:00 2001 From: Adam Date: Mon, 17 Feb 2014 13:53:45 -0500 Subject: [PATCH] Remove docs/IRCD, it is very outdated and no longer correct at all --- docs/IRCD | 202 ------------------------------------------------------ 1 file changed, 202 deletions(-) delete mode 100644 docs/IRCD 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 ¶ms) - { - 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.