[Official] ClientQuery Plugin

[Peter]

What is it?
The ClientQuery Plugin is included and enabled by default in every TS3 Client installation. Through a simple tcp/ip socket the client can be queried and controlled. By default only localhost applications can reach this socket (for security reasons).

How can it be used?
ClientQuery has two main uses:
(1) Integrating "TS3 Client Support" into existing applications (e.g. Games). Say you want to display who is currently talking on TeamSpeak within your game. You can map players to TS3 clients and then display which player is talking on TS next to the player names. Or you wish to add something like a "invite user to my teamspeak" function where a player can invite some other player to join his TeamSpeak etc.
(2) TS3 centred software that can not or does not want to use the Client Plugin SDK can use Client Query instead to retrieve information or initiate actions.

Examples/Docs
Documentation and Examples are shipped with the TS3 Client, from your TS3 Client installation Folder go to "plugins/clientquery_plugin" for per command documentation and "plugins/clientquery_plugin/examples" for example code and a README.

Note you can also get documentation interactively, just connect your telnet client to localhost port 25639, and use "help" and "help <command>".


Please post any questions or feedback or feature suggestions below , but please make sure you are refering to at least TS3 Client 3.0.0 (currently in beta channel), as functionality was much improved.

[Maxe___]

great! very useful!

Edit:
I took a closer look on it and i have a suggestion:
if you register an event that doesn't exist e.g:

clientnotifyregister schandlerid=0 event=test1234
error id=0 msg=ok

it says alright, but I think it would be good if the response would be that the event does not exist.

Regards,
Max

[Scordo]

Ist it by design that the channellist command does not provide "channel_needed_subscribe_power" when used with ClientQuery?
The result of channellist using ServerQuery and ClientQuery is different.

[dante696]

I'm sorry about my answer before

The difference is, that your client does not have the channel permissions in your cache file.
Your real client connects to the server and loads all channels; users and groups with their permissions.
but it dos not load the channe lpermissiosn as long you don't need them, liek you want to see the description of a channel.
The whole process to save a lot of cpu load and network traffic.

The client query does use the informations he already has and does not ask the server for it.

[Scordo]

The reason I'm asking this is that I wrote a C# lib for server query and I would like to reuse as much code as possible when adding support for clientquery. Each command in my lib returns typesafe classes with members filled from the response. If the response is missing values an exception is thrown. So the difference between client and serverquery forces me to reimplement a lot of code for client query support.

[Scordo]

The command "channelconnectinfo" does not work as expected. It always returns the info of the channel I'm currently in, even when I provide an id of a different channel using the channelid parameter.

Btw. is it by design, that I only get the password of the channel when I'm not connected as an admin?

[Scordo]

Found another problem:

clientupdate client_input_deactivated=1 or clientupdate client_input_deactivated=0

results in a "hanging" connection. Just type it using a telnet client and you'll see it.

[Peter]

The command "channelconnectinfo" does not work as expected. It always returns the info of the channel I'm currently in, even when I provide an id of a different channel using the channelid parameter.

This is a flaw in the documentation. The parameter to specify the channel is "cid" not "channelid". The documentation has been updated.

Btw. is it by design, that I only get the password of the channel when I'm not connected as an admin?

You should get the password if your local client knows it. When you have the permissions to ignore channel passwords you often have never entered the password, so the client will not have the password cached. It might even be a wrong password is cached if the password was changed since the client cached it and you received privileges to ignore the password. Use verifychannelpassword to make sure the password is indeed correct.

clientupdate client_input_deactivated=1 or clientupdate client_input_deactivated=0

results in a "hanging" connection. Just type it using a telnet client and you'll see it.

The problem here is that no "error id=0 msg=ok" is returned...the connection itself is fine and everything still works, just this response is missing. I have fixed this and it will be part of the next client release.