NEZNAMY / TAB

"That" TAB plugin.
Apache License 2.0
883 stars 247 forks source link

nametags (group) not properly shown between two proxies #1365

Closed 301haru closed 1 week ago

301haru commented 1 week ago

TAB version

4.1.8

Software causing compatibility issue

Velocity 3.3.0

Additional info

for example lets say

examplegroup: tabprefix: "example" tagprefix: "example"

is written in groups.yml

there are two proxies (Velocity A, Velocity B) pointing to the same minecraft server (Server A)

Player A joins Server via Velocity A, Player B joins Server via Velocity B between Velocity A and Velocity B, TAB settings are exactly same, and permissions (groups) between servers are synced by db

However, even though Player A's primary group is "examplegroup", Player B cannot see Player A's tab prefix nor tag prefix. but if Player B joins the server via Velocity A, now it can see prefixs normally.

even though Velocity B knows Player A's primary group, but TAB does not recognizing Player A's group so Player B just see white default Player A's name.

Checklist

NEZNAMY commented 1 week ago

https://github.com/NEZNAMY/TAB/wiki/Feature-info:-RedisBungee-support Are you sure you installed that plugin? /velocity plugins.

301haru commented 1 week ago

so in this case RedisBungee is essential? I am not using RedisBungee in my server currently because it is not required to handle what I need for multiple proxy.

NEZNAMY commented 1 week ago

Then how is TAB supposed to know there exists some other proxy out there, let alone get data from it?

Tanguygab commented 1 week ago

Why not just use TAB on the backend (which is aware of all players connected to it) rather than on each proxy (which only knows players connected to the backend through itself)?

301haru commented 1 week ago

I am using TAB both on backend and frontend and only using name formatting things on frontend because of some optimizations .

Tanguygab commented 1 week ago

Mixed installation is not supported, do not use TAB on both the proxies and backend server,just keep it on the backend, I don't see what "optimizations" it would bring, it's just making everytime more complex and won't even work for what you need

301haru commented 1 week ago

yeah I know it is not supported and it makes everything more complex. I had many trials to make everything works fine. but in my case mixed installation was mandatory. I am currently using TAB in MultiPaper so if I just let TAB calculate things everything on backend servers, CPU usages was getting so high so mixed installation was the best solution for optimizationing in high player counts.

so RedisBungee would be a best solution for the problem..?

NEZNAMY commented 1 week ago

If you are running into performance issues, make a spark report and send it. For best results, use /spark profiler start --timeout 300 --thread * --interval 0.01 or a different timeout of your choice.

301haru commented 1 week ago

what about let tab bridge send player infos to proxies. maybe that would fix this case. I can't make spart report right now but I'll check it. High CPU usage problem occur in high player counts (1000+player) with scoreboard-teams enabled.

NEZNAMY commented 1 week ago

Using plugin messaging would make performance even worse. Velocity can't even send scoreboard packets, because they are not available there. Dev builds should drastically improve performance at high player counts as well.

301haru commented 1 week ago

I'll try spark with both Dev builds and current release soon as I get free time and if I get any performance problems I'll open new issue for that. For now I'll close this issue.