NEZNAMY / TAB

"That" TAB plugin.
Apache License 2.0
877 stars 248 forks source link

[RedisBungee] Tablist formatting fails to apply for players on other proxies #1317

Open efekurbann opened 2 months ago

efekurbann commented 2 months ago

TAB version

4.1.5

Software causing compatibility issue

RedisBungee (Velocity)

Additional info

In our server, some groups has hex colors in their prefixes, to change the player's displayname. However, as the title says, while the players on the same proxy can see eachother's tablist names correctly. But if a player is on a different server than other is, colors are rounded to the nearest legacy code. Both server's config is the exact same.

image

Checklist

NEZNAMY commented 2 months ago

Could it be that it's the nametag format in tablist instead? Can you add something to tagsuffix and tabsuffix (something different) to confirm? On which marketplace is 4.1.5 latest?

efekurbann commented 2 months ago

My apologies on lying about it being the latest. I'll update it tonight but didn't want to wait until then. What changes do you want me to do on tag and tab suffix? And on both the servers?

NEZNAMY commented 2 months ago

Yes on both servers. You don't seem to have anything configured, so it's a great spot to put the testing text in. Just put in anything that will be different for each property to confirm it's indeed nametag format in tablist. Also try latest build from actions.

efekurbann commented 2 months ago

Updating to 5.0.0-SNAPSHOT from the latest build seem to break EVERYTHING. Here is a few error logs from my setup. https://mclo.gs/xRb3ojo

Player TAG names did not update nor show at all, TAB names did not update as well. I guess 5.0.0 is a breaking update, especially for RedisBungee setups. Even players were not able to see each others displaynames properly. However, /btab reload seemed to solve it. I guess I'll stick to 4.1.6 for now.

If you need further testing, let me know.

efekurbann commented 2 months ago

However, when using 4.1.6 I noticed that whenever I update my parent group, It's colors are shown correctly. Switching servers (Paper, not Velocity) seem to break it. (still, both players on different proxies) I am not sure if this information is good enough for you to understand what's wrong or not, just something I noticed.

NEZNAMY commented 2 months ago

Fixed the error. Please try new build.

efekurbann commented 2 months ago

There is some progress. I can now see hex colors but I am not sure if it is fixed or not because I need to do /btab reload after rejoining the server. here is another err log: https://mclo.gs/ZAI0K5m

NEZNAMY commented 2 months ago

I am recoding the entire feature right now. Do you have discord? I need someone to test it for me (on a testing environment).

efekurbann commented 2 months ago

Sure. @efekurban

MacTh3Mac commented 2 months ago

Similar issue, Velocity 3 (latest) TAB 5.0.0SNAPSHOT from methods. Tablist formatting not applied for players on other proxies with redis-bungee, including sort order.

behaviour observed (ss taken from different proxy where players are located only player displayed correctly is myself:

image

Behaviour Expected (similar to below (discounting the fact that this SS is on a layout) all players shown correctly:

image

NEZNAMY commented 2 months ago

Their names look still colored though. Do you have tablist formatting anti-override enabled?

MacTh3Mac commented 2 months ago
tablist-name-formatting:
  enabled: true
  anti-override: true
  disable-condition: '%world%=disabledworld'
MacTh3Mac commented 2 months ago

color comes from backend bukkit server software and its nametags

image

NEZNAMY commented 2 months ago

Does it show correctly for players on the same proxy? Did you get errors.log file in TAB folder?

MacTh3Mac commented 2 months ago

Error log on fresh boot of Proxy.

28.06.2024 - 16:11:57 - [TAB v5.0.0-SNAPSHOT] An error was thrown when executing task 28.06.2024 - 16:11:57 - java.lang.IllegalStateException: java.io.EOFException 28.06.2024 - 16:11:57 - at com.google.common.io.ByteStreams$ByteArrayDataInputStream.readUTF(ByteStreams.java:458) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.features.redis.message.PlayerJoin.read(PlayerJoin.java:49) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.features.redis.message.Load.read(Load.java:34) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.features.redis.RedisSupport.lambda$processMessage$1(RedisSupport.java:70) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.cpu.TimedCaughtTask.run(TimedCaughtTask.java:28) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.cpu.CaughtTask.run(CaughtTask.java:18) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) 28.06.2024 - 16:11:57 - at java.base/java.lang.Thread.run(Thread.java:833) 28.06.2024 - 16:11:57 - Caused by: java.io.EOFException: null 28.06.2024 - 16:11:57 - at java.base/java.io.DataInputStream.readFully(DataInputStream.java:203) 28.06.2024 - 16:11:57 - at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:614) 28.06.2024 - 16:11:57 - at java.base/java.io.DataInputStream.readUTF(DataInputStream.java:570) 28.06.2024 - 16:11:57 - at com.google.common.io.ByteStreams$ByteArrayDataInputStream.readUTF(ByteStreams.java:456) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.features.redis.message.PlayerJoin.read(PlayerJoin.java:49) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.features.redis.message.Load.read(Load.java:34) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.features.redis.RedisSupport.lambda$processMessage$1(RedisSupport.java:70) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.cpu.TimedCaughtTask.run(TimedCaughtTask.java:28) 28.06.2024 - 16:11:57 - at me.neznamy.tab.shared.cpu.CaughtTask.run(CaughtTask.java:18) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) 28.06.2024 - 16:11:57 - at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) 28.06.2024 - 16:11:57 - at java.base/java.lang.Thread.run(Thread.java:833) 28.06.2024 - 16:13:21 - [TAB v5.0.0-SNAPSHOT] Unable to unregister team of redis player MoonxLightss on quit, because team is null 28.06.2024 - 16:13:21 - [TAB v5.0.0-SNAPSHOT] Unable to unregister team of redis player MoonxLightss on quit, because team is null 28.06.2024 - 16:16:34 - [TAB v5.0.0-SNAPSHOT] Unable to unregister team of redis player Da_SneaX on quit, because team is null 28.06.2024 - 16:16:56 - [TAB v5.0.0-SNAPSHOT] Unable to unregister team of redis player Da_SneaX on quit, because team is null 28.06.2024 - 16:17:22 - [TAB v5.0.0-SNAPSHOT] Unable to unregister team of redis player Da_SneaX on quit, because team is null 28.06.2024 - 16:18:31 - [TAB v5.0.0-SNAPSHOT] Unable to unregister team of redis player rookieEd on quit, because team is null 28.06.2024 - 16:19:47 - [TAB v5.0.0-SNAPSHOT] Unable to unregister team of redis player Hei_bk on quit, because team is null

MacTh3Mac commented 2 months ago

Yes multi players on same proxy display correctly. even when on different grouped servers.

NEZNAMY commented 2 months ago

That error makes absolutely no sense at all. Could you be using completely different TAB versions on each proxy? Are configs the same?

quiquelhappy commented 2 months ago

we see similar issues in which we see white names every now and then. we have 5 proxies, all with the exact same versions (we deploy them using git with exactly the same configuration). the only change factor between proxies is the ping to redis node. some instances can have up to 300ms ping to our redis node - i dont know if that could be a factor causing parsing not to be working correctly.

also (maybe I should create a different issue but it seems it could fit in this issue scope) - spectator mode for players on different servers is not applied when they are on a different proxy, and they show as normal players instead of spectator players.

NEZNAMY commented 2 months ago

we see similar issues in which we see white names every now and then. we have 5 proxies, all with the exact same versions (we deploy them using git with exactly the same configuration). the only change factor between proxies is the ping to redis node. some instances can have up to 300ms ping to our redis node - i dont know if that could be a factor causing parsing not to be working correctly.

also (maybe I should create a different issue but it seems it could fit in this issue scope) - spectator mode for players on different servers is not applied when they are on a different proxy, and they show as normal players instead of spectator players.

Is that with 4.1.6 or 5.0.0? The spectator thing is a missing feature that I will add.

quiquelhappy commented 2 months ago

4.1.6

NEZNAMY commented 2 months ago

Then it makes sense that the bug reported in version 4.1.6 is present in 4.1.6.

MacTh3Mac commented 2 months ago

Confirm that on V5.0 when on all same version, tablist formatting applies as expected. Vanished player support seems to be inconsistent or broken, but no errors generated, TAB installed on front and back ends. Thanks

NEZNAMY commented 2 months ago

Mixed installation is unsupported and will result in issues.