mirror of
https://github.com/anope/anope.git
synced 2026-06-23 22:46:37 +02:00
Adam
203 lines
8.2 KiB
Plaintext
203 lines
8.2 KiB
Plaintext
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> ¶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.
|