- Introduces a new method to replace all current scoreboard lines with a provided list.
- Prevents unnecessary updates if the new list is identical to the current one.
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.
| images | Folder containing all images used in the descriptions and wiki for advertising. Used not only as a backup, but for hosting them as well, so we do not need to rely on third party websites. |
| description_markdown.md | Plugin description written in **markdown** syntax. Used by **Modrinth**. |
| description_bbcode.txt | Plugin description written in **bbcode** syntax. Used by **SpigotMC** and **BuiltByBit**. |
TAB is an all-in-one plugin for displaying information in various places, which aims to outperform all similar plugins in terms of features, compatibility and performance.
The compact configuration allows you to get the plugin to work the way you want regardless of how simple or complex you want it to be or how experienced you are. The default configuration already contains useful values and examples to give you a better understanding and get you started quickly with instant results. The extensive [URL='https://github.com/NEZNAMY/TAB/wiki']wiki[/URL] answers any of your questions.
Official support by me is no longer provided to free users due to limited time and extreme inefficiency (see [URL='https://github.com/NEZNAMY/TAB?tab=readme-ov-file#provided-services']provided services[/URL] for more info).
However, you can join this [URL='https://discord.gg/YPqXt63YQj']fresh new community discord[/URL] made by a nice person who promises to help everyone with all plugins, including TAB.
Before you consider requiring assistance, check out the [URL='https://github.com/NEZNAMY/TAB/wiki']wiki[/URL] first. It will answer any questions you may have and is also constantly getting improved.
TAB is an all-in-one plugin for displaying information in various places, which aims to outperform all similar plugins in terms of features, compatibility and performance.
The compact configuration allows you to get the plugin to work the way you want regardless of how simple or complex you want it to be or how experienced you are.
The default configuration already contains useful values and examples to give you a better understanding and get you started quickly with instant results.
The extensive [wiki](https://github.com/NEZNAMY/TAB/wiki) answers any of your questions.
Official support by me is no longer provided to free users due to limited time and extreme inefficiency (see [provided services]([https://github.com/NEZNAMY/TAB?tab=readme-ov-file#provided-services](https://github.com/NEZNAMY/TAB?tab=readme-ov-file#provided-services)) for more info).
However, you can join this [fresh new community discord]([https://discord.gg/YPqXt63YQj](https://discord.gg/YPqXt63YQj)) made by a nice person who promises to help everyone with all plugins, including TAB.
Before you consider requiring assistance, check out the [wiki](https://github.com/NEZNAMY/TAB/wiki) first. It will answer any questions you may have and is also constantly getting improved.
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.
TAB is not a vanish plugin and does not manage vanishing players in any way, therefore, is not responsible for removing vanished players from the tablist.
However, it checks 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](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Nametags#additional-note-6---vanish-hook) 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](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Nametags#additional-note-6---vanish-hook), 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 proxy,
[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 vanish status of a player 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
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 the 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-Sidebar-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 the best possible experience on each Minecraft version.
## Detection
When TAB is installed on a proxy, the proxy's API is used to get player's 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 by using any of the following:
*`/tab parse <player> %player-version%` - Shows 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 proxy 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` - This was an issue in the past and hasn't been reported in years now.
When a player's 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 alter its logic in some way.
If a player's version is not detected correctly, a side effect might occur instead, making the situation worse.
You will not experience all of these, only those that affect the version difference between the server and client.
| Change of logic | Negative side effect if version is not detected correctly |
| Disabling [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) for 1.7 players | [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) entries being sent into the tablist of the player, breaking it as the layout is not designed support 1.7 |
| Use alternate way of sorting [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) entries for 1.19.3 - 1.21.1 as the optimal sorting way cannot be used | [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) entries being out of order for 1.19.3 - 1.21.1 <br />Layout entries appearing in chat complete for <1.19.3 even if they don't have to |
| Show 1.9+ bossbar on 1.8 servers for 1.9+ players using ViaVersion API | No 1.9+ bossbar for 1.9+ players on 1.8 server |
| Disabling [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) | Trying to fit the entire formatting into 16 characters, resulting in massive cutting and nametag feature not working |
| Play around <1.13 limitations of [Scoreboard](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Scoreboard) | Scoreboard lines limited to ~26 characters, even for 1.13+ clients <br />Scoreboard lines limited to 14 characters for < 1.13 clients |
| Cutting nametag prefix/suffix to 16 characters for <1.13, but keeping it full for 1.13+ | Nametag prefix/suffix being cut to 16 characters, even for 1.13+ clients |
# Debug config option
You may have noticed `debug: false` in your config.
Enabling it will unlock extra console messages beyond the usual misconfiguration / errors.
They give deeper information about what's going on in the plugin in case a more complex issue comes up.
Currently, it offers the following:
* Makes plugin print thrown errors into console as well, instead of just errors.log file. They are printed into the console even if the error log reaches the 16MB limit.
* Sends a message saying 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 their nickname (or resets it), a message should pop up.
* Sends a message whenever another plugin sends a scoreboard (such as a mini-game plugin) and TAB hides its own. Then, when that other plugin removes its scoreboard, TAB sends its own back (and sends a console message).
* Sends a message regarding the 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, the 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.
* On proxy installation, shows how long did Bridge take to answer player join plugin message. This should be below 100ms. If it's continuously significantly higher, it suggests something bad is going on, either bridge being overloaded or the server itself.
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, playerlist objective, 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. You can do this by creating an animation with one frame.
* Adding to the previous point, animations can be used as a way to wrap a placeholder, having two different identifiers return the same value, allowing to use both original and replaced output from [Placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements).
# External tools
If you want an animation 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 number of frames and the same change interval will be synchronized.
If you want to synchronize multiple animations with a different change interval and different number 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.
* [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
Tablist names can be formatted in 2 ways. The main one, designed explicitly for tablist names was added into Minecraft in version 1.8 and can be controlled by TAB's [Tablist name formatting](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Tablist-name-formatting) feature.
If the feature is disabled or not applied properly (disabled with condition, some deeper compatibility issue ...), nametag prefix/suffix will be displayed in tablist instead. This mechanic is also used for <1.8 players due to 16-character tablist name limit there. You can also do this intentionally, for example for better performance.
If you don't want any prefixes in tablist, keep the feature enabled but don't set any prefix / suffix. Disabling this feature 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 the commands and permissions that are available with TAB.
Commands have required permissions associated with them.
**Users who installed TAB on a proxy server:**
* 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 proxy, permission nodes are checked on the proxy, 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.
* Giving yourself OP on the backend server does not give you permissions on the proxy. It's a completely different server. You'll need to give yourself permissions using a permission plugin installed on the proxy (unless you enabled the option above).
* You are not able to execute proxy commands using a backend plugin (for example some menu plugin). If you want to achieve this, you'll need to find an updated plugin that allows you to send commands to the proxy.
* **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 proxy, 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, 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. Handy when plugin is connected to MySQL, where you have no other way to effectively check group settings.
## /tab groups
* **Permission:** `tab.grouplist`
* **Description:** Shows a 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.nametag.view` (`tab.nametag.view.other` for toggling for other players)
* **Description:** Shows / hides / toggles nametag VIEW a specified player.
* **Options:**
*`-s` for silent toggling (no chat message for affected player)
## /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 that are impossible to be measured, so this shows slightly less than the real value is. The content is self-explanatory. All major 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`. It can be used to verify if a placeholder works as expected.
# Additional permissions
*`tab.admin` - Allows the player to execute all commands.
*`tab.bypass` - If the 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 have the permission 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 [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout).
* [Supported server software and versions](#supported-server-software-and-versions)
* [Supported features per platform](#supported-features-per-platform)
* [Plugin / mod hooks](#plugin--mod-hooks)
* [Compatibility issues](#compatibility-issues)
# Requirements
TAB does not depend on any other plugins. The experience can however be enhanced by installing other plugins, see below.
## Java
TAB's shared module is compiled with Java 8. For the platforms themselves, TAB does have a higher requirement, however, it does not require a Java version higher than the server software itself does. Specifically:
<sup>1</sup> Modded platforms only support the latest MC version(s). For older MC versions try [Modrinth](https://modrinth.com/plugin/tab-was-taken)'s version download filter. If TAB is not available for your desired Minecraft version or is very outdated, you may [request a backport](https://github.com/NEZNAMY/TAB/issues/new?template=backport.yml).
<sup>2</sup> Latest only doesn't mean only the latest build will work,
it means the plugin was made to be compatible with the 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, the plugin is updated to support the 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/build of your proxy software if the plugin requires it.
| All platforms | [**Floodgate**](https://github.com/GeyserMC/Floodgate) - For properly detecting bedrock players to adapt features for the best possible user experience. <br /> [**LuckPerms**](https://github.com/LuckPerms/LuckPerms) - Detecting permission groups of players for per-group settings. <br /> [**ViaVersion**](https://github.com/ViaVersion/ViaVersion) - For properly detecting player's version to adapt features for the 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. <br />[**PlaceholderAPI**](https://github.com/PlaceholderAPI/PlaceholderAPI) - Allows users to use its placeholders inside TAB. <br />[**PremiumVanish**](https://www.spigotmc.org/resources/14404) - Supporting PremiumVanish's vanishing levels instead of using a basic compatibility system. <br />[**Vault**](https://github.com/milkbowl/Vault) - Detecting permission groups of players for per-group settings. |
| BungeeCord | [**PremiumVanish**](https://www.spigotmc.org/resources/14404) - Supporting PremiumVanish's vanishing levels instead of using a basic compatibility system. <br />[**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. <br />[**placeholder-api**](https://modrinth.com/mod/placeholder-api) - Displaying placeholders from that mod and offering TAB's placeholders into it. |
| Forge | [**LuckPerms**](https://github.com/LuckPerms/LuckPerms) - Permission checks with a string instead of using vanilla OP levels. <br /> [**ForgePlaceholderAPI**](https://github.com/EnvyWare/ForgePlaceholderAPI) - Allows users to use its placeholders inside TAB. <br /> [**Vanishmod**](https://modrinth.com/mod/vanishmod) - Getting player's vanish status. |
| NeoForge | [**LuckPerms**](https://github.com/LuckPerms/LuckPerms) - Permission checks with a string instead of using vanilla OP levels. |
| Velocity | [**PremiumVanish**](https://www.spigotmc.org/resources/14404) - Supporting PremiumVanish's vanishing levels instead of using a basic compatibility system. <br />[**RedisBungee**](https://github.com/ProxioDev/RedisBungee) - Communicating with other proxies to properly display visuals on players on another proxy. <br />[**VelocityScoreboardAPI**](https://github.com/NEZNAMY/VelocityScoreboardAPI) - Sending scoreboard packets (scoreboard-teams, belowname-objective, playerlist-objective, scoreboard) |
# 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.
* Some Skript addons may cause features to not work properly, such as sorting and scoreboard.
* **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 proxy 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. Avoid this combination. Either install ViaVersion on all backend servers instead or install TAB on the proxy as well.
* **Nexo**'s `hide_scoreboard_numbers` config option (may apply to ItemsAdder and Oraxen as well) makes [Belowname](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Belowname)'s and [Playerlist objective](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Playerlist-Objective)'s `value` and `fancy-value` not visible. When using these features, you'll need to keep the option disabled.
* **LimboAuth** may prevent TAB from applying tablist formatting in a way that is not detectable using Velocity API, resulting in the feature not working properly on join.
* **Custom clients / resource packs** - Unofficially modified Minecraft clients often tend to break things. Just Lunar client has tons of 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 a clean vanilla client. If it works there, it's an issue with the client / resource pack and TAB cannot do anything about it.
For example, 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.
* Rendering belowname 3 times.
* They don't respect nametag visibility rule, showing their own nametag using F5 even if set to invisible by the plugin.
* When the 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.
* **XCord** - Has additional amazing optimizations that prevent TAB from being able to read outgoing packets and modify them if needed, resulting in some features not working properly, such as [tablist name formatting](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Tablist-name-formatting).
* **Random Spigot/BungeeCord forks** - All safe patches for improving security & performance are present in well-known public open-source 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 a 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.
This page explains how to import TAB's API into your project and together with other pages everything you can do with it.
Before starting please seriously reconsider if you really need this and cannot already achieve it using existing features (such as registering placeholders into PlaceholderAPI instead of TAB, using display conditions for scoreboards, ...). If not, consider making a request.
# Adding the dependency
For Maven users, you can add the API dependency like this:
> 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**.
> [!WARNING]
> If you are on Paper and your plugin is defined as a paper plugin (paper-plugin.yml), TAB's classes may not be visible to the class loader that loaded your plugin. To avoid this issue, do not use paper-plugin.yml in your plugin, just plugin.yml.
# Getting started
First, 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 on 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:
* [Example 2 - Hiding `title` for 1.20.3+ players](#example-2---hiding-title-for-1203-players)
* [Example 3 - Displaying health as 0-10 or in %](#example-3---displaying-health-as-0-10-or-in-)
* [Example 4 - Health bar using hearts](#example-4---health-bar-using-hearts)
* [Tips & Tricks](#tips--tricks)
* [Tip 1 - Heart symbol](#tip-1---heart-symbol)
# About
This features gives you control over Minecraft's scoreboard objective feature with BELOW_NAME slot.
This line is displayed below the nametags of all player entities in game. It is not possible to explicitly disable this feature for NPCs; however, this goal can be achieved (see below for more info).
It is only visible when within an 8-block range of the player (the range is hardcoded in the client and cannot be changed with a plugin).
The displayed line is not one continuous configurable text. It consists of 2 parts (score and title) joined with a space.
The exact format is `[score]` + space + `title` (no, the space cannot be removed), where `[score]` is:
*`value` for 1.20.2- (will show `0` on NPCs), which only supports numbers (integers)
*`fancy-value` for 1.20.3+ (will show `fancy-value-default` on NPCs), which supports any text
As you can see, the feature still has limits, even on 1.20.3+. If you are below this version or still don't like the forced space before title, you are out of luck and cannot use this feature the way you would like to. If you have seen this feature seemingly limitless, it could be a feature that was a part of TAB, but removed later. This feature hid the original nametag and placed invisible armor stands instead. If you are interested in this kind of solution, you'll need to look into other plugins.
# Configuration
The feature can be configured in **config.yml** under **belowname-objective** section.
This is how the default configuration looks:
```
belowname-objective:
enabled: false
value: "%health%"
title: "&cHealth"
fancy-value: "&c%health%"
fancy-value-default: "NPC"
disable-condition: '%world%=disabledworld'
```
All the options are explained in the following table.
| value | %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 simplicity. |
| fancy-value | &c%health% | [1.20.3+] Any text, supports placeholders with per-player output. Only visible on 1.20.3+, where it completely replaces `value`. |
| fancy-value-default | NPC | [1.20.3+] Default number format (`fancy-value`) for all player entities. `fancy-value` is displayed on 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+. |
| title | Health | Shared label shown after the score for every player entity. Player sees the same text on everyone (= placeholders are parsed for the viewer). Use the `value`/`fancy-value` fields for per‑player data; use `title` only for static labels like `Health` or placeholders which are supposed to be parsed for the viewing player. |
| disable-condition | %world%=disabledworld | A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) (either name of a condition or a conditional expression) that must be met for disabling the feature for players. Set to empty for not disabling the feature ever. <br/> **Note**: Disabling the feature for a player means sending objective unregister packet to them, which results in player not seeing belowname on anyone anymore. It doesn't work the other way around - you cannot disable this feature on target players, only for viewers. |
# Limitations
* [1.12.2-] Title length is limited to 32 characters (including color codes).
* [1.20.2-] `value` is limited to a white number.
* [Bedrock] Doesn't support 1.20.3+ features (`fancy-value`), `value` will be displayed instead, just like on <1.20.3.
* The format is a **[score] + space + shared title**. No, the space cannot be removed.
* The title is the same on all players, therefore, it cannot be personalized (such as player's faction). Only [score] can be per-player.
* It appears on all entities of player type. **This includes player NPCs.**
# Compatibility with other plugins
TAB does not contain any sort of compatibility functionality for this feature.
It will not try to prevent other plugins from applying the feature and neither will it detect it to re-add back once the other plugin removes it.
Therefore, if another plugin also sends belowname objective, TAB's may not show anymore (depending on who sends it first).
Make sure you do not have any other plugin sending it to ensure the feature works properly.
You can check the list of objectives registered by either commands or plugins using Bukkit API using `/scoreboard objectives list`.
If it contains one that could be the cause, you can unregister it by running `/scoreboard objectives remove <name>`. After doing so, reload TAB, so it resends its objectives again.
Note that if this was automatically generated by a plugin, it will probably be added back again.
The Minecraft feature is programmed to be affected by nametag visibility rule.
This means that when the 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.
## Additional note 3 - Visible on NPCs
Belowname objective is automatically attached to all entities of player type with the default value of
`0` (<1.20.3) or value configured as `fancy-value-default` (1.20.3+).
This includes player NPCs.
There is currently only one way to make them not visible on NPCs.
From [Additional note 1 - Copying nametag visibility rule](#additional-note-1---copying-nametag-visibility-rule) we know
that belowname is not visible if player's nametag is invisible.
NPC plugin can take advantage of this by using teams to hide the original name and display a hologram instead.
This is how you can achieve it using the following popular NPC plugins:
***Citizens**:
* 1 - Select the NPC (`/npc select <ID>` or `/npc select` to select the nearest NPC)
* 2 - Hide its original nametag (which also hides belowname) using `/npc name`
* 3 - Display your desired text using `/npc hologram add <text>` ([more info](https://wiki.citizensnpcs.co/Commands#:~:text=the%20NPC%20hitbox-,/npc%20hologram,-add%20%5Btext%5D%20%7C%20set))
* **FancyNpcs with FancyHolograms**:
* 1 - Create a hologram with `/hologram create text <name>`.
* 2 - Link your newly created hologram with your NPC: `/hologram edit <hologram name> linkWithNpc <NPC name>`.
Its original name will be hidden automatically, so you don't need to manually do it.
* 3 - Change the NPC's name by editing your hologram's line(s): `/hologram edit hi setline 1 <text>`.
You can also add more lines if you want. See [FancyNpcs's wiki](https://docs.fancyinnovations.com/fancyholograms/commands/hologram/#text-hologram-modification) for more commands & info.
# Additional note 4 - Compatibility with modified clients
Sadly, this feature is suffering from bugs introduced by third party clients such as Feather and Lunar. These two completely ignore `fancy-value` as if it was never added into the game, even on 1.20.3+. This is just an example, and it's not limited to these two clients and this one issue. If you experience issues with the feature and believe you configured it correctly, use vanilla client to make sure it's not caused by a broken client.
# Examples
## Example 1 - Per-world values
This feature doesn't directly support per-world values or similar.
However, this can be achieved with conditions.
Let's make `fancy-value` conditional based on player's world.
Let's make an example with 3 worlds.
Check if player is in world `world1`, then show one text.
If not, check if player is in world `world2`, then show another text.
If not, show the final text.
This can be achieved by chaining 2 conditions:
```
conditions:
belowname1:
conditions:
- "%world%=world1"
true: "Text to display in world world1" # Player is in world world1, display the text
false: "%condition:belowname2%" # Player is not in world world1, check another condition
belowname2:
conditions:
- "%world%=world2"
true: "Text to display in world world2" # Player is in world world2, display the text
false: "Text to display in other worlds" # Player is not in any of the 2 worlds
```
> [!WARNING]
> DO NOT JUST RANDOMLY PASTE THIS ENTIRE "CONDITIONS" SECTION INTO YOUR CONFIG!
> INSTEAD, EDIT YOUR EXISTING CONDITIONS SECTION TO PREVENT HAVING THE SECTION TWICE,
> HAVING SECOND ONE COMPLETELY OVERRIDE THE FIRST ONE!
Finally, use this condition as value in `fancy-value`:
```
belowname-objective:
fancy-value: "%condition:belowname1%"
```
If you are under 1.20.3 and want to make `value` and `title` conditional,
create two condition chains, one for each value and use them.
> [!NOTE]
> This is just an example, the plugin is not limited to displaying different values only per world.
> If you want per server values on proxy, use %server% with server names.
> This works for any placeholder offered by TAB or by PlaceholderAPI.
## Example 2 - Hiding `title` for 1.20.3+ players
1.20.3 has replaced `value` field,
which is limited to a white number with value configurable as `fancy-value`, which has no limits.
However, `title` field is still visible on 1.20.3+.
If you support both version ranges and want to make the best out of the new functionality,
you might want to not show `title` to 1.20.3+ players anymore,
since you can fully customize the text you want to display in `fancy-value`.
First, let's remind ourselves what `title`*actually* is.
It is actually called scoreboard title.
Yes, just like the one on top of sidebar, just displayed elsewhere.
This is why it displays on all players and placeholders are parsed for the viewing player.
With this knowledge, all we need to do is check for player's version and only show something for <1.20.3.
For this, we will use `%player-version-id%` placeholder,
which returns the network protocol version of player's game version, which can then be compared to.
```
conditions:
version:
- "%player-version-id%>=765" # 1.20.3 is 765
true: "" # Show empty value for 1.20.3+
false: "Some text to display"
```
> [!WARNING]
> DO NOT JUST RANDOMLY PASTE THIS ENTIRE "CONDITIONS" SECTION INTO YOUR CONFIG!
> INSTEAD, EDIT YOUR EXISTING CONDITIONS SECTION TO PREVENT HAVING THE SECTION TWICE,
> HAVING SECOND ONE COMPLETELY OVERRIDE THE FIRST ONE!
```
belowname-objective:
title: "%condition:version%"
```
Unfortunately, due to the limitations of this feature,
there is a forced space between `value`/`fancy-value` and `title`,
even if the `title` is empty.
You'll either need to live with it, or put some shared text there to avoid having a space at the end.
## Example 3 - 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
## Example 4 - Health bar using hearts
You can achieve this on `1.20.3+` using `healthbar` expansion from PlaceholderAPI:
Sadly, there is no way to remove the forced space between `fancy-value` and `title`. You can only try to play around it by adding some static text after it, to make it look like the space is intended. Or you can just ignore the space and live with it.
# Tips & Tricks
## Tip 1 - Heart symbol
If you want to show health of players and display a heart symbol instead of text saying "Health", you can use this one: `❤`.
```
belowname-objective:
title: "&4❤"
```
> [!IMPORTANT]
> Make sure your config is [saved in UTF-8 encoding](https://github.com/NEZNAMY/TAB/wiki/How-to-save-the-config-in-UTF8-encoding) to properly read the heart symbol.
| toggle-command | /bossbar | A command to toggle bossbar visibility for player running the command. This command requires `tab.bossbar.toggle` permission. <br />**Note:** Commands are not supposed to be registered / unregistered dynamically at runtime. As such, you may run into small issues when changing the toggle command and reloading. After you modify the command to your liking, reconnect to properly see it in tabcomplete. If you don't use TAB on a proxy, consider restarting the server as well for the old command to actually be unregistered. |
| 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. |
| bars | *Map* | Map of defined bossbars, see below for more information. |
Bossbars can be defined in `bars` section. Bossbar name can be anything, but you cannot use the same name for 2 bossbars.
| style | PROGRESS | Type of bossbar division. You can choose from 5 styles: **PROGRESS**, **NOTCHED_6**, **NOTCHED_10**, **NOTCHED_12** and **NOTCHED_20**. <br />  <br /> These were defined by mojang, no other options are available. Other plugins may be using different names, but it's the same result in the end. |
| color | BLUE | Color of bossbar. You can choose from 7 colors: **BLUE**, **GREEN**, **PINK**, **PURPLE**, **RED**, **WHITE** and **YELLOW**. <br />  <br /> These were defined by mojang, no other options are available. |
| progress | 100 | A number between 0 and 100. Accepts decimals. <br />  |
| text | "Hi" | Text of the bossbar. Length is not limited, supports RGB codes on 1.16+. Does not support newlines. |
| announcement-bar | false | When set to `true`, the bossbar will not appear by default, only when used in announce command. |
| display-condition | "%world%=world" | [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. |
| /tab bossbar show \<name\> \[player\] | `tab.bossbar.show` (for yourself) <br /> `tab.bossbar.show.other` (for others) | Shows the bossbar with the given `name`, either to yourself if no `player` was given, or to the given `player`. |
| /tab bossbar \[on/off/toggle\] \[player\] \[options\] | `tab.bossbar.toggle` (for yourself) <br /> `tab.bossbar.toggle.other` (for others) | Shows / hides / toggles bossbar of specified player. If no player was given, command affects the sender. You can use `-s` as option for silent toggling (no chat message for affected player) |
| /tab bossbar announce \<name\> \<duration\> | `tab.announce.bar` | Shows the bossbar with the given `name` to every player on the server for the given `duration`, in seconds. |
# Placeholders
## Internal placeholders
Here are TAB's internal placeholders you can use when this feature is enabled:
| Placeholder | Description |
|-------------|-------------|
| `%bossbar_announce_time_left_<bossbar>%` | Returns remaining time of the announcement of specified bossbar (in seconds). |
| `%bossbar_announce_time_total_<bossbar>%` | Returns total time of the announcement of specified bossbar (in seconds) (the inputted number). |
You can further use these placeholders in progress, for example, using Math expansion from PlaceholderAPI, such as `%math_{tab_placeholder_bossbar_announce_time_left_<bossbar>}/{tab_placeholder_bossbar_announce_time_total_<bossbar>}*100%` (remember to replace `<bossbar>` with the actual name of the bossbar).
## PlaceholderAPI placeholders
Here are TAB's PlaceholderAPI placeholders you can use when this feature is enabled:
| Placeholder | Description |
|-------------|-------------|
| `%tab_bossbar_visible%` | "Enabled" if visible (not toggled with a command), "Disabled" if not (toggled with a command) |
# 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.
# Compatibility with other plugins
Bossbar is a feature that can have multiple instances sent and displayed, so there is no possible conflict like in scoreboard for example. Every plugin manages its own bossbars and doesn't care about others.
One thing to mention is the order of bossbars. They are ordered by the order they were received. This means the final order depends on which plugin is faster (or slower), which is something you can't really control. As such, there is no feasible way to control the order of bossbars across different plugins. TAB's own bossbars are sent in the order they are defined in the configuration, so that won't be a problem.
# 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 is invisible and force your players to get the resource pack.
Here is how to do it:
**Minecraft 1.20+**:
* Navigate to `assets/minecraft/textures/gui/sprites/boss_bar`. You will need to create 2 files. In this example, we will use `WHITE` Bossbar color.
* Use GIMP or any other photo editing software and create a **1x1 px** image, that is fully transparent.
* Name the file **white_progress.png**. Now copy-paste the same file and name it **white_background.png**.
**Minecraft 1.19.4-**:
* Navigate to `assets/minecraft/textures/gui/`. You will need to download the default `bars.png` file (https://github.com/Faithful-Pack/Default-Java/blob/1.19.4/assets/minecraft/textures/gui/bars.png).
* Use GIMP or any other Photo editing software and remove the White bars in the file. Save the file and move it to `assets/minecraft/textures/gui/`.
Finally, set your Bossbar color in TAB Config to `WHITE`. Now the line will be invisible!
# 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 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 the previous parameters 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.
# Examples
## Example 1 - Changing text
You can make the change text periodically using [animations](https://github.com/NEZNAMY/TAB/wiki/Animations).
First, create an animation in **animations.yml**, such as
```
BossBarText:
change-interval: 1000
texts:
- "Text1"
- "Text2"
```
Then, use the animation in bossbar configuration
```
bars:
ServerInfo:
style: "PROGRESS"
color: "PURPLE"
progress: "100"
text: "%animation:BossBarText%"
```
This bossbar will change text every second between `text1` and `text2`. You can make the change interval higher and add more texts to suit your needs.
> [!NOTE]
> This works for style, color and progress as well, not just text. Just make sure the animation returns a valid value accepted by the field (listed enum constants for style and color, number between 0 and 100 for progress).
## Example 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**:
```
bars:
full:
style: "PROGRESS"
color: "YELLOW"
progress: "100"
text: "&aYour health is full"
display-condition: "%health%=20"
notfull:
style: "PROGRESS"
color: "RED"
progress: "0"
text: "&cYou took damage"
display-condition: "%health%!=20"
```
## Example 3 - Periodical appearing and disappearing
This can be achieved using [animations](https://github.com/NEZNAMY/TAB/wiki/Animations) and [conditions](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders). We will create an animation with 2 frames and check if it's on the first one, then display the bossbar. Otherwise, don't display it.
To get started, create an animation in **animations.yml**:
```
animations:
bossbar-toggle:
change-interval: 10000
texts:
- "ON"
- "OFF"
```
Then, create a display condition that checks if the animation is on the first frame (`ON`):
```
bars:
ServerInfo:
display-condition: "%animation:bossbar-toggle%=ON" # Check for the first frame of the animation
style: "PROGRESS"
color: "PURPLE"
progress: "100"
text: "&fWebsite: &bwww.domain.com"
```
Now, the bossbar will appear and disappear every 10 seconds.
## Example 4 - Dynamic progress tracking a relative placeholder value
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.
> [!NOTE]
> 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 2 - Combining AND and OR](#example-2---combining-and-and-or)
# About
Conditions / conditional placeholders allow you
to create output which depends on the 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) or `disable-condition` for disabling a feature (scoreboard-teams, tablist-name-formatting, ...)
* Conditional placeholders which return defined outputs based on if the condition passes or fails
| `=` | Equal to | `%world%=world` will pass if player is in world `world` |
| `!=` | Not equal to | `%world%!=world` will pass if player is in any world except `world` |
| `<-` | Contains (left side for full text, right side text to contain) | `%world%<-lobby-` will pass if player is in any world that contains `lobby-` (such as `lobby-1` etc.) |
| `!<-` | Not Contains (left side for full text, right side text to not contain) | `%world%!<-lobby-` will pass if player is in any world that does not contain `lobby-` (such as `lobby-1` etc.) |
| `\|-` | Starts with (left side for full text, right side text to start with) | `%world%\|-lobby-` will pass if player is in any world that starts with `lobby-` (such as `lobby-1` etc.) |
| `!\|-` | Not Starts with (left side for full text, right side text to not start with) | `%world%!\|-lobby-` will pass if player is in any world that does not start with `lobby-` (such as `lobby-1` etc.) |
| `-\|` | Ends with (left side for full text, right side text to end with) | `%world%-\|nether` will pass if player is in any world that ends with `nether` (such as `world_nether` etc.) |
| `!-\|` | Not Ends with (left side for full text, right side text to not end with) | `%world%!-\|nether` will pass if player is in any world that does not end with `nether` (such as `world_nether` etc.) |
> [!NOTE]
> For `=` and `!=` you can check for empty output of a placeholder using `%my_placeholder%=` and `%my_placeholder%!=`.
> [!NOTE]
> For string operations, the text must match placeholder's output exactly, including color codes, as well as lower/UPPER case letters.
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:<value>` | Permission requirement | `permission:my.permission` will pass if player has `my.permission` permission |
| `!permission:<value>` | Negative permission requirement | `!permission:my.permission` will pass if player **does not have**`my.permission` permission |
# Usage
There are multiple different ways you can use conditions, all of which are described below.
## Conditional text
This way allows you to create conditional text that depends on other placeholders.
First, find the `conditions` section in your config and create a new condition like this one:
```
conditions:
lobby:
conditions:
- '%server%=lobby'
true: "You are in lobby"
false: "You are not in lobby"
```
This condition checks if player is in server `lobby` and if yes, displays `"You are in lobby"`, otherwise displays `"Your are not in lobby"`.
To check for more than just 1 condition, add more to the list. Additionally, you will now need to specify `type`, which is either `AND` or `OR`.
For example,
```
conditions:
lobby:
conditions:
- '%server%=lobby'
- '%server%=lobby2'
type: OR
true: "You are in lobby"
false: "You are not in lobby"
```
will return the lobby text if player is in server `lobby`**OR** in server `lobby2`. If you want both of those conditions to be required to display text, use `type: AND`.
It is not possible to combine both `AND` and `OR` in a single condition. To do that, create multiple conditions and use one inside another (see Example 2 below).
Now that the condition is created, we can use it using `%condition:lobby%`. This placeholder will return the texts configured in `true` and `false` values based on whether the condition was met or not.
## Using in a field where condition is expected
A lot of the features support either `display-condition` or `disable-condition`. The value configured is expected to be a condition. Let's say we want to use it as a display condition somewhere, for example when player is in server `lobby`. First, create the condition:
```
conditions:
lobby:
conditions:
- '%server%=lobby'
```
As you can see, `true` and `false` were not configured. This is because we are not trying to display any text, we are passing the condition as an object to evaluate.
Then, use `display-condition: lobby` in the feature. This will evaluate the condition named `lobby` and either display or not display the visual based on player's server. To check for 2 servers, use
```
conditions:
lobby:
conditions:
- '%server%=lobby'
- '%server%=lobby2'
type: OR
```
Now, the condition `lobby` will pass if player is in server `lobby`**OR** in server `lobby2`. To require both of the conditions to be met instead of at least 1, use `type: AND`.
It is not possible to combine both `AND` and `OR` in a single condition. To do that, create multiple conditions and use one inside another (see Example 2 below).
## Using in a field where condition is expected (short format)
When using condition as a `display-condition` or `disable-condition`, you don't need to specify `true` / `false` texts. In fact, you only need the list of conditions and separator (AND / OR).
For this purpose, short format was created. Instead of having to create a condition and using it, you can specify the expression directly.
**Single condition example**:
```
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**:
It is not possible to combine both `AND` (`;`) and `OR` (`|`) in a single condition. To do that, create multiple conditions and use one inside another (see Example 2 below).
## Relational conditions
> [!NOTE]
> This section only describes differences from standard conditions. For more information about those, see sections above.
Relational conditions allow you to check placeholder outputs for the player who is looking instead of only the target player.
To make placeholder check for viewer instead of the target player, use `%viewer:<placeholder>%` instead of just `%placeholder%`.
You can still check for target player using `%placeholder%` or `%target:<placeholder>%` (if you want to make it more clear for the reader).
Example: `%viewer:server%=%server%` will pass if viewer is in the same server as the target player.
There are 2 ways to use it:
* display-condition of layout player groups (which is currently the only feature supporting it as it would not make sense elsewhere)
* A placeholder using `%rel_condition:<condition>%` syntax
If trying to use relational condition in `%condition:name%` syntax, it will return a warning text instead of evaluating the condition.
Same the other way around, if trying to use standard condition in `%rel_condition:name%` syntax, it will return a warning text.
# Refresh interval
Conditions are just placeholders after all, and, as such, they must be refreshed periodically.
Refresh intervals of conditions are not directly configurable.
They are based on placeholders used inside (subconditions, true/false 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---all-platforms-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 - Combining AND and OR
If you want to combine both "AND" and "OR" types, create 2 conditions and use first one in the second 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 (or as a placeholder - `%condition:main%`). Note that `true`/`false` 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 other plugins](#compatibility-with-other-plugins)
# About
This feature allows you to see players from other servers, instead of only seeing players on the same server.
If TAB is installed on a backend server, you'll need to set up [Multi server support](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Multi-server-support) for proper linking of servers. On proxy installation, this is not required.
# Configuration
The feature can be configured in **config.yml** under **global-playerlist** section.
This is how the default configuration looks:
```
global-playerlist:
enabled: false
display-others-as-spectators: false
display-vanished-players-as-spectators: true
isolate-unlisted-servers: false
update-latency: false
spy-servers:
- spyserver1
- spyserver2
server-groups:
lobbies:
- lobby1
- lobby2
group2:
- server1
- server2
```
All of the options are explained in the following table.
| 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. |
| update-latency | false | When **enabled**, plugin will send ping update to players on other servers, since backend servers only send ping updates of players on the same server. This is displayed as the green bar in tablist, unless altered by a mod / resource pack (?). <br /> <br />When **disabled**, ping of players on other servers will be set to `0` (). <br /> <br />Disabled by default, because it's not only not very useful, but also has a very high CPU usage to due spamming a large amount of packets (especially on large networks). |
| spy-servers | *List* | See [Seeing all players on the network from some server](#seeing-all-players-on-the-network-from-some-server) |
| server-groups | *Map* | See [Grouping players only from certain servers](#grouping-players-only-from-certain-servers) |
## Grouping players only from certain servers
In case you want multiple servers to share playerlist,
but not with every server, 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 the proxy server.
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 the playerlist, simply clear server groups and set
```
server-groups: {}
```
### Pattern Matching
Server names in groups support multiple pattern types for flexible configuration:
**Exact Match** - Matches server name exactly:
```yaml
server-groups:
lobbies:
- lobby1
- lobby2
```
**Wildcard Patterns** - Use `*` for prefix or suffix matching:
```yaml
server-groups:
lobbies:
- "Lobby-*"# Matches: Lobby-1, Lobby-2, Lobby-Hub, etc.
- "*-lobby"# Matches: eu-lobby, us-lobby, etc.
```
**Regex Patterns** - Use `regex:` prefix for advanced pattern matching:
```yaml
server-groups:
lobbies:
- regex:Lobby-[0-9]+ # Matches: Lobby-1, Lobby-23, but not Lobby-Hub
smp:
- regex:SMP-(EU|US)-[0-9]+ # Matches: SMP-EU-1, SMP-US-2, etc.
```
Note: Wildcard patterns are case-insensitive, while regex patterns are case-sensitive by default (use `(?i)` flag for case-insensitive regex).
## 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),
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 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 other 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.
| designs | *Map* | Designs to display based on conditions (see below for more info). |
## Design
A header/footer design consists of the following options:
| Option name | Description |
|-------------|------------------|
| `display-condition` (optional) | [Condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) (either condition name or a conditional expression) <br /> that must be met for the design to be displayed. <br />If not defined, design will be displayed without any required condition. <br />If player does not meet condition, another design may be displayed <br /> based on chaining (see below for more info). |
| `header` | List of lines to display in the header. |
| `footer` | List of lines to display in the footer. |
**Example**:
```
header-footer:
enabled: true
designs:
MyDesign: # Design name
display-condition: "%world%=world" # Delete the line for no condition requirement
header:
- "Header for world %world%"
footer:
- "Footer for world %world%"
```
## Chaining designs
When defining more than 1 design in config, the plugin will display the correct design based on conditions.
The plugin goes through all defined designs, starting with the design on top.
If the design's condition is met or not set, it is displayed.
If not, the next defined design is checked and so on.
If no suitable design is found (the last one has a condition requirement which wasn't met), none is displayed.
**Example**:
```
header-footer:
enabled: true
designs:
per-world:
display-condition: "%world%=world"
header:
- "Header for world world"
footer:
- "Footer for world world"
default: # No display condition
header:
- "Header for every world except world"
footer:
- "Footer for every world except world"
```
Design `per-world` is checked first. If condition is not met, `default` is displayed.
If a chaining 3 or more and player meets 2 or more conditions for 2 (or more) different designs, the first one defined in the config will be displayed. You can swap order of designs based on your priority needs.
# Compatibility with other plugins
Header/Footer is a feature that cannot be handled by multiple plugins at once.
To make sure no other plugin sends their own Header/Footer when not disabled in the plugin's config properly, TAB will block header/footer coming from all other plugins if this feature is enabled (and not disabled for a player with a condition).
An exception to this is Velocity installation, where this "anti-override" is not available.
# Additional info
## Additional note 1 - [1.8 - 1.20.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 plugin that sends some, or even empty header/footer on join.
Velocity sends reset packet, so it isn't a problem there.
# 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:
To reset the header and/or footer for a player back to their original values, use `null` as argument.
# Examples
## Example 1 - Per-version header/footer
Minecraft 1.21.9 has introduced [object components](https://github.com/NEZNAMY/TAB/wiki/How-to-use-Minecraft-components#object-components-1219), but these are not available for older versions. Let's make 2 designs, one for 1.21.9+ and second one for <1.21.9.
For this, we can use design chaining with conditions. There is no limit to how many worlds we can configure, but let's stick to 3 designs - one for `world`, one for `world2` and one for the rest.
```
header-footer:
enabled: true
designs:
world:
display-condition: "%world%=world" # Only show if player is in world "world"
header:
- "Header for world world"
footer:
- "Footer for world world"
world2:
display-condition: "%world%=world2" # Only show if player is in world "world2"
header:
- "Header for world world2"
footer:
- "Footer for world world2"
default:
header:
- "Header for all worlds except world and world2"
footer:
- "Footer for all worlds except world and world2"
```
## Example 3 - 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.
This feature allows you to customize all 80 tablist slots. Displaying less than 4 columns is currently not supported ([here's why](https://gist.github.com/NEZNAMY/3dfcbf7d44283735d3c18266a2851651)). 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.
# Configuration
The feature can be configured in **config.yml** under **layout** section.
| 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. |
| default-skin | "mineskin:383747683" | Default skin to display for fixed slots that do not define a skin, empty slots and fixed slots with invalid skin. |
| enable-remaining-players-text | true | When enabled and there are more players in a player group than available slots, 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. Use `%s` variable for defining how many more players there are. |
| 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 |
| layouts | *Map* | Layouts to display based on conditions (see below for more info). |
## Layout
A layout consists of the following options:
| Option name | Description |
|-------------|------------------|
| `display-condition` (optional) | [Condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) (either condition name or a conditional expression) that must be met for the layout to be displayed. If not defined, layout will be displayed without any required condition. If player does not meet condition, another layout may be displayed based on chaining (see below for more info). |
| `default-skin` (optional) | Overrides global `default-skin` setting for this layout. |
| `slot-count` (optional) | Amount of slots to show in this layout. If not specified, defaults to `80`. **Only works on 1.19.3+**. |
| `fixed-slots` | List of fixed slots, see below for more info. |
| `player-groups` | Map of player groups, see below for more info. |
### 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]` (skin is optional). 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:
```
fixed-slots:
- '1|&3RAM&f:'
- '2|&b%memory-used%MB / %memory-max%MB'
- '3|&8&m '
- '4|&3TPS&f:'
- '5|&b%tps%'
```
If you do not wish to use any fixed slots, make it an empty list (`[]`).
Example:
```
layouts:
staff:
fixed-slots: []
```
### Player groups
These are groups of players that meet the specified condition. They consist of 2 parts - condition and slots.
**1. Display Condition**
The condition players must meet to be displayed in the group.
If a player doesn't meet condition for a 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 condition, they are not displayed at all.
Display condition is not required (can be used to make a "default" group with the remaining players).
**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:
display-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`.
## Chaining layouts
When defining more than 1 layout in config, the plugin will display the correct design based on conditions.
The plugin goes through all defined layouts, starting with the design on top.
If the layout's condition is met or not set, it is displayed.
If not, the next defined layout is checked and so on.
If no suitable layout is found (the last one has a condition requirement which wasn't met), no layout is displayed (player will see the normal tablist).
Example:
```
layouts:
staff:
display-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
*If you're wondering how to enable / disable heads in the tablist, see [FAQ](https://github.com/NEZNAMY/TAB/wiki/Frequently-Asked-Questions#6---how-to-make-player-heads-visible-in-tablist).*
For players, their skin is displayed. For fixed slots and empty slots, you can specify which skin to show using the same skin syntax.
Currently, TAB supports these skin formats:
| Format | Example | Description |
|--------|---------|-------------|
| `mineskin:<UUID>` | `mineskin:37e93c8e12cd426cb28fce31969e0674` | Takes UUID from [MineSkin](https://mineskin.org). |
| `player:<name>` | `player:Notch` | Displays skin of specified player. |
| `texture:<texture>` | `texture:469b3bac406b51ba0e76c2c218aa4d45fde9ea7c101c85fbd8106c92c4aa36dd` | Uses skin texture from `textures.minecraft.net`. Skin browsing websites show this value. |
# Compatibility with other plugins
This feature does not have any compatibility issues with other plugins.
When it comes to compatibility with vanish plugins, see [Additional information - Vanish detection](https://github.com/NEZNAMY/TAB/wiki/Additional-information#vanish-detection).
# Compatibility with other features
## Playerlist objective incompatibility
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.
## 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 a proxy. Because of this, if you use layout, you can disable global playerlist to reduce resource usage.
## 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 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`.
This can be solved by increasing window size either manually, or by pressing the expand button on the top left, next to the "X".
If it still looks the same for you even though you have the game in full screen, your GUI scale can be messed up.
To fix it, go to `Esc -> Options -> Video Settings...` and set `GUI Scale: ` to a lower value.
If you are looking for a more systematic solution that will automatically work for all of your players and not just you, the only way is to make the entries shorter.
Here are a few tips how to do that:
* Avoid using suffix altogether
* Do not use bold (`&l`) code
* Use a shorter alternative for your prefixes, such as `A` instead of `Admin`
* Remove unnecessary brackets from prefix
# Examples
## Example 1 - Per-server columns
```
layout:
enabled: true
direction: COLUMNS
default-skin: mineskin:383747683
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:
display-condition: "%server%=lobby"
slots:
- 2-20
survival:
display-condition: "%server%=survival"
slots:
- 22-40
creative:
display-condition: "%server%=creative"
slots:
- 42-60
skyblock:
display-condition: "%server%=skyblock"
slots:
- 62-80
```
You can also remove the last condition (in this case `display-condition: "%server=skyblock%"`) and the columns will be used for all other servers, instead of just a specified one.
If you want to reproduce the per-world-playerlist feature but with layouts, you can use relational conditions to check the viewer's world (`%viewer:world%`) with the target player's world (`%world%`) like so:
```yml
layout:
enabled:true
direction:COLUMNS
default-skin:mineskin:383747683
enable-remaining-players-text:true
remaining-players-text:'... and %s more'
empty-slot-ping-value:1000
layouts:
default:
slot-count:80
fixed-slots:
- '1|&3Website&f:'
- '2|&bmyserver.net'
- '3|&8&m '
- '4|&3Name&f:'
- '5|&b%player%'
- '7|&3Rank&f:'
- '8|Rank:%group%'
- '10|&3World&f:'
- '11|&b%world%'
- '13|&3Time&f:'
- '14|&b%time%'
- '21|&3Teamspeak&f:'
- '22|&bts.myserver.net'
- '23|&8&m '
- '41|&3Store&f:'
- '42|&bshop.myserver.net'
- '43|&8&m '
groups:
players:
display-condition:"%viewer:world%=%world%"
slots:
- 24-40
- 44-80
```
> [!NOTE]
> This is just an example, relational conditions are not limited to displaying only players in your world.
> If you want players in your server on proxy, use `%viewer:server%=%server%` in `display-condition`.
> This works for any placeholder offered by TAB or by PlaceholderAPI.
# If enabled and compatible plugin is found, hook is enabled to work with proxied players
name: RedisBungee
redis:
url: 'redis://:password@localhost:6379/0'
rabbitmq:
exchange: 'plugin'
url: 'amqp://guest:guest@localhost:5672/%2F'
```
Pick your desired way and configure it. I don't know anything about redis or rabbitmq, so good luck.
> [!IMPORTANT]
> **BACKEND INSTALLATION ONLY**
> You should also add this into your **config.yml** and configure it:
> ```
> server-name: "server"
> ```
> Ideally, name it the same as servers in your proxy config. This value will be used for getting player's server name. Aside from %server% placeholder, it will be used for internal logic when checking for player's server. One of them is global playerlist not adding/removing players who are on the same server in the tablist, as backend servers already do this (and duplicating actions would cause problems).
> **As a result, not configuring this value will result in everyone's server being "N/A", therefore global playerlist will think everyone is on the same server and not add anyone into the tablist, effectively making the feature not work.**
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.
* [Disabling team handling](#disabling-team-handling)
* [Examples](#examples)
* [Example 1 - Taking prefix/suffix from permission plugin](#example-1---taking-prefixsuffix-from-permission-plugin)
* [Example 2 - Making nametags invisible on a subserver](#example-2---making-nametags-invisible-on-a-subserver)
# 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).
* Options - AllowFriendlyFire and CanSeeFriendlyInvisibles
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.
# Configuration
This feature is configured in 2 parts based on what you are configuring. Most settings are in the **config.yml**, but prefix/suffix is configured in **groups.yml** and **users.yml**.
## config.yml
The first part can be configured in **config.yml** under **scoreboard-teams** section. It controls everything except prefix and suffix.
This is how the default configuration looks (excluding sorting options):
```
scoreboard-teams:
enabled: true
enable-collision: true
invisible-nametags: false
can-see-friendly-invisibles: false
disable-condition: '%world%=disabledworld'
```
All of the options are explained in the following table.
| 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 [short format](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders#short-format) conditional expression (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 | Controls nametags visibility rule. Available values are: <br />- `true` - Nametags will be invisible. <br />- `false` - Nametags will be visible. <br /> - *Conditional expression* - Nametags will be invisible if player meets the [short format](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders#short-format) conditional expression. <br /> - *Condition name* - Uses name of a [defined condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders). <br /> Option to hide nametags was added in Minecraft **1.8**, therefore it will not work on 1.7. |
| can-see-friendly-invisibles | false | Controls 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. |
## groups.yml and users.yml
This part allows you to configure prefix and suffix. They are called `tagprefix` and `tagsuffix`, where "tag" refers to name tag, to allow separation from tablist settings.
### Global settings
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"
```
Or with an in-game command `/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"
```
Or with in-game commands `/tab player _NEZNAMY_ tagprefix "&6&lTAB &r"` and `/tab playeruuid _NEZNAMY_ tagprefix "&6&lTAB &r"` (the player must be online for uuid option to work).
Properties can also be set as "default" for everyone who does not have them defined.
For that purpose, a group keyword `_DEFAULT_` was made.
Example:
**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 a proxy), 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-"
```
### Priorities
The full list of priorities to choose correct prefix/suffix for a player 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 of each other.
This means you can set per-world tagprefix, but only keep one global tagsuffix, for example.
You can see the source of a value displayed on player by using `/tab debug <player>` and checking "source"
part of the value you are looking for.
## Name color
On versions 1.12.2 and below, name color follows the last color of prefix. This also includes magic codes. On 1.13+, this is no longer the case. Instead, a new field called "team color" was created. This is an enum constant, where we need to pick from 22 options - 16 colors, 5 magic codes and reset. **As you can see, it doesn't allow for RGB colors**. This also means name can no longer have color and magic codes simultaneously.
TAB does not have an option for configuring team color to avoid complexity, such as per-version configuration, or having to configure an additional field.
For that reason, TAB detects the last used color code and uses that for team color.
> [!CAUTION]
> An exception is when using MiniMessage syntax / using RGB codes on server which has MiniMessage library. In this scenario, it is not possible to detect reset (`&r`) as last used "color", because in Minecraft components it is not a color, rather, it resets formatting by setting all magic codes to false / color to null. If you use `&r` (`<reset>`) and notice it not working, replace it with `&f` (`<white>`) (or add it after the reset to be safe). There seems to be no difference between setting color to `WHITE` versus `RESET`.
| /tab nametag <show/hide/toggle> \[player\] \[viewer\] \[options\] | `tab.nametag.visibility` (for yourself) <br /> `tab.nametag.visibility.other` (for others) | Shows / hides / toggles nametag of a specified player. If viewer is specified, view is only affected for the viewer. You can use `-s` as option for silent toggling (no chat message for affected player). |
| /tab nametag <showview/hideview/toggleview> \[viewer\] \[options\] | `tab.nametag.view` (for yourself) <br /> `tab.nametag.view.other` (for others) | Shows / hides / toggles nametag VIEW a specified player. You can use `-s` as option for silent toggling (no chat message for affected player) |
This feature does not offer any internal placeholders, only PlaceholderAPI placeholders.
## PlaceholderAPI placeholders
Here are TAB's PlaceholderAPI placeholders you can use when this feature is enabled:
| Placeholder | Description |
|-------------|-------------|
| `%tab_tagprefix%` | Player's current tagprefix with placeholders parsed. |
| `%tab_tagsuffix%` | Player's current tagprefix with placeholders parsed. |
| `%tab_tagprefix_raw%` | Player's current raw tagprefix with placeholder identifiers. |
| `%tab_tagsuffix_raw%` | Player's current raw tagsuffix with placeholder identifiers. |
| `%tab_nametag_visibility%` | "Enabled" if player can see nametags, "Disabled" if disabled using `/tab nametag toggleview` |
# Limitations
* [1.12.2-] Prefix/suffix length is limited to 16 characters (including color codes). Any characters beyond that will be cut to prevent players getting disconnected.
* [1.13+] Name color is controlled by a chat format enum constant. This means:
* 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.
* The same value manages name color and glow color, which means they cannot be different.
* The name cannot be effectively changed and the plugin doesn't offer it.
If you want to avoid these at all costs, the only way is to create entities (armor stands / display) and make them ride the player (or teleport). TAB no longer offers this functionality due to a large amount of unfixable issues (full thread [here](https://gist.github.com/NEZNAMY/f4cabf2fd9251a836b5eb877720dee5c/)). You can, however, check out these 3rd party plugins (**not affiliated with me in any way, use at your own risk**):
Scoreboard teams is a feature that cannot be handled by multiple plugins at once.
To make sure no other plugin sends their own teams when not disabled in the plugin's config properly, TAB will block players being added into teams coming from all other plugins (if this feature is enabled and not disabled for a player with a condition).
# 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 the 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 plugin has an option for this).
## Additional note 2 - Prefix/suffix on pets
Since Minecraft 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 and TAB does not offer this functionality in any (other) way. For more information, see [How to display name from nickname plugins - Nametag](https://github.com/NEZNAMY/TAB/wiki/How-to-display-name-from-nickname-plugins#nametag).
## Additional note 4 - F1 view
Using teams causes player nametags to remain visible when using F1 view.
The plugin cannot avoid this in any way.
The only possible solution would be to modify the client.
## Additional note 5 - Transparent players
Minecraft's teams can show players in the same team transparent (partially invisible).
This requires both players (viewer and target) to be in the same team.
As such, this effect is impossible to achieve with TAB,
because it puts every player into a different team
to properly sort players and give them different prefix/suffix in nametag
(and more, such as collision and nametag visibility).
If you want this effect, the only way is to use another plugin that offers this and disable TAB's teams entirely by setting
```
scoreboard-teams:
enabled: false
```
In config.yml. Keep in mind, you'll not be able to use any team features if you do so.
## Additional note 6 - Vanish hook
When a player is [vanished](https://github.com/NEZNAMY/TAB/wiki/Additional-information#vanish-detection), their team is unregistered for all other players who do **not** have `tab.seevanished` permission.
The purpose of this is to avoid players figuring out a staff member is still online but just vanished by "checking" registered teams and their members.
An example of "exploiting" this is to have a 3rd party client spawn a player entity with name of a chosen player (staff member) and seeing if their name is formatted (= team is registered = player is online) or not (offline).
For this reason, make sure you give all of your staff members who can see vanished players the `tab.seevanished` permission, otherwise the vanished player will appear on top of the tablist (players without team are above players with team) and their nametag will not be formatted.
# 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 the original value set by the plugin based on configuration:
*`NameTagManager#getOriginalRawPrefix(TabPlayer)` - Prefix with raw placeholder identifiers
*`NameTagManager#getOriginalRawSuffix(TabPlayer)` - Suffix with raw placeholder identifiers
*`NameTagManager#getOriginalReplacedPrefix(TabPlayer)` - Prefix with all placeholders parsed
*`NameTagManager#getOriginalReplacedSuffix(TabPlayer)` - Suffix with all placeholders parsed
> [!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#setCollisionRule(TabPlayer, Boolean)` - Forces collision rule to the player. Use `null` to reset value and make it follow configuration again.
*`NameTagManager#getCollisionRule(TabPlayer)` - Returns forced collision rule using the API, `null` if no value was forced and player follows the configuration.
## 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 whose 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 whose 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 nametag for specific player, `false` if not. The first `TabPlayer` is the player whose 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.
# Examples
## Example 1 - Taking prefix/suffix from permission plugin
If you want TAB to only take prefixes/suffixes from the permission plugin,
delete all groups from **groups.yml** and only keep this:
```
_DEFAULT_:
tagprefix: "%luckperms-prefix%"
tagsuffix: "%luckperms-suffix%"
```
Or a PlaceholderAPI placeholder from your permission plugin if you use a different one.
> [!NOTE]
> When doing this, make sure you don't delete something you didn't mean to delete, for example ta**b**prefix and ta**b**suffix from tablist name formatting feature.
## Example 2 - Making nametags invisible on a subserver
The config option `invisible-nametags` takes either a [condition or a conditional expression](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders).
We can use short format `%server%=<server name>`. If the server name is `server1`, it will look like this:
```
invisible-nametags: "%server%=server1"
```
If we want to disable it in 2 servers, we separate them with `|` (OR). Result:
| 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.
* [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)
Output will be replaced if it's numeric and belongs in a 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 an 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 the 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 a 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 the 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%
> [!NOTE]
> 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 can break features like [Playerlist Objective](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Playerlist-Objective),
which require a numeric input (for versions prior to 1.20.3).
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.
## Example 3 - Using both original and replaced output
Once configured, replacements are applied as the placeholder output everywhere. It is not directly possible to use original output in one place and replaced in another.
If you need this, you should consider [conditional placeholders](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) instead.
If conditional placeholders are too complicated to use, there are alternate ways. The main point of the solution is to create different placeholder that eventually calls the same function and returns the same result. This can be done by "wrapping" the placeholder into another one. The easiest way using existing TAB's functions is using animations. Create an animation with a single frame that contains the placeholder and configure replacements for that placeholder instead.
<details>
<summary>Example for %ping%</summary>
**animations.yml**:
```
ping:
change-interval: 50 # Actual value doesn't matter
texts:
- "%ping%"
```
Then, configure replacements for the animation in **config.yml**:
```
placeholder-output-replacements:
"%animation:ping%":
"0-50": "&a%animation:ping%" # %ping% would work too
"51-100": "&e%animation:ping%"
"else": "&c%animation:ping%"
```
Now, you can use `%ping%` for original output and `%animation:ping%` for replaced.
| value | "%ping%" | [1.20.2-] An integer from -2147483648 to 2147483647, doesn't support decimal values. The number is always yellow. Supports placeholders with player-specific output, such as player health. Only visible on 1.20.2 and lower (unless you set `render-type` to `HEARTS`). <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+] Any text, supports placeholders with per-player output. Only visible on 1.20.3+, where it completely replaces `value`, or if `render-type` is set to `HEARTS`. |
| title | "TAB" | Title to send. Only visible on Bedrock Edition. |
| render-type | INTEGER | Render type of the value. Supported values are `INTEGER` and `HEARTS`. <br />When set to `HEARTS`, the `value` is used displayed even on 1.20.3+, where `fancy-value` is ignored. |
| disable-condition | %world%=disabledworld | A [condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) (either name of a condition or a conditional expression) that must be met for disabling the feature for players. Set to empty for not disabling the feature ever. <br/> **Note**: Disabling the feature for a player means sending objective unregister packet to them, which results in player not seeing the feature on anyone anymore. It doesn't work the other way around - you cannot disable this feature on target players, only for viewers. |
# Limitations
* [1.20.2-] Only 2 display types are supported - yellow number and hearts.
* [1.20.2-] A yellow 0 will appear on all tablist entries that aren't actual players (such as NPCs and [layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) entries) and it cannot be removed.
# Compatibility with other plugins
TAB does not contain any sort of compatibility functionality for this feature.
It will not try to prevent other plugins from applying the feature and neither will it detect it to re-add back once the other plugin removes it.
Therefore, if another plugin also sends playerlist objective, TAB's may not show anymore (depending on who sends it first).
Make sure you do not have any other plugin sending it to ensure the feature works properly.
You can check the list of objectives registered by either commands or plugins using Bukkit API using `/scoreboard objectives list`.
If it contains one that could be the cause, you can unregister it by running `/scoreboard objectives remove <name>`. After doing so, reload TAB, so it resends its objectives again.
Note that if this was automatically generated by a plugin, it will probably be added back again.
# 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.
# Examples
## Example 1 - Per-world values
This feature doesn't directly support per-world values or similar.
However, this can be achieved with conditions.
Let's make `fancy-value` conditional based on player's world.
Let's make an example with 3 worlds.
Check if player is in world `world1`, then show one text.
If not, check if player is in world `world2`, then show another text.
If not, show the final text.
This can be achieved by chaining 2 conditions:
```
conditions:
playerlist1:
conditions:
- "%world%=world1"
true: "Text to display in world world1" # Player is in world world1, display the text
false: "%condition:playerlist2%" # Player is not in world world1, check another condition
playerlist2:
conditions:
- "%world%=world2"
true: "Text to display in world world2" # Player is in world world2, display the text
false: "Text to display in other worlds" # Player is not in any of the 2 worlds
```
> [!WARNING]
> DO NOT JUST RANDOMLY PASTE THIS ENTIRE "CONDITIONS" SECTION INTO YOUR CONFIG!
> INSTEAD, EDIT YOUR EXISTING CONDITIONS SECTION TO PREVENT HAVING THE SECTION TWICE,
> HAVING SECOND ONE COMPLETELY OVERRIDE THE FIRST ONE!
Finally, use this condition as value in `fancy-value`:
```
playerlist-objective:
fancy-value: "%condition:playerlist1%"
```
> [!NOTE]
> This is just an example, the plugin is not limited to displaying different values only per world.
> If you want per server values on proxy, use %server% with server names.
> This works for any placeholder offered by TAB or by PlaceholderAPI.
## Example 2 - Displaying hearts
In order to display the value as hearts, set `render-type` to `HEARTS`.
Then, set `value` to a placeholder that returns player's health. If you have TAB on a backend server, use `%health%`. If you have TAB on a proxy, use PlaceholderAPI's `%player_health_rounded%`.
Example configuration:
```
value: "%health%"
render-type: HEARTS
```
When using `HEARTS` render type, `fancy-value` is not displayed by the client, so it doesn't matter what it is set to.
| 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:** Commands are not supposed to be registered / unregistered dynamically at runtime. As such, you may run into small issues when changing the toggle command and reloading. After you modify the command to your liking, reconnect to properly see it in tabcomplete. If you don't use TAB on a proxy, consider restarting the server as well for the old command to actually be unregistered. |
| 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. Will not be visible for 1.20.3+ players, instead, you can configure any text to show using `\|\|text` in the lines (scroll up for more info). |
| 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. |
| scoreboards | *Map* | Scoreboards to display based on conditions (see below for more info).
| `display-condition` (optional) | [Condition](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders) (either condition name or a conditional expression) <br /> that must be met for the design to be displayed. <br />If not defined, design will be displayed without any required condition. <br />If player does not meet condition, another design may be displayed <br /> based on chaining (see below for more info). |
| `title ` | Title of the scoreboard. Limited to 32 characters (including color codes) on Minecraft versions below 1.13. It is automatically centered by the client. |
| `lines` | List of lines to display. The client will only display up to 15 lines. See below for more information about syntax. |
**Example**:
```
scoreboards:
MyScoreboard:
display-condition: "%world%=world" # Only display it in world "world"
title: "Scoreboard for world %world%"
lines:
- "Line1||Right side 1"
- "Line2||Right side 2"
- "Line3||Right side 3"
```
### Line syntax
The lines are specified as a list of strings.
Since 1.20.3, you can also configure the value on the right side, which no longer has to be a red number.
On <1.20.3, you can configure red numbers with either a static number, or a placeholder that evaluates to a number.
The final syntax is `<text>||<number format>||<score>`, where:
*`<text>` is the main text displayed on the left side
*`<number format>` is the new 1.20.3+ feature that replaces `score` with any text, not just a number
*`<score>` is the value (red number), only visible on <1.20.3 and must be a number (or a placeholder evaluating to one)
The second and third part are optional. Example syntaxes that configure a line are:
The `number format` will not be visible at 1.20.2 and lower, and `score` will be displayed instead.
### Hiding a line
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.
### Longer lines
*Since 1.13 the line length is unlimited, so you don't need to worry about this if you use 1.13+.*
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 the 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 an additional up to 40 characters.
To do so, add `Long|` prefix to all lines that 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 that 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.
## Chaining scoreboards
When defining more than 1 scoreboard in config, the plugin will display the correct scoreboard based on conditions.
The 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, the 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.
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.
| `/tab scoreboard show <name> [player]` | `tab.scoreboard.show` (for yourself) <br /> `tab.scoreboard.show.other` (for others) | Shows the scoreboard with the given `name`, either to yourself if no `player` was given, or to the given `player`. |
| `/tab scoreboard [on/off/toggle] [player] [options]` | `tab.scoreboard.toggle` (for yourself) <br /> `tab.scoreboard.toggle.other` (for others) | Shows / hides / toggles scoreboard of specified player. If no player was given, command affects the sender. You can use `-s` as option for silent toggling (no chat message for affected player) |
| `/tab scoreboard announce <name> <duration>` | `tab.announce.scoreboard` | Shows the scoreboard with the given `name` to every player on the server for the given `duration`, in seconds. |
# Placeholders
This feature does not offer any internal placeholders, only PlaceholderAPI placeholders.
## PlaceholderAPI placeholders
Here are TAB's PlaceholderAPI placeholders you can use when this feature is enabled:
| Placeholder | Description |
|-------------|-------------|
| `%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 (toggled with a command) |
# Limitations
* [1.12.2-] The title is limited to 32 characters (including color codes).
* [1.12.2-] Line length is limited to 28 characters (including color codes) (64 on lines with static text / [Longer lines](#longer-lines)).
* [1.20.2-] The red numbers on the right really cannot be removed from the plugin side (a client modification / resource pack is necessary).
* [Bedrock] Scoreboard lines may be cut off and show `...`, this can be bypassed by using [GeyserOptionalPack](https://github.com/GeyserMC/GeyserOptionalPack)
* The client only displays up to 15 lines. If a plugin sends more, only the top 15 scores will be displayed. Changing this would require a client modification (on versions below 1.8 the scoreboard won't appear at all if more than 15 lines are sent).
# 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.
# Additional info
## Additional note 1 - Text alignment
**Title**:
The title is always centered by the client. You cannot disable this. You can only pad it with spaces to move it towards your desired direction.
**Lines**:
The 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 "`.
## Additional note 2 - Geyser / Bedrock issues
Currently, there is a great suspicion that there is a geyser bug causing scoreboard to not appear for Bedrock players ([Geyser #5304](https://github.com/GeyserMC/Geyser/issues/5304) and more). This affects other scoreboard plugins as well, not just TAB. If you are experiencing this issue, make sure it is not caused by TAB configuration (for example using %bedrock%=false as display condition). If that wasn't the case, consider making a high quality bug report on Geyser with steps to reproduce.
# 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 number of milliseconds,
use `ScoreboardManager#announceScoreboard(String, int)`,
which will look up a scoreboard with the given `String` name,
and if one is found, send it to all players for the given `int` milliseconds.
# 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, it means player is in that world and the scoreboard is displayed.
If not, check for the next scoreboard's condition.
If none of the conditions are met, display the 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 proxy, use %server% with server names.
> This works for any placeholder offered by TAB 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 the output of this animation as a display condition.
If animation is on the first frame, display the first scoreboard.
Otherwise, display the second scoreboard.
Result:
**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 the 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).
## Example 3 - Per-version scoreboards
1.20.3 has added new features to scoreboards, which are not visible to older clients. If you want to use new features for new players while still displaying things properly for older players, you'll need to create 2 different scoreboards.
You'll find 2 placeholders useful for this:
*`%player-version-id%` - Returns network ID of player's protocol version. Unlike with version names, you can perform numerical comparisons with these. You can find all version IDs [here](https://github.com/NEZNAMY/TAB/blob/master/shared/src/main/java/me/neznamy/tab/shared/ProtocolVersion.java). For example, 1.20.3 is 765.
*`%bedrock%` - Returns `true` if player is using the bedrock edition, which does not support new functions either.
We only want the first scoreboard for players with version 765 or greater and not bedrock players. This can be achieved with the following condition: `display-condition: "%player-version-id%>=765;%bedrock%=false"`.
Let's go ahead and set it up (with proper spacing):
```
scoreboards:
scoreboard-1.20.3+:
title: "Scoreboard for 1.20.3+ and not bedrock"
display-condition: "%player-version-id%>=765;%bedrock%=false" # Only display it to players using 1.20.3+ AND NOT bedrock edition
lines:
- "* &eOnline&7:||%online%"
- "* &eCurrent World&7:||%worldonline%"
- "* &eStaff&7:||%staffonline%"
- "* &bRank&7:||%group%"
- "* &bPing&7:||%ping%&8ms"
- "* &bWorld&7:||%world%"
scoreboard:
title: "Scoreboard for <1.20.3 and bedrock"
lines:
- "* &eOnline&7: &f%online%"
- "* &eCurrent World&7: &f%worldonline%"
- "* &eStaff&7: &f%staffonline%"
- "* &bRank&7: &f%group%"
- "* &bPing&7: &f%ping%&8ms"
- "* &bWorld&7: &f%world%"
```
## Example 4 - Conditional lines
Sometimes you may want a dynamic line that only shows sometimes. TAB is already made to hide lines if they only consist of a placeholder that returned empty value. However, you may want to add more text around it, such as
```
- "Faction: %factionsuuid_faction_name%"
```
Now, even if the placeholder returns empty string, text `Faction: ` will remain, and as such, the line will stay. In order to avoid this, create a [conditional placeholder](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders). If the placeholder returned empty value, show empty value. Otherwise, show result of the placeholder with the static text:
```
conditions:
faction:
conditions:
- '%factionsuuid_faction_name%='
true: "" # No faction, return empty string to hide the line
false: "Faction: %factionsuuid_faction_name%" # Player has a faction, show the static text before it as well
```
> [!WARNING]
> DO NOT JUST RANDOMLY PASTE THIS ENTIRE "CONDITIONS" SECTION INTO YOUR CONFIG!
> INSTEAD, EDIT YOUR EXISTING CONDITIONS SECTION TO PREVENT HAVING THE SECTION TWICE,
> HAVING SECOND ONE COMPLETELY OVERRIDE THE FIRST ONE!
Now, configure your scoreboard line as:
```
- "%condition:faction%"
```
and it will only display if the placeholder returned non-empty value.
* [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.
> [!TIP]
> To verify you enabled sorting, run `/tab debug`. It will say `Sorting type:` followed by anything except `DISABLED`.
# Methods of sorting
Below are all the different methods that you can use to sort players.
## 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 the 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).
> [!TIP]
> 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"
```
> [!TIP]
> 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
> [!CAUTION]
> 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`.
> Verify sorting permissions of a player using `/tab debug <player>`
## PLACEHOLDER
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 alphabetically, 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 the lowest value to the 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 the 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 from the highest value to the 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:
With AFK status taking the highest priority, AFK players will always be 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 copy-paste 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).
| 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 artificially 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).
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 a member of one team.
In other words, only one plugin can handle teams at a time.
Having multiple plugins handling teams is supposed to end in a disaster.
Fortunately, TAB contains a function that prevents other plugins from assigning players into teams.
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.
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` (though CMI won't allow you to change glow color if you do, so keep that in mind).
*`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 an 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.
* Mistaking `primary-group-finding-list` for the 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 a proxy without knowing what it does.
* Installing TAB on a proxy without having any permission plugin on the proxy.
* Enabling `assign-groups-by-permissions` without giving those permissions (or the opposite - giving away OP to users, resulting in the highest group being taken).
[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 backend and proxy, causing the installations to conflict.
* Using TAB on Velocity without installing [VelocityScoreboardAPI](https://github.com/NEZNAMY/VelocityScoreboardAPI/releases)
# 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 the 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 the 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 [Playerlist Objective](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Playerlist-Objective).
This feature cancels gamemode change packets to spectator gamemode, cancelling this Minecraft feature.
# Enabling
To enable this feature, open **config.yml** and set
| `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 canceled 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).
* [Compatibility with other plugins](#compatibility-with-other-plugins)
* [API](#api)
* [Examples](#examples)
* [Example 1 - Taking prefix/suffix from permission plugin](#example-1---taking-prefixsuffix-from-permission-plugin)
# About
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 supported 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,
This feature is configured in 2 parts based on what you are configuring. Some settings are in the **config.yml**, but prefix/suffix is configured in **groups.yml** and **users.yml**.
## config.yml
The first part can be configured in **config.yml** under **tablist-name-formatting** section. It controls everything except prefix and suffix.
This is how the default configuration looks:
```
tablist-name-formatting:
enabled: true
disable-condition: '%world%=disabledworld'
```
All of the options are explained in the following table.
| 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. |
## groups.yml and users.yml
### Format structure
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 and displayed in the tablist.
You are free to use the 3 properties in any way you want since they are only split for convenience.
However, it is still a good idea to use them for their designed purpose to not get lost in a poor configuration.
This means that the text which should appear before player's name should be put into `tabprefix`,
any placeholder that is supposed to display player's name (such as from a nickname plugin)
should go into `customtabname` and any text that should appear after player's name should be put into `tabsuffix`.
### Global settings
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"
```
Or with an in-game command `/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"
```
Or with in-game commands `/tab player _NEZNAMY_ tabprefix "&6&lTAB &r"` and `/tab playeruuid _NEZNAMY_ tabprefix "&6&lTAB &r"` (the player must be online for uuid option to work).
Properties can also be set as "default" for everyone who does not have them defined.
For that purpose, a group keyword `_DEFAULT_` was made.
Example:
**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 a proxy), 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 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_:
tabsuffix: "Shared tagsuffix in worlds world1 and world2"
lobby-*:
_DEFAULT_:
tabsuffix: "Suffix in all worlds starting with lobby-"
```
### Priorities
The full list of priorities to choose correct prefix/name/suffix for a player 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 of each other.
This means you can set per-world tabprefix, but only keep one global tabsuffix, for example.
You can see the source of a value displayed on player by using `/tab debug <player>` and checking "source"
part of the value you are looking for.
# Placeholders
This feature does not offer any internal placeholders, only PlaceholderAPI placeholders.
## PlaceholderAPI placeholders
Here are TAB's PlaceholderAPI placeholders you can use when this feature is enabled:
| Placeholder | Description |
|-------------|-------------|
| `%tab_tabprefix%` | Player's current tabprefix with placeholders parsed. |
| `%tab_customtabname%` | Player's current customtabname with placeholders parsed. |
| `%tab_tabsuffix%` | Player's current tabprefix with placeholders parsed. |
| `%tab_tabprefix_raw%` | Player's current raw tabprefix with placeholder identifiers. |
| `%tab_customtabname_raw%` | Player's current raw customtabname with placeholder identifiers. |
| `%tab_tabsuffix_raw%` | Player's current raw tabsuffix with placeholder identifiers. |
# Compatibility with other plugins
Tablist formatting is a feature that cannot be effectively handled by multiple plugins at once.
To make sure no other plugin sets tablist display names when not disabled in the plugin's config properly, TAB will block attempts to modify tablist display names coming from all other plugins (if this feature is enabled and not disabled for a player with a condition).
# 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:
To get the original value set by the plugin based on configuration:
*`TabListFormatManager#getOriginalRawPrefix(TabPlayer)` - Prefix with raw placeholder identifiers
*`TabListFormatManager#getOriginalRawName(TabPlayer)` - Name with raw placeholder identifiers
*`TabListFormatManager#getOriginalRawSuffix(TabPlayer)` - Suffix with raw placeholder identifiers
*`TabListFormatManager#getOriginalReplacedPrefix(TabPlayer)` - Prefix with all placeholders parsed
*`TabListFormatManager#getOriginalReplacedName(TabPlayer)` - Name with all placeholders parsed
*`TabListFormatManager#getOriginalReplacedSuffix(TabPlayer)` - Suffix with all placeholders parsed
**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).
# Examples
## Example 1 - Taking prefix/suffix from permission plugin
If you want TAB to only take prefixes/suffixes from the permission plugin,
delete all groups from **groups.yml** and only keep this:
```
_DEFAULT_:
tabprefix: "%luckperms-prefix%"
tabsuffix: "%luckperms-suffix%"
```
Or a PlaceholderAPI placeholder from your permission plugin if you use a different one.
> [!NOTE]
> When doing this, make sure you don't delete something you didn't mean to delete, for example ta**g**prefix and ta**g**suffix from nametag feature.
* [#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 - I enabled MySQL, and my prefix is now gone!](#3---i-enabled-mysql-and-my-prefix-is-now-gone)
* [#4 - Why is player sorting not working?](#4---why-is-player-sorting-not-working)
* [#5 - How to add players to %staffonline% placeholder?](#5---how-to-add-players-to-the-staffonline-placeholder)
* [#6 - How to make player heads visible in tablist?](#6---how-to-make-player-heads-visible-in-tablist)
* [#7 - Where can i find current default config files?](#7---where-can-i-find-current-default-config-files)
* [#8 - How can I split players into multiple columns?](#8---how-can-i-split-players-into-multiple-columns)
* [#9 - How to use space in prefix/suffix command?](#9---how-to-use-spaces-in-prefixsuffix-command)
* [#10 - Can I change/remove the green connection bar in tablist?](#10---can-i-changeremove-the-green-connection-bar-in-tablist)
* [#11 - Placeholder is not working](#11---placeholder-is-not-working)
* [#12 - How can I display images from resource pack plugin?](#12---how-can-i-display-images-from-resource-pack-plugin)
* [#13 - How can I use UTF characters in configuration?](#13---how-can-i-use-utf-characters-in-configuration)
* [#14 - Is there a way to remove all players from tablist?](#14---is-there-a-way-to-remove-all-players-from-tablist)
* [#15 - How to add images to tablist?](#15---how-to-add-images-to-tablist)
* [#16 - Is MiniMessage supported?](#16---is-minimessage-supported)
* [#17 - Is it possible to show the number of players in a specific group, similar to staffonline placeholder?](#17---is-it-possible-to-show-the-number-of-players-in-a-specific-group-similar-to-staffonline-placeholder)
* [#18 - Why is the plugin flagged as a virus by Windows defender?](#18---why-is-the-plugin-flagged-as-a-virus-by-windows-defender)
* [#19 - How can I show amount of online players on the entire network?](#19---how-can-i-show-amount-of-online-players-on-the-entire-network)
* [#20 - Why is LuckPerms prefix/suffix not updating on a network?](#20---why-is-luckperms-prefixsuffix-not-updating-on-a-network)
## #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. 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 - 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.
## #4 - 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).
## #5 - How to add players to the %staffonline% placeholder?
Give them the `tab.staff` permission.
## #6 - How to make player heads visible in tablist?
Players who did not buy the game will never be able to see heads.
The client displays Player heads 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.
The same goes for disabling heads - you cannot disable them if you have online mode enabled.
Minecraft 1.21.9 has added [object components](https://github.com/NEZNAMY/TAB/wiki/How-to-use-Minecraft-components#object-components-1219), which allow you to display player heads. You can put for example `<head:name:%player%>` at the beginning of tabprefix to simulate this.
## #7 - Where can i find current default config files?
You can do any of the following:
* Check the [source code](https://github.com/NEZNAMY/TAB/tree/master/shared/src/main/resources/config).
* Delete or rename a file, and the plugin will regenerate it.
* Open the plugin jar as a zip file and take files from there.
## #8 - How can I split players into multiple columns?
The client puts players into columns, 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.
## #9 - How to use spaces in prefix/suffix command?
Use "", for example `/tab group owner tabprefix "&2&lOwner&r "`
## #10 - Can I change/remove the green connection bar in tablist?
The connection bar is client sided and cannot be re-textured or removed by TAB.
You will need a custom Minecraft client or a resource pack.
## #11 - 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 backend-only placeholders](https://github.com/NEZNAMY/TAB/wiki/Placeholders#backend-only) on a proxy
* Trying to use PlaceholderAPI placeholders on proxy without installing [bridge plugin](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge)
The full list of reasons can be found on the [Placeholders](https://github.com/NEZNAMY/TAB/wiki/Placeholders#placeholder-is-not-working) page.
## #12 - How can I display images from resource pack plugin?
Images work by mapping a chosen character to an image in a resource pack.
When the game receives this character, it displays the image instead of the character.
What you need to do is send this character to the client.
Although resource pack plugins are not all the same, they all have things in common.
The first main functionality is offering placeholders.
You can use their PlaceholderAPI placeholders in TAB, and they will return the symbol, which then the client displays as an image.
The second main functionality is creating internal placeholders, which are different per plugin.
The plugin then listens to outgoing packets and replaces the internal placeholder with the symbol.
This can, however, fail.
Here are possible reasons why:
* You have TAB on proxy, so backend plugin cannot modify packets sent by the proxy
* TAB also listens to packets and modifies them to make sure no other plugin is overriding it. This mostly applies to [Tablist name formatting](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Tablist-name-formatting). TAB then ends up having the last shot, overriding the resource pack plugin.
In order to make sure images display properly, use PlaceholderAPI placeholders instead of internal placeholders of your resource pack plugins.
Here is some extra information for each resource pack plugin you might find useful:
* ItemsAdder:
* The PlaceholderAPI placeholders are formatted as `%img_<name>%`, internal placeholders (`:something:`) may not always work (see above).
* If you are unable to change the placeholder references from internal placeholders to PlaceholderAPI placeholders (for example, because they are defined in permission plugin and used elsewhere as well, where PlaceholderAPI isn't supported), you can use [PlaceholderAPI](https://github.com/NEZNAMY/TAB/wiki/Quick-PlaceholderAPI-startup-guide)'s `imgfix` expansion that replaces format of given placeholders into the correct format.
* Here is a collection of tips from Nexo discord: <br /><img width="476" height="238" alt="image" src="https://github.com/user-attachments/assets/0eca8e9b-a73f-4e66-9c76-11a230e823b4" />
## #13 - 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 hex code 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 the 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.
## #14 - Is there a way to remove all players from tablist?
In Minecraft, for a player to be visible in-game, they also need to appear in the tablist.
Remember the issue with NPCs showing up in the tablist? It's the same underlying mechanic.
If you're okay with players not being visible in the world, you can use a plugin that hides all players completely.
Since Minecraft 1.19.3, this limitation has been lifted — it's now possible to have entities in the game without showing them in the tablist.
However, the TAB plugin does **not** support removing all players from the tablist in any version of Minecraft.
An alternative solution using TAB is putting a lot of empty lines into header,
which will push all players out of the screen.
## #15 - 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, remember to use `""` in config instead of `''`.
## #16 - Is MiniMessage supported?
Yes, however, it must be included in your server software (it is only in Paper / Velocity). Read more about MiniMessage hook [here](https://github.com/NEZNAMY/TAB/wiki/How-to-use-Minecraft-components#minimessage).
## #17 - Is it possible to show the number 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).
## #18 - Why is the plugin flagged as a virus by Windows defender?
First, this is a false positive.
[Here](https://www.spigotmc.org/threads/windows-defender-false-positives.639507/)'s a spigot thread confirming it.
After experimenting with VirusTotal,
it turns out the antivirus software available on the website used flags [bStats](https://github.com/Bastian/bStats) library as malicious.
Its purpose is to collect anonymous data about servers and submitting it to [bStats.org](https://bstats.org/),
where plugin authors can see how many servers use their plugins (if they don't disable it).
It also checks for CPU and OS types, which could be the reason for the false positive.
[Here](https://bstats.org/plugin/bukkit/TAB%20Reborn/5304) is one of TAB's pages as an example.
Windows defender could be flagging it for the same reason.
## #19 - How can I show amount of online players on the entire network?
If you have TAB installed on the proxy, use `%online%` placeholder.
If you have TAB installed on the backend servers, use `%bungee_total%` from [PlaceholderAPI](https://github.com/NEZNAMY/TAB/wiki/Quick-PlaceholderAPI-startup-guide). This placeholder has an internal cooldown, which can be configured in `plugins/PlaceholderAPI/config.yml` under `expansions` -> `bungee` -> `check_interval`, default value is 30 (seconds).
## #20 - Why is LuckPerms prefix/suffix not updating on a network?
In order for LuckPerms instances to pick up the changes to player data in real time, it needs to communicate the changes between proxy ↔ backend.
If you notice changes not taking effect in TAB, try running `/lpb user <player> info` (or `/lpv` on velocity). If running the command updates it in TAB, that's the problem - LuckPerms instances not communicating in real time.
This is controlled by a LuckPerms setting called [messaging-service](https://luckperms.net/wiki/Syncing-data-between-servers#messaging-services). Set it to `pluginmsg` to make changes update immediately.
Additionally, make sure `auto-push-updates` is still `true` (it is by default already).
The wiki explains the functionality of the plugin as of version **5.5.0**.
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.
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.
This will give 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).
# Terminology
On order to not have to explain something every time it is mentioned, it will be explained here once.
| Name | Description |
|----------------|-----------------------|
| proxy server | Server running BungeeCord or Velocity software, which are used to connect multiple servers, allowing easy transfer between them. |
| modded server | Fabric, Forge and NeoForge. |
| backend server | Minecraft server that is actually being played on, not a proxy. This includes Bukkit (and its forks) and modded servers |
# Limitations of plugins
TAB is a plugin (even on modded platforms, it is only a server-sided mod).
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 the 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 the needs of a 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.
The majority of things that are not supported directly can be achieved in 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 proxy](#taking-groups-from-backend-servers-when-tab-is-on-proxy)
## 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.
There are 2 simple steps to this:
* Keep `assign-groups-by-permissions: false` in your config
* Put players into groups in your permission plugin
> [!CAUTION]
> If assigning players into multiple groups, make sure their weights are correct
> (for luckperms /lp group \<group\> setweight \<number\>).
> [!TIP]
> Verify player's 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 the 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 necessary because:
#1 - there's no way to get the list of permissions, only checking for a permission.
The list will be used for a 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).
> [!WARNING]
> Remember 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.
# Taking groups from backend servers when TAB is on proxy
By default, TAB takes groups from the permission plugin installed on the same server instance.
In the 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` on BungeeCord and `/lpv user <player> info` on Velocity).
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 the 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 the lowest priority](#tip-2---sorting-nicked-players-with-the-lowest-priority)
# Tablist
This one is straightforward.
The tablist format of players is one text 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.
> [!CAUTION]
> Do NOT put nickname placeholder into tabprefix!
> You will end up with double names!
> Put the nickname placeholder into customtabname instead.
# Nametag
**TLDR: TAB does not offer this functionality**.
With that out of the way, let's learn more about this issue.
Unlike with tablist name formatting, which is a single component containing everything (and therefore fully customizable), nametags are different.
They consist of prefix and suffix components (coming from scoreboard teams) and name itself.
This name is contained in player info packet (coincidentally the same one that controls tablist format), along with player's skin and other things.
This name is limited to 16 characters (since Minecraft doesn't allow longer names) and since it's not a component, naturally it does not support RGB colors.
Strangely enough, legacy codes using `§` work, but they further limit the length of the rest of the name.
There are really only 2 ways to achieve this solution:
***Change the profile name** - This requires sending player info packet that removes the old player and adds a new one with the same name. Then respawn the player. Additionally, it requires a lot of packets to be sent to the affected player, since you cannot just remove & add self, as well as a lot of other packets to restore previously sent data. These packets have been changing a lot with various MC versions. A lot of them cannot even be sent from a proxy server. As such, TAB does not offer this functionality, since it would be very limited anyway (see above) and require a lot of adapting for proper functionality.
If you decide to use a plugin with this functionality, keep in mind it breaks all name-bound features, such as scoreboard teams, belowname or playerlist objective. See below for compatibility information.
Example third party plugins that offer this: None?
***Use an armor stand / text display to show any text** - TAB no longer offers this functionality ([here's why](https://gist.github.com/NEZNAMY/f4cabf2fd9251a836b5eb877720dee5c)), so you will need to look into other plugins.
If you decide to use a plugin with this functionality, just remember to make the vanilla nametag invisible, so you don't see both vanilla nametag and the entity (`invisible-nametags: true`).
Example third party plugins that offer this: [UnlimitedNameTags](https://www.spigotmc.org/resources/unlimitednametags.117526/), [DisplayNameTags](https://github.com/Matt-MX/DisplayNameTags), [NotJustNamePlates](https://github.com/YouHaveTrouble/NotJustNameplates), [CustomNameplates](https://polymart.org/product/2543/customnameplates)
# Proper compatibility with plugins that change profile name
If using a nickname plugin that changes player's profile name 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.
> [!WARNING]
> If you have TAB installed on backend server and a proxy plugin changes nickname, TAB is not able to detect this change, since the modified packets never actually go through the backend server where TAB is installed.
> [!TIP]
> If automatic detection is not working for you (you use proxy plugin for changing names while TAB is on backend), you can use [this API method](https://github.com/NEZNAMY/TAB/blob/master/api/src/main/java/me/neznamy/tab/api/TabPlayer.java#L88) to let TAB know player's name changed.
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, the 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%'
true: "%player%" # If nickname = player name -> player is not nicked
false: "~%essentials_nickname%" # If nickname != player name -> player is nicked
```
Then, use `%condition:nick%` in your `customtabname` instead of the placeholder directly.
## Tip 2 - Sorting nicked players with the 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'
true: "default"
false: "%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.
> [!WARNING]
> For Minecraft versions below 1.13 the prefix can't be longer than 14 characters due to [16-character limit](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Nametags#limitations) 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.
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.
In Minecraft 1.7, new feature called components was introduced. This is an upgrade from using legacy colors (using § symbol) into creating a JSON object where text, color, and magic codes (boolean values) are separated.
Additionally, it received new features called hover event and click event. The only place this affects is chat, which TAB does not handle, so these functions are not implemented by TAB at all.
Components have been receiving a lot of new functions since then, which are explained below.
There are also a few config options for components. You can find them in your **config.yml** under `components` section. They are explained [below](#config-options).
# RGB colors (1.16+)
As of 1.16, mojang introduced RGB color support.
This allows us to use 16,777,216 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.**
> [!CAUTION]
> Remember to replace `RRGGBB` with actual hexadecimal numbers (0-9, a-f)!
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 inside the text. 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.
TAB, server software or viaversion (depending on your setup)
will find the closest legacy color to the desired RGB combination and will use that color instead.
# Fonts (1.16+)
The plugin offers usage of the font feature introduced in Minecraft 1.16.
> [!IMPORTANT]
> 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>`
TAB (currently?) does not have any built-in way to convert text input into shadow color field. However, you can use [MiniMessage](#minimessage) for that. TAB will properly read this value from adventure components and convert it further into Minecraft components.
# Object components (1.21.9+)
A new component of "object" type was added into the game in 1.21.9. It currently has 2 implementations described below.
## Atlas sprite
This type allows you to display any item or block. The syntax is
```
<sprite:ATLAS:SPRITE>
```
where `ATLAS` is the atlas and `SPRITE` is the sprite. Note that atlas can contain the `:` symbol. In order to make TAB recognize it properly, wrap at least the first value into quotes.
> These values change over MC versions (for example items were in `minecraft:blocks` atlas in 1.21.9 - 1.21.10, but got moved to `minecraft:items` in 1.21.11), so make sure you are using the correct values for your MC version. For proxy installations, you may need to use conditional placeholders and check for player's version. On backend, ViaVersion may or may not automatically translate these.
> [!TIP]
> For full list of available sprites you can check out https://www.gamergeeks.net/apps/minecraft/list-of-atlas-sprites. However, it doesn't contain any information regarding different Minecraft versions.
## Player sprite
> [!WARNING]
> In order to use these, you will need to disable MiniMessage support, because head components were not added to MiniMessage yet. Even when they are added, they will have a different syntax, so TAB will be updated to match the format to avoid complications. For now, use the existing syntax for prototyping and testing. To disable MiniMessage support, set:
> ```
> components:
> minimessage-support: false
> ```
> in **config.yml**.
This type allows you to display Minecraft heads. There are 3 ways to define a head:
| Player name | The client checks recently received profiles (players on current server) and shows skin of player with that name. If no such player was found, connects to Mojang and gets skin of player with specified name. <br />**Note**: This means using a plugin for changing skins will result in the skin being changed here too (the client has a cache, so it won't be visible immediately (restarting the client resets the cache)). If using offline mode and no skin plugin, head won't display correct skin even if such player is registered at Mojang. |
| Player UUID | The client checks recently received profiles (players on current server) and shows skin of player with that UUID. If no such player was found, connects to Mojang and gets skin of player with specified UUID. <br />**Note**: This means using a plugin for changing skins will result in the skin being changed here too (the client has a cache, so it won't be visible immediately (restarting the client resets the cache)). |
| Skin value and signature | The client displays skin from given value and signature |
Here are all the ways you can display player skins using TAB and their implementation (using `ALL CAPS` for "placeholder" text instead of `<>` to avoid confusion as `<>` is actual part of the syntax):
| Syntax | Explanation | Implementation |
|-----|-------------|------------|
| `<head:name:NAME>` | Shows head defined by player name | name |
| `<head:id:UUID>` | Shows head defined by player UUID | uuid |
| `<head:signed_texture:VALUE;SIGNATURE>` | Shows head defined by value and signature | value and signature |
| `<head:player:NAME` | Connects to Mojang and retrieves value and signature of defined player | value and signature |
| `<head:mineskin:ID>` | Connects to Mineskin and retrieves value and signature of specified upload ID | value and signature |
| `<head:texture:TEXTURE>` | Gets the texture from `http://textures.minecraft.net/texture/TEXTURE` | value and signature |
Here is an example for all types:
```
footer:
- 'Head by id: <head:id:%uuid%>' # This will obviously not work in offline mode
- 'Head by name: <head:name:%player%>' # May or may not work in offline mode (see above for full explanation)
- 'Head by raw texture: <head:signed_texture:ewogICJ0aW1lc3RhbXAiIDogMTc1NjMxNjc0OTk4MywKICAicHJvZmlsZUlkIiA6ICIyMzdkOGI1NTNmOTc0NzQ5YWE2MGU5ZmU5N2I0NTA2MiIsCiAgInByb2ZpbGVOYW1lIiA6ICJfTkVaTkFNWV8iLAogICJzaWduYXR1cmVSZXF1aXJlZCIgOiB0cnVlLAogICJ0ZXh0dXJlcyIgOiB7CiAgICAiU0tJTiIgOiB7CiAgICAgICJ1cmwiIDogImh0dHA6Ly90ZXh0dXJlcy5taW5lY3JhZnQubmV0L3RleHR1cmUvZmY1ZTNhNWRmODkxYzEzMTdhZjUzMmMzNmY4NDgxNDBhNDBmMGZhMGNlZGRmZmEwNWU5NGU1NzU1OGQxY2Q4YyIKICAgIH0KICB9Cn0=;YFVoqA0CqWgnZhme5s/M7xtadURyLkyLWVsh0vN8BqdfwzN32nqlBJb2pRjkxIs0V21EOeKbGFjgdKQKzPRQdf6sTFQ/x0KOjUg8A/neAiwCvDSDrsTQ2Yf7yoVP6M2PpuB7te19N+I139mGY5psxU100x6GiV/uFfpUfG3XBJog43JtXzRJ9fRtoSeIEzqLrkpCmt6o5Mzo6GZFZc4CtI76OU90Mg9ZvTZTYelvtjFtllxTtkNZCcglzvh5R19+qtzLOzEr+N8m4Ed+5yZyezEb3LeeSgmbSLIjuOKuUupE+2F6yVYP3eKhgGLZ2G+cg9TZZjTCsNMzHqewM/1+qStzTQCdNmggXCGcIfC8HcYsBfdv4SicxBq8ff+BDyveFZMFyREpQNqX/fLmlz16cmxHvBQ9qqA+IzIsBJ7i/mrG78jBhkJsvtcHMHvTviXascCSQP1TCn58D6HJ/Agww6HFTJe/B6sX0Utzm0URE4jZK7wnhrx0q2H8OkCXc5ZwuXALqtvk0uWmZo2RMnIGQNi4nb5AUsGV8pNirhS16MfqZeJ4q0HGaIVscRp4jazab6kMVKusbuqQB1cZNbaao7mP1HAUVCd5geWQL4CQQIc6gv0q3KT2E45d0YeYqpy/RppKMWmg1+aQ5wVGQW4/p2mqXos71FKy6vP0ur6txd8=>'
- 'Head by player: <head:player:%player%>'
- 'Head by mineskin: <head:mineskin:37e93c8e12cd426cb28fce31969e0674>'
- 'Head by texture: <head:texture:ff9bb9e56125c8227b94bbda9f6e0f862931c229255ba8f1205d13c44c1bb561>'
| Backend <1.21.9 | TAB | `<Object components were added in 1.21.9>` (even for 1.21.9+ players) |
| Backend 1.21.9+ | ViaVersion | (empty text) |
| BungeeCord | TAB | `<Object components were added in 1.21.9>` |
| Velocity | (no one) | Client disconnects with a packet decoding error |
# MiniMessage
TAB has [MiniMessage](https://docs.advntr.dev/minimessage/format.html) hook, however, it does not include this library on its own. Including it would cause conflicts, so it has to be included in the server software.
* It **is** included in **Paper 1.18.2+**, **Velocity** and **Sponge**.
* It **is not** included in **Spigot**, any server software for **1.18.1-**, **BungeeCord**, **Fabric**, **Forge** and **NeoForge**.
When MiniMessage is detected on your server, it is automatically used. All codes are translated to MiniMessage syntax and then parsed by MiniMessage.
| disable-shadow-for-heads | true | Automatically disables shadows for head object components (1.21.9+) to match the appearance of online-mode heads, which don't use shadows. |
# Tips & Tricks
## Tip 1 - Manually defining legacy color
For features that don't depend on any other players (header/footer, bossbar, scoreboard), you can easily specify legacy color instead of automatic rounding for <1.16 players. This can be done using [conditional placeholders](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders).
Check for `%player-version-id%`, which returns network protocol id of the version, which can be easily compared to. 1.16's version is `735`. Final condition may look like this:
```
conditions:
rgb:
conditions:
- '%player-version-id%>=735'
true: "#00FF00 RGB text"
false: "&a Legacy text"
```
Then, use this condition with `%condition:rgb%`.
This will not work in nametags and tablist formatting, because this would parse the condition for target player, not the viewer. To achieve this, you'll need a custom-made [relational placeholder](https://github.com/NEZNAMY/TAB/wiki/Placeholders#relational-placeholders) that checks for viewer's version.
Installation on backend servers is as simple as it can be.
Put the plugin into the plugins folder and restart the server.
# Proxy
When running a network, you have 3 options:
* Installing TAB only on the proxy (recommended)
* Installing TAB on all backend servers instead
* Installing TAB everywhere and disabling features, so they don't conflict (not recommended)
See below for more information regarding each way.
## Proxy installation
This is the recommended setup.
Put the plugin into the 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.
**Recommended**:
If you are using **Velocity**,
install [VelocityScoreboardAPI](https://github.com/NEZNAMY/VelocityScoreboardAPI/) plugin **on the proxy** for scoreboard-related features to work.
> [!NOTE]
> With proxy 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) without requiring Redis set up
* [Layout](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Layout) can work with all players connected to the proxy
* 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 running a network, install the plugin on all servers where you want the plugin. However, this setup is not as good (see advantages of proxy installation).
## Mixed installation
Mixed installation is absolutely not supported and should be avoided.
There is no sort of communication between backend and proxy TAB installations (this is only done by TAB-Bridge, which doesn't do anything on its own). Having TAB on both proxy and backend is effectively installing 2 plugins to do the same thing, which will naturally cause issues (although TAB's anti-override for key features should help with this).
If you really wish to proceed (for example having feature X handled by proxy and feature Y on backend), make sure to properly disable features (`enabled: false`) to avoid problems. However, the only case where this makes any sense is per world playerlist feature, which is not available on proxies. Everything else can be done from proxy side.
# 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 an old plugin version cannot know what the future config format is / will be.
Just like Minecraft itself, although TAB won't fail with an error message like Minecraft does, but you will get warnings and / or features not working correctly.
There is no reason for downgrading anyway, since in general, every version is typically superior to older versions released before it.
* [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)
* [Showing head components only to 1.21.9+ players](#showing-head-components-only-to-1219-players)
# 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 a proxy, and you want prefixes to be taken from backend servers, use `%vault_prefix%` (or `%luckperms_prefix%`) with [PlaceholderAPI support on proxy](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge).
# Showing player's 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 colors 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 [Playerlist objective](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Playerlist-Objective)
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"
true: "<#55FF55>%tps%</#00AA00>"
false: "%condition:tps2%"
tps2:
conditions:
- "%tps%>=15"
true: "<#FFFF55>%tps%</#FFAA00>"
false: "<#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"
true: "<#55FF55>%mspt%</#00AA00>"
false: "%condition:mspt2%"
mspt2:
conditions:
- "%mspt%<50"
true: "<#FFFF55>%mspt%</#FFAA00>"
false: "<#FF5555>%mspt%</#AA0000>"
ping:
conditions:
- "%ping%<100"
true: "<#55FF55>%ping%</#00AA00>"
false: "%condition:ping2%"
ping2:
conditions:
- "%ping%<200"
true: "<#FFFF55>%ping%</#FFAA00>"
false: "<#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 the 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%="
true: "%luckperms-prefix%"
false: "%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.
# 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)
Remember 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 tabsuffix:
```
_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 use 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>`. Remember 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
The 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 disadvantage, 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).
# Showing head components only to 1.21.9+ players
Object components were added in 1.21.9, which means they cannot be shown to 1.21.8- players. [If you try to do so, you'll either get an ugly text (BungeeCord / backend), or disconnect with a packet decode error (on Velocity)](https://github.com/NEZNAMY/TAB/wiki/How-to-use-Minecraft-components#compatibility-with--1219).
To achieve this goal, we will use [relational conditions](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Conditional-placeholders#relational-conditions) and check if viewer is 1.21.9+:
```
conditions:
head:
conditions:
- "%viewer:player-version-id%>=773"
true: "<head:name:%player%> "
false: "" # Show nothing
```
The `773` is the protocol version of 1.21.9, so we can use a simple math operation instead of comparing strings. You can check [TAB's source code](https://github.com/NEZNAMY/TAB/blob/master/shared/src/main/java/me/neznamy/tab/shared/ProtocolVersion.java) for the full list. This condition will return head component of the **target** player if the **viewer** is 1.21.9+, empty value otherwise.
[If you want to use this head syntax, you'll need to disable MiniMessage support](https://github.com/NEZNAMY/TAB/wiki/How-to-use-Minecraft-components#player-sprite), or use a syntax supported by MiniMessage (which is currently extremely limited).
Use this condition with `%rel_condition:head%`. The rel is important, so TAB knows the placeholder is a relational placeholder. If you forget to, the condition will return a warning message instead of configured value.
To showcase it, I have this in **groups.yml** (to show player versions as well):
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 the 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 the compatibility table below for current information about compatibility:
| Platform | Available |
|------------|-----------|
| Bukkit | ✔ |
| BungeeCord | ✔ |
| Modded | ❌ |
| 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 the 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 the 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 run 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 a 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 the plugin is reloaded.
* Users - Nothing is loaded on a plugin load. Whenever a player joins, all data of that player is requested from the database. Therefore, if a player's data changes on another server, it is visible immediately when a 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)
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.
Internal placeholders use a value hardcoded into the plugin by default. PlaceholderAPI placeholders use `default-refresh-interval`.
To begin, find this part in your config
```yml
placeholder-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 the 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] Don't use animations
While animations look cool, they also have a high resource usage.
This is because they work by spamming updates every time an animation switches to a new frame.
When animations are not used, no updates need to be sent (unless another placeholder changes value),
not causing extra CPU usage.
# #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,
the 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)
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.
# #7 - [Proxies] Disable TAB expansion
To maximize the 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.
**config.yml**:
```
placeholders:
register-tab-expansion: false
```
# #8 - [Proxies] Disable update-latency option in global playerlist
When [Global playerlist](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist) is enabled, you can enable / disable [update-latency](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Global-playerlist#:~:text=other%20unlisted%20servers.-,update%2Dlatency,-false) option (open the link for detailed description of the option). Disabling this option massively improves performance.
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 a manually defined refresh interval,
which I found the most optimal. You can [override the refresh intervals](https://github.com/NEZNAMY/TAB/wiki/Optimizing-the-plugin#2---all-platforms-placeholder-refresh-intervals) if you want to.
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 the fastest refreshing placeholder used inside each condition.
## Universal
These placeholders are available on all platforms.
| %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 |
| %uuid% | -1 | Player's UUID |
| %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 list in [TAB's source code](https://github.com/NEZNAMY/TAB/blob/master/shared/src/main/java/me/neznamy/tab/shared/ProtocolVersion.java). Useful for conditions to create per-version results using numeric operations since version names cannot be effectively compared. |
| %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 |
| %luckperms-prefixes% | 1000 | All prefixes combined from LuckPerms from the server where TAB is installed |
| %luckperms-suffixes% | 1000 | All suffixes combined 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) |
| %bossbar_announce_time_total_\<bossbar\>% | -1 | Total time (inputted value) of an announced bossbar. |
| %bossbar_announce_time_left_\<bossbar\>% | 100 | Remaining time of an announced bossbar. |
| %online_\<server name\>% | 1000 | Amount of online players on specified server (excluding vanished players) |
| %% | -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, they don't work when TAB is on a proxy. If you have TAB installed on proxy 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 proxy.
| %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 the server. Not directly available on modded platforms - primitive approximation using MSPT (TPS = 1000/MSPT, max 20) is used there. | %server_tps_1% |
| %mspt% | 1000 | Server's current milliseconds per tick (not available on Spigot) | - |
| %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) |
| %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 the second argument.
You can find most of the 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. To enable TAB's expansion, set
```
placeholders:
register-tab-expansion: true
```
in **config.yml**.
Full list of placeholders (general + feature specific):
| `%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%`) (this also applies [Placeholder output replacements](https://github.com/NEZNAMY/TAB/wiki/Feature-guide:-Placeholder-output-replacements) to them if configured) |
| `%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 (toggled with a command) |
| `%tab_tabprefix%` | Player's current tabprefix with placeholders parsed. |
| `%tab_customtabname%` | Player's current customtabname with placeholders parsed. |
| `%tab_tabsuffix%` | Player's current tabprefix with placeholders parsed. |
| `%tab_tabprefix_raw%` | Player's current raw tabprefix with placeholder identifiers. |
| `%tab_customtabname_raw%` | Player's current raw customtabname with placeholder identifiers. |
| `%tab_tabsuffix_raw%` | Player's current raw tabsuffix with placeholder identifiers. |
# Relational placeholders
## About
Unlike classic placeholders which take either 0
(placeholders with the 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.
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 it 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 a 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.
> [!CAUTION]
> Remember 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.
* You attempted to use a proxy-only placeholder on backend, or backend-only placeholder on proxy
* You used the `%` symbol before the placeholder, breaking placeholder starts and ends (see above).
## PlaceholderAPI placeholder is not working
Here are few possible reasons:
* The placeholder is not working in PlaceholderAPI. You can check this using `/papi parse me <placeholder>`. If it isn't working there, it's not a TAB issue. If the placeholder you used is advertised somewhere, make sure you have the adequate expansion downloaded.
* If you have TAB installed on a proxy, make sure [TAB-Bridge](https://github.com/NEZNAMY/TAB/wiki/TAB-Bridge) is installed on backend servers to forward support to the proxy.
* You used the `%` symbol before the placeholder, breaking placeholder starts and ends (see above).
# 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 the 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 username 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 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 that can be installed just like any other plugin.
It does not support proxies.
If you have TAB on a proxy server 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
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>_<placeholder>%`, where `<expansion>` 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%`.
Some plugins offer their own expansions,
which are either integrated into the plugin itself or external on PlaceholderAPI cloud.
Integrated expansions are not downloaded; instead, plugins register them automatically.
You can download / update external expansions using `/papi ecloud download <expansion>`. After downloading it, run `/papi reload` to enable it.
# 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 a proxy, 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 a proxy.
You can download it from [GitHub](https://github.com/NEZNAMY/TAB-Bridge/releases), [Spigot](https://www.spigotmc.org/resources/83966) or [Modrinth](https://modrinth.com/plugin/tab-bridge).
# Installation
Installation is as simple as it can be.
Put it into the plugins folder of your backend servers.
Bridge is NOT a proxy 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 their nametag invisible (compensation for 1.8.x client sided bug)
* Allow detection if a player is disguised to disable collision to prevent endless push
* Forwarding permission groups of players if no permission plugin is installed on the proxy
* 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 proxy
* Forward player's gamemode for spectator fix feature to work
# Compatibility
Just like with Minecraft, when there is a change in the communication protocol between TAB ↔ TAB-Bridge,
older software will not be compatible with the new one.
You should always be running the 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:
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.
* Create spark reports and then send them to me. I will analyze them and try to find optimizations to make the plugin run faster. Commands:
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Loaded 100 of 934 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.