Incorrect Tab List Displayed on Server Change Using 1.20.2 Client

[MacTh3Mac]

Steps to reproduce: Join Bungee Network. (Correct tab List is Shown). in all client versions
Change Server to a server that should display either a server specific tab list or global tab list.
Tab list shown has players in wrong order, gaps, formatting is incorrect places, Only on client version 1.20.2

No errors generated in logs, Doesn't occur on Client Versions 1.20.1 or lower.

Below are 2 example tab lists, the issue is the same for global tablists as well as the server specific tablist as shown in the example below that is shown on our long-term hubs.

Is some of the formatting not making it to the client?

If it helps, Environment All Linux, multiple bungees with player data synced with redis-bungee (all on waterfall). I have also tested on a single non-load balanced and data shared bungee and the issue persists.

Tablist Shown on 1st Join

Tablist Shown after Server Change

I also have logs spammed with this error upon disconnect only.
https://pastebin.com/7jypXQ4N

Note the error is on final user proxy disconnect, not server change / join or otherwise. Log produced on Test Proxy running Bungeecord (not waterfall)

Originally posted by @MacTh3Mac in #727 (comment)

[Kas-tle]

I have tried ignoring packets after the connection is no longer valid but they are not the cause of this error. But I would just like to confirm, do these issues still occur on the first join immediately after a proxy restart?

[MacTh3Mac]

I have tried ignoring packets after the connection is no longer valid but they are not the cause of this error. But I would just like to confirm, do these issues still occur on the first join immediately after a proxy restart?

If you are referring to this error: https://pastebin.com/5tz5iEq6
I just generated it on a freshly booted Bungeecord Server, joined, didn't change servers and disconnected. (note tab list displayed correctly)

If you are referring to the incorrectly formatted tab-list - Same behaviour is experienced on a freshly started proxy on backend server switch

[Kas-tle]

Sorry, correction. The packets are the cause of the logged error. But the error is unfortunately not related to the issue.

[4L0N50asd]

I'm having this issue too, here's some images to prove it
Network info:
3 Paper Servers build 196 (latest) (1.20.1)
BungeeCord 1.20.2 version #1756 (build from 4 october)
Plugin version: BungeeTabListPlus #1141 from Jenkins (latest dev build)

Client info:
Vanilla 1.20.2

When i join to the network, I see correctly the tablist

Switched to Factions server

then I switch to Survival server

if i change my gamemode to spectator i won't see the plugin's tablist because i set up that a long time ago in the config, so i thought this would work as a way to "update" the tablist. Then I change my gamemode to spectator and change it again to survival, and i see again that buggy tablist (second image)

Here are some errors the Bungee console sends every time i leave from the server https://pastebin.com/raw/TSLCxUg2
https://pastebin.com/raw/fcYrBuWz

This problem is not showing up when using client 1.20.1 or lower. This is just happening with client 1.20.2

Also here are some proofs using client 1.20.1 that the tab is working and how i expected to work with 1.20.2 client

[andrewkm]

@4L0N50asd The errors I believe relate to #730 which is a separate issue.

[CodeCrafter47]

I now have been able to reproduce the issue. Apparently it only happens when experimentalTabCompleteSmileys is set to true.

[MacTh3Mac]

Can Confirm Resolved by : 960de6c

Many Thanks

[MacTh3Mac]

After Further Testing with Waterfall 547 & BungeeCord (Latest) it appears that this issue is unresolved. It just so happened on previous test we got lucky on 5 backend server changes.

Additional Info experimentalTabCompleteSmileys is set to false

Appears #732 (comment) is duplicate of this issue.

[Niko302]

Experiencing same issue.
Quick note if you relog it fixes it. (if that is to any help at all)

[MacTh3Mac]

Experiencing same issue.
Quick note if you relog it fixes it. (if that is to any help at all)

This issue isn't apparent on 1st Join (hence the re-log). It only occurs after server change.

[andrewkm]

I still cannot reproduce this.
Perhaps post your config so we can compare and find what is causing it.

[aurel85]

I have this problem too, here is my config for this server : https://paste.denizenscript.com/View/116510
and general config : https://paste.denizenscript.com/View/116511

[MacTh3Mac]

I still cannot reproduce this.
Perhaps post your config so we can compare and find what is causing it.

The config is clearly not an issue when it doesn't occur on any client other that 1.20.2.
The issue is that the teams / tablets formatting information isn't making it to the client after a server switch on all occasions. Likely a timing issue to ensure the client isn't still in a configuration state when packets sent.

Configs posted below, only to allow author to ensure he has ticket all eventualities, but IMO his last fix is in the right direction, just needs to be a little more robust. (it works on a local client with very low latency in 90% of cases, just doesn't on a busy public network)

Config - https://pastebin.com/AAz6PsV1
Hub Tablist - https://pastebin.com/1we0JsLu
GameServer Tablist - https://pastebin.com/TUAwL7Jt

[CodeCrafter47]

I made another change. It is a bit of a shot in the dark. But I hope it will address the issue.

The previous fix was to add a check whether the client in in the configuration phase, and suspend updating the tab list while that is the case. I have now noticed, that the client would still sometimes receive packets while in configuration phase. I'm not sure why that is. Maybe it can't be accurately checked for or I'm doing it wrong.

Now I suspended updating the tab list when switching servers until a tab list packet is received from the new server, which should indicate that the configuration phase is over.

[Toni-99]

Works fine for me. Thanks 4 the update

[aurel85]

The bug persists on my server despite the new version :/

[Toni-99]

Yep. Worked one time for me, then it was buggy again

[Toni-99]

Are there any updates scheduled? @CodeCrafter47

[CodeCrafter47]

At the moment I'm out of ideas. I don't know how to fix the issue.

[andrewkm]

I've still been completely unable to reproduce this, even on servers that are very active and busy.

[MedvedEE]

Having the same issue, changing server messes up the tab order. Currently some times, for couple players, the tab order fixes itself and then for some minutes/few tab presses, the order breaks again

[Toni-99]

It's a 1.20.2 Client Bug I guess. 1.20.1 works completely fine 4 me

[ItzRobin]

Hmm yes, it only occurs with a 1.20.2 client but as soon as I reload the plugin (/btlp reload) the problem is solved. That suggests that the solution should be looked for on the server-side right?

Waterfall version: waterfall-1.20-545.jar

[aurel85]

With the last version of this plugin and PlaceHolderAPI (2.11.5), Paper (260) & Bungee (1763) here's what it looks like this morning :

Error in bungee console : https://pastebin.com/Btqxf1W4

[waseric]

With the last version of this plugin and PlaceHolderAPI (2.11.5), Paper (260) & Bungee (1763) here's what it looks like this morning :

Error in bungee console : https://pastebin.com/Btqxf1W4

These are symptoms of #735

[MedvedEE]

The latest dev-build fixed it for me

[aurel85]

For my part it is not completely resolved, my config has not changed and yet it seems that everything is broken :/

[aurel85]

With the last version everything is ok ! Thanks !

[andrewkm]

With the last version everything is ok ! Thanks !

This is great to hear!
This was quite a long issue, and although I could never reproduce it, it's clear others had problems.
I did try my best to fiddle with certain aspects of the server but could never get it going lol.

Are things good for you @MacTh3Mac ?

[MacTh3Mac]

Can confirm in the following environment:

BTLP: 9c56d1b

Proxy:
BungeeCord-Bootstrap:1.20-R0.2-SNAPSHOT:bd8d114:1769
or
Waterfall-Bootstrap:1.20-R0.2-SNAPSHOT:cc856ed:552

Client any version > 1.13

Display issue appears resolved after 20-30 server changes.

Unfortunate side effect can confirm this build does indeed prevent users on a client <1.13 from joining network. So not suitable for public deployment as stands, but really really close. Unconnected issue so will post no more about the client crash <1.13 in this thread.