mirror of
https://github.com/anope/anope.git
synced 2026-06-23 21:06:38 +02:00
viper viper@31f1291d-b8d6-0310-a050-a5561fc1590b
30e6da5753
git-svn-id: svn://svn.anope.org/anope/trunk@1438 31f1291d-b8d6-0310-a050-a5561fc1590b git-svn-id: http://anope.svn.sourceforge.net/svnroot/anope/trunk@1153 5417fbe8-f217-4b02-8779-1006273d7864
602 lines
28 KiB
Plaintext
602 lines
28 KiB
Plaintext
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.
|