-
Notifications
You must be signed in to change notification settings - Fork 108
- Why can't I connect to the server?
- Why am I getting a TS3ConnectionFailedException?
- What is the difference between a voice and a query port?
- How do I create a Server Query login?
- Why can't I listen to channel chat for all channels?
- Why am I getting a command error by calling getClientInfo() on a ClientLeaveEvent?
- What is the difference between an event's client and invoker?
- Why are messages to my query being sent to my client?
- Why does ClientLeaveEvent only provide getClientId(), but not getClientUniqueId() or getClientNickname()?
- What's the difference between a Client ID, a Database ID, and a Unique ID?
Coming soon!
Coming soon!
The voice port is the port used for clients to connect to the server. If a server's address is of the form "www.domain.com:9999," the 9999 represents the voice port (default 9987) used to connect via client. The voice port is also known as the virtual server port. (Note that servers that can be connected to without a port may be on the default voice port. It could also be the case that they are utilizing a DNS to resolve the port automatically.)
The query port (default 10011) is the port used by query accounts to connect via Telnet. If your server is through a host, there's a chance your query is not the default. If that is the case, your host should let you know what your query port is when you receive your server. Otherwise, you can only find your query port within the "server.ini" file.
While connected to a TeamSpeak server through a client, go to "Tools" along the menu bar and select "ServerQuery Login" to initiate the dialog. Once open, input the name you wish your query to log in with and click "OK."
The next screen will display both the name and the password your query will use to connect.
Note that any query created this way will share its database ID and UId with the client who created it.
This issue is especially pronounced when privately messaging users from the query while the target user has an existing private conversation active with the creator.
First, it helps to understand that a query is essentially a text-only client. Like a normal client, your query can only be present in a single channel (and by extension, a single channel's chat) at a time.
This is a limitation of the ServerQuery interface as provided by TeamSpeak, and thus something we cannot fix.
The Event is fired after the user already left the server. Since getClientInfo() only works with online clients you cannot use this command with the ID anymore. Unfortunately for us, the ClientLeaveEvent only responds with the client's ID, which is volatile and thus cannot be used to grab information about the client that has left anymore. You would need to store client ID -> DBID/UID mappings in a map to still identify the client.
The invoker is the person causing the event to be triggered, while the client is the person being affected by the event. In the example of a ClientLeaveEvent triggered by kicking a client, the person being affected (the client) is the person leaving while the person causing the event (the invoker) is the person kicking the victim. If someone left of their own volition, they are still the client; there is just no invoker.
The major known reason behind this is that your query login credentials were creating using a client identity of yours that is currently connected to the same server as the query program. Since "you" and the query share the same Unique Identity, the client attempts to send messages to another client before attempting to send messages to a query. As such, responses to query messages will be sent to your client instead. For a more in-depth answer (and steps to fix,) see this Issue response.
Why does ClientLeaveEvent only provide getClientId(), but not getClientUniqueId() or getClientNickname()?
The TeamSpeak Query service sends very little information with its events. When a ClientLeaveEvent is fired, the only information sent to us is the standard for most events (client and invoker information) as well as the reason for leaving. However, since the client no longer has an active connection, very little can be learned by using their ClientId since it no longer exists. As the client's UniqueID and Nickname are normally only found by using the ClientId, this information is now unavailable.
The most common work-around to this issue appears to be creating a Map<Integer, Client> or similar to cache the connected clients.
When a user starts up their TS3 client for the first time, they are given a default identity. That identity contains the "TeamSpeak Unique ID," also known as the "TS3UID," the "Unique ID," or just the "UID." Each UID is paired with that identity profile permanently, and follows that identity to any server it connects to. A UID is 28 digits long, can contain alphanumeric characters and symbols (excluding ';', ''', '"', '-', and ' ') and always ends with an equals ('=') sign. Exceptions to this rule include the "serveradmin" account, which always uses the special UID serveradmin, and anonymous query connections, which always use the special UID ServerQuery.
When a user connects to a server for the first time, they are assigned a Database ID (also known as a "DBID.") This integer is used within the server's database to store information that is persistent across that client's connections to the server (such as groups, avatars, bans, etc.) A user's DBID is unique only at the server level; a user connecting to multiple servers will have the same UID across all servers, but each server will have a different DBID for that user.
Finally, the client ID is utilized by the server to identify active connections to the server. This ID cannot be used to identify users when they are offline, and cannot be considered unique to a user (or a user unique to it.). It's also the only information about a leaving client in ClientLeaveEvent, see here for more information.