Skip to content

Instantly share code, notes, and snippets.

@NEZNAMY
Last active June 28, 2025 16:50
Show Gist options
  • Select an option

  • Save NEZNAMY/3dfcbf7d44283735d3c18266a2851651 to your computer and use it in GitHub Desktop.

Select an option

Save NEZNAMY/3dfcbf7d44283735d3c18266a2851651 to your computer and use it in GitHub Desktop.
The "less than 4 columns" problem

The "less than 4 columns" problem

About

This page explains how the layout feature in TAB works and what are the problems preventing me from adding support for less than 4 columns.

Current functionality

Currently, TAB takes advantage of the 80 player tablist limit and therefore sends 80 fake players. They are sorted by UUID (<1.19.3), name (1.19.3 - 1.21.1) or listOrder (1.21.2+). The real players are pushed out of the tablist and not visible. This gives the plugin full control over what players see in the tablist without having to rely on other functions like teams to sort players.

The problems

Let's assume we are below 1.19.3 (new possibilities will be explained below). If we want let's say 3 columns, the tablist will have to consist of real players, as well as fake players.

Problem #1 - Teams - permanently enabled & no disable-condition

To sort all entries (real and fake), the only realistic way is with teams. So now, layout feature will require teams feature enabled. Not only that, but also disable-condition cannot be respected for this reason. While you might think "what if we want no layout under certain condition, while also having teams disabled there", this wouldn't be possible, because disable-condition for teams works for target player, not viewers. For that reason, even if a player doesn't see any layout, if their team was disabled, players who can see a layout would see this player without a team, causing incorrect sorting. While most users should be fine with this, it is still a thing to consider.

Problem #2 - Limited size of player-groups

People usually want to limit the amount of slots in player-groups. When a limit is reached, the last slot says "... and X more" (or whatever message is configured). However, now, the players will need to be somewhere. But where? In a new column? That defeats the purpose of limiting player slots / separating them. Yes, there is at least 1 server in existence that puts all players into one group and just wants those empty slots like it was back in 1.7, but most users of this feature don't do that.

Problem #3 - Handling players that overflow

Following up on the previous problem, even if overflow of player groups was not a problem, there can still be just a general overflow if too many players are connected. If you configured for example 3 columns and your fixed slots + online players exceeded 60, what then? Just put the players into the 4th column without any deeper logic? Allow users to configure this? One way would be letting people configure multiple layouts with conditions and check for %online% count and display layout based on that. It would require them to properly calculate the correct player count to check for. And I'm not even mentioning possibly different tablist view if someone can see vanished players, so even this solution wouldn't work all the time. This is, as you can see, not an ideal solution and if people don't do it, the plugin shouldn't explode.

Configuration changes

TODO

News in recent MC versions

Recent MC versions contain some cool additions, but they are unfortunately not enough. We could make less than 4 columns a feature only since a certain version, which is not ideal, as we would like a solution for all MC versions. Regardless, let's go through the new content.

News in 1.19.3

In 1.19.3, tablist entries have received a new property called "listed". It specifies whether the entry is actually visible or not. This way, we could hide some players or actually hide all of them and only show fake players like we do now, except we only show less of them. This would solve all 3 previously discussed problems. The problem here is controlling this new property. On Bukkit, BungeeCord and Fabric the plugin is listening to packets to modify them. This could be used to make real players unlisted. The issue is that this is not available on Velocity. They don't want us to use their internals and only share the API module. It would require a periodic check, which is not instant by nature, causing flickering. With high player counts, it would also cause high CPU usage. There were some pull requests that would solve this, but Velocity doesn't really accept contributions, so nothing came out of it. Very promising addition, but still not perfect. Maybe one day? Or maybe "not available on Velocity (yet?)?"

News in 1.21.2

In 1.21.2, tablist entries have received a new property called "listOrder". It defines sorting priority as a number (from highest to lowest). This would get rid of Problem #1 - Teams - permanently enabled & no disable-condition.

News in 1.21.4

In 1.21.4, tablist entries have received a new property called "showHat". It defines whether players should have their hats (extra layer of skin) visible. Previously, they were not visible, as the player must be spawned nearby to see it. This will no longer be an issue and therefore make the option to only show fake players even more viable.

Conclusion

There are many unanswered questions for this functionality to be added. In order to add a feature, first I need to know what it is actually supposed to do. If you believe you have something useful to share, feel free to do so below. If you are a customer, please consider doing it on the customer discord instead (in #chat for example).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment