[Plugin] Teamspeak Connector
#1

TeamSpeak Connector v1.3
The TSConnector plugin gives you the possibility to control a TeamSpeak3 server from within your gamemode. That means you can kick or ban users, create, edit and delete channels and more!

Installation
  1. create a ServerQuery account for your TeamSpeak3 server
    NOTE: The ServerQuery account should have enough rights to subscribe to all channels!
  2. add this line to your PAWN script to establish a connection to the TS3 server:
    Code:
    TSC_Connect("serveradmin", "password", "127.0.0.1", 9987);
    //  "serveradmin": the ServerQuery login name
    //  "password": the ServerQuery login password
    //  "127.0.0.1" the TeamSpeak3 server IP
    //  9987: the TeamSpeak3 server port
    The call to TSC_Connect will freeze the server as long as a valid connection has been established.
  3. You are ready to go!
If you are done using the plugin (e.g. in "OnGameModeExit"), call TSC_Disconnect to disconnect from the TeamSpeak3 server.


Here is a small code example:
pawn Code:
#define TS_SERVER_GROUP_PLAYER 1337

public OnGameModeInit()
{
    TSC_Connect("serveradmin", "password", "127.0.0.1", 9987);
    TSC_ChangeNickname("SA:MP Server");
   
    TSC_CreateChannel("Channel 1", .type = SEMI_PERMANENT, .maxusers = 25);
    return 1;
}

public TSC_OnChannelCreated(channelid)
{
    new channel_name[32];
    TSC_GetChannelName(channelid, channel_name);
    if(strcmp("Channel 1", channel_name) == 0)
    {
        TSC_SetChannelDescription(channelid, "Description of Channel 1!");
    }
    return 1;
}

public TSC_OnClientConnect(clientid, nickname[])
{
    TSC_PokeClient(clientid, "Welcome!");
    TSC_AddClientToServerGroup(clientid, TS_SERVER_GROUP_PLAYER);
    return 1;
}
Some more ideas:
  • moving a player automatically to the right faction channel when going on-duty
  • kicking annoying people from the SA:MP server AND TS3 server
  • ingame proximity-voicechat by creating a channel if two players are in range and moving them into that channel
A list of all functions can be found in the include file.

Notes
  • like noted above, make sure the ServerQuery account has enough rights to subscribe to all channels
  • there is an inbuilt ServerQuery flood protection in the TS3 server, make sure the IP you are connecting from (the SA:MP server address) is on the ServerQuery whitelist ("127.0.0.1" is by default on that list)
  • make sure the TS3 server listens to incoming query connections (you can change that in your 'ts3server.ini' file with the 'query_ip' variable)
  • the plugin is fully threaded, thus no major lags can occur (except through 'TSC_Connect')
Source on GitHub
Download on GitHub
Reply
#2

nice job
Reply
#3

Sounds like useful! Gonna try it
Good job
Reply
#4

Aw, this is very nice release
Reply
#5

Nice one pain, is there a way to play the audio into the server?
Reply
#6

Uh, no, it's not possible. What would you do anyway if you had the voices in the server?
Reply
#7

This is awesome. Good job!
Reply
#8

Nice job, but i've noticed something, almost in every native you send the command then receive the answer,
so if this plugin gets connected with an external server, it'll lag the local one, since the recv function hangs the server until an answer is received, i know that its only designed to work with local servers so there is no such a problem

my suggestion is that if you run the Receive function on a seperated thread, and everytime a response is received you check for errors and use a callback to pass it to scripts, something like "TSC_OnError" maybe ?

apart that good work
Reply
#9

I feel like this plugin would be MUCH more useful if you could determine the amount of the people in your channel, the name of the people in your channel, your channel name, and possibly even get messages sent between members of the channel.

Nevertheless, nice job!
Reply
#10

Nice job ! :O i will test it, i've many idea to use it
Reply
#11

nice work on this, but you should add more features to it.
Reply
#12

Use
pawn Code:
enum _:ChannelTypes {
    CHANNEL_TYPE_PERMANENT = 1,
    CHANNEL_TYPE_SEMI_PERMANENT = 2,
    CHANNEL_TYPE_TEMPORARY = 3
};

enum _:KickTypes {
    KICK_TYPE_CHANNEL = 1,
    KICK_TYPE_SERVER = 2
};
or
pawn Code:
enum {
    CHANNEL_TYPE_PERMANENT = 1,
    CHANNEL_TYPE_SEMI_PERMANENT = 2,
    CHANNEL_TYPE_TEMPORARY = 3
};

enum {
    KICK_TYPE_CHANNEL = 1,
    KICK_TYPE_SERVER = 2
};
This way, you'll never have to clear the tag (using _. Also there is no need for "= 2", "= 3". They increment automatically.
Reply
#13

Nice plugin, I like the idea. Will try to do the same in Pawn with BlueG's plugin.
Reply
#14

Quote:
Originally Posted by OrMisicL
View Post
Nice job, but i've noticed something, almost in every native you send the command then receive the answer,
so if this plugin gets connected with an external server, it'll lag the local one, since the recv function hangs the server until an answer is received, i know that its only designed to work with local servers so there is no such a problem

my suggestion is that if you run the Receive function on a seperated thread, and everytime a response is received you check for errors and use a callback to pass it to scripts, something like "TSC_OnError" maybe ?

apart that good work
But then every result has to be called in an extra callback in the script, it would work like BlueG's MySQL plugin Well, I think I can configure the socket to set a max_timeout value, so the recv-function will abort if it takes too long. And that's not the biggest problem. Imagine, I want to know what channel user X is currently in. I send the query to require the information, then receive it. Without any threading and callback calling, I get immediatly the current channel. But with threading and callbacks I could get the information, that user X is in channel Y, but it took so long to get that information, that user X has already switched channels and is now in channel Z. So I would get a wrong, outdated information. That's why I don't want to use threads.

Quote:
Originally Posted by Kar
View Post
Nice! Really, is there any possible way to retrieve messages sent by teamspeak users?
You can't get the messages send in a channel or server, but users can send offline messages to the admin account which was used to log in and these messages can be retrieved, but I don't think this is useful. (or maybe it is useful?)

Quote:
Originally Posted by RealCop228
View Post
I feel like this plugin would be MUCH more useful if you could determine the amount of the people in your channel, the name of the people in your channel, your channel name, and possibly even get messages sent between members of the channel.

Nevertheless, nice job!
list of people in a channel: possible
channel name: you would have to know the exact channelid to get the name, is this really important?
messages: not possible


Quote:
Originally Posted by Dan..
View Post
Use
pawn Code:
enum _:ChannelTypes {
    CHANNEL_TYPE_PERMANENT = 1,
    CHANNEL_TYPE_SEMI_PERMANENT = 2,
    CHANNEL_TYPE_TEMPORARY = 3
};

enum _:KickTypes {
    KICK_TYPE_CHANNEL = 1,
    KICK_TYPE_SERVER = 2
};
or
pawn Code:
enum {
    CHANNEL_TYPE_PERMANENT = 1,
    CHANNEL_TYPE_SEMI_PERMANENT = 2,
    CHANNEL_TYPE_TEMPORARY = 3
};

enum {
    KICK_TYPE_CHANNEL = 1,
    KICK_TYPE_SERVER = 2
};
This way, you'll never have to clear the tag (using _:). Also there is no need for "= 2", "= 3". They increment automatically.
Thanks, I was to lazy to update the include and reupload it again because of the example, I will change it in the next update.


If you have other suggestions feel free to post them here.
Reply
#15

If you send the query to request the information, then you hang the samp main thread until a response is received, it'll lag the server

Quote:
Originally Posted by Pain123
View Post
Without any threading and callback calling, I get immediatly the current channel. But with threading and callbacks I could get the information, that user X is in channel Y, but it took so long to get that information, that user X has already switched channels and is now in channel Z. So I would get a wrong, outdated information. That's why I don't want to use threads.
why you would get a wrong information on a separated thread ? you get the response as fast as you do it without threads, it simply wont lag the server
Reply
#16

I meant that if the Teamspeak server takes too long to answer a request, without threading the server would lag and with threading I could get a wrong information. So I think it is better to abort a long request and stick with the unthreaded solution. (and maybe call a TSC_Error callback, I like that idea)
Reply
#17

Quote:
Originally Posted by Pain123
View Post
I meant that if the Teamspeak server takes too long to answer a request, without threading the server would lag and with threading I could get a wrong information. So I think it is better to abort a long request and stick with the unthreaded solution. (and maybe call a TSC_Error callback, I like that idea)
Well, thats ok if you abort long requests, but it'll depend on how much time it'll wait before the request gets aborted
Reply
#18

Nice job man!
Will you consider implementing a way of manipulating with connected clients?
This way we would be able to change the clients' permissions from the server! With that option we could assign players the appropriate groups within the server when the player joins an organisation or gang. It would be awesome
Reply
#19

Quote:
Originally Posted by OrMisicL
View Post
Well, thats ok if you abort long requests, but it'll depend on how much time it'll wait before the request gets aborted
I implemented the function "TSC_SetTimeoutTime" to manually adjust the time. By default the timeout time is at 200ms.

Quote:
Originally Posted by Gigi-The-Beast
View Post
Nice job man!
Will you consider implementing a way of manipulating with connected clients?
This way we would be able to change the clients' permissions from the server! With that option we could assign players the appropriate groups within the server when the player joins an organisation or gang. It would be awesome
You mean you want to change a clients server or channel group?
Reply
#20

Very nice.
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)