Additional information

About

This is a collection of random information about the plugin not necessarily limited to a single feature or function.

Content

• Bedrock compatibility
  • Detection
  • Differences
  • Issues with . in name
• Vanish detection
• Async player loading
• Scoreboard objective and team naming
• Per-version experience
  • Detection
  • Differences

Bedrock compatibility

Detection

For TAB to properly detect player as a bedrock player, floodgate and TAB must be installed on the same server instance and if TAB is on bukkit and floodgate is on both bungeecord and bukkit, make sure they are connected.

To make sure floodgate is configured correctly, set debug: true in TAB config and check console output on join/reload.
It should say Floodgate returned bedrock status TRUE for player <player>.
If it says FALSE for an actual bedrock player, you didn't connect floodgate properly.

Differences

It is job of plugin allowing bedrock clients to connect (probably Geyser) to correctly translate all packets. If you are experiencing an issue on bedrock but not java, it is most likely not an issue in TAB code.

Currently, TAB does check for bedrock clients for:

• Displaying scoreboard numbers as 1-15 instead of all 0 even if it's set to all 0, because lines would not be ordered correctly.
• Disabling Layout for bedrock players.
• Disabling Yellow Number for bedrock players due to many issues with the feature on bedrock.

These are the only 3 known changes that are required on TAB side.

Issues with . in name

If you configured Geyser to prefix bedrock player names with ., it will mess up config loading, because . is used to split section path. This means that using /tab player <playername containing .> ... will not work.
There are 3 solutions available:

• Use player UUID if commands are executed via another plugin (/tab player <uuid> ...).
• Use playeruuid type, which accepts player name and saves the online player's UUID (/tab playeruuid <player name> ...).
• Use a different username prefix than ..

Vanish detection

Although TAB does not manage player vanishing in any way, it checks for vanish status for features to be properly compatible. At the moment, vanishing detection is used for:

• %vanished% placeholder (used for internal functionality, but can be used to display vanish status if one wants to)
• %online%, %serveronline%, %worldonline% and %staffonline will not count vanished players
• Aligned tabsuffix uses it to make sure it doesn't add extra spaces due to vanished players people cannot see (unless player can see vanished players, see below).
• Global playerlist makes vanish plugins unable to remove players on other servers from tablist, vanish check will make TAB remove vanished players.
• Potentially hide vanished players from Layout.

Permission tab.seevanished allows players to:

• See vanished players in Global playerlist.
• Makes Aligned tabsuffix count for vanished players when applying spaces for alignment.
• See vanished players in Layout.

For a player to be detected, at least one condition must be met:

• When TAB is installed on BungeeCord, PremiumVanish is installed as well and PV says player is vanished, player is considered vanished.
• Player has to have vanished metadata flag set to true. Most, if not all vanish plugins do this, including, but not limited to CMI, Essentials, SuperVanish, PremiumVanish and probably more. If TAB is installed on BungeeCord, Bridge must be installed on backend servers to forward vanish status to the proxy.

Async player loading

In order to not slow down the server, TAB loads players asynchronously on join. As a casual user this does not impact you, but there are some cases where you'll feel it:

• Players will not be accessible in the API during PlayerJoinEvent
• TAB's PlaceholderAPI expansion will not be accessible during join process, such as when trying to use it in plugins editing join messages (the exception is replace_ placeholder, which doesn't directly use any TAB code).

Scoreboard objective and team naming

There's a well known BungeeCord bug that kicks players if a duplicate team or objective is registered. This message also shows the name of the objective/team. Before reporting this, make sure it actually comes from TAB.

TAB's objective and team naming:

• Objectives ("Objective ... already exists in this scoreboard")
  • TAB-BelowName for Belowname
  • TAB-Scoreboard for Scoreboard
  • TAB-YellowNumber for Yellow Number
• Teams ("Team ... already exists in this scoreboard")
  • For sidebar scoreboard: TAB-SB-TM-x where x is a number from 1 to 15+ (for each line)
  • For players: This is more complicated to use the 16 character limit to the max and heavily depends on configuration. If you are sorting by player names, part of player name will be there. The most reliable way is the team name (almost) always ending with A (or B, C etc if you tried to sort several players into the same slot).

Per-version experience

Minecraft has changed over the years - it had some limits removed, some added, some bugs fixed, but also some bugs added. TAB adapts code based on player's version for best possible experience on each minecraft version.

Detection

When TAB is installed on a proxy, the proxy's API is used to get player version.
When TAB is installed on a backend server, ViaVersion's API is used to get player's version (as it's the only plugin allowing multiple versions, ProtocolSupport is abandoned).

You can check what version the plugin thinks player has using any of the following:

• /tab parse <player> %player-version% - Returns version name, if multiple versions share the same protocol, the newer one is returned
• /tab parse <player> %player-version-id% - Returns network id of player's version
• Set debug: true in config and check console messages on player join, it will send a message containing game version ViaVersion API has returned

Player game version detection may fail. Here are a few possible scenarios why:

• ViaVersion is installed on BungeeCord
  • And TAB on BungeeCord as well - ViaVersion makes BungeeCord API return version of the backend server player is connected to instead of player's actual version
  • And TAB is on backend servers - There is no ViaVersion to hook into, therefore there is no suspicion of player not using server's version not having a way to verify it
• ViaVersion API returns -1 - There is currently no known cause when or why this happens. However, when this happens, TAB prints a console warn notifying this has happened. Plugin will assume player is using same version as the server in such cases.

When game version is not detected correctly, player's experience will be very limited, see below.

Differences

To ensure the best possible experience, TAB is currently checking for player's version to:

• Layout:
  • Disable for 1.7 and lower due to massive tablist differences and plugin not being adapted to those
  • Use alternate method of sorting the entries for 1.19.3+ using entry names, as the previous, better option was removed
• Unlimited nametag mode:
  • Hide armor stands for 1.14.x players when sneaking due to a bug with sneaking armor stands
  • Disable for 1.7 and lower due to armor stands not being available there and nametags not supporting invisible option
  • Show armor stands in height that matches vanilla tags which has been changing over the versions
• Use RGB color codes for 1.16+ and use closest (or forced) legacy color for 1.15-
• Use 1.9+ bossbar on 1.8 servers for 1.9+ players using ViaVersion API
• Not try to send Header/Footer to 1.7 and lower
• Disable Tablist name formatting for 1.7 and lower due to a 16 character limit total to take advantage of the mechanic where nametags are displayed in tablist, which extends the limit to up to 48 characters (16 prefix, 16 name, 16 suffix)
• Play around <1.13 limitations of Scoreboard
• Cutting nametag prefix/suffix to 16 characters for <1.13, but keeping it full for 1.13+

When version detection fails, plugin's workarounds will be wrong and cause problems, such as:

• Nametag prefix/suffix being cut to 16 characters, even for 1.13+ clients
• Scoreboard lines limited to ~26 characters, even for 1.13+ clients
• Scoreboard lines limited to 14 characters, even for < 1.13 clients
• Scoreboard lines might be out of order
• RGB colors displaying as legacy colors for 1.16+ clients
• Layout being out of order for 1.19.3+ clients