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
|
o !votekick und !kick müssen best. kickfunktion aufrufen. die kann dann
kickban und nach 3 sec unban oder sowas machen.
o benutzergruppen; z.B. votekick-wahlberechtigt?
o ein plugin soll auf verschiedene commands ansprechen können
(z.B. !kick, !kickban etc)
o neuladen von listen + conf via plugins
o listenfunktionen: add/del z.B.(useradd, userdel)
o bot forken lassen (damit nohup wegfallen kann)
o user per nickserv identifizieren, alternative: passwort
o alle plugins sollen configfile nutzen
o bannlisten??? (mode #channel +b)
o einige sachen können mit maps besser gelöst werden
o DrunkenMan[,:] do_sth statt !do_sth als befehl-prefix
channel und session ist dafür relevant
o slot- oder hook-konzept: plugins senden nicht mehr "KICK :foo", sondern
rufen parent->do("KICK", arg1, ...) auf
returnval: -1=no such hook, -2 .. -inf = error, 0..inf=ok
einige dinge, wie kick, ban, kickban, stellt drunkenman selbst bereit
diese, und alle undefinierten können durch hooks überschrieben werden
so kann z.B. drunkenman's kick nur kicken, ein spezielles kick aber
noch für 3 sec bannen, um autorejoins zu vermeiden
plugins können folgendes tun:
if (parent->do("timedkick"...)<0) parent->do("normalkick")
ODER:
plugins stellen hook(string what, void* data, TConnection* parent)
bereit, und sagen in init, was sie können (kann auch "nichts" sein)
wenn nun ein plugin als "KICK" eingetragen ist, wird statt
dm's eigenem kick dieser hook gerufen, mit allen infos über den
momentanen verbindungskontext.
-> plugins können auch später noch darauf reagieren
außerdem können hooks "antworten". dafür wird ein weiterer
exe-grund erstellt, nämlich REASON_ANSWER. den können plugins
nicht ignorieren.
so kann z.B. "is_master" erst einen whois starten, und erst dann
antworten, wenn der whois durch ist.
|
