-
-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proxy does not handle duplicate scoreboard teams across connections #318
Comments
What's even that? |
Known bungeecord issue, you can't swap to servers which duplicate scoreboard names, "fix" is to ensure that servers won't duplicate scoreboard team names, hopefully I'll try and take a proper stab at this sometime... |
any progress on this? |
It's fixed for me after new updates |
i still see |
This issue is ongoing. Please fix |
Workaround already presented in here. |
I dont understand the scoreboard fix or how I got about fixing it. I dont use default scoreboard |
you need your plugins to use different scoreboard names on each server |
How do I do this @Janmm14. Also which plugins? |
whichever plugin is creating the team that is conflicting on the other server, if you copied worlds over and aren't using plugins, potentially wanna consider delating the scoreboard.dat for the servers involved; The only current fix is for bukkit plugins to take steps to prevent team name collisions across servers, this is an upstream issue |
Hmm I use featherboard and TAB. Not sure how to go about fixing |
@electronicboy How do I prevent plugins from creating the same team names on my different servers? |
Once again, you would need to speak to plug-in authors to try to mitigate
this;
…On Sun, 3 Nov 2019, 16:31 JHarris12345, ***@***.***> wrote:
@electronicboy <https://github.com/electronicboy> How do I prevent
plugins from creating the same team names on my different servers?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#318?email_source=notifications&email_token=AAJMAZAZNZRUOVJ2H4B3AX3QR34GBA5CNFSM4GHSAY42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5W76I#issuecomment-549154809>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJMAZBMKKIZ6D7C5G6PKT3QR34GBANCNFSM4GHSAY4Q>
.
|
If this is your suggested fix for the proxy, it would require additional
overheads to remap teams, would also create some potential oddball handling
if bungee plugins come into play
The ultimate fix is going to be to figure how to handle the server switch
better, my current thought is to just queue scoreboard packets and flush
them through, it is it's own set of headaches and mess, but the only other
alternative is to leave this solely on server/plug-in devs
…On Sun, 3 Nov 2019, 08:05 Mystiflow, ***@***.***> wrote:
One approach to fixing this is intercepting the Send Scoreboard packet,
comparing the scoreboard names and if they match; just mutate the new name
by 1 character or so (pretty sure a different name doesn't affect game
mechanics) and then cancelling the original packet and sending the new one.
Any teams and objectives should then bind to the new scoreboard in theory.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#318?email_source=notifications&email_token=AAJMAZABT4LKVNYMDGVM53LQR2A5LA5CNFSM4GHSAY42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5NBPI#issuecomment-549114045>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJMAZB2IBTF3IKFOE5O5J3QR2A5LANCNFSM4GHSAY4Q>
.
|
@electronicboy would intercepting the inbound Scoreboard Send work? Compare the previous scoreboard name with the latter and if they match; mutate the name by a character or so and send that packet instead? If I'm correct team/scoreboard packets don't require a scoreboard name they just latch on to the clients current scoreboard and if the client thinks it has a new scoreboard now; the team in theory won't pre exist? Would obviously need to confirm it wasn't the same server sending the Send Scoreboard packet though |
The client only has a singular scoreboard, teams are shared across all instances; This issue is also not down to the client, this is pretty much 100% a flaw in bungees server connection process; The new target server sends it’s scoreboard data before the proxy has cleaned up the scoreboard on the client, rewriting team names just adds additional complexity, bloat and overheads in the proxy
as an afterthought, this would also break the clients tab completion for scoreboards in these cases
… On 5 Nov 2019, at 11:34, Mystiflow ***@***.***> wrote:
@electronicboy <https://github.com/electronicboy> would intercepting the inbound Scoreboard Send work? Compare the previous scoreboard name with the latter and if they match; mutate the name by a character or so and send that packet instead? If I'm correct team/scoreboard packets don't require a scoreboard name they just latch on to the clients current scoreboard and if the client thinks it has a new scoreboard now; the team in theory won't pre exist? Would obviously need to confirm it wasn't the same server sending the Send Scoreboard packet though
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#318?email_source=notifications&email_token=AAJMAZHP2VQ7OVMBNFN4HSTQSFK2RA5CNFSM4GHSAY42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDCQ53Q#issuecomment-549785326>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJMAZBEUNCGIVMWUUYA5UDQSFK2RANCNFSM4GHSAY4Q>.
|
I haven't looked into the client code but what purpose then does the name string serve in the Scoreboard Send packet?
Do you mean storing each server sent scoreboard packet in a list and then sending the destroy packet for them on server switch? |
I have a similar problem...
|
@JH3Y50N Your issue is completley different (unrelated to duplicate scores!) . FYI bungee has recently fixed a regression with <1.13 scoreboard/team stuff, so wait for waterfall to update. |
congraturations for reply a 2018 post |
[23:25:54] [Netty Worker IO Thread #23/ERROR]: [/1.156.19.57:50127|Uber_Elite] <-> DownstreamBridge <-> [LegendBender] - encountered exception
java.lang.IllegalArgumentException: Team §7§0§l[§9§lP_Mc� already exists in this scoreboard
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:191) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at net.md_5.bungee.api.score.Scoreboard.addTeam(Scoreboard.java:73) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at net.md_5.bungee.connection.DownstreamBridge.handle(DownstreamBridge.java:208) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at net.md_5.bungee.protocol.packet.Team.handle(Team.java:122) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at net.md_5.bungee.netty.HandlerBoss.channelRead(HandlerBoss.java:103) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:323) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:297) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:799) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:421) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:321) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:897) ~[Waterfall.jar:git:Waterfall-Bootstrap:1.13-SNAPSHOT:a4b5eaf:238]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
The text was updated successfully, but these errors were encountered: