summaryrefslogtreecommitdiff
path: root/docs/EVENTS
blob: bf0b3e7f73a6e39c6b405b09f6a4ae576a8ebc18 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
Anope Internal Events
---------------------

1) Intro
2) Complex Events
3) Triggered Events
4) Triggered Events List

1) Introduction to Internal Events

    Internal Events are setup to give module developers more information
    about what the core is doing at different times. This information can
    be as complex as data we are feeding to the uplink, to simple triggered
    events such as the databases being saved. A list of triggered  events
    can be found below. Additional there is a module included with the core
    which can  provide some clue as to how to use the code in your modules.
    The rest of this document assumes that you are used to writing modules.

2) Complex Events

    This type of events are based around what happens when we talk to the
    IRCd, much like MESSAGE events that the IRCD sends to us. The events
    are triggered when Anope writes to the ircd. To watch for these events
    you must have some knowledge of how the IRCd command system works. In
    our example we will trap for NICK events.

    A) All functions most be formatted as:

        int functioname(char *source, int ac, char **av);

    B) In AnopeInit you must declare EvtMessage in some fashion, it is into
       this variable that we will create the event handler. Here is what the
       base AnopeInit should look like at this point:
 
        int AnopeInit(int argc, char **argv)
        {
            EvtMessage *msg = NULL;
            int status;

            moduleAddAuthor(AUTHOR);
            moduleAddVersion(VERSION);
            return MOD_CONT;
        }

       Note that AUTHOR and VERSION should be defined above the AnopeInit
       function, just like you should do with any module.

    C) Pass "createEventHandler" the name of the message in this case NICK,
       and the function that was created in Step A. At this point you should
       assign the return of "createEventHandler" to the EvtMessage variable.

        msg = createEventHandler("NICK", my_nick);

    D) The Handler is not ready for use yet; now you must add it to the hash
       with "moduleAddEventHandler". You will want to pass to this function
       the return of "createEventHandler".

        status = moduleAddEventHandler(msg);

       It will return the same module error codes as adding a regular message,
       which you can use to confirm it was added correctly.

    E) With that setup in your function you will be passed 3 items. The source
       most of the time this will be set to ServerName or NULL; consult our
       IRCd documentation about how messages are formatted. AC is the count of
       variables you will find in AV.

        int my_nick(char *source, int ac, char **av)
        {
            alog("Internal Event - nick is %s",av[0]);
            return MOD_CONT;
        }

3) Triggered Events

    These events also known as "event hooks" are internal events such as
    expiring of nicks to the saving of databases.

    A) All functions most be formatted as:

        int functioname(char *message);

    B) In AnopeInit you must declare EvtHook in some fashion; it is into
       this variable that we will create the event handler. Here is what
       the base AnopeInit should look like at this point:
 
        int AnopeInit(int argc, char **argv)
        {
            EvtHook *hook = NULL;
            int status;

            moduleAddAuthor(AUTHOR);
            moduleAddVersion(VERSION);
            return MOD_CONT;
        }

    C) Pass "createEventHook" the name of the event. In this case we are
       going to hook to the saving of databases, "EVENT_DB_SAVING".

        hook = createEventHook(EVENT_DB_SAVING, my_save);

    D) The Handler is not ready for use yet; now you must add it to the hash
       with "moduleAddEventHook". You will want to pass to this function the
       return of "createEventHook"

        status = moduleAddEventHook(hook);

       It will return the same module error codes as adding a regular message,
       which you can use to confirm it was added correctly.

    E) With that setup in your function you will be passed 1 item. The message
       is very simple; it could be as simple as a start, stop or message. In
       the case of saving it has a start and stop.

        int my_save(char *source)
        {
            if (!stricmp(source, EVENT_START)) {
                alog("Saving the databases! has started");
            } else {
                alog("Saving the databases is complete");
            }
            return MOD_CONT;
        }

4) Triggered Events List

    Here's a list of all event hooks we currently offer, with a description
    of what argument is being passed to the event functions for this type of
    event. All arguments are plain-text strings (char *). The list is sorted
    in alphabetical order.

    Note that all events are emitted AFTER the action has taken place, so
    any deleted nick/channel/etc won't exist anymore and any created one will
    exist when your function is being run, unless noted otherwise.

    Also note that EVENT_START and EVENT_STOP should not be matched with an
    equal sign, but with string comparision. See the bundled events module for
    an example on how to do this.

    EVENT_BOT_ASSIGN
        A BotServ bot has been assigned to a channel.
        The argument contains the nickname of the bot involved.

    EVENT_BOT_CHANGE
        The properties of a BotServ bot have been changed.
        The argument contains the nickname of the bot involved.

    EVENT_BOT_CREATE
        A new BotServ bot has been created, and is ready to use.
        The argument contains the nickname of the newly created bot.

    EVENT_BOT_DEL
        A BotServ bot is being deleted from BotServ. This event is being sent
        just before the actual deletion is performed.
        The argument contains the nickname of the bot being deleted.

    EVENT_BOT_JOIN
        A BotServ bot has joined a channel and opped itself.
        The argument contains the channel name the bot is on.

    EVENT_BOT_UNASSIGN
        A BotServ bot is being unassigned from a channel. This event is being
        sent before the actual removing of the bot is done.
        The argument contains the channel name the bot is on.

    EVENT_CHAN_DROP
        A channel has been dropped and deleted.
        The argument is the name of the channel that has been dropped.

    EVENT_CHAN_EXPIRE
        A channel has been expired and will be deleted. The event will be
        emitted just before the actual channel deletion happens.
        The argument is the name of the channel being deleted.

    EVENT_CHAN_FORBIDDEN
        A channel has been forbidden (ChanServ FORBID).
        The argument is the name of the channel that has been forbidden.

    EVENT_CHAN_REGISTERED
        A new channel has been registered.
        The argument is the name of the channel that has been registered.

    EVENT_CHAN_SUSPENDED
        A channel has been suspended (ChanServ SUSPEND).
        The argument is the name of the channel that has been suspended.

    EVENT_CHANGE_NICK
        A user has just changed it's nick.
        The argument contains the new nickname of the user.

    EVENT_CONNECT
        This event is emitted when the connection to our uplink hub is being
        made.
        The argument is either EVENT_START or EVENT_STOP, to indicate if it's
        emitted before or after the connection has been made. EVENT_STOP is
        emitted before our burst is being sent over the link.

    EVENT_DB_EXPIRE
        This event is emitted when the expiry routines for all things that can
        expire in Anope are being run.
        The argument is either EVENT_START or EVENT_STOP, to indicate if it's
        being emitted before or after the expiry routines have been run.

    EVENT_DB_SAVING
        This event is emitted when the databases are being saved.
        The argument is either EVENT_START or EVENT_STOP, to indicate if it's
        emitted before or after the saving routines.

    EVENT_DEFCON_LEVEL
        The DefCon level has just been changed. This event is emitted before
        any DefCon-related action is taken. The internal DefConLevel has
        already been raised at this point.
        The argument contains the new level of DefCon being invoked.

    EVENT_GROUP
        A user has grouped it's nickname to another user group.
        The argument contains the nickname of the user that joined the group.

    EVENT_NEWNICK
        A new user has been introduced on the network.
        The argument contains the nickname of the newly introduced user.

    EVENT_NICK_DROPPED
        A user's nick has just been dropped. Note that the nickname information
        has already been deleted!
        The argument contains the nickname of the user that has just been
        dropped.

    EVENT_NICK_EXPIRE
        A user's nick has just expired. Note that, as with EVENT_NICK_DROPPED,
        the nickname information has already been deleted!
        The argument contains the nickname of the user that has just expired.

    EVENT_NICK_FORBIDDEN
        A user's nick has just been forbidden.
        The argument contains the nickname of the user that has just been
        forbidden.

    EVENT_NICK_IDENTIFY
        A user has just identified for it's nickname with NickServ.
        The argument contains the nickname of the user that just identified.

    EVENT_NICK_REGISTERED
        A new user has just registered it's nickname. This event is being
        emitted when the registration is completed, but the user modes have not
        yet been set.
        The argument contains the nickname of the newly registered user.

    EVENT_RESTART
        This event is emitted before the services are being restarted.
        The argument is always EVENT_START.

    EVENT_SERVER_CONNECT
        A new server has just connected to the network.
        The argument contains the name of the new server.

    EVENT_SERVER_SQUIT
        A server has sent an SQUIT and is about to be removed from the
        network. This event is being sent before the server is actually removed
        from the network.
        The argument is the name of the server that is being removed.

    EVENT_SHUTDOWN
        This event is emitted when Anope is being shut down.
        The argument is either EVENT_START or EVENT_STOP, to indicate where in
        the process of restarting the core is. With EVENT_START, services are
        still fully online and operating. With EVENT_STOP, every internal clean
        up has been done already, and the SQUIT has been sent; the only thing
        done after emitting the event is closing the socket to the uplink hub.

    EVENT_SIGNAL
        This event is emitted when Anope is quitting because of a signal it
        received.
        The argument contains the quit message that will be sent with the SQUIT
        for this shutdown.

    EVENT_TOPIC_UPDATED
        A channel topic has been succesfully updated. Note that this even is
        only emitted if the new topic has been fully accepted and set by the
        Anope core.
        The argument is the name of the channel involved.

    EVENT_USER_LOGOFF
        A user has left the network. This event is emitted before the internal
        removal is performed, so the user still exists internally.
        The argument contains the nickname of the user leaving the network.