TeamSpeak 3 Server Query Notify (servernotifyregister)

Hier geht es um die Events, über die man mit servernotifyregister benachrichtigt wird.

Abonnements verschwinden auch, wenn man sich ausloggt, umloggt (auch selber Benutzer) oder auf einen anderen(!) oder keinen Server wechselt.

Abonnements müssen einzeln erstellt werden, Arrayparameter sind für den Parameter event nicht möglich. Der Quellkanal der einzelnen Events kann nicht herausgefunden werden. Die hier gemachten Unterscheidungen entstanden, indem sich mehrere Clients verbunden und jeweils andere Kanäle abonniert haben.

Werden einem die Rechte für Abonnements entzogen, bleiben bestehende Abonnements erhalten.

Inhaltsverzeichnis

Die Namen der abonnierbaren Kanäle sind auf der ersten Ebene, die Namen der von ihnen ausgelösten Events sind auf zweiter Ebene.

server und channel

Die hier genannten Events erhält man sowohl als Server- als auch als Channel-Event. Wenn man im entsprechenden Channel ist, erhält man also zweimal dasselbe Event.

notifycliententerview

Die Ausgabe ist ähnlich zu clientinfo. Dazu kommen die notify-exklusiven ersten drei Felder für Benutzerbewegungen und das vor längerer Zeit aus clientinfo gelöschte Feld client_unread_messages.

1. cfid (Quellchannel; „0“ beim Betreten des Servers)
2. ctid (Zielchannel)
3. reasonid (siehe Anhang)
4. clid
5. client_unique_identifier
6. client_nickname
7. client_input_muted
8. client_output_muted
9. client_outputonly_muted
10. client_input_hardware
11. client_output_hardware
12. client_meta_data (Query-Clients können hier mit clientupdate für sich selbst während ihres Aufenthaltes etwas speichern, das war ursprünglich mal für die Kommunikation zwischen Plugins gedacht, was aber über einen Kanal läuft, auf den man per Query keinen Zugriff hat)
13. client_is_recording
14. client_database_id
15. client_channel_group_id
16. client_servergroups
17. client_away
18. client_away_message
19. client_type („1“ für Query, „0“ für Voice)
20. client_flag_avatar
21. client_talk_power
22. client_talk_request
23. client_talk_request_msg
24. client_description
25. client_is_talker
26. client_is_priority_speaker
27. client_unread_messages (hier immer noch vorhanden, obwohl es aus clientinfo längst gelöscht wurde)
28. client_nickname_phonetic
29. client_needed_serverquery_view_power (Änderung für Voice-Nutzer während einer Sitzung manchmal nicht rückwirkend, funktioniert jedoch bei Gruppenwechsel)
30. client_icon_id
31. client_is_channel_commander
32. client_country
33. client_channel_group_inherited_channel_id
34. client_badges (leer bei Query- und zu alten Clients, sonst in sich selbst parametrisierter String)

notifycliententerview gibt jeden Client zurück, der sich auf den Server verbindet, selbst wenn man diese mit clientlist nicht sehen könnte oder kann. Warum diese Formulierung? Tja, die Ausgabe bei clientlist ist großes Chaos. Während ein Voice-Client alle Clients sieht, die er sehen soll (channel_needed_subscribe_power) oder in deren Channel er ist, fällt letzteres für Query-Clients weg. Man sieht also nur Clients, deren Channel man abonnieren kann. Das gilt insbesondere für Query-Clients und insbesondere für sich selbst.

notifyclientleftview

1. cfid
2. ctid („0“ bei Verlassen)
3. reasonid (siehe Anhang)
4. invokerid (für Bans und Kicks)
5. invokername (für Bans und Kicks)
6. invokeruid (für Bans und Kicks)
7. reasonmsg
8. bantime (für Bans, Dauer in Sekunden)
9. clid (Array nicht möglich)

Dieses Event erhält man über sich selber und alle vor einem rausgeschmissenen, wenn der Server heruntergefahren wird. Nur über denjenigen, der den Server heruntergefahren hat, bekommen die anderen(!) reasonid=8 reasonmsg=deselected\svirtualserver gesagt, er selbst bekommt das normale Event (wie alle anderen über alle anderen).

server

notifyserveredited

1. reasonid (immer „10“)
2. invokerid
3. invokername
4. invokeruid

Anschließend folgen die neuen Werte der Parameter, die geändert wurden. Aber Halt: Man wird nicht bei allen Parametern über den neuen Wert informiert. Das Event wird auch ausgelöst, wenn deshalb gar keine neuen Werte mitgeteilt werden können.

Über die neuen Werte folgender Eigenschaften wird man sofort mitinformiert:

1. virtualserver_name
2. virtualserver_codec_encryption_mode
3. virtualserver_default_server_group
4. virtualserver_default_channel_group
5. virtualserver_hostbanner_url
6. virtualserver_hostbanner_gfx_url
7. virtualserver_hostbanner_gfx_interval
8. virtualserver_priority_speaker_dimm_modificator
9. virtualserver_hostbutton_tooltip
10. virtualserver_hostbutton_url
11. virtualserver_hostbutton_gfx_url
12. virtualserver_name_phonetic
13. virtualserver_icon_id
14. virtualserver_hostbanner_mode
15. virtualserver_channel_temp_delete_delay_default

Für die passive Änderungen von virtualserver_ask_for_privelege_key durchs Benutzen eines Tokens gibt es kein Event.

Man bekommt zwar die neue Standard-Server- und -Channel-Gruppe gesagt, nicht jedoch die Standard-Channeladmin-Gruppe...

channel

Der id-Parameter ist bei event=channel verpflichtend und überall sonst weder erforderlich noch wirksam, insbesondere auch bei event=textchannel (man kann also nur seinem eigenen Channelchat lauschen). Der id-Parameter muss nicht auf einen existierenden Channel zeigen. id=0 steht für alle bestehenden und neuen Channel.

Man kann nur ein Channel-Abo haben. Es gilt das erste, das man abonniert hat. Dies wird nur durch Verlassen des Servers oder servernotifyunregister zurückgesetzt. Insbesondere wird es nicht zurückgesetzt, wenn der Channel gelöscht wird. Arrays als Parameter sind nicht möglich. Beim Löschen eines Channels geht das Abonnement nicht verloren.

Es gibt beim Abonnieren eines bestimmten Channels kein Event fürs Erstellen eines Channels, selbst wenn man die zukünftige Channel-ID richtig rät. Eine richtig geratene ID des Channels informiert einen jedoch darüber, dass man selbst dorthin gegangen ist, wenn man selbst einen temporären Channel erstellt hat. Die Zeile steht zwischen der zurückgegebenen Channel-ID und dem Ergebnis der Funktion...

notifychanneldescriptionchanged und notifychannelpasswordchanged

1. cid

notifychanneledited wird stets zusätzlich ausgelöst. Die Reihenfolge ist:

1. notifychanneledited
2. notifychanneldescriptionchanged
3. notifychannelpasswordchanged

Entgegen des Namens wird notifychannelpasswordchanged nicht ausgelöst, wenn das Passwort geändert wird. Es wird nur ausgelöst, wenn das Passwort gesetzt oder entfernt wird. In dem Fall informiert notifychanneledited über den neuen Wert von channel_flag_password. Wird das Passwort geändert, wird notifychanneledited ausgelöst und gibt, soweit es sonst nichts zu vermelden gibt, nur die Minimalparameter zurück.

Ebenso ohne weiteren Anlass nur mit Minimalparametern wird notifychanneldescriptionchanged ausgelöst, wenn die Beschreibung geändert wird. Allerdings führt auch das Ändern der Beschreibung zu notifychanneldescriptionchanged.

notifychannelmoved

notifychannelmoved wird nur ausgelöst, wenn sich der Elternchannel ändert. Ändert sich der Elternchannel nicht, wird bei Verschiebungen notifychanneledited ausgelöst. notifychanneledited wird nicht ausgelöst, wenn sich Elternchannel und Sortierung ändern.

1. cid
2. cpid
3. order
4. reasonid
5. invokerid
6. invokername
7. invokeruid

Ändert sich die Reihenfolge eines Channels, weil ein anderer Channel vor ihn geschoben wird, ergibt das kein Event.

notifychanneledited

1. cid
2. reasonid
3. invokerid
4. invokername
5. invokeruid

Anschließend kommen die neuen Werte. Wie bereits erwähnt und auch zu erwarten, wird man nicht über die neuen Werte von channel_description und channel_password (wobei das eh nur ein Hash ist) informiert, jedoch über alle anderen, die da wären:

1. channel_name
2. channel_topic
3. channel_codec
4. channel_codec_quality
5. channel_maxclients
6. channel_maxfamilyclients
7. channel_order
8. channel_flag_permanent
9. channel_flag_semi_permanent
10. channel_flag_default
11. channel_flag_password
12. channel_codec_latency_factor
13. channel_codec_is_unencrypted
14. channel_delete_delay
15. channel_flag_maxclients_unlimited
16. channel_flag_maxfamilyclients_unlimited
17. channel_flag_maxfamilyclients_inherited
18. channel_needed_talk_power
19. channel_name_phonetic
20. channel_icon_id

channel_icon_id bekommt, wenn man es mit dem offiziellen Client ändert, stets eine Extrawurst, wenn noch irgendwas anderes geändert wurde. Dann kommt es immer ganz am Ende, also auch noch nach Auslösung den beiden Sonder-Events. Das dürfte daran liegen, dass der offizielle Client das Icon über channelpermadd ändert (gelöscht wird durch Setzen auf 0, nicht durch channelpermdel), worüber man ebenfalls informiert wird. Ändert man channel_icon_id über channeledit zusammen mit anderen Werten, ergibt das nur ein Event notifychanneledited.

Man wird, wie man oben sieht, nicht über das Ändern der Rechte informiert. Ausnahme ist channel_needed_talk_power, was bei einer Änderung notifychanneledited auslöst und damit zurückgegeben wird. Auch hier löst channelpermadd das Event notifychanneledited aus, allerdings bekommt channel_needed_talk_power keine Extrawurst wie channel_icon_id.

notifychanneledited wird nicht ausgelöst, wenn dem Channel das Standard-Flag entzogen wird oder man die benötigten Rechte (außer wie erwähnt Talkpower) ändert (im offiziellen Client).

notifychannelcreated

Wie schon erwähnt wird das Event nur ausgelöst, wenn man alle Channel abonniert hat (id=0).

1. cid
2. cpid
3. channel_name
4. channel_topic
5. channel_codec
6. channel_codec_quality
7. channel_maxclients
8. channel_maxfamilyclients
9. channel_order
10. channel_flag_permanent
11. channel_flag_semi_permanent
12. channel_flag_default
13. channel_flag_password
14. channel_codec_latency_factor
15. channel_codec_is_unencrypted
16. channel_delete_delay
17. channel_flag_maxclients_unlimited
18. channel_flag_maxfamilyclients_unlimited
19. channel_flag_maxfamilyclients_inherited
20. channel_needed_talk_power
21. channel_name_phonetic
22. channel_icon_id
23. invokerid
24. invokername
25. invokeruid

Setzt man ein Icon, wird dies erst nach der Erstellung des Channels mittels notifychanneledited gesetzt.

notifychanneldeleted

1. invokerid („0“ bei Löschung eines temporären Channels durch den Server)
2. invokername („Server“ bei Löschung eines temporären Channels durch den Server)
3. invokeruid (fehlt bei Löschung eines temporären Channels durch den Server)
4. cid

Das Event wird nicht ausgelöst, wenn ein Elternchannel gelöscht wird und der abonnierte Channel dadurch mitgelöscht wird. Hat man alle Channel oder den zu löschenden Elternchannel abonniert, wird das Event ebenfalls nur für den Elternchannel ausgelöst.

notifyclientmoved

1. ctid
2. reasonid („0“ oder „1“; ist clid ein Array, ist dieser Wert pauschal „1“, auch wenn der schiebende Benutzer selbst dabei ist; zu den IDs siehe Anhang)
3. invokerid (wenn reasonid nicht „0“ ; „0“ bei Erstellung eines temporären Channels)
4. invokername (wenn reasonid nicht „0“ ; Server bei Erstellung eines temporären Channels)
5. invokeruid (wenn reasonid nicht „0“ ; fehlt bei Erstellung eines temporären Channels)
6. clid (Array möglich)

Wird ein Channel gelöscht, erhält man einen regulären Channelkick mit der Begründung reasonmsg=channel\sdeleted.

Hat man alle Channel abonniert, erhält man jedes notifyclientmoved zweimal.

textserver, textchannel, textprivate und Notifys die man gar nicht abonniert hat

gm geht an textserver.

Man erhält über Flüsternachrichten, die man verschickt, immer ein Notify, auch wenn man gar nichts abonniert hat.

notifytextmessage

1. targetmode („1“=privat, „2“=Channel, „3“=Server)
2. msg
3. target (clid des Empfängers; Parameter nur bei textprivate vorhanden)
4. invokerid („0“ bei gm)
5. invokername („Server“ bei gm)
6. invokeruid (fehlt bei gm; „serveradmin“ beim Nur-Query-Account, „ServerQuery“ bei Nachrichten von Query-Gästen)

Man kann sich selbst anschreiben und erhält auch sonst sämtliche selbst ausgelösten Events.

tokenused

Diese Event-Anmeldung ist nicht zentral dokumentiert. Das Event wurde von Enril1112 im Forum gewünscht.

notifytokenused

Tritt auf, wenn ein Token benutzt wird.

1. clid
2. cldbid
3. cluid
4. token
5. tokencustomset
6. token1 (Gruppe)
7. token2 („0“ bei Servertoken)

Ausdrücklich nicht dabei sind tokendescription und tokentype. Letzteres kann man sich aber erschließen, indem man prüft, ob token2 auf 0 steht.

Anhang

reasonid