Skip to content

Teamspeak Commands

Jump to bottom
Firedroide edited this page Sep 8, 2013 · 6 revisions

‌Index

  1. Introduction
  2. The permissions.yml file
  3. ServerGroup layout
  4. Incompatible plugins

‌Introduction

Teamspeak commands allow you to run a command on your Minecraft server remotely from the TeamSpeak server.

To use this feature, you'll need to enable Teamspeak commands in your configuration file first!

Running a command from TeamSpeak

To tell BukkitSpeak that you want to run a command and not just send a regular chat message, you'll need to prefix your command. Because / is reserved for commands of the TeamSpeak client itself, you'll need to choose a different prefix, which can be longer than one character. By default it's just an exclamation mark, so your command would look like !command argument1 argument2 ....

You can send your command by typing

  • in the leftmost tab for server broadcasts
  • in the middle tab for (channel) chat messages, as long as you're in the channel BukkitSpeak is listening to.
  • in the rightmost tab for private messages, as long as you're in a conversation with BukkitSpeak's ServerQuery.

However...
When you run a command by sending via server or channel chat, this message will still appear for everyone on TeamSpeak but not for the players on the Minecraft server. Unfortunately there's no way to cancel these messages implemented in TeamSpeak.
So you should - when possible - send your commands as private messages to the ServerQuery.

The command you've just typed in will then be sent to the Minecraft server and - after checking permissions and everything - be executed. Usually the plugin owning the command will then send a message back, like for example Teleporting player X to player Y.

BukkitSpeak will actually wait for a configurable period of time (50 ms by default) for these responses to queue up and then send all of them back to TeamSpeak in one go. This way there's not as much network traffic and the responses will actually arrive faster.

‌The permissions.yml file

After enabling Teamspeak commands, there will be a new file created in the BukkitSpeak folder called permissions.yml.
This file will already contain entries for every (server) permissions group currently set up for regular clients on your TeamSpeak 3 server.

Work with backups

As BukkitSpeak will always add new server groups to the file, update the names of your server groups and mark old ones as unused, the file will be overriden quite often.

This means that all the comments and unreadable YAML tags will be removed.
Therefore, you should always work with a backup in case something goes wrong.

‌ServerGroup layout

Every ServerGroup in permissions.yml has this basic layout:

'id':
  name: ServerGroup name
  op: true / false
  permissions:
    someplugin.somenode.somepermission: true / false
    something:
      else:
        thisworkstoo: true / false
  plugin-whitelist:
  \- List
  \- Of
  \- Plugins
  command-blacklist:
  \- List
  \- Of
  \- Blocked
  \- Commands
  inherits: ['12345', 'id']
  blocked: true / false

To actually be able to execute a command from TeamSpeak, you have to meet 4 criteria:

  • You need to have the permissions required to run the command just like on the Minecraft server
  • The plugin owning the command must be whitelisted
  • The command you're trying to run mustn't be on the blacklist
  • The ServerGroup of the client executing the command cannot be blocked
‌ID

Every ServerGroup in the permissions file starts with an ID, like '18256':. This is the ID of the ServerGroup on the Teamspeak server, which will won't change even when you change the name of the ServerGroup.

You should not change this ID to something different or BukkitSpeak will not recognize it as the ServerGroup it's looking for anymore and create a new section for the group.

‌Name

This field is purely for user information.

It allows you to recognize a ServerGroup without having to look up the ID on Teamspeak every time you're editing the permissions file.

Changes to this field won't do anything and will be reverted to the current name of the ServerGroup when the permissions file is loaded, i.e. on a server start / reload and when the Reload command is used.

‌OP

This field lets you chose whether a ServerGroup should execute commands on the Minecraft server like an operator or not.

Seriously, don't foolishly give out operator permissions to everyone, even be cautious with TS Server Admins; accidentally adding someone to the Server Admin group is only one context menu away.

‌Permissions

When executing a command from Teamspeak, you'll get the same default permissions assigned like someone on the Minecraft server, e.g. bukkit.command.tell or bukkit.command.me.

Plugins can also have these default permissions. For example, BukkitSpeak's permission bukkitspeak.commands.help is given out to everyone.

With the permissions section, you can assign more permissions to the clients in the ServerGroup. The syntax is similar to PermissionsBukkit's one, so in the way of somePlugin.someNode: true.

The only difference is that BukkitSpeak also allows you to split those permissions at the position of the dots in the permission, so you can write either

somePlugin.someNode.somePermission: true
somePlugin.someNode.someOtherPermission: true

or

somePlugin:
  someNode:
    somePermission: true
    someOtherPermission: true

This should let you organize your permissions much better and help keep the permissions file clean.

To be more specific, permissions: is a ConfigurationSection, the values of this section can be either Boolean values or other ConfigurationSections, which again contain other Boolean values or ConfigurationSections.

‌Plugin whitelist

You'll also need to whitelist all plugins you want the clients on Teamspeak to have access to.

The plugin whitelist is a list of Strings, so in YAML it looks like plugin-whitelist: [Plugin1, Plugin2] or like

plugin-whitelist:
\- Plugin1
\- Plugin2

It is important that you use the name of the plugin used in /plugins and that the names are actually spelled correctly.
Bukkit commands are not affected by the whitelist and can be executed anyways.

The reason for there being a whitelist is that there are plugins that give out OP permissions to everyone who's not a player and thus also treat everyone on Teamspeak like an operator.

‌Command blacklist

Similar to the plugin whitelist, you can disallow the usage of certain commands.
When blocking a command, all aliases of that command will be blocked, too.

This field is also a list in YAML, just like the plugin-whitelist.

‌Inheritances

Using the inherits: field, you can actually inherit the permissions, plugin whitelist and the command blacklist of one or more other ServerGroups, so you don't have to retype everything.

To inherit from a ServerGroup, just put its ID with the apostrophe in the inherits list.

‌Blocked ServerGroups

This field lets you block a certain ServerGroup completely, so it won't be able to run any commands from TeamSpeak.

This feature is mostly designed for larger TS servers, where a large number of commands flooding in from Teamspeak could potentially lag out the server.

‌Incompatible plugins

Some plugins aren't able to work properly with commands from TeamSpeak, mostly due to bad programming.
I'm trying to create a list of plugins that seem to be incompatible.

If you have trouble with a certain plugin, just tell me about it and I'll add it to this list.

Essentials

Essentials assumes that everything that is not a player must automatically be a console and thus grants it every possible permission.

You really shouldn't whitelist Essentials, because everyone could just run /give Player diamond 9999 from Teamspeak.

What is more, Essentials tends to override as many commands as it can, so when you're running /list from plugin X, you will first run the Essentials command and Essentials then redirects the command to plugin X. Head > Desk

The only way to stop Essentials from overriding those commands is by disabling those Essentials commands in the configuration of Essentials.

Plugins that dynamically register commands / aliases

There are some plugins that don't register their commands properly, but instead listen to every command on this server and check every event if the executed command matches its commands' / aliases' names.

Yes, those plugin actually exist...

The problem is that BukkitSpeak needs to know the plugin owning the command and thus requires a normal command registration.

Known plugins
  • MChat, MSocial, MAdvanced. mChatSuite-plugins

Back to the top

Clone this wiki locally