Explanation:
Both TAB and ViaVersion PlayerJoinEvent priority are LOWEST and seems that TAB registers earlier than ViaVersion the listeners, this causes TAB not being able to get the client protocol version due to ViaVersion not being able to register it firstly.
There might be another way to workaround this since i don't know changing the priority would cause any issue with TAB itself.
When BungeeTabPlayer#isVanished uses PV's API, PV needs to actually be enabled, not just loaded. A soft-dependency should ensure that PV is fully enabled before TAB's onEnable() uses the API.
description:Current version of the text (if modifying), ignore in case of new section.
placeholder:|
Installation on Bukkit/Spigot/Paper is as simple as it can be. Just put the plugin into plugins folder and restart the server. You can also run `/plugman load tab` to load the plugin while server is running.
validations:
required:false
- type:textarea
attributes:
label:New text
description:What the text should be changed to / how should new section look
placeholder:|
Put the plugin into plugins folder and restart the server. In case you don't want to restart your server, loading with plugins like PlugMan is supported.
This is a backup of the wiki in case anything happened to the repository, so the wiki will not get lost forever.
The "Clone this wiki locally" option on GitHub wiki does not actually work (the downloaded file is malformed) and cannot be used to import data from the file (?).
Since GitHub wiki does not support reading the wiki from source code, every change
to the wiki must be copied here as well. The wiki is being updated on an almost daily basis for many reasons, including, but not limited to
updating compatibility page (especially when new MC versions come out), adding more examples, improving descriptions, fixing mistakes or
adding information that was previously missing. This synchronization will be done periodically once a month.
# Hyperlinks
All hyperlinks used inside the wiki link to other wiki pages using full URLs. As a result, they will all be broken when browsing here.
For TAB to properly detect player as a bedrock player, floodgate and TAB must be installed on the same server instance and if TAB is on bukkit and floodgate is on both bungeecord and bukkit, make sure [they are connected](https://geysermc.org/wiki/floodgate/setup/?platform=proxy-servers).
To make sure floodgate is configured correctly you have 2 options:
* Set `debug: true` in TAB config and check console output on join/reload. It should say `Floodgate returned bedrock status TRUE for player <player>`.
* Run `/tab parse <player> %bedrock%`. It should return `true`.
If any of them say `false` for an actual bedrock player, you didn't connect floodgate correctly.
## Differences
It is job of plugin allowing bedrock clients to connect (probably Geyser) to correctly translate all packets. If you are experiencing an issue on bedrock but not java, it is most likely not an issue in TAB code.
Currently, TAB does check for bedrock clients for:
* Displaying scoreboard numbers as 1-15 instead of all 0 even if it's set to all 0, because lines would not be ordered correctly.
* Disabling [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) for bedrock players.
* Disabling [Playerlist objective](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Playerlist-Objective) for bedrock players due to many issues with the feature on bedrock.
These are the only 3 known changes that are required on TAB side.
## Issues with `.` in name
If you configured Geyser to prefix bedrock player names with `.`, it will mess up config loading, because `.` is used to split section path. This means that using `/tab player <playername containing .> ...` will not work.
There are 3 solutions available:
* Use player UUID if commands are executed via another plugin (`/tab player <uuid> ...`).
* Use `playeruuid` type, which accepts player name and saves the online player's UUID (`/tab playeruuid <player name> ...`).
* Use a different username prefix than `.`.
# Vanish detection
Although TAB does not manage player vanishing in any way, it checks for vanish status for features to be properly compatible. At the moment, vanishing detection is used for:
*`%vanished%` placeholder (used for internal functionality, but can be used to display vanish status if one wants to)
*`%online%`, `%serveronline%`, `%worldonline%` and `%staffonline%` will not count vanished players
* [Global playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist) makes vanish plugins unable to remove players on other servers from tablist, vanish check will make TAB remove vanished players.
* Hide vanished players from [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout).
* Unregister teams of vanished players to players who cannot see them to prevent third party client exploits from seeing vanished players.
Permission `tab.seevanished` allows players to:
* See vanished players in [Global playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist).
* See vanished players in [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout).
* Not have teams of vanished players unregistered, which would make them not appear sorted properly and have no nametag prefix/suffix.
For a player to be detected, player has to have `vanished` metadata flag set to `true`. Most, if not all vanish plugins do this, including, but not limited to CMI, Essentials, SuperVanish, PremiumVanish and probably more. If TAB is installed on BungeeCord, [Bridge](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) must be installed on backend servers to forward vanish status to the proxy.
Additionally, if PremiumVanish is installed and player's vanish status changes, it is asked if the vanished player can be seen by each player. Players who are marked as being able to see that vanished player by PV do not require `tab.seevaninished` permission.
# Async player loading
In order to not slow down the server, TAB loads players asynchronously on join. As a casual user this does not impact you, but there are some cases where you'll feel it:
* Players will not be accessible in the [API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) during PlayerJoinEvent
* [TAB's PlaceholderAPI expansion](https://github.com/NEZNAMY/TAB/wiki/Placeholders#placeholderapi) will not be accessible during join process, such as when trying to use it in plugins editing join messages (the exception is `replace_` placeholder, which doesn't directly use any TAB code).
# Scoreboard objective and team naming
There's a well known BungeeCord bug that kicks players if a duplicate team or objective is registered. This message also shows the name of the objective/team. Before reporting this, make sure it actually comes from TAB.
TAB's objective and team naming:
* Objectives ("Objective ... already exists in this scoreboard")
*`TAB-BelowName` for [Belowname](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Belowname)
*`TAB-Scoreboard` for [Scoreboard](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Scoreboard)
*`TAB-PlayerList` for [Playerlist objective](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Playerlist-Objective)
* Teams ("Team ... already exists in this scoreboard")
* For sidebar scoreboard: `TAB-SB-TM-x` where `x` is a number from 1 to 15+ (for each line)
* For players: This is more complicated to use the 16 character limit to the max and heavily depends on configuration. If you are sorting by player names, part of player name will be there. It also often contains random non-alphanumeric symbols. The most reliable way is the team name (almost) always ending with `A` (or `B`, `C` etc if you tried to sort several players into the same slot).
# Per-version experience
Minecraft has changed over the years - it had some limits removed, some added, some bugs fixed, but also some bugs added. TAB adapts code based on player's version for best possible experience on each minecraft version.
## Detection
When TAB is installed on a proxy, the proxy's API is used to get player version.
When TAB is installed on a backend server, ViaVersion's API is used to get player's version (as it's the only plugin allowing multiple versions, ProtocolSupport is abandoned).
You can check what version the plugin thinks player has using any of the following:
*`/tab parse <player> %player-version%` - Returns version name, if multiple versions share the same protocol, the newer one is returned
*`/tab parse <player> %player-version-id%` - Returns network id of player's version
* Set `debug: true` in config and check console messages on player join, it will send a message containing game version ViaVersion API has returned
Player game version detection may fail. Here are a few possible scenarios why:
* ViaVersion is installed on BungeeCord
* And TAB on BungeeCord as well - ViaVersion makes BungeeCord API return version of the backend server player is connected to instead of player's actual version
* And TAB is on backend servers - There is no ViaVersion to hook into, therefore there is no suspicion of player not using server's version and not having a way to verify it
* ViaVersion API returns `-1` - There is currently no known cause when or why this happens. However, when this happens, TAB prints a console warn notifying this has happened. Plugin will assume player is using same version as the server in such cases.
When game version is not detected correctly, player's experience will be very limited, see below.
## Differences
To ensure the best possible experience, TAB is currently checking for player's version to:
* Disable for 1.7 and lower due to massive tablist differences and plugin not being adapted to those
* Use alternate method of sorting the entries for 1.19.3+ using entry names, as the previous, better option was removed
* Use RGB color codes for 1.16+ and use closest (or forced) legacy color for 1.15-
* Use 1.9+ bossbar on 1.8 servers for 1.9+ players using ViaVersion API
* Disable [Tablist name formatting](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Tablist-name-formatting) for 1.7 and lower due to a 16 character limit total to take advantage of the mechanic where nametags are displayed in tablist, which extends the limit to up to 48 characters (16 prefix, 16 name, 16 suffix)
* Play around <1.13 limitations of [Scoreboard](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Scoreboard)
* Cutting nametag prefix/suffix to 16 characters for <1.13, but keeping it full for 1.13+
When version detection fails, plugin's workarounds will be wrong and cause problems, such as:
* Nametag prefix/suffix being cut to 16 characters, even for 1.13+ clients
* Scoreboard lines limited to ~26 characters, even for 1.13+ clients
* Scoreboard lines limited to 14 characters for < 1.13 clients
* Scoreboard lines might be out of order
* RGB colors displaying as legacy colors for 1.16+ clients
* Layout being out of order for 1.19.3+ clients
# Debug config option
You may have noticed `debug: false` in your config. Enabling it will unlock extra console messages beyond the usual miconfiguration / errors. They give a deeper information about what's going on in the plugin in case a more complex issue comes up. Currently, it offers the following:
* Prints thrown errors into console as well, instead of just errors.log file. They are printed into the console even if error log reaches 1MB limit.
* Sends a message how long each feature + total it took to process player join/quit or plugin reload. High values may suggest something is not optimized correctly. Originally added for myself when optimizing, but adding/removing it each time would be too much of a hassle, so it remains as a debug message.
* Sends a message when plugin detects player name change by a nick plugin. Since lots of things are bound to player names, having players change their name and plugin not detecting it would result in plugin not working correctly them. Therefore, every time a player changes nickname (or resets it), a message should pop up.
* Sends message whenever another plugin sends a scoreboard (such as a minigame plugin) and TAB hides it own. Then, when that other plugin removes its scoreboard, TAB sends its own back (and sends a console message).
* Sends a message regarding bedrock client status of players who join in using Floodgate API. This includes a message if floodgate is not enabled correctly (API instance is null), as well as true/false bedrock status of players.
* Shows network id of protocol version of players who join when ViaVersion is installed. It should show the version players are actually using. If not, plugin may not work correctly for those players. This is usually caused by having ViaVersion on proxy and backend.
* Sends a message whenever a placeholder takes more than 50 milliseconds to retrieve value. If it only happens once, it may be a random hiccup and can be ignored. In case of consistent problems, this may cause plugin overload.
* Sends a message if plugin attempted to send packet to a player who left already. On bungeecord 1.20.2+ this causes an error if not checked. This is completely the plugin's fault if it happens, but it cannot be shown to everyone, since it would require steps to reproduce and most users are not going to cooperate, resulting in stalling issues.
* On BungeeCord, shows how long did Bridge take to answer player join plugin message. This should be below 100ms. If it's continuously significantly higher, it means bridge is overloaded with the most likely cause being an inefficient placeholder.
Animations can be created in **animations.yml** file.
To begin, you can copy an already existing animation or directly modify already existing one.
Let's take a look at an example:
```animations:
Welcome: #this is name of the animation
change-interval: 400 #this is refresh interval of the animation in milliseconds
texts: #the frames of animation
- "&7&lW_"
- "&7&lW_"
- "&7&lWe_"
- "&7&lWel_"
- "&7&lWelc_"
- "&7&lWelco_"
- "&7&lWelcom_"
- "&7&lWelcome_"
- "&7&lWelcome_"
- "&7&lWelcome_"
- "&7&lWelcome_"
- "&7&lWelcom_"
- "&7&lWelco_"
- "&7&lWelc_"
- "&7&lWel_"
- "&7&lWe_"
- "&7&lW_"
- "&7&lW_"
```
This is an animation called `Welcome` with `change-interval` of `400` milliseconds, which is 2.5 refreshes per second. `Texts` are the actual frames of animation.
# Using an animation
To use an animation, use `%animation:<name>%` format. In the example above it's `%animation:Welcome%`. Animations are supported everywhere. That includes header/footer, prefix/suffix, belowname, yellow number, bossbar and more.
# Tips & Tricks
* Animations don't need to be fast. You can use them as a changing text in general.
* Animations can also be used as a short alias to a long text. Just create an animation with one frame.
# External tools
If you want an animation that's too complicated to be done manually, you can check out these websites:
* https://www.birdflop.com/resources/animtab/
* https://starve-l.github.io/tab-animation.html
* https://srnyx.com/gradient
# Additional info
## Additional note 1 - Frame synchronization
All animations start at the same time, which is time of plugin being (re)loaded. Thanks to this, all animations with the same amount of frames and same change interval will be synchronized.
If you want to synchronize 2 animations with different change interval and different amount of frames, you need to make sure `frame count`*`change interval` is same for both animations, for example one animation with 10 frames and 1000ms and second animation with 2 frames and 5000ms.
# Examples
## Example 1
Swichtes between green and red in an extra smooth way (could replace the default animation bar for a christmas theme).
Works on 1.16+ only due to RGB/Hex values being used.
* [Nametag format in tablist](#nametag-format-in-tablist)
* [Tablist entry overlap](#tablist-entry-overlap)
* [Tablist entry widths](#tablist-entry-widths)
# About
This is a collection of mechanics related to the plugin explaining how does the minecraft client process information from the server and what you can and what you cannot impact.
# Nametag format in tablist
When disabling [Tablist name formatting](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Tablist-name-formatting), nametag prefix/suffix will be displayed in tablist instead. If you don't want any prefixes in tablist, keep the feature enabled but don't set any prefixes. Disabling this option is only useful to allow other plugins to use the feature or to intentionally display teams in tablist.
# Tablist entry overlap
When having enough online players for 3-4 columns (or using [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout)) and their name formats are too long, they might overlap. This is caused by attempting to display text wider than the monitor can handle.
There isn't really any ideal solution for this. Here are a few tips that might help:
* Decrease GUI scale in client options to make text smaller
* Make tablist entries shorter, such as avoiding using bold text (&l) or using short aliases for ranks instead of their full names (such as `A` instead of `Admin`).
# Tablist entry widths
All tablist entries are rendered with the same width regardless of their content to match width of the longest text. This is done globally, not on a per-column basis. Therefore, one wide entry with make them all render wide, even if the content is empty. This can be a problem when using [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) to force all 80 slots. Just like in the point above, you need to make the longest entry shorter to have the tablist smaller.
This page lists all of the commands and permissions that are available with TAB. Commands have required permissions associated with them.
**BungeeCord / Velocity users:**
* If you have TAB installed **on the proxy**, use **/btab** instead of /tab. Permissions are the same.
* Permission nodes are checked on the server where the plugin is installed (by default). This means that with TAB on BungeeCord, permission nodes are checked on BungeeCord and therefore you'll need a permission plugin there as well. If you wish to take permission groups and checks from backend servers instead, set `use-bukkit-permissions-manager: true` in config.
* **Description:** Removes all direct data from the given player/group.
#### Notes
* The `playeruuid` argument requires the name of an **online player** to remove data from.
## /tab reload
* **Permission:** `tab.reload`
* **Description:** Unloads the plugin, loads configuration files including changes and loads the plugin.
## /tab debug [player]
* **Permission:** `tab.debug`
* **Description:** Shows the server version, plugin version, permission group choice logic, and sorting type. If player argument is filled, shows info about that player:
* On BungeeCord, shows whether player is connected to the backend server with [Bridge](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) plugin or not.
* Sorting value & explanation, useful to see what went wrong if players are not sorted correctly.
* Primary group set using [How to assign players into groups](https://github.com/NEZNAMY/TAB/wiki/How-to-assign-players-into-groups)
* List of all configured properties of players, their values and source.
## /tab group \<group\>
* **Permission:** `tab.groupinfo`
* **Description:** Shows all settings applied to the specified group, both global and per-world / per-server. Handly when plugin is connected to MySQL, where you have no other way to effectively check group settings.
## /tab groups
* **Permission:** `tab.grouplist`
* **Description:** Shows list of all groups that have anything assigned to them, either globally or per-world / per-server. Handy when plugin is connected to MySQL, where you have no other way to effectively check your groups.
# Scoreboard
## /tab scoreboard show \<name\> \[player\]
* **Permission:** `tab.scoreboard.show` for showing to yourself, `tab.scoreboard.show.other` for showing to others.
* **Description:** Shows the scoreboard with the given `name`, either to yourself if no `player` was given, or to the given `player`.
* **Permission:** `tab.bossbar.toggle` for toggling for yourself, `tab.bossbar.toggle.other` for toggling for others.
* **Description:** Shows / hides / toggles bossbar of specified player. If no player was given, command affects the sender.
* **Options:**
*`-s` for silent toggling (no chat message for affected player)
## /tab bossbar announce \<name\> \<duration\>
* **Permission:** `tab.announce.bar`
* **Description:** Shows the bossbar with the given `name` to every player on the server for the given `duration`, in seconds.
# Nametags / Teams
## /tab nametag toggle
* **Permission:** `tab.nametag.toggle`
* **Description:** Toggles nametag visibility on all players for player who ran the command. Running the command again will make nametags visible again.
## /tab setcollision \<player\> \<true|false\>
* **Permission:** `tab.setcollision`
* **Description:** Forces collision rule for specified player, overriding configuration.
# MySQL
## /tab mysql upload
* **Permission:** `tab.mysql.upload`
* **Description:** Uploads all data from users.yml and groups.yml to MySQL. MySQL must be enabled and connected for this command to work.
## /tab mysql download
* **Permission:** `tab.mysql.download`
* **Description:** Downloads all data to users.yml and groups.yml from MySQL. MySQL must be enabled and connected for this command to work.
# Other
## /tab cpu
* **Permission:** `tab.cpu`
* **Description:** Shows approximate CPU usage of the plugin from the last 10 seconds. There are parts which are impossible to be measured, so this shows slighty less than the real value is. The content is self-explanatory. All ways to decrease CPU usage can be found at [Optimizing the plugin](https://github.com/NEZNAMY/TAB/wiki/Optimizing-the-plugin).
## /tab parse \<player\> \<text\>
* **Permission:** `tab.parse`
* **Description:** Replaces all placeholders (both the plugin's internal ones, and those from PlaceholderAPI if it is installed) in the given `text`. Can be used to test if a placeholder works as expected.
# Additional permissions
*`tab.admin` - Allows the player to execute all commands.
*`tab.bypass` - If per-world player list is enabled as well as this permission, it allows the player to see everyone on the server, regardless of what the per-world player list settings allow. For example, if your per-world player list is set up to isolate worlds A and B, players with this permission will see all players from both A and B on their player list, whereas players that don't will only see either players from world A or players from world B, depending on what world they are in.
*`tab.staff` - Allows the player to be counted in the `%staffonline%` placeholder.
*`tab.spectatorbypass` - If enabling bypass permission in [Spectator fix](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Spectator-fix), this is the permission.
*`tab.tabcomplete` - Allows the player to auto-complete the `/tab` command.
* `tab.seevanished` - Allows the player to see other vanished players on the [Global Playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist) and marks the player as able to see vanished players when using [Aligned suffix](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Aligned-Tabsuffix) feature to properly space out suffixes of players based on what the player can and cannot see.
<sup>1</sup> Due to a bug in Sponge 7, it cannot coexist in the same jar with classes compiled with Java higher than 8, which is required by some other platforms. To get the plugin to run on Sponge 7, you will need to do one of the following:
* Compile the plugin yourself and use the jar from `sponge7/build/libs`, which only contains sponge support instead of the universal jar from `jar/build/libs`.
* Unzip the plugin jar, go to `me/neznamy/tab/platforms/` and delete everything except `sponge7`.
<sup>2</sup> Latest only doesn't mean only the latest build will work, it means the plugin was made to be compatible with latest version/build. Since breaking changes don't happen too often, it means a wide range of versions is usually supported. When a breaking change occurs, plugin is updated to support new version, automatically making old versions incompatible. Since proxies support all client versions, there is never a reason to stay outdated, so you can always safely update to new version version/build of your proxy software if plugin requires it.
❗ = NameTags: Anti-override missing, Scoreboard: [compatibility with other plugins](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Scoreboard#compatibility-with-other-plugins) missing.
❌ = Completely missing
# Plugin hooks
In order to enhance user experience, TAB hooks into other plugins for better experience. This set of plugins is different for each platform based on their availability. Some are available on all platforms, some only in a few.
## All platforms
[**Floodgate**](https://github.com/GeyserMC/Floodgate) - For properly detecting bedrock players to adapt features for best possible user experience.
[**LuckPerms**](https://github.com/LuckPerms/LuckPerms) - Detecting permission groups of players for per-group settings.
[**ViaVersion**](https://github.com/ViaVersion/ViaVersion) - For properly detecting player version to adapt features for best possible user experience.
## Bukkit
[**LibsDisguises**](https://github.com/libraryaddict/LibsDisguises) - Detecting disguised players to disable collision to avoid endless push by colliding with own copy created by LibsDisguises.
[**PlaceholderAPI**](https://github.com/PlaceholderAPI/PlaceholderAPI) - Allows users to use its placeholders inside TAB.
[**PremiumVanish**](https://www.spigotmc.org/resources/14404) - Supporting PV's vanish levels instead of using a basic vanish compatibility system.
[**Vault**](https://github.com/milkbowl/Vault) - Detecting permission groups of players for per-group settings.
## BungeeCord
[**PremiumVanish**](https://www.spigotmc.org/resources/14404) - Supporting PV's vanish levels instead of using a basic vanish compatibility system.
[**RedisBungee**](https://github.com/ProxioDev/RedisBungee) - Communicating with other proxies to properly display visuals on players on another proxy.
## Fabric
[**fabric-permissions-api**](https://github.com/lucko/fabric-permissions-api) - Supporting permission nodes instead of OP levels.
## Sponge
*None*
## Velocity
[**PremiumVanish**](https://www.spigotmc.org/resources/14404) - Supporting PV's vanish levels instead of using a basic vanish compatibility system.
[**RedisBungee**](https://github.com/ProxioDev/RedisBungee) - Communicating with other proxies to properly display visuals on players on another proxy.
# Compatibility issues
* **Glow plugins** will fail to apply glow color correctly. Check [How to make the plugin compatible with glow plugins](https://github.com/NEZNAMY/TAB/wiki/How-to-make-TAB-compatible-with-glow-plugins) for more information.
* **[Tablisknu](https://forums.skunity.com/resources/tablisknu.727/)** (skript addon) prevents TAB from assigning teams (sorting & nametags).
* **SkBee** (skript addon) sends empty scoreboard, causing TAB's to not show sometimes.
* **Waterfall**'s `disable_tab_list_rewrite: true`**may** cause tablist to use offline UUIDs while TAB expects online uuids, causing various problems (most notably tablist formatting not working). Checking for this option is not an option either, because tablist rewrite might still be enabled despite being disabled (don't ask how, I have no idea). Set the option to `false` if you are experiencing issues.
* **ViaVersion on BungeeCord and TAB on backend** acts like a client-sided protocol hack, making it impossible for TAB to know player's real version and causing issues related to it, see [Per-version experience](https://github.com/NEZNAMY/TAB/wiki/Additional-information#per-version-experience) for more info. Just avoid this combination - either install ViaVersion on all backend servers instead or install TAB on BungeeCord instead.
* **Custom clients / resource packs** - Unofficially modified minecraft clients often tend to break things. Just Lunar client has 3 bugs that can be reproduced with TAB. Resource packs may also contain modifications you are not aware of, making things not look the way you want them to. If you are experiencing any visual issue and are using a custom client or resource pack, try it with clean vanilla client. If it works there, it's an issue with the client / resource pack and TAB cannot do anything about it. Here are a few bugs in LunarClient / FeatherClient that you may run into when using TAB:
* They add their icon to players in tablist, but don't widen the entries. This results in player names overlapping with latency bar. You can avoid this by configuring some spaces in tabsuffix.
* They don't support color field in chat components, which means they don't support RGB codes and will display bossbar without colors as well.
* Bossbar is not visible on 1.8.
* Rendering belowname 3 times.
* They don't respect nametag visibility rule, showing own nametag using F5 even if set to invisible by the plugin.
* When scoreboard is set to use all 0s, lines are rendered in opposite order on 1.20.3+.
* They don't display 1.20.3+ NumberFormat feature in scoreboard objectives.
* **Random Spigot/BungeeCord forks** - All safe patches for improving security & performance are present in well-known public opensource projects, such as Paper, Purpur or Waterfall. Using a random overpriced closed-source (and probably obfuscated) fork from BuiltByBit may not be safe, since they likely include unsafe patches that may break compatibility with plugins in an attempt to fix things that are not broken. Before spending your entire budget on such fork, reconsider it first. Paper (and its forks) is a performance-oriented fork used by 2/3 of all MC servers worldwide, while the rest is still stuck on Spigot. It is highly unlikely your needs are so specific you need every single "improvement" anyone can come up with. If you need a feature, Purpur is a feature-oriented fork. Together with plugins you should achieve what you are looking for.
**WARNING: DO NOT SHADE THE API IN TO YOUR JAR! DO NOT RELOCATE THE API FROM ITS ORIGINAL PACKAGE!**
If you relocate, the API that you are calling will also get relocated in your code, meaning that you will be trying to call the relocated API. If you shade the API in, your code could load that bundled API, causing class path conflicts.
Ensure that you are using **`<scope>provided</scope>` for Maven**, or **`compileOnly` for Gradle**.
# Getting started
First of all, you need to get an instance of the API. You can do this with `TabAPI.getInstance()`.
The `TabAPI` class that you want to import is located in the `me.neznamy.tab.api` package. If you do not see this imported, or it is imported but the package is not `me.neznamy.tab.api`, then you have the **wrong class**.
Now you have the instance, you can get a `TabPlayer` with the methods `getPlayer(UUID)` and `getPlayer(String)`, to get players by UUID and name respectively.
If no player was found with the UUID or the name that you gave, these methods will return `null`. It is important that you catch this, to avoid running in to a `NullPointerException`. You should **NOT** assume that just because a player has logged in that TAB will already have a player for them, as players are processed asynchronously. This will be especially true for join events like `PlayerJoinEvent`.
If you want to be 100% sure that the player you want is loaded when you want to process them, use `PlayerLoadEvent`. This will give you the `TabPlayer` that has been loaded, so that you can process that `TabPlayer`. See below for more details how to use the event.
# Lifespan of API calls
All API calls result in temporary changes to the plugin's logic. When the plugin is reloaded or server restarted, all previous API calls will lose effect. This also applies for players after they reconnect - they are reset back. If you want to perform long-term changes to player's prefix or suffix, call TAB's [commands](https://github.com/NEZNAMY/TAB/wiki/Commands-&-Permissions) from your plugin.
If you want to re-apply your changes on plugin reload, listen to [events](#events) using plugin's own event system, specifically `TabLoadEvent`, which is called on plugin reload.
# Events
TAB is using a custom platform-independent event API. As such, the same event listener code will work on all supported platforms. Usage is also different, let's take a look at an example:
TAB logs various events in up to 3 files to keep the console clean. All of these notifications are negative, so they should be looked at.
Files are only created when something is about to get logged. This means if you have none of these files in your folder, everything is good. Also, it is safe to delete the logs any time while server is running without needing to reload the plugin or anything.
All files have their sizes limited to 1MB to avoid giant files consisting of the same error repeating over and over. Don't forget these files are **logs**, therefore, after solving the problems you must delete them. These files will not delete themselves.
After deleting a file, there is no need to perform any other action. Every time an error is about to be logged, file is created if it doesn't exist.
Java errors usually contain stack traces. If you got an error spamming with exception message but no stack trace, the most common cause is java not including it because too many errors were thrown already. To bypass this check, add `-XX:-OmitStackTraceInFastThrow` to your startup parameters.
# errors.log
No one likes having their console spammed with errors. Fixing errors is the most reliable solution, however that takes time and you usually don't get an update fixing an error the second you report it. Because of that, all plugin errors are moved to this file instead.
# placeholder-errors.log
This file is used to track errors thrown by PlaceholderAPI expansions when trying to retrieve value of a placeholder. These should be reported to the expansion author. First line(s) of error should give you a good idea which expansion it is, as well as the actual placeholder which threw the error (displayed on top of the error).
# anti-override.log
This file logs all attempts of other plugins to override TAB's visuals. This is checking for features that only 1 plugin can be displaying info in at once (such as nametag prefix/suffix, tablist prefix/suffix). This means that (at least) one of your plugins is not configured correctly and you didn't disable functions you don't want. If you want TAB to use a feature, disable it in other plugins. If you want a different plugin to display it, disable it in TAB (disabled features do not log this).
It is unfortunately not possible to easily figure out which plugin is causing it, you can only guess from the message.
Although this is technically unnecessary since TAB automatically blocks other plugins from overriding it, it's good to have your plugins configured properly. This might come in handy when moving TAB from bukkit to bungeecord where anti-override does not work too well due to missing functions in bungeecord, so you won't suddenly experience half of the features to not work when moving to bungeecord.
* [Additional note 2 - Hidden on sneak on 1.8](#additional-note-2---hidden-on-sneak-on-18)
* [Tips & Tricks](#tips--tricks)
* [Tip 1 - Heart symbol](#tip-1---heart-symbol)
* [Tip 2 - Displaying health as 0-10 or in %](#tip-2---displaying-health-as-0-10-or-in-)
* [Limitations](#limitations)
# About
The scoreboard objective with BELOW_NAME display slot that adds another line of text below nametag of players. It is only visible on players within 8 block range. This value is client sided and cannot be changed by the plugin.
This line automatically appears on all player entities when enabled. **Therefore, it is not possible to only display it on some players or not display it on NPCs**.
The feature can be configured in **config.yml** under **belowname-objective** section.
The feature's properties are displayed as `[score]` + space + `text`, where `[score]` is:
*`number` for 1.20.2- (will show `0` on NPCs)
*`fancy-display-players` for 1.20.3+ (will show `fancy-display-default` on NPCs)
| number | %health% | [1.20.2-] An integer from -2147483648 to 2147483647, doesn't support decimal values. The number is always white. Supports placeholders with player-specific output, such as player health. Only visible on 1.20.2 and lower. <br/> **Note**: Even if you only support 1.20.3+, you still need to configure this value to properly evaluate to a number, because the value is still sent to the client (just not displayed). You can set it to `0` for simiplicity. |
| fancy-display-players | &c%health% | [1.20.3+] Any text, supports placeholders with per-player output. Only visible on 1.20.3+. |
| fancy-display-default | NPC | [1.20.3+] Default display for all player entities. Plugin uses the value above for every real player, therefore this default value will only appear on player entities which are not actual players, a.k.a. NPCs. Only visible on 1.20.3+. |
| text | Health | Text displayed after number. It is formally called scoreboard title, which is displayed on all player entities and value is shared on all players and therefore not bound to specific players, which makes it unable to display the value per-player. It should only contain static text or placeholders which return same value for all players. All inserted placeholders are parsed for the player viewing the text. This is intentional to allow advanced configuration with conditions for per-world values for example. |
| disable-condition | %world%=disabledworld | A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met for disabling the feature for players. Set to empty for not disabling the feature ever. |
The minecraft feature is programmed to be affected by nametag visibility rule. This means that when nametag is set to invisible, belowname will be invisible as well.
## Additional note 2 - Hidden on sneak on 1.8
Belowname is not visible on 1.8.x clients when player is sneaking. This is client-sided behavior and cannot be changed by the server.
# Tips & Tricks
## Tip 1 - Heart symbol
If you want to show health of players and display a heart symbol as text, you can use this one: `❤`. Make sure you [save config in UTF-8 encoding](https://github.com/NEZNAMY/TAB/wiki/How-to-save-the-config-in-UTF8-encoding) so it's loaded correctly.
```
belowname-objective:
text: "&4❤"
```
## Tip 2 - Displaying health as 0-10 or in %
If you want health to display health as 0-10 instead of 0-20, you can achieve it with PlaceholderAPI:
*`%math_0_{player_health}/2%` for 0-10
*`%math_0_{player_health}*5%` for 0-100
# Limitations
* The format is a **[score] + space + shared text**, where [score] is either a white number (1.20.2-) or any text (1.20.3+).
* The text is same on all players, therefore cannot be personalized (such as player's faction). Only the [score] can be per-player.
* It appears on all entites of player type. **This includes player NPCs.**
* Text length is limited to 32 characters on <1.13
Bars with text on top of the screen originally designed to display health of ender dragon & wither, but plugins found another use for it. In 1.9 mojang added a packet dedicated to displaying text without requiring an entity and allowing customizable color and style as well.
This feature can be configured in **config.yml** under **bossbar** section.
# Configuration
## Defining bossbars
```
bossbar:
bars:
MyBossbar:
style: "PROGRESS"
color: "%animation:barcolors%"
progress: "100"
text: "&fWebsite: &bwww.domain.com"
```
Every bossbar line has 4 properties:
### style
Type of bossbar division. Only visible on 1.9+ clients.
You can choose from 5 styles: **PROGRESS**, **NOTCHED_6**, **NOTCHED_10**, **NOTCHED_12** and **NOTCHED_20**
If you want to show the progress of a placeholder's value relative to a maximum one, you can use the [Math Expansion](https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders#math) from PlaceholderAPI and use a placeholder like this one: `%math_{placeholder_current_value}/{placeholder_max_value}*100%` or `%math_{placeholder_current_value}/<max_value>*100%` if your max value is fixed.
Notes:
Replace the text in between the `{}` with the actual placeholder you want to use and `<max_value>` with a valid number (i.e. 20).
You cannot use the `%placeholder%` format inside the math placeholder.
Example for showing a player's health: `%math_{player_health}/20*100%` or `%math_{player_health}/{player_max_health}*100%`
### text
Text of the bossbar. Length is not limited, supports RGB codes on 1.16+. Does not support newlines.
### announcement-bar
When set to true, the bossbar will not appear by default, only when used in announce command.
```
bossbar:
bars:
MyBossbar:
style: "PROGRESS"
color: "BLUE"
progress: "100"
text: "Text"
announcement-bar: true #false or undefined means it will be visible all the time
```
### display-condition
[Condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met for player to see the bossbar. Even when using announce command on a bossbar with display condition, players must meet it to see the bossbar. When condition is not defined, bossbar has no requirement to be displayed.
**Example**:
```
bossbar:
bars:
MyBossbar:
style: "PROGRESS"
color: "BLUE"
progress: "100"
text: "This bossbar is only visible in world 'world'"
display-condition: "%world%=world"
```
## Announce command
`/tab bossbar announce <name> <time>`
`name` is name of bossbar defined in config.yml under **bossbar** section, `time` is length of display time in seconds.
When using a bossbar announcement, you have a new placeholder available: `%countdown%` that shows remaining time of the announce in seconds. You can further use this placeholder in progress for example, using Math expansion from PlaceholderAPI, such as `%math_{tab_placeholder_countdown}/<total time>*100%`.
| toggle-command | /bossbar | A command to toggle bossbar visibility for player running the command. This command requires `tab.bossbar.toggle` permission. <br />**Note:** This command will not appear in command auto-complete, because it's not a real registered command. Registered commands must be defined in plugin jar directly and cannot be dynamic. If you want to solve this, you can try getting a dummy private plugin made which registers that command. |
| remember-toggle-choice | false | When enabled, disabling bossbar using `toggle-command` is remembered between reloads and restarts. |
| hidden-by-default | false | When enabled, bossbar will automatically be hidden until toggle command is used. |
# Limitations
* Does not support newlines. If you want to display more lines, you'll need to create multiple bossbars.
* The bar itself cannot be removed from the server side. However, it can be removed with a resource pack.
## on < 1.9
* **Will not display at all if TAB is installed on bungeecord** (bungeecord is missing entity packets needed to make it work)
* Doesn't offer color and style features.
* Only one line can be displayed at a time.
* You can see the fog if you don't disable particles in options.
* Text length is limited to 64 characters on <1.7
* May not be visible when looking at blocks
# Additional info
## Additional note 1 - Hiding bar itself
If you want to hide the bossbar itself and only show text, this is possible, but not from the plugin's side. You'll need to create a custom resource pack where the bar doesn't show up and only text does. Then, you need to force your players to get the resource pack.
## Additional note 2 - Not hiding on server switch
When under a BungeeCord network and having TAB installed on backend server and switching to another server, the bossbar will not hide. This is because BungeeCord makes it look like a world switch to the client. To avoid this, the only way is to install TAB on BungeeCord and disable bossbar on that server.
# API
*To get started with the API, see [Developer API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) page.*
To access this feature, you'll need to obtain `BossBarManager` instance. Get it using `TabAPI.getInstance().getBossBarManager()`. If this feature is disabled, the method will return `null`.
A boss bar is made up of a few things:
* A name. This is either the name given in the config, if the bar was loaded from the config, or a random UUID string when created with API.
* A title. This is the display message of the boss bar.
* The progress from 0 to 100.
* The color. This determines what color the boss bar will appear when it is shown to clients.
* The style. This determines how many segments, if any, the boss bar will be split in to.
Let's start with methods in `BossBarManager`:
*`BossBarManager#createBossBar(String, float, BarColor, BarStyle` - Creates new bossbar using direct values.
*`BossBarManager#createBossBar(String, String, String, String` - Creates new bossbar. Accepts all of the previous as strings, to allow for placeholders, though the given placeholders must match the requirements (progress will be a number, color and style matching enum names).
*`BossBarManager#getBossBar(String)` - Returns bossbar by name defined in config.
*`BossBarManager#toggleBossBar(TabPlayer, boolean)` - Toggles all bossbars for specified player. The boolean flags whether toggle message defined in messages.yml should be sent to the player or not.
*`BossBarManager#hasBossBarVisible(TabPlayer)` - Returns `true` if player has bossbars visible, `false` if disabled using toggling.
*`BossBarManager#setBossBarVisible(TabPlayer, boolean, boolean)` - Sets bossbar visibility status for specified player to specified value (first boolean). Second boolean determines whether toggle message configured in messages.yml should be sent or not.
*`BossBarManager#sendBossBarTemporarily(TabPlayer, String, int)` - Temporarily sends bossbar to player. String defines name of the bossbar defined in config. Int defines length in milliseconds.
*`BossBarManager#announceBossBar(String, int)` - Sends bossbar with specified name in config to all players for `int` milliseconds.
*`BossBarManager#getAnnouncedBossBars()` - Returns all bossbars, which are currently being announced.
*`BossBarManager#getRegisteredBossBars()` - Returns map of all registered bossbars using configuration or the API.
Methods in `BossBar`:
*`BossBar#getName()` - Returns name of the bossbar defined in config, or randomly generated UUID string when generated using API.
*`BossBar#setTitle(String)` - Sets title. Accepts placeholders, which will be replaced and periodically updated.
*`BossBar#setProgress(String)` - Sets progress. Accepts placeholders, which will be replaced and periodically updated.
*`BossBar#setProgress(float)` - Sets progress.
*`BossBar#setColor(String)` - Sets color. Accepts placeholders, which will be replaced and periodically updated.
*`BossBar#setColor(BarColor)` - Sets color.
*`BossBar#setStyle(String)` - Sets style. Accepts placeholders, which will be replaced and periodically updated.
*`BossBar#setStyle(BarStyle)` - Sets style.
*`BossBar#getTitle()` - Returns raw title.
*`BossBar#getProgress()` - Returns raw progress as string.
*`BossBar#getColor()` - Returns raw color as string.
*`BossBar#getStyle()` - Returns raw style as string.
*`BossBar#addPlayer(TabPlayer)` - Sends the bossbar to specified player.
*`BossBar#removePlayer(TabPlayer)` - Removes the bossbar from specified player.
*`BossBar#getPlayers()` - Returns all players that can currently see this bossbar.
*`BossBar#containsPlayer(TabPlayer)` - Returns `true` if player can see this bossbar, `false` if not.
*`BossBar#isAnnouncementBar()` - Returns `true` if this bossbar is defined as announcement bar in config, `false` if visible permanently.
# 1.8 vs 1.9 bossbar
The way of displaying information in bossbar is completely different on 1.8 and 1.9+. Here you can find out why.
## Background
Server owners have always been looking for ways to display information. Another way they discovered is by spawning a fake ender dragon / wither, making it invisible, giving it custom name and teleporting it near player. This way, however, has several flaws as you can see above. As of 1.9, mojang decided to add a packet purely for displaying text without requiring an entity. They also added options to set color and style of the bossbar.
## Execution by plugins
With introduction of 1.9 bossbar which is much easier to use, plugins have switched over to that method. However, this feature cannot be used for <1.9 clients as the feature did not exist back then. For this reason you can see some bossbar plugins saying "supports 1.9 and higher", as they don't want to mess with entities.
## Execution by TAB
TAB will attempt to display 1.9 bossbar whenever possible, entity otherwise. 1.9+ clients will always see 1.9 bossbar (even on a 1.8 server thanks to viaversion api). <1.9 clients will see an invisible entity. On bungeecord, however, <1.9 clients won't see anything as bungeecord did not implement entity packets required to make it work.
# Tips & Tricks
## Tip 1 - Animated bossbar color
You can animate color of a bossbar using [animations](https://github.com/NEZNAMY/TAB/wiki/Animations).
First, create an animation in **animations.yml**, such as
```
BossColor:
change-interval: 1000
texts:
- "BLUE"
- "YELLOW"
```
Then, use the animation in bossbar configuration
```
bars:
ServerInfo:
style: "PROGRESS"
color: "%animation:BossColor%"
progress: "100"
text: "&fWebsite: &bwww.domain.com"
```
This bossbar will change color every second between blue and yellow colors.
You can do the same with progress, style and text as well.
## Tip 2 - Switching between bossbars with condition
If you want the plugin to switch between bossbars based on a condition, first consider using condition for text itself (or some other property). If this is not an option (you want text, color, style and progress to be different, which would result in 4 conditions), create 2 bars and give them the same condition, except negate it. If your original condition uses `=`, make second condition use `!=`. For number comparisons, negate `<` using `>=` and so on.
* [Example 2 - Conditions in conditions](#example-2---conditions-in-conditions)
# About
Conditions / conditional placeholders allow you to create output which depends on output of other placeholders or permission requirement.
They have 2 main uses in the plugin:
* Display condition which must be met to be able to see something (bossbar, scoreboard, layout)
* Conditional placeholders which return defined outputs in both cases if condition passes or fails
# Condition types
## Number comparations
`>=`: greater than or equal to
Example: `%ping%>=100` will pass if the player's ping is greater than or equal to `100`.
`>`: greater than
Example: `%ping%>100` will pass if the player's ping is greater than `100`.
`<=`: less than or equal to
Example: `%ping%<=100` will pass if the player's ping is less than or equal to `100`.
`<`: less than
Example: `%ping%<100` will pass if the player's ping is less than `100`.
## Text operations
`=`: equal to (must match exactly)
Example: `%world%=world` will pass if player is in world `world`.
`!=`: not equal to (opposite of the above)
Example: `%world%!=world` will pass if player is in any world except `world`.
**Note 1**: For `=` and `!=` you can check for empty output of a placeholder using `%my_placeholder%=` and `%my_placeholder%!=`.
`<-`: contains (left side for full text, right side text to contain)
Example: `%world%<-lobby-` will pass if player is in any world that contains `lobby-` (such as `lobby-1` etc).
`|-`: starts with (left side for full text, right side text to start with)
Example: `%world%|-lobby-` will pass if player is in any world that starts with `lobby-` (such as `lobby-1` etc).
`-|`: ends with (left side for full text, right side text to end with)
Example: `%world%-|nether` will pass if player is in any world that ends with `nether` (such as `world_nether` etc).
**Note 2**: For string operators, text must match placeholder's output exactly, including color codes. If you are using [Placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements), condition must contain the altered output.
To see the exact output of a placeholder including color codes, use `/tab parse <player> <placeholder>`.
## Permission
`permission:<value>`: permission requirement
Example: `permission:my.permission` will pass if player has `my.permission` permission.
# Multiple condition requirements
Each condition has a `conditions` parameter, which a list of conditions. If you define more than 1 condition, you must specify the condition type.
This value can be found under `type` field. Types are:
*`AND` - all sub-conditions must be met for the final condition to pass
*`OR` - at least one sub-condition must be met for the final condition to pass
If you only defined one subcondition, you don't need to define type at all, since it's not used for anything.
# Condition output
If using condition as a placeholder, you can specify output in both cases using `yes` and `no` values. `yes` is used when condition passes, `no` if not. If using condition only as a view requirement, you can leave these values empty / not specify them at all.
# Configuration
Open **config.yml** and find this section:
```
conditions:
health:
conditions:
- '%health%<21'
- '%health%>15'
type: AND
yes: Healthy!
no: Damaged!
```
`health` is name of our condition in this case.
`conditions` is a list of subconditions that must be met for this condition to pass.
`type` defines whether all subconditions must be met or at least one.
`yes` & `no` define output in both cases.
# Usage
You have 2 ways to use conditions.
## Displaying text
First way is to use conditions to display text. Configure outputs in `yes` and `no` values and then use `%condition:<name>%`, which will output text defined in `yes` or `no` depending on if condition is met or not.
<details>
<summary>Example</summary>
```
conditions:
serverName:
conditions:
- "%server%=lobby"
yes: "You are in the lobby"
no: "You are not in lobby"
```
Use with `%condition:serverName%`
</details>
## Display condition of a feature
The second way is to use condition's name in places where a condition is accepted. This includes display conditions for bossbar, scoreboard and layout. In these cases yes/no texts are unused, therefore, they do not need to be defined.
<details>
<summary>Example</summary>
```
conditions:
MyCondition:
conditions:
- "permission:tab.admin"
```
```
scoreboards:
MyScoreboard:
display-condition: MyCondition
```
In this example, scoreboard will only be displayed to players with `tab.admin` permission.
</details>
### Short format
If trying to use a condition on place where it's available (bossbar display condition, scoreboard display condition) where you don't need the yes/no values, you can use a short format instead.
This can be used by simply creating all subconditions and separating them with `;` for `AND` condition type. For `OR` type, use `|`.
<details>
<summary>Example</summary>
Single condition:
```
display-condition: "%server%=lobby"
```
Multiple conditions, all of them must be met:
```
display-condition: "%server%=lobby;%world%=world"
```
Multiple conditions, at least one of them must be met:
Conditions are just placeholders afterall, and, as such, they must be refreshed priodically. Refresh intervals of conditions are not directly configurable. They are based on placeholders used inside (subconditions, yes/no values).
Permission checks count as 1000ms.
To configure refresh intervals of placeholders, check out the [Optimization guide](https://github.com/NEZNAMY/TAB/wiki/Optimizing-the-plugin#2---placeholder-refresh-intervals).
# Examples
## Example 1 - Chaining conditional placeholders
Let's create colored ping by chaining conditions using multiple intervals for ping quality. This specific case would be easier done using [replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements), but this is just an example. Let's say we want <50 for good, <100 for medium and 100+ for bad. Let's create the first condition:
```
conditions:
ping:
conditions:
- "%ping%<50"
true: "&a%ping%"
false: "%condition:ping2%"
```
When ping is <50, display it as green. Otherwise, use another condition. Put them together and we get
```
conditions:
ping:
conditions:
- "%ping%<50"
true: "&a%ping%" # Ping is < 50, display as green
false: "%condition:ping2%" # Ping is 50+, check another condition
ping2:
conditions:
- "%ping%<100"
true: "&e%ping%" # Ping is < 100, display as yellow
false: "&c%ping%" # Ping is 100+, display as red
```
Finally, we can use this ping placeholder using `%condition:ping%`.
This example chained 2 conditions, but more can be used. There is no limit.
# Example 2 - Conditions in conditions
If you want to use a condition in another one, for example to use both AND and OR types, create 2 conditions and use one in the other one.
For example, if we want to check that player is in server `lobby`**and** in worlds **either**`world1` or `world2`, it can be achieved in the following way:
```
conditions:
world:
conditions:
- "%world%=world1"
- "%world%=world2"
type: OR
main:
conditions:
- "%condition:world%=true"
- "%server%=lobby"
type: AND
```
Then, use condition `main` as the display condition. Note that `yes`/`no` values were not defined, as such, they default to `true` and `false`, respectively. Therefore, we use the placeholder from the condition and check if the result is `true`. Then, check if player is also in the specified server.
* [Seeing all players on the network from some server](#seeing-all-players-on-the-network-from-some-server)
* [Compatibility with vanish plugins](#compatibility-with-vanish-plugins)
# About
This feature allows you to see players from other servers under a bungeecord network, instead of only seeing players on the same server.
To use this feature, you need [TAB installed on bungeecord](https://github.com/NEZNAMY/TAB/wiki/Installation#bungeecord). This option is not available on bukkit and will not be added.
| server-groups | *Map* | See [Grouping players only from certain servers](#grouping-players-only-from-certain-servers) |
| spy-servers | *List* | See [Seeing all players on the network from some server](#seeing-all-players-on-the-network-from-some-server) |
| display-others-as-spectators | false | When enabled, players on different servers will appear as having spectator gamemode in tablist. |
| display-vanished-players-as-spectators | true | When enabled, vanished players will show as in spectator gamemode for those, who have permission to see vanished players (tab.seevanished) (others will obviously not see them at all). Vanished players will still see themselves in the gamemode they are actually in, since changing that would cause problems (client would think it's in spectator gamemode while it isn't). |
| isolate-unlisted-servers | false | When enabled, servers not listed in any group will not share playerlist with any other server, instead of sharing it with other unlisted servers. |
## Grouping players only from certain servers
In case you want multiple servers to share playerlist, but not with every server, simply create a server group and put servers there. The default example
```
global-playerlist:
server-groups:
lobbies:
- lobby1
- lobby2
group2:
- server1
- server2
```
contains 2 groups, each of them consisting of 2 servers. Server group name can be anything (in our case they're called "lobbies" and "group2"). Under group name, list the actual server names defined in config.yml of bungeecord.
With this setup, "lobby1" and "lobby2" will share playerlist, as well as "server1" with "server2". All unlisted servers are automatically put into a hidden default group and share playerlist. This means that all other servers except these 4 will share playerlist.
To make all servers share playerlist, simply clear server groups and set
```
server-groups: {}
```
## Configuring isolated servers
If you want servers which are isolated (no one will see these players and they will not see anyone on other servers), simply create a new group and only put that 1 server there. For example:
```
global-playerlist:
server-groups:
test1:
- isolatedServer1
test2:
- isolatedServer2
```
## Seeing all players on the network from some server
If despite configuring server groups you want players to see everyone on the network if they're connected to specific server(s), you can simply list those servers at
```
global-playerlist:
spy-servers:
- spyserver1
- spyserver2
```
Now, players connected to "spyserver1" or "spyserver2" will see everyone on the network in tablist, but no one else (unless on another spy server / in the same server group) will see them.
# Compatibility with vanish plugins
For compatibility with vanish plugins, vanish status must be detected correctly. See [Additional information - Vanish detection](https://github.com/NEZNAMY/TAB/wiki/Additional-information#vanish-detection) for more info.
| disable-condition | %world%=disabledworld | A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met for disabling the feature for players. Set to empty for not disabling the feature ever. |
## Global settings
The example above is using this configuration:
```
header-footer:
header:
- "This is the first line of header"
- "2nd line of header"
footer:
- "This is the first line of footer"
- "2nd line of footer"
```
It is the default header/footer for everyone, unless overridden in some way.
## Per-world / per-server
```
header-footer:
per-world:
<your world>:
header:
- "Header in specified world"
footer:
- "Footer in specified world"
per-server:
<your server>:
header:
- "Header in specified server"
footer:
- "Footer in specified server"
```
For multiple worlds/servers to share the same settings, separate them with `;`.
For worlds/servers starting with a specified text, use `*` after the shared part. For ending with a shared part, use `*` at the beginning.
Example:
```
header-footer:
per-world:
world1;world2:
header:
- "Shared header in worlds world1 and world2"
lobby-*:
header:
- "Header in all worlds starting with lobby-"
```
**Note**: To make per-world work on BungeeCord, install the [TAB-Bridge](https://www.mc-market.org/resources/21641) plugin on your backend servers.
## Per-group / per-player
**groups.yml**
```
MyGroup:
header:
- "This is a header for MyGroup group"
footer:
- "This is a footer for MyGroup group"
per-world:
MyWorld:
TestGroup:
header:
- "Header for group TestGroup in world MyWorld"
```
Same for users, which can be configured in **users.yml**.
# Additional info
## Additional note 1 - Not resetting on server switch
When under a BungeeCord network and having TAB installed on backend server and switching to another server, the header/footer will not reset. This is because BungeeCord makes it look like a world switch to the client. To avoid this, you have 2 options:
* Install TAB on BungeeCord and disable header/footer on the server.
* Install a(nother) plugin that sends some, or even empty header/footer on join.
# Tips & Tricks
## Tip 1 - Dynamic line count
The entire header is just a single character sequence that allows newline symbol (`\n`) for new lines. It is only being split into multiple lines in config for convenience to make it readable when configuring and editing. Same for footer.
If using a placeholder that returns the newline symbol, it will create a new line. You can use this to your advantage and create a [conditional placeholder](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) or an [animation](https://github.com/NEZNAMY/TAB/wiki/Animations) that includes newline in some frames.
<details>
<summary>Example</summary>
**animations.yml**
```
MyAnimation:
change-interval: 1000
texts:
- "First frame with only 1 line"
- "Second frame\nconsisting of 2 lines"
```
**config.yml**
```
header-footer:
header:
- "%animation:MyAnimation%"
```
</details>
# API
*To get started with the API, see [Developer API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) page.*
To access this feature, you'll need to obtain `HeaderFooterManager` instance. Get it using `TabAPI.getInstance().getHeaderFooterManager()`. If this feature is disabled, the method will return `null`.
To set the header and/or footer for a player, use the following:
This feature allows you to customize all 80 tablist slots. Displaying less than 4 columns is currently not supported. This feature can be enabled and configured in **config.yml** file under **layout** section.
This feature is only available for versions **1.8** and up due to massive tablist changes, which would make 1.7- compatibility require a complete rewrite of the functionality and could still cause all kinds of visual issues, including, but not limited to compatibility with other plugins adding/removing players from the tablist.
# Creating a layout
Layouts can be creating in config under `layout.layouts` section. Each layout contains 3 settings: Fixed slots, player groups and display condition (optional).
## Display condition
Condition that must be met for player to see the layout. If player does not meet the condition, next defined layout's condition is checked. If player does not meet any defined display condition, they will see default tablist. Display condition is optional and doesn't need to be set.
For list of possible condition types see [Conditions page](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders).
Example:
```
layouts:
staff:
condition: "permission:tab.staff"
```
This layout will only be visible to players with `tab.staff` permission.
## Fixed slots
These are slots with fixed position that contain configurable text and skin.
They can be configured under `fixed-slots` option of each layout. The definition syntax is `SLOT|TEXT|SKIN`. If you don't want to define custom skin for that slot, use `SLOT|TEXT`.
`SLOT` - the position of the fixed slot. It can be from 1 to 80. By default, the direction is set to columns, so the first column is 1-20.
`TEXT` - the text. It supports placeholders.
`SKIN` - layout's skin, see below for configuration.
Example:
```
layouts:
staff:
fixed-slots:
- '1|&3RAM&f:'
- '2|&b%memory-used%MB / %memory-max%MB'
- '3|&8&m '
- '4|&3TPS&f:'
- '5|&b%tps%'
```
## Player groups
These are groups of players which meet the specified condition. They consist of 2 parts - condition and slots.
**1. Condition**
Condition players must meet to be displayed in the group. If a player doesn't meet condition for group, the next group's condition is checked (groups are checked in the order they are defined in config). If player doesn't meet any codnition, they are not displayed at all. Display condition is not required (can be used for default group).
**2. Slots**
Slot intervals dedicated to the group. Interval `1-5` would mean all slots from 1 to 5. In case you want to define multiple intervals to exclude some slots, define another interval below the first one.
Example:
```
layouts:
myLayout:
groups:
staff:
condition: permission:tab.staff
slots:
- '24-40'
players:
slots:
- '44-80'
```
In this example, slots `24-40` will be reserved for players with `tab.staff` permission. Players without that permission will be in slots `44-80`.
# Managing multiple layouts with conditions
You can define multiple layouts and display them based on a condition. To do so, define `condition` for layouts. Conditions are checked in the order layouts are defined in config. If layout doesn't specify condition, it is displayed with no requirement. If player does not meet display condition for any layout, they will see the classic tablist.
Example:
```
layouts:
staff:
condition: "permission:tab.staff"
fixed-slots:
...
groups:
...
default:
fixed-slots:
...
groups:
...
```
In this example, players with `tab.staff` permission will see `staff` layout, others will see `default` layout.
# Skins
In slots where players are, their skin is displayed. For fixed slots, if their skin is defined, it is used, otherwise `default-skin` is used. It is also used if invalid skin is specified anywhere.
## Format
Currently, TAB supports 3 skin formats:
*`mineskin:<ID>` - takes UUID from [MineSkin](https://mineskin.org). You can find some pre-uploaded skins at the bottom of this page.
*`player:<name>` - displays skin of player `name`
*`texture:<texture>` - uses literal skin texture. This lets you use heads from [Minecraft-Heads](https://minecraft-heads.com/custom-heads) by taking the texture in the `Minecraft-URL` field.
| direction | COLUMNS | Defines direction of slots. Options are COLUMNS (top to bottom, left to right) and ROWS (left to right, top to bottom). This does not only change the slot numbers in configuration, but will also affect the way players are being filled into player groups. |
| enable-remaining-players-text | true | When enabled, the last slot of player group will show how many more players there are, instead of using the last slot for one more player. |
| remaining-players-text | "... and %s more" | Text to show if option above is enabled. |
| default-skin | "mineskin:1753261242" | Default skin to display for fixed slots that do not define a skin, empty slots and fixed slots with invalid skin. |
| empty-slot-ping-value | 1000 | Ping value to use for fixed slots and empty slots. The ping intervals for bars are client sided and are as following: <br />- Negative value: ✖ <br />- 0 - 149: 5 bars <br />- 150 - 299: 4 bars <br />- 300 - 599: 3 bars <br />- 600 - 999: 2 bars <br />- 1000+: 1 bar |
To avoid showing fake players in tab-complete, TAB uses an empty string as the fake players' names.
Though Minecraft's scoreboard objectives (which help achieve the Playerlist objective feature) only use players' names and not players' UUIDs to define values.
As a result, it is impossible for TAB to assign a different value for each fake player since they all have the same name, making the [Playerlist objective](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Playerlist-Objective) feature incompatible.
## Additional note 2 - Global playerlist incompatibility
The way this feature works is by pushing all real players out of the tablist and showing fake players instead.
As a result, enabling [Global playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist) feature won't make any difference, since real players aren't visible in the tablist.
Layout feature is capable of working with all online players connected to the server where TAB is installed, meaning it can show players from all servers when installed on BungeeCord. Because of this, if you use layout, you can just disable global playerlist to reduce resource usage.
Since 1.19.3 until 1.21.1 (inclusive), entries will also appear in chat complete. The mechanic used to hide them on <1.19.3 can no longer be used since 1.19.3. 1.21.2 has added a new way of sorting players, which is being taken advantage of to restore empty chat complete.
**Note**: In order to hide entries from chat complete on 1.21.2+, the server also has to be 1.21.2+ so it can send new content to the players (having TAB installed on proxy counts as using latest version).
**Note 2**: The 1.21.2+ improvement was added in [dev builds](https://github.com/NEZNAMY/TAB/actions) (v5) and will not be added into v4.
## Additional note 4 - Per world playerlist incompatibility
Layout works by adding 80 fake players into the tablist, pushing real player entries out of view. Because of this, when using [per world playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Per-world-playerlist), the feature will only hide the real players, which are outside of tablist and not visible anyway and not touch the layout entries. However, you can replicate the same effect using layout feature itself, using conditions.
<details>
<summary>Example</summary>
*We are going to ignore fixed slots in the examples, as they don't affect anything and you can just configure them however you want.*
Let's create 2 layouts, one for world `world1` and one for world `world2`. Each layout only displays players in that world.
```
layouts:
layout1:
condition: "%world%=world1"
fixed-slots: []
groups:
players:
condition: "%world%=world1"
slots:
- 1-80
layout2:
condition: "%world%=world2"
fixed-slots: []
groups:
players:
condition: "%world%=world2"
slots:
- 1-80
```
You can also merge multiple worlds into a group.
```
layouts:
layout1:
condition: "%world%=world1|%world%=world2"
fixed-slots: []
groups:
players:
condition: "%world%=world1|%world%=world2"
slots:
- 1-80
```
You can also replicate "ignore-effect-in-worlds" by creating a layout with condition for displaying, but not for groups.
```
layouts:
globalWorld:
condition: "%world%=globalWorld"
fixed-slots: []
groups:
players: # No condition here to show all players
slots:
- 1-80
```
</details>
# Examples
## Example 1 - Per-server columns
```
layout:
enabled: true
direction: COLUMNS
default-skin: mineskin:1753261242
enable-remaining-players-text: true
remaining-players-text: '... and %s more'
empty-slot-ping-value: 1000
layouts:
default:
fixed-slots:
- "1|&2&lLobby"
- "21|&2&lSurvival"
- "41|&2&lCreative"
- "61|&2&lSkyblock"
groups:
lobby:
condition: "%server%=lobby"
slots:
- 2-20
survival:
condition: "%server%=survival"
slots:
- 22-40
creative:
condition: "%server%=creative"
slots:
- 42-60
skyblock:
condition: "%server%=skyblock"
slots:
- 62-80
```
You can also remove the last condition (in this case `condition: "%server=skyblock%"`) and the columns will be used for all other servers, instead of just a specified one.
* [Disabling team handling](#disabling-team-handling)
# About
Nametags are controlled by a feature called scoreboard teams. They offer 6 properties:
* Team name - used for sorting players in tablist, see [Sorting guide](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Sorting-players-in-tablist) for more info
* Prefix - prefix displayed in nametag, it will be referred to as `tagprefix`
* Suffix - suffix displayed in nametag, it will be referred to as `tagsuffix`
* Nametag visibility rule
* Collision rule
* Team color (1.13+) - used to set name and glow color (check out [How to make TAB compatible with glow plugins](https://github.com/NEZNAMY/TAB/wiki/How-to-make-TAB-compatible-with-glow-plugins)) (on 1.12- it uses last color of prefix).
When enabling this feature, TAB will control all of these. It is not possible to take values from 2 different teams (plugins). Most of the compatibility problems with other plugins can be solved with placeholders. If you want sorting but not nametags, just don't configure any prefix/suffix. If you want another plugin to handle teams, configure sorting in that plugin.
This feature can be configured in **config.yml** under **scoreboard-teams** section.
# Configuration
## Groups and users
Properties can be applied in 2 ways: groups and users. Users can be defined by both username and their UUID. Values applied to users take priority over groups.
**groups.yml**
```
admin:
tagprefix: "&4&lAdmin &r"
```
This can also be achieved with commands, in this case `/tab group admin tagprefix "&4&lAdmin &r"`.
**users.yml**
```
_NEZNAMY_:
tagprefix: "&6&lTAB &r"
# An alternate way using UUID
237d8b55-3f97-4749-aa60-e9fe97b45062:
tagprefix: "&6&lTAB &r"
```
This can also be achieved with commands, in this case `/tab player _NEZNAMY_ tagprefix "&4&lAdmin &r"` or `/tab playeruuid _NEZNAMY_ tagprefix "&4&lAdmin &r"`.
Properties can also be set as "default" for everyone who does not have them defined. For that purpose, a group keyword `_DEFAULT_` was made.
**groups.yml**
```
admin:
tagprefix: "&4&lAdmin &r"
_DEFAULT_:
tagprefix: "&7" # This will be displayed on everyone except admin
```
## Per-world / per-server
Values can also be applied per-world (and per-server on bungeecord), where they can be defined per group/user. These values take priority over global settings. Example:
**groups.yml**
```
per-world:
world1:
_DEFAULT_:
tagprefix: "&a" # Everyone in world "world1" will have this prefix
per-server:
server1:
_DEFAULT_:
tagprefix: "&a" # Everyone in server "server1" will have this prefix
```
For multiple worlds/servers to share the same settings, separate them with a`;`.
For worlds/server starting with a specified text, use `*` after shared part. For ending with a shared part, use `*` at the beginning.
Example:
```
per-world:
world1;world2:
_DEFAULT_:
tagsuffix: "Shared tagsuffix in worlds world1 and world2"
lobby-*:
_DEFAULT_:
tagsuffix: "Suffix in all worlds starting with lobby-"
```
## Priority system
Full list of priorities looks like this:
1. value set using the [API](#api)
2. per-world / per-server applied to username
3. value applied to username
4. per-world / per-server applied to uuid
5. value applied to uuid
6. per-world / per-server applied to player's group
7. per-world / per-server applied to group `_DEFAULT_`
8. value applied to player's group
9. value applied to group `_DEFAULT_`
This list is browsed through until the first match is found. If no match is found, empty value is used.
Values are taken independently from each other. This means you can set per-world tagprefix, but only keep one global tagsuffix for example.
You can see source of a value displayed on player by using `/tab debug <player>` and checking "source" part of the value you are looking for.
## Placeholder support
All values fully support [TAB's internal placeholders](https://github.com/NEZNAMY/TAB/wiki/Placeholders#internal-placeholders) and [PlaceholderAPI placeholders](https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders) including relational placeholders. Amount of placeholders is not limited and they can be used in combination with static text as well.
| enable-collision | true | Controls collision rule. Available values are: <br />- `true` - Collision will be enabled permanently. <br />- `false` - Collision will be disabled permanently. <br /> - *Conditional expression* - Collision will be enabled if player meets the condition (for example `%world%=world` will result in collision only being enabled for players in world `world`). <br /> - *Condition name* - Uses name of a [defined condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met for a player to have collision enabled. |
| invisible-nametags | false| When enabled, everyone will have invisible nametag all the time. Option to hide nametags was added in minecraft **1.8**, therefore it will not work on 1.7 and lower. |
| anti-override | true | While enabled, prevents other plugins from assigning online players into teams and making TAB not work correctly. They should be configured to not use teams, however many users fail to disable features in other plugins that they don't want, making this option required. Some plugins don't even say they use teams to achieve their goals. Did you know even Paper uses teams? |
| can-see-friendly-invisibles | false | Controlling value of the team flag. It allows you to see invisible players in the same team as transparent instead of completely invisible. Since TAB places each player into an individual team, this option will only take effect in combination with plugins that spawn a dummy clone of the player (sit or disguise plugins). |
| disable-condition | %world%=disabledworld | A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met for disabling the feature for players. Set to empty for not disabling the feature ever. |
# Tips & Tricks
If you want TAB to only take prefixes/suffixes from permission plugin, delete all groups from **grous.yml** and only keep this:
```
_DEFAULT_:
tagprefix: "%luckperms-prefix%"
tagsuffix: "%luckperms-suffix%"
```
# Limitations
* Prefix/suffix length is limited to 16 characters (including color codes) on <1.13. There is no reachable limit on 1.13+.
* Name cannot be effectively changed and plugin doesn't offer it.
* Since 1.13, the name can only have one code. That is either color or magic code (such as &4 or &l), but not both.
* Name does not support RGB codes. Any used RGB colors will be rounded to the nearest legacy code.
* Name color and glow color are managed by the same value, which means they cannot be different.
# Additional info
## Additional note 1 - NPC (in)compatibility
Teams are bound to player names, not uuids or entity ids. Because of that, they will affect all player entities with that name. This includes NPCs with same names as online players and prefixes/suffixes will be displayed on those as well. To avoid it, make their names not match any online player and use holograms to display them instead (Citizens has an option for this).
## Additional note 2 - Prefix/suffix on pets
Since 1.9 teams affect tamed animals as well, displaying prefix/suffix on them as well and if nametags are set to be invisible, they will be completely invisible as well. If you want to avoid it, install [this plugin](https://www.spigotmc.org/resources/109466/).
## Additional note 3 - Changing name itself
Teams do not allow to change the nametag name itself. Changing name is a complicated process which is slightly out of scope of the plugin as well, this is what nick plugins are about. On top of that, it's a pain requiring a ton of different packets which change their structure every version and with how many versions TAB supports it doesn't sound like fun doing.
## Additional note 4 - F1 view
Using teams causes player nametags to remain visible when using F1 view. This cannot be avoided by the plugin in any way. The only possible solution would be to modify the client.
# API
*To get started with the API, see [Developer API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) page.*
To access this feature, you'll need to obtain `NameTagManager` instance. Get it using `TabAPI.getInstance().getNameTagManager()`. If this feature is disabled, the method will return `null`.
## Changing prefix and suffix
To set the values for the respective formatting, use the following:
*`NameTagManager#setPrefix(TabPlayer, String)`
*`NameTagManager#setSuffix(TabPlayer, String)`
To reset them, set values to `null`.
To get custom values previously set using the API (they will return `null` if no custom value is set):
*`NameTagManager#getCustomPrefix(TabPlayer)`
*`NameTagManager#getCustomSuffix(TabPlayer)`
To get original value set by the plugin based on configuration:
*`NameTagManager#getOriginalPrefix(TabPlayer)`
*`NameTagManager#getOriginalSuffix(TabPlayer)`
**Note**: These values are only temporary, meaning they won't get saved anywhere and will get reset on player quit or plugin reload. If you wish to save these values into file, use [commands](https://github.com/NEZNAMY/TAB/wiki/Commands-&-Permissions#tab-playergroupplayeruuid-name-property-value-options).
## Collision
*`NameTagManager#getCollisionRule(TabPlayer)` - Returns forced collision rule using the API, `null` if no value was forced and player follows the configuration.
*`NameTagManager#setCollisionRule(TabPlayer, Boolean)` - Forces collision rule to the player. Use `null` to reset value and make it follow configuration again.
## Manipulating visibility
*`NameTagManager#hideNametag(TabPlayer)` - Hides player's nametag from all players
*`NameTagManager#hideNametag(TabPlayer, TabPlayer)` - Hides player's nametag from a specific player, where the first `TabPlayer` is the player who's nametag you want to hide, and the second `TabPlayer` is the player who you want to hide the first player's nametag from.
*`NameTagManager#showNametag(TabPlayer)` - Shows player's nametag back again for everyone
*`NameTagManager#showNametag(TabPlayer, TabPlayer)` - Shows player's nametag back. The first `TabPlayer` is the player who's nametag you want to show, and the second `TabPlayer` is the player who you want to show the first player's nametag to.
*`NameTagManager#hasHiddenNametag(TabPlayer)` - Returns `true` if player has hidden nametag for everyone, `false` if not
*`NameTagManager#hasHiddenNametag(TabPlayer, TabPlayer)` - Returns `true` if player has hidden anmetag for specific player, `false` if not. The first `TabPlayer` is the player who's nametag you want to check is hidden, and the second `TabPlayer` is the player who you want to check if they can see the first player's nametag.
## Disabling team handling
*`NameTagManager#pauseTeamHandling(TabPlayer)` - Pauses team handling for a specific player. This will unregister the player's team and disable anti-override for teams.
*`NameTagManager#resumeTeamHandling(TabPlayer)` - Resumes team handling for a specific player. This will register the player's team and enable anti-override for teams.
* `NameTagManager#hasTeamHandlingPaused(TabPlayer)` - Returns `true` if handling is disabled using methods above, `false` if not.
| allow-bypass-permission | false | If enabled, players with `tab.bypass` permission will see everyone in tablist despite this feature enabled. |
| ignore-effect-in-worlds | *List* | List of worlds where players will see everyone in tablist, not just players in the same world / world group |
| shared-playerlist-world-groups | *Map* | See [Grouping playerlist from multiple worlds](#grouping-playerlist-from-multiple-worlds) |
## Grouping playerlist from multiple worlds
In case you want multiple worlds to share playerlist despite this option enabled, create a group and put world names there. The default example
```
per-world-playerlist:
shared-playerlist-world-groups:
lobby:
- lobby1
- lobby2
minigames:
- paintball
- bedwars
```
contains 2 groups, each of them consisting of 2 worlds. World group name can be anything (in our case they're called "lobby" and "minigames"). Under group name, list the actual world names.
With this setup, "lobby1" and "lobby2" will share playerlist, as well as "paintball" with "bedwars". All other worlds will have playerlist not shared with any other worlds. Creating a group for 1 world only is completely useless.
By default, the server sends information about ping of players to everyone, which you can see in the tablist as the green bar. Some modified clients allow to see the exact value instead of just bars. This feature spoofs ping value of all players to the configured value, hiding their true ping. I don't know why would anyone want to do that.
# Configuration
Find this section in your **config.yml**
```
ping-spoof:
enabled: false
value: 0
```
To enable the feature, set `enabled: true`.
When the feature is enabled, everyone's ping value will be shown as value configured in `value` field.
The ping intervals for bars are client sided and are as following:
* [Pattern 2: Number intervals](#pattern-2-number-intervals)
* [Pattern 3: else](#pattern-3-else)
* [Supported content in values](#supported-content-in-values)
* [Using in other plugins](#using-in-other-plugins)
* [Examples](#examples)
* [Example 1 - Adding brackets to placeholder output if it returns non-empty value](#example-1---adding-brackets-to-placeholder-output-if-it-returns-non-empty-value)
Most placeholders don't have fully configurable output, making you unable to customize it as you'd like. This is especially a problem with placeholders such as vanish or afk ones that return "yes" or "no" instead of some fancy text. It is job of the plugins providing placeholders to allow control over outputs, but for plugins that don't we have a solution - now you're able to configure output of any placeholder in many ways.
# Configuration
Open **config.yml** and find this section:
```
placeholder-output-replacements:
<placeholder>:
<original output>: <new output>
```
## Supported replacement patterns
### Pattern 1: Exact text
If placeholder's output is exact to the text on left side, it will return text on the right side.
<details>
<summary>Example</summary>
```
placeholder-output-replacements:
"%tps%":
"20": "Running at perfect 20 TPS!"
"%essentials_vanished%":
"yes": " &7[V]"
"no": ""
```
</details>
**Note 1:** If you want to replace empty output, use `""` or `''` on the left side.
**Note 2:** The text must match exactly, including color codes. To check color codes a placeholder returns use [`/tab parse <player> <placeholder>`](https://github.com/NEZNAMY/TAB/wiki/Commands-&-Permissions#tab-parse-text) and check "Without colors" part.
### Pattern 2: Number intervals
Output will be replaced if it's numeric and belongs in configured interval.
<details>
<summary>Example</summary>
```
placeholder-output-replacements:
"%tps%":
"15-20": "Solid"
"5-15": "Bad"
"0-5": "Terrible"
```
</details>
**Note:** If a number is included in more than 1 interval (just like 5 and 15 from the example above), the one higher is used. In this case, 15 would give `Solid` and 5 would give `Bad`.
Intervals can be defined using both `-` and `~`. If you need support for negative values, use `~` for interval instead of `-`.
<details>
<summary>Example</summary>
```
placeholder-output-replacements:
"%my_negative_placeholder%":
"-100~-1": "Negative"
"0": "Zero"
"1-100": "Positive"
```
</details>
### Pattern 3: else
If none of the configured outputs are used and "else" is set, that value will be used instead.
<details>
<summary>Example</summary>
```
placeholder-output-replacements:
"%tps%":
"20": "Running at perfect 20 TPS!"
"15-20": "Solid"
"5-15": "Bad"
"else": "Terrible" #0-5 in this case
```
</details>
## Supported content in values
You can use placeholders inside outputs, including the original placeholder you are altering. It will return original output of the placeholder.
<details>
<summary>Example</summary>
```
placeholder-output-replacements:
"%tps%":
"20": "Running at perfect 20 TPS!"
"15-20": "%tps% (Solid)"
"5-15": "%tps% (Bad)"
"else": "%tps% (Terrible)"
```
With this example, if TPS reaches for example 17.5, the output would be `17.5 (Solid)`.
</details>
# Using in other plugins
These replacements are only supported inside TAB. They won't work in other plugins.
If you want to use these in other plugins, you'll need to [enable tab's PlaceholderAPI expansion](https://github.com/NEZNAMY/TAB/wiki/Placeholders#placeholderapi) and use `%tab_replace_<placeholder>%`. If you for example configure output for %player_health%, use `%tab_replace_player_health%`.
This only works for PlaceholderAPI placeholders, not TAB's internal ones. For TAB's internal ones use `%tab_placeholder_<placeholder>`, such as for %health% use `%tab_placeholder_health%`.
# Examples
## Example 1 - Adding brackets to placeholder output if it returns non-empty value
When displaying faction or clan of players, you may want to add brackets if player is in a faction/clan, but not show them if they are not in one. To achieve this, we are going to use [Pattern 1: Exact text](#pattern-1-exact-text) and [Pattern 3: else](#pattern-3-else). If placeholder returned nothing, show nothing. Otherwise, show the output with added brackets:
```
placeholder-output-replacements:
"%my_placeholder%":
"": ""
"else": "[%my_placeholder%] "
```
Note that you'll need to match the placeholder output exactly. Not all clan/faction-like plugins return empty value when player doesn't have any. They may return just a color code, such as `&7`, in which case replacing empty value won't work. To see what the exact output of a placeholder is, use `/tab parse <player> <placeholder>` and check "Without colors" part. If that's the case, you'll need to change it on the left side. Example:
```
placeholder-output-replacements:
"%my_placeholder%":
"&7": ""
"else": "[%my_placeholder%] "
```
**Don't forget that parse command applies replacements, so when trying to see what placeholder returns, you should disable any previously configured replacements for that placeholder to see the correct raw output**.
## Example 2 - Replicating PlaceholderAPI's %player_colored_ping%
*Please note that this is just an example to demonstrate the plugin's functionality. It is not supposed to discourage anyone from using PlaceholderAPI or any of its placeholders.*
The placeholder allows you to configure intervals in config.yml. Default values are <50 for good, <100 for medium and 100+ for high. We can achieve this using [Pattern 2: Number intervals](#pattern-2-number-intervals) and [Pattern 3: else](#pattern-3-else). When put together, it looks as following:
```
placeholder-output-replacements:
"%ping%":
"0-50": "&a%ping%"
"51-100": "&e%ping%"
"else": "&c%ping%"
```
Keep in mind that now the placeholder will no longer return just a number, which breaks features like [Yellow Number](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Yellow-number), which require a numeric input. If you want that feature and ping to be displayed there, replacements won't work for you and you'll need to use [Conditional placeholders](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) instead to achieve colored ping.
| value | "%ping%" | [1.20.2-] Defines value displayed. You can set this to any placeholder that outputs a number. Setting value to `%health%`, `%player_health%` or `%player_health_rounded%` will result in the display type being changed to hearts instead of number. If you want to display health but as a number and not hearts, set value to `0%health%` for example. Only visible on 1.20.2 and lower. <br/> **Note**: Even if you only support 1.20.3+, you still need to configure this value to properly evaluate to a number, because the value is still sent to the client (just not displayed). You can set it to `0` for simplicity. |
| fancy-value | "&7Ping: %ping%"| [1.20.3+] Value to display for 1.20.3+ clients. Supports any text. |
| disable-condition | %world%=disabledworld | A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met for disabling the feature for players. Set to empty for not disabling the feature ever. |
# Limitations
On 1.20.2 and lower, only 2 display types are supported - number and hearts. The number's color is yellow and cannot be changed.
# Additional info
## Additional note 1 - Spectator gamemode
The feature will not be visible on players with spectator gamemode. To resolve this, check out [Spectator fix](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Spectator-fix) feature.
This feature can be configured in **config.yml** under **scoreboard** section.
# Creating a scoreboard
Scoreboards can be created in `scoreboards` section. You can define as many scoreboards as you want. Each scoreboard can have a condition requirement, which must be met to display the scoreboard. If it's not met, the next defined scoreboard is checked and so on. If the last defined scoreboard has a condition requirement which isn't met, player won't see anything.
Each scoreboard defines up to 3 parameters:
## title
Title of the scoreboard. Limited to 32 characters on MineCraft versions below 1.13 (including color codes. It is automatically centered by the client.
## lines
Up to 15 lines of text. You can define more, but client won't display them.
Since 1.20.3, you can also configure the value on the right side, which no longer has to be a red number. To set it, use `||` sequence and put right-side text after it. Example:
```
lines:
- "Left side text 1||Right side text 1"
- "Left side text 2....||Right side text 2...."
- "Left side text 3.......||Right side text 3......."
The right side text will not be visible on 1.20.2 and lower and numbers will be displayed instead. In order to properly see the right side not only the client has to be 1.20.3+, but the server as well, since plugin cannot send a packet that does not exist (on older versions). BungeeCord always includes new content and therefore counts as latest version. This can be used to send new content to new players while having outdated server version.
### Alignment
Left side of the text is automatically aligned to the left, while the right side is automatically aligned to the right. This is done by the client and is out of plugin's control. If you want to center a line, you'll need to do it manually. If dynamic placeholder output length is preventing your from doing it, you can try to bypass it by adding spaces before and after it to artificially increase and force the scoreboard width, such as `- " Centered text "` (or more spaces if needed).
### Empty placeholder output
When a line consists only of a placeholder that returned empty output, the line will be hidden completely. This is intentional to allow dynamic scoreboard size based on placeholder output. This is not the case if empty line is configured (`""`), to allow empty lines in configuration.
## display-condition
A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met to display this scoreboard. If it isn't met for the player, the next scoreboard's condition is checked.
# Chaining scoreboards
When defining more than 1 scoreboard in config, the plugin will display the correct scoreboard based on conditions. Plugin goes through all defined scoreboards, starting with the scoreboard on top. If the scoreboard's condition is met or not set, it is displayed. If not, next defined scoreboard is checked and so on. If no suitable scoreboard is found (the last one has a condition requirement which wasn't met), none is displayed. Example:
Scoreboard `scoreboard1` is checked first. If condition is not met, `scoreboard2` is checked. If that condition is not met, `scoreboard3` is displayed.
If a player meets both conditions (has defined permission and is in defined world), `scoreboard1` will be displayed, because it is defined first and therefore has the highest priority. You can switch scoreboards based on your priority needs.
# Announce command
This takes priority over current scoreboard. Once the announce is over, previous scoreboard is restored.
`/tab announce scoreboard <name> <time>`
name - name of scoreboard to be displayed
time - amount of seconds to display the scoreboard for
| toggle-command | /sb | Command that can be used to toggle scoreboard for the player running the command. Players need `tab.scoreboard.toggle` permission to use it. <br />**Note:** This command will not appear in command auto-complete, because it's not a real registered command. Registered commands must be defined in plugin jar directly and cannot be dynamic. If you want to solve this, you can try getting a dummy private plugin made which registers that command. |
| remember-toggle-choice | false | When enabled, toggling decision is saved into a file to remember it even after reloads/restarts/reconnects |
| hidden-by-default | false | If enabled, scoreboard will automatically be hidden on join until toggle command is used to show it. |
| use-numbers | false | If enabled, numbers 1-15 will be used in the scoreboard. If disabled, `static-number` is shown everywhere. |
| static-number | 0 | If `use-numbers` is disabled, this is number to be in all lines. |
| delay-on-join-milliseconds | 0 | Delay in milliseconds to send scoreboard after joining. |
| respect-other-plugins | true | When enabled, TAB will hide its scoreboard if another plugin sent one and send it back once the other plugin's scoreboard is hidden. |
# Limitations
* Title is limited to 32 characters (including color codes) on <1.13.
* Line length is limited to 28 characters (including color codes) on <1.13 (68 on lines with static text / [Longer lines](#longer-lines)).
* Only displays up to 15 lines.
* The red numbers on the right really cannot be removed from the plugin side (a client modification / resource pack is needed) on 1.20.2 and lower. They no longer appear on 1.20.3+ and instead any text can be configured (see above).
# Longer lines
In order to make sure the scoreboard never flickers, it's only using prefix/suffix components to display text. These can easily be changed without any visual issues. The player name part, however, cannot be changed. A line has to be completely removed and a new one added. There's a chance a frame is rendered between these 2 packets are sent, causing the scoreboard to have 1 line missing for 1 frame, causing visual issue known as "flickering".
However, if your scoreboard only has placeholders that don't change value often (pretty much any placeholder except animations, really), you can make TAB use player name part, allowing you to use additional up to 40 characters. To do so, add `Long|` prefix to all lines which should use this bypass.
```
lines:
- "Classic line with shorter limit"
- "Long|Long line with much higher character limit"
```
This bypass is automatically enabled for all lines which only use static text (since there's nothing to refresh and cause flickering), therefore doing it for such lines (like in the example above) has no effect.
# Compatibility with other plugins
TAB automatically detects scoreboard coming from other plugins and when one is sent, TAB hides its own scoreboard. Later, when the other plugin hides its scoreboard, TAB will send its scoreboard back to the player.
This detection must be available on your platform. For that, see Scoreboard section on [compatibility page](https://github.com/NEZNAMY/TAB/wiki/Compatibility#supported-features-per-platform). If it says ✔, the detection is available. If it says ❗, it means this detection is not available on your platform. As a result, when the other plugin hides its scoreboard, TAB will not be able to resend its own.
If you want this detection and it's not supported by your platform, you can achieve it using an alternate solution with conditions that will make TAB display no scoreboard if the condition is not met. For this, you'll need to have more information about when exactly do plugins send scoreboards and how to detect it.
<details>
<summary>Example using PremiumVanish</summary>
When you are vanished using PremiumVanish plugin, placeholder `%premiumvanish_isvanished%` will return `Yes` instead of the usual `No`. You can put this as a display condition to all defined scoreboards.
Don't forget to add this condition to all of your scoreboards if you have more than 1 (for those with an existing condition merge them using `;`).
Keep in mind [placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements) apply to placeholders here as well, so if you configured a fancy output for that placeholder, you'll need to use it in the display condition as well. To see what exactly has placeholder returned, use `/tab parse <player> <placeholder>`.
</details>
# API
*To get started with the API, see [Developer API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) page.*
To access this feature, you'll need to obtain `ScoreboardManager` instance. Get it using `TabAPI.getInstance().getScoreboardManager()`. If this feature is disabled, the method will return `null`.
## Creating custom scoreboards
You can create and register new scoreboards using `ScoreboardManager#createScoreboard(String, String, List<String>)`, where the first `String` is the name, the second `String` is the title that will be displayed, and the `List<String>` is the list of lines that the scoreboard will display.
## Showing custom scoreboards
To show your new scoreboard to a player, you can use `ScoreboardManager#showScoreboard(TabPlayer, Scoreboard)`, where the `TabPlayer` is the player you want to show the scoreboard to, and the `Scoreboard` is the scoreboard you want to show. Doing this will also disable automatic scoreboard updating for the player, so that your scoreboard does not get overridden until you unregister it.
To reset the scoreboard that a player is using to the default scoreboard that they should be seeing as determined by the config, use `ScoreboardManager#resetScoreboard(TabPlayer)`.
To determine whether a player has a custom scoreboard set (one that was shown through the API), use `ScoreboardManager#hasCustomScoreboard(TabPlayer)`.
## Toggling scoreboard visibility
To change whether a player can see scoreboards, use `ScoreboardManager#setScoreboardVisible(TabPlayer, boolean, boolean)`, and to determine whether a player can see scoreboards, use `ScoreboardManager#hasScoreboardVisible(TabPlayer)`.
To toggle whether a player can see scoreboards, use `ScoreboardManager#toggleScoreboard(TabPlayer, boolean)`. This will either make scoreboards visible if they are not already, or make them hidden if they are currently visible.
## Announcing a scoreboard
To announce a scoreboard to all players on the server for a given amount of ticks, use `ScoreboardManager#announceScoreboard(String, int)`, which will lookup a scoreboard with the given `String` name, and if one is found, send it to all players for the given `int` ticks.
# Examples
## Example 1 - per-world scoreboards
We will be using a condition of "equals" (=) type and check for output of `%world%` placeholder. If condition is met, player is in that world and scoreboard is displayed. If not, checking for next scoreboard's condition. If none of the conditions are met, display default scoreboard.
```
scoreboards:
# start
scoreboard1:
display-condition: "%world%=world1"
title: 'Scoreboard 1'
lines:
- 'You are in world world1'
# first condition didn't pass, try next
scoreboard2:
display-condition: "%world%=world2"
title: 'Scoreboard 2'
lines:
- 'You are in world world2'
# first two conditions didn't pass, try next
scoreboard3:
display-condition: "%world%=world3"
title: 'Scoreboard 3'
lines:
- 'You are in world world3'
# none of the conditions above passed, display default scoreboard
default:
title: 'Default scoreboard'
lines:
- 'You are not in any of the worlds listed above'
```
*Note: This is just an example, the plugin is not limited to displaying scoreboard only per world. If you want per server scoreboards on BungeeCord, use %server% with server names. If you want worldguard regions, use %worldguard_region_name% with region names. This works for any placeholder offered by the plugin or by PlaceholderAPI.*
## Example 2 - Periodical scoreboard switching
We can use [animations](https://github.com/NEZNAMY/TAB/wiki/Animations) to make the plugin switch between scoreboards using display condition. Let's say we want to switch between 2 scoreboards. First, we create an animation:
**animations.yml**
```
switchingScoreboard:
change-interval: 10000
texts:
- "1"
- "2"
```
This animation will switch frames every 10 seconds.
Then, we will use output of this animation as a display condition. If animation is on the first frame, display first scoreboard. Otherwise, display second scoreboard.
**config.yml**
```
scoreboards:
scoreboard1:
display-condition: "%animation:switchingScoreboard%=1" # If animation is on the first frame
title: "Scoreboard 1"
lines:
- 'Text'
# Animation is on the second frame
scoreboard2:
title: "Scoreboard 2"
lines:
- 'Text'
```
We don't need to define display condition for second scoreboard, since if animation is not on the first frame, it has to be on the second one. If using more than 2, you will need to define display condition for all of them (except the last one).
* [Additional note 3 - Compatibility issues with other plugins](#additional-note-3---compatibility-issues-with-other-plugins)
* [Common mistakes](#common-mistakes)
* [API](#api)
# Enabling
To enable sorting, you must have either [Nametags](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Nametags) or [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) (or both) enabled.
To **verify** you enabled sorting, run `/tab debug`. It will say `Sorting type:` followed by anything except `DISABLED`.
# Methods of sorting
Below are all of the different methods that you can use to sort players in TAB.
## GROUPS
This is the default and recommended method. Players will be sorted by their primary permission group, according to the configured group list.
First, put your players into groups in your permission plugin. All ways to do it can be found at [How to assign players into groups](https://github.com/NEZNAMY/TAB/wiki/How-to-assign-players-into-groups).
**Verify** player's group using `/tab debug <player>`. It should say `Primary permission group:` followed by group you configured. If not, you did not assign players into groups correctly.
Second, place all of your groups in to a comma separated list **in order of priority** into `sorting-types`. Example:
```yaml
scoreboard-teams:
sorting-types:
- "GROUPS:owner,admin,mod,default"
```
**Verify** configured sorting priority of players using `/tab debug <player>`.
If that's the case, you forgot to add that group into the list.
## PERMISSIONS
**This method is not recommended, as many low quality servers give OP to every staff member and don't know how to negate permissions, making this option not function as intended. If you think you can pull it off, and sorting by primary group is not an option, you can give this a try.
This method is, however, handy when trying to sort specific players **without** assigning them into a group.**
This method will sort players based on permission nodes they have.
Place all of your permissions in to a comma separated list **in order of priority**.
For example, if you have the permissions `my.permission.1`, `my.permission.2`, `my.permission.3`, and want to have players sorted in that order, you would end up with a configuration like `PERMISSIONS:my.permission.1,my.permission.2,my.permission.3`.
This method sorts players using the output of a placeholder and comparing that to pre-defined values.
To configure this sorting type, write the placeholder that you want to use, followed by a colon (`:`), followed by a comma separated list of outputs to check against.
For example, if you want to sort players using the output of the `%essentials_afk%` placeholder, depending on whether it is `yes` or `no`, you would do that using a configuration such as `PLACEHOLDER:%essentials_afk%:no,yes`, where players who the placeholder outputs `no` for will be sorted above players who the placeholder outputs `yes` for in this case, putting AFK players on the bottom.
Example:
```yaml
scoreboard-teams:
sorting-types:
- "PLACEHOLDER:%essentials_afk%:no,yes"
```
## PLACEHOLDER_A_TO_Z
This method sorts players alphabetically according to the output of a placeholder.
To configure this sorting type, write the placeholder that you want to use. That's it.
For example, if you want to sort players by their name alphabetically, you would do that using a configuration such as `PLACEHOLDER_A_TO_Z:%player%`.
Example:
```yaml
scoreboard-teams:
sorting-types:
- "PLACEHOLDER_A_TO_Z:%player%"
```
## PLACEHOLDER_Z_TO_A
This method sorts players reverse alphabetically according to the output of a placeholder.
This is identical to the above A to Z sorting, except that the alphabet is backwards, so Z comes first, and A comes last.
To configure this sorting type, write the placeholder that you want to use. That's it.
For example, if you want to sort players by their name reverse alphabetiically, you would do that using a configuration such as `PLACEHOLDER_Z_TO_A:%player%`.
Example:
```yaml
scoreboard-teams:
sorting-types:
- "PLACEHOLDER_Z_TO_A:%player%"
```
## PLACEHOLDER_LOW_TO_HIGH
This method sorts players numerically depending on the output of a **numeric** placeholder from lowest value to highest value.
**Only placeholders that output number values will work with this sorting type!**
Supported number interval is from -1,000,000,000 to 1,000,000,000 and 5 decimal places.
To configure this sorting type, write the placeholder that you want to use. That's it.
For example, if you want to sort players using the output of the `%health%` placeholder from lowest health to highest, you would do that using a configuration such as `PLACEHOLDER_LOW_TO_HIGH:%health%`.
Example:
```yaml
scoreboard-teams:
sorting-types:
- "PLACEHOLDER_LOW_TO_HIGH:%health%"
```
## PLACEHOLDER_HIGH_TO_LOW
This method sorts players numerically depending on the output of a **numeric** placeholder fro highest value to lowest value.
**Only placeholders that output number values will work with this sorting type!**
Supported number interval is from -1,000,000,000 to 1,000,000,000 and 5 decimal places.
To configure this sorting type, write the placeholder that you want to use. That's it.
For example, if you want to sort players using LuckPerms weights, you would do that using a configuration such as `PLACEHOLDER_HIGH_TO_LOW:%luckperms_highest_group_weight%`.
If using a sorting type that uses pre-defined values ([GROUPS](#groups), [PERMISSIONS](#permissions) or [PLACEHOLDER](#placeholder)), you can sort multiple elements with the same priority by separating them with `|` symbol. Example using group sorting:
```
scoreboard-teams:
sorting-types:
- "GROUPS:owner,admin,vip1|vip2,default"
```
Where `vip1` and `vip2` will be sorted with the same priority (3rd).
This works for permissions and pre-defined placeholder values as well.
# Combining multiple sorting types
Since `sorting-types` is a list, you are able to use more than one sorting type. Sorting type priorities go in the same order as defined in the config. Let's take a look at the default config:
Here, players are sorted by their group first. Owner goes above admin etc. However, if 2 people have the same group (such as admin), next sorting type decides final order. In this case, admin with alphabetically lower username will be higher in the tablist.
A common request is putting AFK players on the bottom of tablist. This can be achieved with the following configuration:
With AFK status taking the highest priority, AFK players will be always sorted below players which are not AFK. Both player groups (afk and non-afk) then follow the rest of the logic explained above to define the final order. If trying to copypaste this example, keep in mind [Placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements) work here as well, so if you are using a fancier output for %essentials_afk%, you will need to use outputs respectively when defining sorting as well.
Although you can theoretically use as many sorting types as you want, there are still strict limits set by mojang. See more about these limits and how to avoid them as much as possible at [Additional note 1 - Limitations](#additional-note-1---limitations).
# Additional settings
| Option name | Default value | Description |
| ------------- | ------------- | ------------- |
| case-sensitive-sorting | true | When enabled, players will be sorted as A-Z a-z. When disabled, Aa-Zz. |
# Additional info
## Additional note 1 - Limitations
All sorting elements must together build a team name up to 16 characters long. Because of that, cuts in placeholder outputs may be required. TAB is already using the shortest possible values for all sorting types:
*`GROUPS`, `PERMISSIONS` and `PLACEHOLDER` - 1 character
*`PLACEHOLDER_LOW_TO_HIGH` and `PLACEHOLDER_HIGH_TO_LOW` - 3 characters
*`PLACEHOLDER_A_TO_Z` and `PLACEHOLDER_Z_TO_A` - as many as used
All your sorting types must be within a 15 character limit. Any characters above that will be cut off (TAB reserves 1 character to ensure each player is in a unique team). To get the most out of it, use the 1-character sorting types where possible.
You can bypass this limit by using [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) feature. Player ordering is fully plugin-sided and therefore is not artificialy limited.
## Additional note 2 - per-world sorting
Defining a per-world sorting type is not supported. However, this can be achieved with [Conditional placeholders](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders). Simply check for %world% and return one placeholder if it matches, another one if not. This will work with anything, not just worlds (server, regions, etc).
## Additional note 3 - Compatibility issues with other plugins
As you already know by now, sorting is managed by scoreboard teams (their names to be exact). Player can only be member of one team. In other words, only one plugin can handle teams at a time. Having multiple plugins handle teams is supposed to end in a disaster.
Fortunately, TAB contains a function that prevents other plugins from assigning players into teams. This can be enabled/disabled by toggling `anti-override` setting under `scoreboard-teams`. This is however highly recommended to keep enabled, unless all of your plugins are configured correctly. When a plugin tries to override TAB's teams, this action is logged into `anti-override.log` file. If your file is empty / does not exist, it means you have no conflicting plugins / settings and can disable this option, slightly boosting performance. If the file exists, most of the time you can guess where the teams come from by their name.
Here are a few common teams and their sources (`xxxx` means any, usually random character sequence):
*`collideRule_xxxx` - this comes from Paper. Not going to explain why as that would be quite long, but the way you can avoid is by setting `enable-player-collisions: true` in paper config and `enable-collision: false` in TAB config (yes, collisions will be disabled).
*`CMINPxx` - CMI, set `DisableTeamManagement: true` in `plugins/CMI/config.yml`.
*`CIT-xxxxxxxxxxxx` - Citizens NPC with the same name as some online player. Make NPC names not match real players and use holograms to display your desired text (/npc name or something).
*`PVP-xxxxxxxxxxxx` - Team coming from [PvPManager](https://www.spigotmc.org/resources/pvpmanager-lite.845/) plugin.
This detection, however, is not 100%. Because of that, you may still be experiencing a compatibility issue even with anti-override enabled. To identify such issue, check if /tab reload fixes your sorting issue. If it does, it's a compatibility issue of some sort. If not, it is most likely a misconfiguration issue.
# Common mistakes
Every possible mistake could be called "not reading this wiki page", but that would make this section pointless. For that reason let's call it list of mistakes made when following this page.
The most common mistakes include:
* Disabling both teams and layout, not realizing it disables sorting as well.
* Disabling anti-override without disabling teams in other plugins.
* Mistaking `primary-group-finding-list` for sorting list, despite that list having nothing to do with sorting and by default even having a comment above it saying it has nothing to do with sorting.
* Not configuring primary groups correctly. This can have multiple reasons, such as
* Not configuring group weights in LuckPerms.
* Accidentally enabling `use-bukkit-permission-manager` option when on BungeeCord without knowing what it does.
* Installing TAB on BungeeCord without having any permission plugin on BungeeCord.
* Enabling `assign-groups-by-permissions` without giving those permissions.
[Debug command](https://github.com/NEZNAMY/TAB/wiki/Commands-&-Permissions#tab-debug-player) will help you identify if this is your case.
* Using a plugin that causes TAB to fail to apply teams (such as Tablisknu). This includes installing TAB plugin on both bukkit and bungeecord, causing the installations to conflict.
# API
*To get started with the API, see [Developer API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) page.*
To access this feature, you'll need to obtain `SortingManager` instance. Get it using `TabAPI.getInstance().getSortingManager()`. If sorting is disabled, the method will return `null`.
You can change player's team name using following methods:
*`SortingManager#forceTeamName(TabPlayer, String)` - Sets player's team name to specified value (and performs team unregister & register with new name).
*`SortingManager#getForcedTeamName(TabPlayer)` - Returns player's forced team name using the method above. Will return `null` if no value is set.
Unfortunately, there is no simple way of just changing one's position while still accounting for other players. This is because the plugin supports a lot of sorting options, not just groups, so doing amateur stuff like "priority 1, 2" doesn't make sense. If you are really only interested in sorting by groups and changing group which player is sorted as, you can use `TabPlayer#setTemporaryGroup(String)`. To reset group back to normal, call the function with `null` argument.
* [Additional note 1 - Seeing yourself still as spectator](#additional-note-1---seeing-yourself-still-as-spectator)
# About
With the introduction of spectator gamemode in 1.8, players having it automatically appear on the bottom of tablist with transparent name and missing [Yellow number](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Yellow-number). This feature cancels gamemode change packets to spectator gamemode, cancelling this minecraft feature.
# Enabling
To enable this feature, open **config.yml** and set
```
prevent-spectator-effect:
enabled: true
```
# Permissions
| Permission | Description |
| ------------- | ------------- |
| `tab.spectatorbypass` | Players with this permission will see spectators the usual way despite this feature being enabled. If you don't want players (or even staff members) to bypass this feature, don't give them that permission. |
# Additional info
## Additional note 1 - Seeing yourself still as spectator
Receiving information about going spectator gamemode allows players to clip through walls. Cancelling this on self would result in inability to go through walls. To avoid this, the information will be cancelled for every player except the one going spectator gamemode. Therefore, if you change gamemode to spectator, you will still see yourself on the bottom, but no one else will (unless someone has the bypass permission).
This feature allows you to configure player name formats in the tablist. It was added to minecraft in version 1.8. Versions 1.7 and lower only allow up to 16 characters including name, which is too limiting and not suppored by this plugin. If you wish to have prefix/suffix for 1.7 and lower, take advantage of [this client-sided mechanic](https://github.com/NEZNAMY/TAB/wiki/Client%E2%80%90sided-mechanics#nametag-format-in-tablist) and configure tagprefix/tagsuffix, which will appear in the tablist.
Settings of this feature can be configured in **config.yml** under **tablist-name-formatting** section.
# Configuration
## Introduction
The display name is split into 3 parts for convenience:
`tabprefix` - first part of the text, this is where prefix is usually configured
`customtabname` - second part of the text, it will be used as player name. If customtabname is not defined at all (not just setting empty value!), player's original name will be used instead
`tabsuffix` - last part of the text, this is where suffix is usually configured
These values are then merged together and displayed in the tablist.
Properties can be applied in 2 ways: groups and users. Users can be defined by both username and their UUID. Values applied to users take priority over groups.
**groups.yml**
```
admin:
tabprefix: "&4&lAdmin &r"
```
This can also be achieved with commands, in this case `/tab group admin tabprefix "&4&lAdmin &r"`.
**users.yml**
```
_NEZNAMY_:
tabprefix: "&6&lTAB &r"
# An alternate way using UUID
237d8b55-3f97-4749-aa60-e9fe97b45062:
tabprefix: "&6&lTAB &r"
```
This can also be achieved with commands, in this case `/tab player _NEZNAMY_ tabprefix "&6&lTAB &r"` or `/tab playeruuid _NEZNAMY_ tabprefix "&6&lTAB &r"`.
Properties can also be set as "default" for everyone who does not have them defined. For that purpose, a group keyword `_DEFAULT_` was made.
**groups.yml**
```
admin:
tabprefix: "&4&lAdmin &r"
_DEFAULT_:
tabprefix: "&7" # This will be displayed on everyone except admin
```
## Per-world / per-server
Values can also be applied per-world (and per-server on bungeecord), where they can be defined per group/user. These values take priority over global settings. Example:
**groups.yml**
```
per-world:
world1:
_DEFAULT_:
tabprefix: "&a" # Everyone in world "world1" will have this prefix
per-server:
server1:
_DEFAULT_:
tabprefix: "&a" # Everyone in server "server1" will have this prefix
```
For multiple worlds/servers to share the same settings, separate them with `;`.
For worlds/servers starting with a specified text, use `*` after shared part. For ending with a shared part, use `*` at the beginning.
Example:
```
per-world:
world1;world2:
_DEFAULT_:
tabsuffix: "Shared tabsuffix in worlds world1 and world2"
lobby-*:
_DEFAULT_:
tabsuffix: "Suffix in all worlds starting with lobby-"
```
## Priority system
Full list of priorities looks like this:
1. value set using the [API](#api)
2. per-world / per-server applied to username
3. value applied to username
4. per-world / per-server applied to uuid
5. value applied to uuid
6. per-world / per-server applied to player's group
7. per-world / per-server applied to group `_DEFAULT_`
8. value applied to player's group
9. value applied to group `_DEFAULT_`
This list is browsed through until the first match is found. If no match is found, empty value is used (except `customtabname`, which defaults to player's name).
Values are taken independently from each other. This means you can set per-world tabprefix, but only keep one global tabsuffix for example.
You can see source of a value displayed on player by using `/tab debug <player>` and checking "source" part of the value you are looking for.
## Placeholder support
All values fully support [TAB's internal placeholders](https://github.com/NEZNAMY/TAB/wiki/Placeholders#internal-placeholders) and [PlaceholderAPI placeholders](https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders) including relational placeholders. Amount of placeholders is not limited and they can be used in combination with static text as well.
| anti-override | true | When enabled, prevents other plugins from overriding TAB. This results in slightly higher CPU usage, but will make sure the function works as expected. <br />Unlike with teams, attempts to override TAB are not logged into anti-override.log file. This is due to high amount of false positives from TAB's own features, as well as bungeecord server switch, higher CPU usage and more. Whether you need this or not depends on how properly your plugins are configured. Some of them attempt to format tablist even if you'd not expect it from such plugin. Keep this enabled to stay safe. |
| disable-condition | %world%=disabledworld | A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that must be met for disabling the feature for players. Set to empty for not disabling the feature ever. |
# Tips & Tricks
If you want TAB to only take prefixes/suffixes from permission plugin, delete all groups from **groups.yml** and only keep this:
```
_DEFAULT_:
tabprefix: "%luckperms-prefix%"
tabsuffix: "%luckperms-suffix%"
```
# API
*To get started with the API, see [Developer API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) page.*
To access this feature, you'll need to obtain `TabListFormatManager` instance. Get it using `TabAPI.getInstance().getTabListFormatManager()`. If this feature is disabled, the method will return `null`.
To set the values for the respective formatting, use the following:
**Note**: These values are only temporary, meaning they won't get saved anywhere and will get reset on player quit or plugin reload. If you wish to save these values into file, use [commands](https://github.com/NEZNAMY/TAB/wiki/Commands-&-Permissions#tab-playergroupplayeruuid-name-property-value-options).
The hook does not and will never support [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout), which would require drastic changes to the feature itself and wouldn't be worth it, since the amount of visible players is usually even lower due to fixed slots and RedisBungee is used on networks with many players, so there will be enough players to work with anyway.
* [#1 - Why are NPCs showing up in the tablist?](#1---why-are-npcs-showing-up-in-the-tablist)
* [#2 - How to make TAB work with LuckPerms?](#2---how-to-make-tab-work-with-luckperms)
* [#3 - How can i make belowname not affect NPCs but keep it for players?](#3---how-can-i-make-belowname-not-affect-npcs-but-keep-it-for-players)
* [#4 - I enabled MySQL and my prefix is now gone!](#4---i-enabled-mysql-and-my-prefix-is-now-gone)
* [#5 - Why is player sorting not working?](#5---why-is-player-sorting-not-working)
* [#6 - How to add players to %staffonline% placeholder?](#6---how-to-add-players-to-the-staffonline-placeholder)
* [#7 - How to make player heads visible in tablist?](#7---how-to-make-player-heads-visible-in-tablist)
* [#8 - Where can i find current default config files?](https://github.com/NEZNAMY/TAB/tree/master/shared/src/main/resources)
* [#9 - How can I split players into multiple columns?](#9---how-can-i-split-players-into-multiple-columns)
* [#10 - How to use space in prefix/suffix command?](#10---how-to-use-spaces-in-prefixsuffix-command)
* [#11 - Can I change/remove the green connection bar in tablist?](#11---can-i-changeremove-the-green-connection-bar-in-tablist)
* [#12 - Placeholder is not working](#12---placeholder-is-not-working)
* [#13 - How can I display ItemsAdder images?](#13---how-can-i-display-itemsadder-images)
* [#14 - How can I use UTF characters in configuration?](#14---how-can-i-use-utf-characters-in-configuration)
* [#15 - Is there a way to remove all players from tablist?](#15---is-there-a-way-to-remove-all-players-from-tablist)
* [#16 - How to add images to tablist?](#16---how-to-add-images-to-tablist)
* [#17 - Is MiniMessage supported?](#17---is-minimessage-supported)
* [#18 - Is it possible to show amount of players in a specific group, similar to staffonline placeholder?](#18---is-it-possible-to-show-amount-of-players-in-a-specific-group-similar-to-staffonline-placeholder)
## #1 - Why are NPCs showing up in the tablist?
See [Citizens FAQ](https://wiki.citizensnpcs.co/Frequently_Asked_Questions#Why_are_NPCs_showing_up_in_the_tablist.3F).
## #2 - How to make TAB work with LuckPerms?
* If you want to take prefixes/suffixes, check [this guide](https://github.com/NEZNAMY/TAB/wiki/Mini-guides-collection#taking-prefixessuffixes-from-permission-plugin) and use `%luckperms-prefix%` & `%luckperms-suffix%`.
* Sorting:
First, [Configure weights correctly in LuckPerms](https://github.com/NEZNAMY/TAB/wiki/How-to-setup-weights-priorities#luckperms). Then, you have 2 options:
* Configure [sorting by groups](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Sorting-players-in-tablist#groups) (recommended).
* Sorting by weights directly: `PLACEHOLDER_HIGH_TO_LOW:%luckperms_highest_group_weight%`.
## #3 - How can I make belowname not affect NPCs but keep it for players?
Make NPC plugin hide their original names (using teams) and place holograms for displaying text.
## #4 - I enabled MySQL and my prefix is now gone!
When enabling [MySQL](https://github.com/NEZNAMY/TAB/wiki/MySQL), it will be used as a data storage and groups.yml / users.yml files will no longer be used.
If you want to upload your configuration to MySQL (or download it back to files), use [MySQL conversion commands](https://github.com/NEZNAMY/TAB/wiki/MySQL#data-conversion) - [`/tab mysql upload`](https://github.com/NEZNAMY/TAB/wiki/MySQL#uploading-from-files-to-mysql) and [`/tab mysql download`](https://github.com/NEZNAMY/TAB/wiki/MySQL#downloading-from-mysql-to-files), respectively.
After you are done, run `/tab reload` for the changes to take effect.
## #5 - Why is player sorting not working?
See [Common mistakes section on sorting page](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Sorting-players-in-tablist#common-mistakes).
## #6 - How to add players to the %staffonline% placeholder?
Give them the `tab.staff` permission.
## #7 - How to make player heads visible in tablist?
Players who did not buy the game will never be able to see heads. Player heads are displayed by the client when connection to the server is an online connection authenticated through Mojang. It cannot be directly controlled by plugins. The intended way to reach this is by setting `online-mode=true` in `server.properties`.
If you want to allow pirates on your server, you can still display heads for players who bought the game by changing their connections to online connections. Most commonly used plugins for this are [FastLogin](https://www.spigotmc.org/resources/14153/) and [JPremium](https://www.spigotmc.org/resources/27766/), which change connections of premium players who enabled it to online connections.
Same goes for disabling heads - you cannot disable them if you have online mode enabled.
## #8 - Where can i find current default config files?
You can find all default files in the [source code](https://github.com/NEZNAMY/TAB/tree/master/shared/src/main/resources). You can also delete or rename a file and the plugin will regenerate it.
## #9 - How can I split players into multiple columns?
Players are put into columns by the client, it is not managed by the server. The only way is to get more players. They automatically split into more columns at 21, 41 and 61 players (due to limit of 20 entries per column). If you don't mind getting all 80 slots filled with fake player slots, check out the [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) feature.
## #10 - How to use spaces in prefix/suffix command?
Use "", for example `/tab group owner tabprefix "&2&lOwner&r "`
## #11 - Can I change/remove the green connection bar in tablist?
Connection bar is client sided and cannot be retextured or removed by TAB. You will need a custom minecraft client or a resource pack.
## #12 - Placeholder is not working
Most common reasons for a placeholder to not work include:
* Using % symbol by itself, which breaks placeholder starts and ends and therefore breaks all placeholders after it (use %% to display the symbol)
* Trying to use a PlaceholderAPI placeholder without downloading its expansion or not having PlaceholderAPI installed at all
* Trying to use [TAB's internal bukkit-only placeholders](https://github.com/NEZNAMY/TAB/wiki/Placeholders#bukkit-only) on BungeeCord
* Trying to use [PlaceholderAPI placeholders on BungeeCord](https://github.com/NEZNAMY/TAB/wiki/How-to-set-up-PlaceholderAPI-support-on-bungeecord) without installing [bridge plugin](https://www.mc-market.org/resources/20631/)
Full list of reasons can be found on the [Placeholders](https://github.com/NEZNAMY/TAB/wiki/Placeholders#placeholder-is-not-working) page.
## #13 - How can I display ItemsAdder images?
ItemsAdder offers placeholders, which return the respective symbol to which your desired image is bound to. You can get them using ItemsAdder's PlaceholderAPI expansion using their `%img_<something>%` placeholder. ItemsAdder's internal placeholders (`:something:`) will not work in TAB.
## #14 - How can I use UTF characters in configuration?
**Option 1**: [Save the file in UTF-8 encoding](https://github.com/NEZNAMY/TAB/wiki/How-to-save-the-config-in-UTF8-encoding) and use your desired symbol directly.
**Option 2**: Find hex code of your symbol (4 hexadecimal numbers) and use `\uxxxx` format, where `xxxx` is hexcode of the symbol.
Make sure to also wrap the text into `""` for the text to properly take `\` as an escape symbol. Using `''` will result in text being display literally, not as a code.
**Note:** Minecraft does not support every single UTF symbol and displays unsupported symbols as a box. You can try sending your symbol into chat and see if it works or not. If not, it's not supported by MC.
## #15 - Is there a way to remove all players from tablist?
For a player to be visible in game, they must be in the tablist as well. Remember the NPC in tablist issue? If you don't mind players not appearing in game, get a plugin that hides all players. If you want to see them in game however, your only choice is to put a lot of empty lines into header, which will push all players out of the screen.
## #16 - How to add images to tablist?
You can check out [this reddit post](https://www.reddit.com/r/admincraft/comments/llrgty/comment/gnswdcz/?utm_source=share&utm_medium=web2x&context=3). When using the symbol in configuration using \u format, don't forget to use `""` in config instead of `''`.
## #17 - Is MiniMessage supported?
Kind of. MiniMessage support **is** included, however, this doesn't mean it is guaranteed to work. Here are a few reasons why it may not work for you:
* MiniMessage library must be included in your server software. TAB does not include this library.
* It **is** included in Paper 1.16.5 and higher, Velocity and Sponge 8.
* It **is not** included in Spigot, any server software for 1.16.4 and lower, BungeeCord (and any of its forks), Sponge 7 and Fabric.
* You may not use any legacy color codes (&) in the text where you want MiniMessage support. If you use them, MiniMessage parser will throw an error. Therefore, if trying to use both legacy colors and MiniMessage syntax, MiniMessage syntax will not work.
* A plugin/mod might be shading an outdated/incomplete version of Adventure without relocating it, and java class loader might make TAB use the wrong source of the duplicated library.
This list is not final. There might still be other reasons why MiniMessage won't work for you which are not known yet. If you believe MiniMessage should be supported on your server but doesn't work, open a bug report.
## #18 - Is it possible to show amount of players in a specific group, similar to staffonline placeholder?
The plugin's internal placeholders are limited and this kind of functionality is not included. However, you can achieve this using PlaceholderAPI's `PlayerList` expansion and following [this example](https://github.com/Tanguygab/PlayerList-PlaceholderAPI-Expansion/wiki#list-of-players-in-group).
The wiki explains functionality of the plugin as of version **4.1.8**. If your config looks different or is missing some features, you are using an old version of the plugin. To get the latest version, check [releases](https://github.com/NEZNAMY/TAB/releases/).
Wiki for older plugin versions is not available, as there is never a reason to be outdated. Support for older MC versions is not being removed and new plugin version is simply superior to any of the previous versions, as it contains more optimizations, fixes and features.
If you plan to run your server for longer than 1 week, it's a good idea to read this wiki as it explains everything about the plugin, giving you knowledge to do things you had no idea were possible, giving you an advantage over everyone else.
A lot of examples on the wiki use PlaceholderAPI placeholders without explaining its installation step by step. If you are going to use the examples and aren't familiar with the plugin, check out [Quick PlaceholderAPI startup guide](https://github.com/NEZNAMY/TAB/wiki/Quick-PlaceholderAPI-startup-guide).
# Limitations of plugins
TAB is a plugin. It only modifies the server behavior to your liking. It does not add anything into the game. Because of that, you'll need to carefully read limitations of each feature to know what they are capable of and what they are not capable of. Some of the undesired behavior can be altered using a resource pack and some using a modified client. Both of these are out of scope of TAB as a plugin, therefore no advanced information regarding this is provided.
# Public plugin
TAB is a public plugin designed to satisfy needs of majority of servers.
This means it has functions not everyone will need. All you need to do is disable functions you don't want. Disabled features do not consume the CPU at all.
On the other hand, it cannot contain everything everyone can think of. There must be a balance between providing as much as possible while making the configuration as short and readable as possible. This is not an easy task. Majority of things that are not supported directly can be achieved using different ways. Adding direct way for everything everyone asks for would not only take a lot of time, but make the plugin harder to configure for everyone as well as introduce a lot of duplicate ways to achieve things, making the plugin overcomplicated.
If your need is very specific and not available in the plugin in any way, you should look into private plugin development. You will end up with a plugin made just for you with everything you want and nothing else.
* [Taking groups from backend servers when TAB is on BungeeCord](#taking-groups-from-backend-servers-when-tab-is-on-bungeecord)
## About
TAB uses groups to assign properties (such as tabprefix) and sort players in tablist (if sorting by groups). You have 2 ways of configuring primary groups of players in TAB.
First option hooks into your permission plugin and takes groups from it. Therefore, your permission plugin must be supported.
**Supported permission plugins**: **LuckPerms** everywhere, on Bukkit any plugin supporting **Vault**.
If your permission plugin is not supported, you can use [Option 2](#option-2-permission-nodes).
## Option 1: Primary group from permission plugin
This is the default method and recommended. TAB will ask your permission plugin for player's primary group.
To use it, keep `assign-groups-by-permissions: false` in your config.
Put players into groups in your permission plugin (don't forget to configure weights - for luckperms /lp group \<group\> setweight \<number\>).
**Verify** group using `/tab debug <player>`. It should say `Primary permission group: <your group>`.
## Option 2: Permission nodes
Instead of taking whole groups, TAB will check for permission nodes and assign groups based on highest permission.
1. Go to config.yml and set `assign-groups-by-permissions: true`.
2. Give `tab.group.<group name>` permission to the user/permission group.
3. Put all possible groups into `primary-group-finding-list`. This is needed because:
#1 - there's no way to get list of permissions of a player, only checking for a permission. The list will be used for list of permissions to check for.
#2 - if a player has permission for more than one group, the list will be used to pick the correct one (the one higher in the list).
**Don't forget that OP = all permissions!** That's the whole point of OP function. To grant all permissions. In that case, you need to negate permissions in your permission plugin for other groups which are higher than player's wanted group (depending on your permission plugin it can be achieved using `-tab.group.groupname` or setting the permission value to false).
# Taking groups from backend servers when TAB is on BungeeCord
By default, TAB takes groups from permission plugin installed on the same server instance. In case of proxy installation, groups are by default taken from the proxy. To see how is your proxy permission plugin configured, use its respective command (for LuckPerms it's `/lpb user <player> info` instead of `/lp`).
If you don't have your permission plugin synced using MySQL for sharing groups and don't wish to, and want groups to be taken from backend servers instead, enable the config option:
```
use-bukkit-permissions-manager: true
```
When enabling it, all group **and** permission requests will be done through [Bridge plugin](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) to take data from backend servers. Your groups will now match data from backend server a player is connected to (in case of LuckPerms `/lp user <player> info`).
When assigning by permissions instead of taking primary group directly from permission plugin, the permission nodes (`tab.group.<name>`) will be taken from backend servers instead.
* [Tip 2 - Sorting nicked players with lowest priority](#tip-2---sorting-nicked-players-with-lowest-priority)
# Tablist
This one is easy. The tablist format of players is one text that's split into 3 parts in the plugin for convenience (tabprefix, customtabname, tabsuffix). Using `customtabname` you can configure name part into any placeholder you want, including one from your nickname plugin. All you need is a working PlaceholderAPI placeholder from your nickname plugin. Example:
**groups.yml**
```
_DEFAULT_:
customtabname: '%essentials_nickname%'
```
or using in-game command `/tab group _DEFAULT_ customtabname %essentials_nickname%`.
This example uses `%essentials_nickname%` placeholder from Essentials. Giving it to `_DEFAULT_` group keyword makes it a default value for all groups that do not override this property.
**WARNING: Do NOT put nickname placeholder into tabprefix! You will end up with double names!**
# Nametag
Nametags are more complicated, because they consist of player's username, team prefix and team suffix. There is no intended way to do this. The only way is changing it using a nickname plugin. Some nickname plugins actually change name in game profile, which also changes it in nametag. You will need to find one that offers this and then use it. This is a complicated process with lots of side effects, so TAB does not offer it.
# Proper compatibility with plugins that change profile name
If using a nickname plugin that changes player's profile name in order to change it in the name tag, this has lots of side effects. Most notably, it breaks all name-bound features, especially [nametags](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Nametags) and [sorting](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Sorting-players-in-tablist). For that reason, TAB must detect name change. This is done automatically on Bukkit, BungeeCord and Fabric. This detection is not available on Sponge and Velocity.
In order for TAB to properly detect name change, player UUID must remain the same, otherwise it's a random entry with a random uuid and random name, which TAB isn't able to match with actual players. Make sure your nickname plugin is not changing UUID of players. If UUID changes, plugin won't be able to properly format names even in the tablist, since entries there are bound to UUIDs and by changing it, it will break.
Identifying whether name change detection is working properly or not can be checked by setting `debug: true` in config and checking console on name change. It should say `Processing name change of player <player name> to <new nickname>`. If it doesn't, something went wrong, most likely UUID not matching.
# Tips & Tricks
## Tip 1 - Nickname prefix
By default, Essentials prefixes nicknames of players in chat using `~` symbol for nicked players. We can very easily replicate that with [Conditional placeholders](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders). First, create a new condition:
```
conditions:
nick:
conditions:
- '%essentials_nickname%=%player%'
yes: "%player%" # If nickname = player name -> player is not nicked
no: "~%essentials_nickname%" # If nickname != player name -> player is nicked
```
Then, use `%condition:nick%` in your `customtabname` & `customtagname` instead of the placeholder directly.
# Tip 2 - Sorting nicked players with lowest priority
Let's also assume that you want every nicked player to be sorted as `default`. This can be achieved using [sorting by placeholder](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Sorting-players-in-tablist#placeholder) and creating a [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) that will return output based on nick status. First, let's create the condition:
```
conditions:
group:
conditions:
- '%haonick_isNicked%=true'
yes: "default"
no: "%group%"
```
When the condition is met, meaning player is nicked, it will return the group we want nicked players to be sorted as, in this case `default`. Otherwise, return player's actual group.
The condition check may differ with different nickname plugins. You will need to check documentation of your nickname plugin to see what kind of placeholders it offers and what they return (you can also use `/tab parse` to see what exactly did a placeholder return).
In this case, we are using placeholder `%haonick_isNicked%`, which returns `true` for nicked players.
If using Essentials, the line would look like this: `%essentials_nickname%!=%player%`, because Essentials is made to return player's actual name when not nicked, meaning when it's not equal, player is nicked.
Finally, use the conditional placeholder in sorting:
This will result in nicked players being sorted as `default`.
If you want to achieve something more complicated, such as not only sorted as default, but another rank, you will need to dig deeper into your problem, analyzing available placeholders and functions that will help you achieve your result.
This guide will explain how to solve the incompatibility with glow plugins.
# Content
* [Reason for compatibility issue](#reason-for-compatibility-issue)
* [Solution](#Solution)
* [Examples of glow plugins](#examples-of-glow-plugins)
## Reason for compatibility issue
Glow color is managed by scoreboard teams, which also handle nametag formatting and player sorting in tablist. Only one plugin can handle teams at a time. Because of that, TAB will prevent glow plugins from assigning players into teams.
## Solution
The solution to get around this issue is to use the glow plugin's placeholder (if it has any).
This placeholder has to be at the end of the player's `tagprefix` as it has to be the last color in the prefix.
**NOTE: For Minecraft version 1.9 - 1.12 the prefix can't be longer than 14 characters due to [16 character limit](https://github.com/NEZNAMY/TAB/wiki/Limitations#name-tags) total (glow placeholder adds 2 characters - `&` and the color code)**
**Example:**
This example uses the placeholder of the [eGlow](https://www.spigotmc.org/resources/63295/) plugin.
**groups.yml**
```
_DEFAULT_:
tagprefix: '%vault-prefix%%eglow_glowcolor%'
```
Keep in mind glow color is the same as name color. That's because there's only one field handling both values. However, you can bypass this with [Unlimited nametag mode](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Unlimited-nametag-mode). When enabling it, you'll get access to `customtagname` property, which is really just a part of the final armor stand string and can be freely modified.
To do so, you can configure for example
```
_DEFAULT_:
customtagname: '&2%player%'
```
With this example, all players will have green visible name, despite their glow color.
Open the file in WinSCP and check if it is in UTF-8 encoding already (1). If it is not, click on ENCODING at the top (2), select UTF-8 (3) and then save the file. You can now edit the file as you like and paste in characters.
* [Compatibility with RGB and gradients](#compatibility-with-rgb-and-gradients)
# Introduction
As of 1.16 mojang introduced RGB color support. This allows us to use 256^3 different colors instead of the original 16 ones. This is not supported on <1.16 in any way.
# Usage
Supported RGB formats:
*`#RRGGBB`
*`&#RRGGBB`
*`{#RRGGBB}`
*`#<RRGGBB>`
*`&x&R&R&G&G&B&B`
Gradients:
*`<#RRGGBB>Text</#RRGGBB>`
*`{#RRGGBB>}Text{#RRGGBB<}`
*`<$#RRGGBB>Text<$#RRGGBB>`
TAB uses the first by default, but is able to accept the other types as well without leaving any characters (such as `{}`) behind.
**Gradients only support 2 colors, using more will result in an invalid syntax and won't work.**
**Don't forget to replace `RRGGBB` with actual hexadecimal numbers, for example `FFAA00`** (yes, some people straight up copy "RRGGBB" and ask why is it not working):
This color code has 256 red, 170 green and 0 blue. It is equal to the legacy color `6` (gold/orange).
You can use a tool like [this one](https://htmlcolorcodes.com/) to easily find suitable colors.
## Magic codes
Just like with legacy colors, use color first, then magic codes (in any order). For example with **bold**: `#00FFFF&lText`.
For gradients, put the magic codes at the beginning of text. For example `<#00FF00>&lBold gradient text</#FF00FF>`.
# Invalid code handling
In case you accidentally use invalid hex color code, the plugin will simply ignore it and keep it in raw format.
# Compatibility with <1.16
Since <1.16 clients do not understand these color codes, something else must be displayed instead. The plugin will find the closest legacy color to the desired RGB combination and will use that color instead.
## Manually defining legacy color
If you want to specify a legacy color to use instead of plugin finding the closest one, you can define it by adding `|L` after RGB code, where `L` is a legacy color to use (0-9 a-f).
Usage for classic codes:
*`#RRGGBB|L`
*`&#RRGGBB|L`
*`{#RRGGBB|L}`
*`#<RRGGBB|L>`
*`<#RRGGBB|L>`
*`&x&R&R&G&G&B&B|L`
For gradients, defining color will result in the whole text having the same color instead of each character converting to closest colors, resulting in color groups. To define it, put `|L` after the begin color of gradient.
Usage:
*`<#RRGGBB|L>Text</#RRGGBB>`
*`{#RRGGBB|L>}Text{#RRGGBB<}`
*`<$#RRGGBB|L>Text<$#RRGGBB>`
# Fonts
The plugin offers usage of the font feature introduced in Minecraft 1.16.
**Warning!** This does NOT refer to different character sets! This refers to different fonts defined in resource packs or MC itself.
## Usage
The syntax is `<font:FONT_NAME>Text</font>` where `FONT_NAME` is name of your desired font.
**Example**
`<font:minecraft:alt>This is a text written in minecraft enchantment table language which no one understands</font>`
When trying to use both font and RGB or gradients, font must be outside and RGB/gradients inside.
**Example**
`<font:minecraft:alt><#00FF00>This is a colorful text written in minecraft enchantment table language which no one understands, but it looks pretty</#FF0000></font>`
Installation on Bukkit/Spigot/Paper is as simple as it can be. Just put the plugin into plugins folder and restart the server.
Dynamic (re)loads at runtime such as `/plugman load tab` to load the plugin are fully supported. However, plugins hooking into TAB may break when you use plugman to reload it.
# BungeeCord
## Proxy installation
This is the recommended setup. Put the plugin into plugins folder of the proxy server and restart it.
**Recommended**: Install [TAB-Bridge](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) on your backend servers for PlaceholderAPI support and more.
**Note**: With BungeeCord installation use **/btab** command instead of **/tab**.
Advantages of proxy installation compared to installing on all backend servers instead:
* Can use the [Global player list](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist)
* Can use new content for new clients even if backend server version is old (1.16+ RGB codes, 1.20.3+ scoreboard features)
* Avoid [header/footer](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Header-&-Footer#additional-note-1---not-resetting-on-server-switch) and [bossbar](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Bossbar#additional-note-2---not-hiding-on-server-switch) not disappearing on server switch
* Configuration files in a single place for easier editing / no need to use MySQL for syncing data
Disadvantages compared to installing on all backend servers instead:
* No [per-world player list](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Per-world-playerlist) (can be achieved by installing the plugin on backend servers and disabling all features except the per-world player list)
## Backend installation
Just like when not using BungeeCord, install the plugin on all servers where you want the plugin. However, this setup is not recommended (see advantages of proxy installation).
## Mixed installation
Mixed installation is absolutely not recommended and should be avoided. It requires you to disable features to make only 1 instance handle a single feature at a time, which most people fail miserably to do, resulting in issues such as header/footer flashing between proxy and backend configuration. With bridge you are able to achieve almost anything with proxy installation.
# Updating the plugin
Updating the plugin is always as simple as replacing old jar with the new one.
You do not need to reset your configuration files or make any manual changes to them. If any changes to configuration are made (changed / removed / added), TAB will automatically convert your existing configuration files to the latest format (most notably 2.9.2 -> 3.0.0, but any other changes as well).
Downgrading is completely unsupported, as old plugin version cannot know what the future config format is / will be. Just like Minecraft itself. There is no reason for downgrading anyway, as every version is superior to older versions released before it.
This is collection if minecraft issues/bugs you may experience when using TAB, which are not TAB bugs and cannot be fixed with a plugin.
# 1.5.x - 1.12.x - Unwanted space
You may see unwanted space at the end of a line of text even if you didn't configure any. This is a client sided bug. To avoid it, add &r after ending bold segment (for example prefix &4&lAdmin&r&6).
# 1.15.x - Strikethrough and underline
Using &m (strikethrough) and &n (underline) does not work in header, last line of scoreboard and possibly other places ([MC-180110](https://bugs.mojang.com/browse/MC-180110)).
# 1.20 - 1.20.4 - Chat over tablist
Visual bug rendering chat over the tablist ([MC-263256](https://bugs.mojang.com/browse/MC-263256)).
# 1.20.3+ - Text not bold
Since 1.20.3 text configured to be bold (using &l) may not appear bold. Steps to reproduce are currently unknown, if you have any information that may help, let us know.
Clue #1 - It might be a BungeeCord bug breaking bold text. It may or may not have been fixed.
* [Moving nametag when player wears a hat](#moving-nametag-when-player-wears-a-hat)
* [Displaying AFK status in tablist](#displaying-afk-status-in-tablist)
* [Showing combined online player count from multiple servers](#showing-combined-online-player-count-from-multiple-servers)
* [Option 1 - Using global playerlist](#option-1---using-global-playerlist)
* [Option 2 - Using PlaceholderAPI](#option-2---using-placeholderapi)
# Displaying kill / death counter in tablist
This example uses PlaceholderAPI placeholders.
Kills:
```
playerlist-objective:
enabled: true
value: "%statistic_player_kills%"
```
Deaths:
```
playerlist-objective:
enabled: true
value: "%statistic_deaths%"
```
**Note:** These values are taken from server stats. You can modify / reset them for each player in `<main world>/stats/<player uuid>.json` file.
# Taking prefixes/suffixes from permission plugin
Delete all groups from **groups.yml** and only keep this:
```
_DEFAULT_:
tabprefix: "%vault_prefix%"
tagprefix: "%vault_prefix%"
tabsuffix: "%vault_suffix%"
tagsuffix: "%vault_suffix%"
```
This requires Vault and a permission plugin to work.
If you have luckperms installed on the same server instance, you can use TAB's internal `%luckperms-prefix%` (and suffix) placeholders instead.
**Note:** If TAB is on bungeecord and you want prefixes to be taken from backend servers, use `%vault_prefix%` (or `%luckperms_prefix%`) with [PlaceholderAPI support on bungeecord](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge).
# Showing player version in tablist
Run `/tab group _DEFAULT_ tabsuffix " &8[&3%player-version%&8]"` or any other color combination you want. You can also include other placeholders with it. You can also modify it directly in **groups.yml** file instead. With the provided example command, you'll get the following result:
*This guide was made purely for demonstration of TAB's functionality to show you can even do things like this with conditions. It is not meant to be used as a replacement for Purpur or any of its functions or discouraging users from using Purpur.*
By default, Purpur's TPSBar shows server's TPS, MSPT and player ping. These change color from green to red based on value. The easier way to achieve this is with [Placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements-(premium-only)), however, it alters placeholders everywhere inside TAB, which would result in features like [Yellow number](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Yellow-number) to stop working correctly when %ping% is used, since it would contain color codes now. For that reason, we will use [Conditions](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) instead.
When TPS is above 19, it displays as `<#55FF55>value</#00AA00>`. When above 15, `<#FFFF55>value</#FFAA00>`, otherwise `<#FF5555>value</#AA0000>`. This can be achieved with 2 conditions:
```
conditions:
tps:
conditions:
- "%tps%>=19"
yes: "<#55FF55>%tps%</#00AA00>"
no: "%condition:tps2%"
tps2:
conditions:
- "%tps%>=15"
yes: "<#FFFF55>%tps%</#FFAA00>"
no: "<#FF5555>%tps%</#AA0000>"
```
To use this, we will use `%condition:tps%`.
Now, repeat for mspt and ping. For mspt, purpur's intervals are <40, <50, 50+. For ping, it's <100, <200, 200+.
Conditions for mspt and ping may look something like this:
```
conditions:
mspt:
conditions:
- "%mspt%<40"
yes: "<#55FF55>%mspt%</#00AA00>"
no: "%condition:mspt2%"
mspt2:
conditions:
- "%mspt%<50"
yes: "<#FFFF55>%mspt%</#FFAA00>"
no: "<#FF5555>%mspt%</#AA0000>"
ping:
conditions:
- "%ping%<100"
yes: "<#55FF55>%ping%</#00AA00>"
no: "%condition:ping2%"
ping2:
conditions:
- "%ping%<200"
yes: "<#FFFF55>%ping%</#FFAA00>"
no: "<#FF5555>%ping%</#AA0000>"
```
To use them, we will use `%condition:mspt%` and `%condition:ping%`. Purpur's TPSBar is using mspt as bossbar progress with range from 0 to 50. This can be achieved with PlaceholderAPI's math expansion: `%math_0_{tab_placeholder_mspt}*2%`. It always uses `GREEN` color and `NOTCHED_20` style. Let's put all of this together:
The last step is to configure when should this bossbar be displayed. One way is to use bossbar announce/send command. Another is to use display conditions. An example can look like `display-condition: "permission:tab.tpsbar`. Now, only players with the permission will see the bossbar.
# BedWars1058 compatibility
## Sorting
To sort teams through TAB, add the PLACEHOLDER_A_TO_Z sorting type with the %bw1058_player_team% placeholder. Example:
```yml
sorting-types:
- "PLACEHOLDER_A_TO_Z:%bw1058_player_team%"
- "GROUPS:admin,mod,default"
- "PLACEHOLDER_A_TO_Z:%player%"
```
## Team name in tablist/nametag
To display the team name in the tablist, use this command: `/tab group _DEFAULT_ tabprefix %bw1058_player_team%`
The same goes for the nametag, but with tagprefix instead: `/tab group _DEFAULT_ tagprefix %bw1058_player_team%`
To display only the first letter of the team, download this PlaceholderAPI expansion: https://api.extendedclip.com/expansions/bw1058plus/
and use `%bw1058plus_team_letter%` instead, if you want the color as well, put `%bw1058plus_team_color%` right before.
## Rank in lobby & Team name in game
If you want to display the rank of the player while he's in the lobby or waiting lobby, BUT show the team name while in game, then don't worry, there's a way =)
You can create a condition which checks if the player's current team = nothing (which means the player isn't playing), and return either the rank or the team name depending on that condition. Example:
```yml
conditions:
rankOrTeam:
conditions:
- "%bw1058_player_team%="
yes: "%luckperms-prefix%"
no: "%bw1058_player_team%"
```
And then do `/tab group _DEFAULT_ tabprefix %condition:rankOrTeam%` and `/tab group _DEFAULT_ tagprefix %condition:rankOrTeam%` so it shows in your nametag and in your tablist name.
# Moving nametag when player wears a hat
Unfortunately, there is no simple solution to this problem. We are going to use conditions with [unlimited nametag mode](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Unlimited-nametag-mode) to reach our results.
First, enable [unlimited nametag mode](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Unlimited-nametag-mode) by setting
```
scoreboard-teams:
enabled: true
unlimited-nametag-mode:
enabled: true
```
in config.yml.
Second, define static lines, which will be used in case player has a hat. Let's make them 1 block higher than normal (hint: default space between lines is 0.26 blocks).
```
unlimited-nametag-mode:
enabled: true
dynamic-lines:
- abovenameNormal
- nametagNormal
- belownameNormal
static-lines:
abovenameHat: 1.52
nametagHat: 1.26
belownameHat: 1
```
Now, we are going to assume your configuration is [taking prefixes/suffixes from permission plugin](#taking-prefixessuffixes-from-permission-plugin), because otherwise we would end up with a TON of conditions, which would take too much brain power create and maintain. Let's create 2 conditions: 1 for having a hat, 1 for not having a hat. In the example, we will use `%magicosmetics_equipped_HAT%` placeholder. It return `true` if player has a hat, `false` if not.
```
conditions:
nametagNormal:
conditions:
- '%magicosmetics_equipped_HAT%=false'
true: '%vault-prefix%%player%%vault-suffix%'
false: ""
nametagHat:
conditions:
- '%magicosmetics_equipped_HAT%=true'
true: '%vault-prefix%%player%%vault-suffix%'
false: ""
```
Let's use it in groups.yml
```
_DEFAULT_:
nametagNormal: "%condition:nametagNormal%"
nametagHat: "%condition:nametagHat%"
```
Obviously don't forget to add your tabprefix and stuff. If you are using abovename and/or belowname as well, do the same for those lines as well. We already created static lines for them, let's create conditions for them.
```
conditions:
nametagNormal:
conditions:
- '%magicosmetics_equipped_HAT%=false'
true: '%vault-prefix%%player%%vault-suffix%'
false: ""
nametagHat:
conditions:
- '%magicosmetics_equipped_HAT%=true'
true: '%vault-prefix%%player%%vault-suffix%'
false: ""
abovenameNormal:
conditions:
- '%magicosmetics_equipped_HAT%=false'
true: 'abovename text'
false: ""
abovenameHat:
conditions:
- '%magicosmetics_equipped_HAT%=true'
true: 'abovename text'
false: ""
belownameNormal:
conditions:
- '%magicosmetics_equipped_HAT%=false'
true: 'belownametext'
false: ""
belownameHat:
conditions:
- '%magicosmetics_equipped_HAT%=true'
true: 'belowname text'
false: ""
```
and use in groups.yml
```
_DEFAULT_:
nametagNormal: "%condition:nametagNormal%"
nametagHat: "%condition:nametagHat%"
abovenameNormal: "%condition:abovenameNormal%"
abovenameHat: "%condition:abovenameHat%"
belownameNormal: "%condition:belownameNormal%"
belownameHat: "%condition:belownameHat%"
```
If you are not using all 3 lines, you can also remove them from static lines. You may also need to adjust static height, since you may want different height of the prefix+name+suffix line based on if you have belowname or not, to avoid the line being too high.
# Displaying AFK status in tablist
First, you'll need to get an AFK plugin. TAB does not track player AFK status. Then, find a PlaceholderAPI placeholder for your AFK plugin in their documentation, such as
* `%essentials_afk%` for Essentials
* `%cmi_user_afk_symbol%` for CMI
* `%purpur_player_afk%` for Purpur (server software)
Don't forget to install PlaceholderAPI and the respective expansion of your afk plugin.
Then, use the placeholder in configuration wherever you want it. Assuming you want it for all players, use `_DEFAULT_` group keyword in **groups.yml** for default settings for all groups. Combined with other settings, it may look like this for tabsufffix:
```
_DEFAULT_:
tabsuffix: "%luckperms-suffix%%essentials_afk%"
```
Or running an in-game command: `/tab group _DEFAULT_ tabsuffix %luckperms-suffix%%essentials_afk%`.
This is not limited to displaying AFK status in suffix, you can also using it in tabprefix instead (or nametags).
Finally, you will most likely need to set up [placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements) for the placeholder, as lots of them, including the %essentials_afk% placeholder used as an example, return `yes` and `no` values, which you most likely want to customize.
As mentioned, by default, Essentials' afk placeholder returns `yes` / `no` (unless modified in PlaceholderAPI's config.yml). Other placeholders may return different values. To find out what a placeholder returned, use `/tab parse <player> <placeholder>`. Don't forget to include color codes as well.
An example customization may look like this:
```
placeholder-output-replacements:
"%essentials_afk%":
"yes": " &4&lAFK"
"no": "" # display nothing if not afk
```
Keep in mind that some placeholders don't need this. For example CMI has 2 placeholders - %cmi_user_afk% that returns true/false, and %cmi_user_afk_symbol% that returns AFK text configured in CMI configuration. Therefore, if you decide to use the latter one, you don't need to set up replacements.
# Showing combined online player count from multiple servers
## Option 1 - Using global playerlist
First way is to install TAB on the proxy and enable [global playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist). It allows you to create groups of servers that share playerlist. These groups can then be used to show player count on those servers using a placeholder. Using the following example:
```
global-playerlist:
enabled: true
server-groups:
lobbies:
- lobby1
- lobby2
```
Servers `lobby1` and `lobby2` will share playerlist. You will also be able to use placeholder formula `%playerlist-group_<group>%`, in this case `%playerlist-group_lobbies%`. It will show amount of players on `lobby1` and `lobby2` combined.
Advantage of this is the natural compatibility with global playerlist's settings, which is also its disavantage, since global playerlist has to be configured that way. When using [layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) feature, global playerlist is redundant and having it enabled only for the placeholder is inefficient.
## Option 2 - Using PlaceholderAPI
Unlike the first option, this one offers much more freedom, but also requires another plugin. You'll need to [download PlaceholderAPI and its expansions called math and bungee](https://github.com/NEZNAMY/TAB/wiki/Quick-PlaceholderAPI-startup-guide) (`/papi ecloud download bungee`, `/papi ecloud download math`, `/papi reload`).
First, you need placeholders for online count on specific servers. Bungee expansion does exactly that. The format is `%bungee_<server>%`. To merge the online counts, use math expansion. The syntax will be `%math_0_<expression>%`, where `expression` uses online counts from specific servers from bungee expansion. Finally, you'll end up with a placeholder like `%math_0_{bungee_lobby1}+{bungee_lobby2}%`. This placeholder will merge online counts from `lobby1` and `lobby2`.
Please note that by default, bungee expansion updates values only every 30 seconds. This can be changed in PlaceholderAPI's config. If the numbers still don't show correct value, check if the placeholder works correctly using `/papi parse me <placeholder>`. If not, this is not a TAB issue.
Advantage of this is no requirement for a specific TAB feature to be enabled, which also includes no need to have TAB installed on the proxy. The downside is relying on 3rd party software. If TAB is on proxy, you'll also need [bridge plugin](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge).
By default, groups and users are stored in separate files (groups.yml and users.yml).
Enabling MySQL will use it as storage of groups and users instead of the files.
playerdata.yml file (for toggling scoreboard/bossbar and remembering decision) is not affected and will still be used instead of MySQL. It may be added in the future.
All tables from TAB are prefixed with `tab_`, currently `tab_groups` for groups and `tab_users` for users.
# Availability
Before attempting to use the function, make sure your server software has an integrated MySQL driver. TAB does not contain it by itself. See compatibility matrix below for current information about compatibility:
| Platform | Available |
| ------------- | ------------- |
| Bukkit | ✔ |
| BungeeCord | ✔ |
| Fabric | ❌ |
| Sponge | ❌ |
| Velocity | ❌ |
# Enabling
Find this section in **config.yml**:
```
mysql:
enabled: false
host: 127.0.0.1
port: 3306
database: tab
username: user
password: password
useSSL: true
```
Enabling it will enable MySQL. The other settings are pretty straight forward.
# Configuration changes
Once enabled, configured values in groups.yml and users.yml will not be visible anymore, which is expected, because your database is empty when created. This is not a bug. All you need to do is [upload your data to the database](#uploading-from-files-to-mysql).
Since groups.yml and users.yml files will no longer be used, making any changes to them will take no effect. If you wish to perform any changes, you have 2 options:
* Use in-game commands, which will upload changes to the database
* Upload the file to database after every change (will not work for removing though) (useful when enabling for the first time).
# Data conversion
## Downloading from MySQL to files
This can be done using `/tab mysql download` command (permission is `tab.mysql.download`). It will download all data from the MySQL and save into groups.yml / users.yml.
This command requires the MySQL function enabled.
Existing data in files will not intentionally be deleted, but may get overwritten.
## Uploading from files to MySQL
This can be done using `/tab mysql upload` command (permission is `tab.mysql.upload`). It will upload all content from groups.yml and users.yml into MySQL.
This command requires the MySQL function enabled.
Existing data in database will not intentionally be deleted, but may get overwritten.
# Synchronization frequency
When using files to store data, it's simple - groups.yml and users.yml files are loaded into memory and read from when needed. When a command is ran to update something, it is updated in memory and saved into files as well.
When using MySQL, the plugin has to keep data up to date with other servers, but at the same time not kill the server with requests all the time.
For writing, both groups and users, whenever a command is used to update something, the update is sent to the database immediately.
For reading, data is updated as following:
* Groups - All data from groups table is loaded into memory on load (server start, plugin reload). When a player joins in or any other action, values from memory are checked. Therefore, if a change is made on another server, it will not be visible until plugin reload.
* Users - Nothing is loaded on plugin load. Whenever a player joins, all data of that player is requested from the database. Therefore, if player's data changes on another server, it is visible immediately when player joins this one, without the need to reload the plugin.
This guide will explain all primary ways you can reduce plugin's CPU usage besides the obvious things like "don't spam animations" or "disable features you don't want".
The usage can be checked at any time using [**/tab cpu**](https://github.com/NEZNAMY/TAB/wiki/Commands-&-Permissions#tab-cpu) command. If the numbers appear to be higher than they should be, check this guide for various ways to optimize the plugin. Most of these apply for all platforms, but some of them are only specific for some platforms.
# Content
* [#1 - [All platforms] Static text instead of placeholders](#1---all-platforms-static-text-instead-of-placeholders)
# #1 - [All platforms] Static text instead of placeholders
Static text doesn't need to be refreshed periorically, resulting in better performance. Some placeholders can be replaced with static text, such as placeholder for max player counts, since that value doesn't change at runtime. Another option is to configure prefixes per-group in config instead of using placeholders to take those values from permission plugin.
Some placeholders take a long time to process and result in high cpu usage. However, this can be optimized by configuring refresh interval of placeholders.
This only works for PlaceholderAPI placeholders. Internal ones have an interval hardcoded already with values I found the most appropriate.
To begin, find this part in your config
```yml
placeholderapi-refresh-intervals:
default-refresh-interval:500
"%server_uptime%": 1000
"%server_tps_1_colored%": 1000
"%player_health%": 200
"%player_ping%": 1000
"%vault_prefix%": 1000
"%rel_factionsuuid_relation_color%": 500
```
Refresh interval is in milliseconds. It must be divisible by 50.
`default-refresh-interval` is refresh interval for all unlisted PlaceholderAPI placeholders.
Keep in mind that CPU measurement is reset every 10 seconds. This means that if you configure a higher refresh interval than 10000, there will be intervals when placeholder didn't refresh at all, making it look like the CPU is perfect, while on the next refresh it may be high. For this reason, if you want to cleanly track usage, keep interval at 10000 at most. Using a higher interval will help if needed, but may lead to misleading info in cpu output.
# #3 - [All platforms] Don't use RGB
Though RGB colors look good, they require the text to be split into several components with `color` field used instead of the whole text pasted into the `text` field. This is a complicated process that takes quite some time. Sticking to legacy colors results in better performance.
# #4 - [All platforms] Disable anti-override
By default, TAB prevents other plugins from overriding it. This is because many server owners are not competent enough to configure their plugins correctly, such as disabling CMI collision handling which breaks nametags or even disabling team handling in paper. This obviously causes higher CPU usage. TAB logs all override attemps of teams into [anti-override.log](https://github.com/NEZNAMY/TAB/wiki/Action-logging#anti-overridelog) file. If you didn't get the file, it looks like you configured your plugins correctly. In that case, you can disable anti-override for teams in TAB.
```
scoreboard-teams:
anti-override: false
```
Tablist formatting is tricker, as override attempts are not logged, because it would have a lot of false positives. You will need to try and see.
```
tablist-name-formatting:
anti-override: false
```
# #5 - [All platforms] Disable tablist name formatting
As we already know from [Client-sided mechanics](https://github.com/NEZNAMY/TAB/wiki/Client%E2%80%90sided-mechanics#nametag-format-in-tablist) page, nametag format appears in tablist if tablist name is not defined. You can take advantage of this to effectively disable one entire feature and its cpu usage, while not losing on anything. However, you can only do this if:
* You are fine with nametag and tablist formats being identical, which also means all [nametag limitations](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Nametags#limitations) will transfer to tablist as well
* You don't have any plugin formatting the tablist names
Whether you have another plugin attempting to handle them or not may not be easy to identify with a lot of plugins and not enough time spent configuring them. In that case, your best choice is to try it and see. If tablist names break, it means you have another plugin and cannot take advantage of this optimization option.
* Group retrieving from permission plugin (for sorting / per-group properties)
* Prefix/suffix placeholders taking data from permission plugin
Default value
```
permission-refresh-interval: 1000
```
refreshes them every second. If you don't need any permission/group changes to take effect within a second, you can increase this value for better performance.
In order to maximize performance of TAB's response to PlaceholderAPI request, values are tracked in advance and then quickly returned. This process takes resources and is especially heavy on proxy installation, where values must be constantly sent to bridge using plugin messages.
Disabling TAB's PlaceholderAPI expansion if you don't use it improves performance.
In order for anti-override to work properly, some packets must be manually deserialized due to BungeeCord not doing it. If you don't need it, you can disable those functions, which will also disable the deserialization completely. To do so, you must disable 2 functions (only having 1 disabled is not enough):
#1 - Anti-override for teams
```
scoreboard-teams:
anti-override: false
```
Whether you need anti-override or not depends on configuration of your plugins. The easiest way is to have it enabled and see if you get `anti-override.log` file in TAB folder. If you don't, you don't need it. If you do, you'll need to do some configuring. [Here](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Sorting-players-in-tablist#additional-note-3---compatibility-issues-with-other-plugins) are a few examples of software and their team names, which you may find helpful.
#2 - Scoreboard detection of other plugins
```
scoreboard:
respect-other-plugins: false
```
TAB checks for packets sent by other plugins and if another plugin sends a scoreboard, TAB hides its own and resends it after the other plugin removes it. If you don't use scoreboard feature, this option is naturally disabled. If you do, but don't need compatibility with other plugins, you can disable this option.
Velocity offers header/footer translation of translatable components, however, TAB does not use these. Despite that, attempts to "translate" it are still there, causing the whole feature to use up to 3x more CPU than it would without it. There is no way to disable this inside Velocit itself, however, there is a third party [fork](https://github.com/GemstoneGG/Velocity-CTD/) that offers it.
**Use at your own risk**.
After installing, default velocity.toml file will contain `translate-header-footer = true` option. If just upgrading, you will need to add it there yourself. Setting it to `false` will disable this function.
TAB offers various placeholders to display the most common information. It also supports [PlaceholderAPI placeholders](https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders).
# Internal placeholders
Basic placeholders provided by the plugin. Most of these placeholders were added because they were requested by people who don't want to install another plugin just to show username. Some of them have configurable output in config.yml in `Placeholders` section. Unused placeholders do not affect performance in any way.
Placeholders must be refreshed. All internal placeholders have manually defined refresh interval, which I found the most optimal and cannot be changed. Time is in milliseconds. `-1` is used for placeholders which are in fact constants (such as %player%), or fire an event each time they change, which can be listened to (such as %world%) and value updated. Refresh interval for conditions is set to be equal to fastest refreshing placeholder used inside each condition.
## Universal
These placeholders are available on all platforms.
| Identifier | Refresh interval | Description |
| ------------- | ------------- | ------------- |
| %online% | 1000 | Total online player count on server where plugin is installed (excluding [vanished players](https://github.com/NEZNAMY/TAB/wiki/Additional-information#vanish-detection)). If the plugin is installed on a proxy, it will show total player count on the whole network. |
| %world% | -1 | Name of world where player is |
| %worldonline% | 1000 | Amount of players in the same world (excluding [vanished players](https://github.com/NEZNAMY/TAB/wiki/Additional-information#vanish-detection)) as the player |
| %ping% | 500 | Player's ping to the server where TAB is installed. <br />**Note**: This value is measured by the server and TAB is only retrieving that value. If it's wrong, it's not a TAB issue. |
| %player% | -1 | Player's name |
| %time% | 500 | Current real time, output is configurable in **config.yml** in `time-format` option |
| %date% | 60000 | Current date, output is configurable in **config.yml** in `date-format` option |
| %staffonline% | 2000 | Amount of online players with `tab.staff` permission |
| %nonstaffonline% | 2000 | Amount of online players without `tab.staff` permission |
| %memory-used% | 200 | Used RAM of server in MB |
| %memory-max% | -1 | Total RAM of server in MB |
| %memory-used-gb% | 200 | Used RAM of server in GB |
| %memory-max-gb% | -1 | Total RAM of server in GB |
| %player-version% | -1 | User-friendly version of player, such as `1.14.4`. For versions that share the same protocol version number, the higher one is returned (for example 1.20 & 1.20.1 -> 1.20.1 is returned) |
| %player-version-id% | -1 | Network ID of player's version. You can see the full version map on [fan wiki](https://wiki.vg/Protocol_version_numbers) for all versions or [TAB's source code](https://github.com/NEZNAMY/TAB/blob/master/shared/src/main/java/me/neznamy/tab/shared/ProtocolVersion.java) for releases only. Useful for conditions to create per-version results. |
| %luckperms-prefix% | 1000 | Prefix from LuckPerms from the server where TAB is installed |
| %luckperms-suffix% | 1000 | Suffix from LuckPerms from the server where TAB is installed |
| %displayname% | 500 | Display name variable set by permission plugin, typically prefix + name + suffix |
| %group% | 1000 | Returns player's primary group name. Created for internal functionality, but can be used as a display placeholder as well. |
| %vanished% | 1000 | Returns `true`/`false` based on player's vanish status. Created for internal functionality, but can be used as a display placeholder as well. |
| %bedrock% | -1 | Returns `true`/`false` based on whether player is using Bedrock edition or not (Java) |
| %% | -1 | Returns the `%` symbol. Useful to display `%` symbol without breaking all placeholders after it |
## Backend only
These placeholders only work when TAB is installed on a backend server (Bukkit / Sponge / Fabric), they don't work when TAB is on BungeeCord. If you have TAB installed on BungeeCord and wish to use these, use their [PlaceholderAPI](https://github.com/NEZNAMY/TAB/wiki/Quick-PlaceholderAPI-startup-guide) alternative with [Bridge plugin](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) installed for PlaceholderAPI support on BungeeCord.
| %health% | 100 | Player's health, rounded up to match Minecraft's heart display. | %player_health_rounded% |
| %displayname% | 500 | Player's display name value set by permission plugin. | %player_displayname% |
| %tps% | 1000 | TPS of server from the last minute (measured by server, not available on Fabric as it doesn't measure the value) | %server_tps_1% |
| %mspt% | 1000 | Server's current milliseconds per tick (Paper / Sponge 8+ / Fabric only) | - |
## BungeeCord only
| Identifier | Refresh interval | Description |
| ------------- | ------------- | ------------- |
| %server% | -1 | Name of server where player is, defined in proxy's config. |
| %serveronline% | 1000 | Amount of online players on server where the player is (excluding vanished players) |
| %online_\<servername\>% | 1000 | Amount of online players on specified server (excluding vanished players) |
| %playerlist-group_\<group\>% | 1000 | Amount of online players in specified [global playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist) group (therefore the feature must be enabled) |
# PlaceholderAPI
PlaceholderAPI is supported and relational placeholders are supported too. When parsing relational placeholders, TAB puts viewer as the first player argument and target player as second argument.
You can find most of placeholders that PlaceholderAPI offers on [PlaceholderAPI wiki](https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders). Some plugins are not listed there, for those you'll need to check their own wiki for placeholders.
TAB also offers its own placeholders into PlaceholderAPI. In order to enable TAB's expansion, set
```
placeholders:
register-tab-expansion: true
```
in **config.yml**.
Full list of placeholders:
| Identifier | Description |
| ------------- | ------------- |
| %tab_tabprefix% | Current tabprefix with replaced placeholders |
| %tab_tabsuffix% | Current tabsuffix with replaced placeholders |
| %tab_tagprefix% | Current tagprefix with replaced placeholders |
| %tab_tagsuffix% | Current tagsuffix with replaced placeholders |
| %tab_customtabname% | Current customtabname with replaced placeholders |
| %tab_customtagname% | Current customtagname with replaced placeholders |
| %tab_belowname% | Current belowname with replaced placeholders |
| %tab_abovename% | Current abovename with replaced placeholders |
| %tab_tabprefix_raw% | Raw tabprefix containing unparsed placeholders |
| %tab_tabsuffix_raw% | Raw tabsuffix containing unparsed placeholders |
| %tab_tagprefix_raw% | Raw tagprefix containing unparsed placeholders |
| %tab_tagsuffix_raw% | Raw tagsuffix containing unparsed placeholders |
| %tab_customtabname_raw% | Raw customtabname containing unparsed placeholders |
| %tab_customtagname_raw% | Raw customtagname containing unparsed placeholders |
| %tab_belowname_raw% | Raw belowname containing unparsed placeholders |
| %tab_abovename_raw% | Raw abovename containing unparsed placeholders |
| %tab_scoreboard_name% | Returns name of player's currently displayed scoreboard or empty string if none is displayed due to no display condition being met |
| %tab_scoreboard_visible% | "Enabled" if visible, "Disabled" if not |
| %tab_bossbar_visible% | "Enabled" if visible, "Disabled" if not |
| %tab_nametag_preview% | "Enabled" if previewing armor stands using /tab nametag preview, "Disabled" if not |
| %tab_nametag_visibility% | "Enabled" if player can see nametags, "Disabled" if disabled using /tab nametag toggle |
| %tab_replace_\<placeholder\>% | Applies [Placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements) to a PlaceholderAPI placeholder (for example %tab_replace_essentials_vanished%) |
| %tab_placeholder_\<placeholder\>% | returns value of tab's internal placeholder (such as %tab_placeholder_animation:name% for %animation:name%) |
# Relational placeholders
## About
Unlike classic placeholders which take either 0 (placeholders with same output for all players) or 1 (per-player placeholders) players, relational placeholders take in 2 players. The first usage was to display relation between two players, specifically enemies / allies (red / green) for factions, allowing players to see faction names of other players colored based on relation. While the usage is not limited to this, the name of the 2-player placeholder type has been established as "relational" and will be called that everywhere.
## Usage
TAB does not offer any internal relational placeholders. However, it has full support for PlaceholderAPI placeholders. You can also register your own relational placeholders using the [API](#relational-placeholders-1). In PlaceholderAPI, all relational placeholder identifiers must start with `%rel_`. This rule is adopted and used in TAB as well (including those registered via API).
When passing players into the function, first player is the player viewing the text, second player is the one text is being displayed on.
Code wise, the PlaceholderAPI request function becomes
```
public String onPlaceholderRequest(Player viewer, Player target, String identifier)
```
where `viewer` is the player looking and `target` is the player the value is being displayed on.
When trying to use placeholders from other plugins, you will need to check their documentation and search for relational placeholders. If your plugin does not appear to offer any, you ran out of luck and TAB cannot do anything about it.
In order to properly distinguish viewer/target (if needed), your relational placeholder expansion must follow the same order as TAB does. Since PlaceholderAPI never created any convention regarding this and instead calls the players `one` and `two`, I had to decide and this is the decision.
# Refreshing
## Refresh intervals
TAB is refreshing placeholders in intervals. For internal placeholders it's using values I found the most optimal and set directly in the plugin. Refresh intervals for PlaceholderAPI placeholders can be [configured](https://github.com/NEZNAMY/TAB/wiki/Optimizing-the-plugin#2---placeholder-refresh-intervals).
## Sync refreshing
By default, all placeholders are refreshed asynchronously so they don't slow down the server, since reading should be a thread-safe operation. Some placeholders, however, require to be refreshed in the main thread, causing problems or throwing errors when refreshed asynchronously. For these, replace them with `%sync:<original placeholder>%` and they will be refreshed in the main thread, for example `%server_total_entities%` -> `%sync:server_total_entities%`.
Keep in mind that now you should configure reasonable refresh interval for these placeholders to not cause TPS drops (with async placeholders it doesn't really matter). Configured refresh intervals and CPU usage of placeholders can be checked using `/tab cpu`.
# Placeholder is not working
When using a placeholder, you should know if it's a [TAB's internal placeholder](#internal-placeholders) or a [PlaceholderAPI placeholder](https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders). If you don't, that's the problem.
**Note:** Don't forget that using `%` symbol will mess up placeholder starts and ends, breaking all placeholders after it. To make the symbol display correctly without messing up placeholders, use `%%` to display the symbol.
All TAB's internal placeholders are listed above. Some of them are bukkit only (meaning they won't work on bungeecord) and some are bungee only. **Trying to use a bukkit-only placeholder on bungeecord will not work.**
If you want to use those, [set up PlaceholderAPI support on bungeecord](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) and find their PlaceholderAPI equivalent. Large portion of those are included on [PlaceholderAPI's wiki](https://github.com/PlaceholderAPI/PlaceholderAPI/wiki/Placeholders).
For example you can use %vault_prefix% instead of %vault-prefix%, %player_health% instead of %health% and so on.
## PlaceholderAPI placeholder is not working
If you have TAB installed on bungeecord, make sure you [set up PlaceholderAPI support on bungeecord](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) as there is no other way to retrieve data from technically a different server.
If you have TAB on bukkit or the previous step did not work, make sure it works when using `/papi parse me <placeholder>`. If it does not work, the issue is not on TAB's end.
# API
*To get started with the API, see [Developer API](https://github.com/NEZNAMY/TAB/wiki/Developer-API) page.*
For working with placeholders, you will need the `PlaceholderManager`. Get it using `TabAPI.getInstance().getPlaceholderManager()`.
Placeholders have two attributes:
* An identifier, which is used to uniquely identify the placeholder. This is also what's usually used for replacement. For example, in `%uptime%`, the identifier is `%uptime%`.
* A refresh rate in milliseconds, which is how often the placeholder's refresh function will be called, to get a new value to display. Use `-1` to make the placeholder never refresh periodically. This can be used for either constants or placeholders that update on events and you wish to update their value manually using functions in respective placeholder interface.
## Server placeholders
Server placeholders are global to the entire plugin. Their values are not dependent on player.
Examples of server placeholders would be uptime and TPS placeholders.
To register a new server placeholder, use `PlaceholderManager#registerServerPlaceholder(String, int, Supplier<Object>)`. The first two parameters are explained above, and the last parameter is a function that will be called to refresh the value of the placeholder.
This placeholder will show current system time and update every 50 milliseconds.
</details>
## Player placeholders
Player placeholders are calculated on a per-player basis. These depend on the player that we want to get the value for.
Examples of player placeholders would be nickname and prefix.
To register a new player placeholder, use `PlaceholderManager#registerPlayerPlaceholder(String, int, Function<TabPlayer, Object>)`. The first two parameters are explained above, and the last parameter is a function that will be called to refresh the value of the placeholder.
<details>
<summary>Example</summary>
```
TabAPI.getInstance().getPlaceholderManager().registerPlayerPlaceholder("%player-uuid%", -1, player -> player.getUniqueId());
```
This placeholder will show player's UUID and never refreshes, since UUID doesn't change at runtime.
</details>
## Relational placeholders
Relational placeholders are calculated using a pair of players, instead of a single one. These depend on the player pair that we want to get the value for. Their identifier must start with `rel_`.
To register a new relational placeholder, use `PlaceholderManager#registerRelationalPlaceholder(String, int, BiFunction<TabPlayer, TabPlayer, Object>)`. The first two parameters are explained above, and the last parameter is a function that will be called to refresh the value of the placeholder.
This placeholder will show version of players, but only to those, who have `tab.staff` permission. First player in the method is viewer, second player is target. Same order is applied when hooking into PlaceholderAPI as well.
This is a quick guide for [PlaceholderAPI](https://www.spigotmc.org/resources/placeholderapi.6245/) plugin, which is often referred to on the wiki and we also get many assistance requests with TAB which turn out to be asking for help with PlaceholderAPI. Whether its documentation is not clear enough, missing information or users just don't read it isn't the topic here to judge, instead, a quick guide with everything needed is provided.
# Installation
PlaceholderAPI is a standalone bukkit plugin which can be installed just like any other plugin. It does not support BungeeCord. If you have TAB on BungeeCord and wish to use PlaceholderAPI placeholders, you'll need to install [Bridge](https://www.spigotmc.org/resources/83966) plugin on backend servers. Alongside other features, it forwards PlaceholderAPI support to the proxy.
# Expansions
In order to effectively scale and allow the level of modification it does, PlaceholderAPI is using placeholder packages called expansions. They are loaded into the plugin on startup. Each expansion can be created and modified independently of the main plugin's update frequency. Each expansion has a name, which is used to identify its placeholders.
The syntax is `%<expansion name>_<placeholder>%`, where `<expansion name>` is name of the expansion, for example `player` and `<placeholder>` is placeholder of the expansion, for example `health`, which returns player's health. The full placeholder syntax will then be `%player_health%`.
You can therefore guess name of the expansion which a placeholder you are trying to use comes from. You have 2 ways of getting expansions. Which one it is for your specific placeholder expansion should be included in documentation.
## External expansions
First way is using external jars, which are stored on [PlaceholderAPI website](https://api.extendedclip.com/all/). You can get them by either manually downloading them into `plugins/PlaceholderAPI/expansions/` folder, or by running `/papi ecloud download <expansion name>`.
To load new expansions, run `/papi reload`.
## Expansions in plugins
PlaceholderAPI expansion is in the end just a java class (or a set of classes), which can also be included in the plugin they are hooking into. If wiki of the plugin says something like "no download command" or "expansion is included in the plugin", it's this case. You can also identify this case by trying the previous method and download command saying expansion was not found.
If no further installation steps are provided, these expansions are automatically enabled when their respective plugin is installed.
# Managing installed expansions
To see what expansions are currently enabled, run `/papi list`. It will show list of all currently enabled expansions. If you downloaded an expansion but it's not in the list, it may have failed to enable due to an error. Check console if you got any errors on startup.
Updating expansions can be done in the same way as installing them. For external expansions, run the download command or download it manually and reload. For expansions in plugins, they always contain "latest" (the only) version of the expansion, so if a new placeholder was added, you need to update the plugin.
# Checking if placeholder is working
To check if a placeholder is working, run `/papi parse <player> <placeholder>`. You can also use `me` as player, which parses placeholder for the player who ran the command. If the command outputs the identifier you entered and not the actual output, it means you either entered and invalid placeholder or you are missing an expansion (or you have an outdated version of the expansion), see above.
When TAB is installed on BungeeCord, the plugin has very limited access to information. It is unable to retrieve internal server data, as well as hook into backend plugins, because it's a different server.
Bridge is a backend plugin that sends this data to the proxy, allowing TAB to work better when installed on BungeeCord.
You can download it from [GitHub](https://github.com/NEZNAMY/TAB-Bridge/releases) or [Spigot](https://www.spigotmc.org/resources/83966).
# Installation
Installation is as simple as it can be. Put it into plugins folder of your backend servers. **Bridge is NOT a BungeeCord plugin!** Bridge itself has no config file, as everything is configured in the main plugin.
# Features
* Forwarding PlaceholderAPI support to the proxy
* Allow detection if player is invisible to make nametag invisible (compensation for 1.8.x client sided bug)
* Allow detection if player is disguised to disable collision to prevent endless push
* Forwarding permission groups of players if no permission plugin is installed on BungeeCord
* Forwarding vanish status for compatibility with global playerlist / layout features
* Forward player's world for %world% and per-world settings
* Allow TAB's PlaceholderAPI expansion with TAB on BungeeCord
* Encodes scoreboard packets (if TAB is installed on Velocity, which doesn't offer them)
* Forward player's gamemode for spectator fix feature to work
# Compatibility
Just like with Minecraft, when there is a change in the communication protocol, older software will not be compatible with the new one. You should always be running latest versions of both TAB and Bridge.
# Confirming it works
You have many ways to verify TAB and Bridge are properly connected. Besides checking if the features above work, the easiest one is to run `/btab debug <player>`.
If it's properly connected, you'll get a message saying this:
Whether the plugin runs in server's main thread (sync) or in a different thread (async). If a plugin is running sync, it may slow down the server's TPS. All of these features can be done async.
| Conditionally disable the feature | If any specified condition is met | ❌ |
| Bonus | - Option to use armor stands to bypass<br />all limits and support multiple lines<br />- Anti-override to avoid random plugins breaking it | - |
Support for all possible Minecraft versions containing features the plugin is able to take advantage of, support for multiple platforms (Bukkit, BungeeCord, Velocity, Fabric, Sponge), with everything contained in a single jar which you can download directly. No need to browse version history, ask what plugin version you need for your server version, visit random websites looking for the download button, or anything similar. The same jar supports all versions & platforms, and the latest plugin version will always work for you.
## It works
The plugin doesn't spam your console with errors, doesn't have compatibility issues with half of the plugins, and doesn't just decide to randomly stop working for no reason. It just works. Bug reports are fixed with highest priority and preferred over adding new features. It's not unusual for a plugin of this size to have a 3-digit open issue count on github. Meanwhile TAB is usually at 1-digit count.
## Feature packed
All of the most requested features in a single plugin. No need to install many plugins, disable features so they don't conflict with each other, or be forced to run your server on a version that all of the plugins support in common. All features, all server versions in a single plugin.
## Beyond the limits
Mojang decided to put some kind of limitation on almost every feature TAB offers. Other developers simply say "Mojang limit, nothing we can do about it, goodbye". This is not the case here. With every limitation I find, I look for ways to bypass it, and I've found most of them. These bypasses require a ton of work involved, and it's much easier to say "not possible" than actually doing it.
## Up to date
The plugin is not abandoned. It is constantly getting updated to fix reported bugs, add support for new MC versions as they come out and get new optimizations that can help it run as smoothly as possible, whilst still working the way you want it to.
## High performance
Unlike with other plugins where "high performance" often means your CPU usage will be high, TAB has a very low CPU footprint. There is a [command](https://github.com/NEZNAMY/TAB/wiki/Commands-&-Permissions#tab-cpu) available that shows the entire plugin's CPU usage. Here you can see which part of TAB is occupying the most of your CPU, and there are [many ways to optimize TAB](https://github.com/NEZNAMY/TAB/wiki/Optimizing-the-plugin) to get the most out of it, the most common being increasing refresh rates for individual placeholders if they're inefficient. This is done on a per-placeholder basis, instead of slowing down the refresh rate of an entire feature, which may break animations. Performance is also actively monitored on large servers, and observations show that it performs very well, meaning it will almost certainly perform even better on smaller servers.
## Simple yet powerful configuration
Compared to other plugins, each feature is easier to configure and actually offers more.
Want a simple result with simple configuration? No problem. Want a complicated result? No problem.
If this plugin has helped you in any way, and you would like to return something back
to make the plugin even better, there is a lot of ways to contribute:
* Open a **pull request** containing a new feature or a bug fix, which you believe many users will benefit from.
* Make detailed high-quality **bug reports**. The difference between a bug getting fixed in 1 week vs 1 hour
is in quality of the report (typically providing correct steps to reproduce that actually work).
* Test **experimental builds**, which can be found in [GitHub Actions](https://github.com/NEZNAMY/TAB/actions) for problems of any kind including bugs.
This way you will help make the actual releases more stable / help get stable releases sooner.
* Help improve the wiki by opening a [Wiki change issue](https://github.com/NEZNAMY/TAB/issues/new?assignees=&labels=Wiki&template=wiki_change.yml),
where you can improve existing descriptions, add information you found missing, fix typos / grammar mistakes or add more examples.
Here it is. After countless requests to go opensource, I did it to make those people quiet. It worked.
It's already been a year and I still can't see any positives of it. This way I just made it easierfor everyone to make a plugin as good, so people can stop using it and switch to something better. Or just get premium version for free.
## Compiling
Plugin can be compiled using maven. Once you've purchased the premium version, you can enable premium features by setting [this line to return true](https://github.com/NEZNAMY/TAB/blob/master/shared/src/main/java/me/neznamy/tab/shared/TAB.java#L78) and apply your code improvements. Enabling it without purchasing the plugin may result in the features not working correctly.
**No support is provided for self-compiled jars, only for official compilations.** If you compiled it yourself, it is highly likely you modified something, which might be the reason why is the plugin not working. If you didn't modify anything, you can just get the plugin from official download locations.
TAB aims to be a superior all-in-one minecraft plugin for displaying information that outperforms all
similar plugins in terms of features, performance and compatibility.
More information can be found at [Why TAB?](https://github.com/NEZNAMY/TAB/wiki/Why-TAB%3F) wiki page.
# Download
### Releases
You can download full releases from [GitHub releases](https://github.com/NEZNAMY/TAB/releases),
[SpigotMC](https://www.spigotmc.org/resources/57806/), [Modrinth](https://modrinth.com/plugin/tab-was-taken) or [BuiltByBit](https://builtbybit.com/resources/20631).
## Maven Repository
```
<repositories>
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
</repositories>
### Dev builds
Plugin's development is continuous and contains lots of small changes/fixes not worthy of being called a full
update, therefore development builds are being created and eventually a full update is released when enough changes are made.
If you want to benefit from a recent change in the code before official release, you can download development builds
from [GitHub actions](https://github.com/NEZNAMY/TAB/actions) (you must be logged into GitHub to be able to download it).
<dependencies>
<!-- TAB -->
<dependency>
<groupId>com.github.NEZNAMY</groupId>
<artifactId>TAB</artifactId>
<version>2.9.0</version>
</dependency>
</dependencies>
```
# Compiling
Compilation requires JDK 21 and up.
To compile the plugin, run `./gradlew build` from the terminal.
Once the plugin compiles, grab the jar from `/jar/build/libs/` folder.
The universal jar contains all modules for all supported platforms.
# Documentation
You can find everything about the plugin on the [Wiki](https://github.com/NEZNAMY/TAB/wiki). This includes a detailed description
of all features, as well as information regarding compatibility or limitations of each feature.
# Issues
The [Issues](https://github.com/NEZNAMY/TAB/issues) section is an issue tracker for all the kind of problems covered in issue templates.
Please refrain from attempting to use it to receive help with your server, such issues will be closed immediately.
When opening an issue, provide as much information as possible. The difference between a bug getting fixed in 1 week vs 1 hour
is in quality of the report. Bug reports where steps to reproduce are "idk" have no value and will not help to get the bug fixed at all.
# Contributing
See [CONTRIBUTING.md](https://github.com/NEZNAMY/TAB/blob/master/CONTRIBUTING.md)
# Provided services
The plugin is being used by a large amount of servers, which also means the demand for my attention is high. Unfortunately,
I am no longer able to keep up with the demand since I don't want to dedicate my whole existence to a free plugin.
In order to provide the best quality of all provided services, the amount of services provided may vary over time.
Here is the full list of potential services and their status:
| Service type | Availability |
|-------------------------------|--------------|
| Updates for new MC versions | ✔ |
| Bug fixes | ✔ |
| Wiki improvements | ✔ |
| Performance optimizations | ✔ |
| Feature requests | ❌ |
| Customer support<sup>1</sup> | ✔ |
| Free user support<sup>2</sup> | ❌* |
<sup>1</sup> - Unrestricted assistance with the plugin for those, who bought a copy of the plugin when it was purchasable.
<sup>2</sup> - Unlimited access to my free time for everyone in the world.
*Instead, you can use [this fresh new community discord](https://discord.gg/YPqXt63YQj) made by a nice person who will provide this service.
Loaded 100 of 634 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.