Waterfall
Waterfall copied to clipboard
Proxy does not handle duplicate scoreboard teams across connections
[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]
What's even that?
Team §7§0§l[§9§lP_Mc� already exists in this scoreboard
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 [17:51:04] [Netty Worker IO Thread #60/ERROR]: [/79.45.96.127:53816|Killator] <-> DownstreamBridge <-> [hub-1] - encountered exception java.lang.IllegalArgumentException: Team 718eb already exists in this scoreboard at com.google.common.base.Preconditions.checkArgument(Preconditions.java:191) ~[waterfall.jar:git:Waterfall-Bootstrap:1.14-SNAPSHOT:c3d67e5:290] at net.md_5.bungee.api.score.Scoreboard.addTeam(Scoreboard.java:73) ~[waterfall.jar:git:Waterfall-Bootstrap:1.14-SNAPSHOT:c3d67e5:290]
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, [email protected] 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 https://github.com/PaperMC/Waterfall/issues/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, [email protected] 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 https://github.com/PaperMC/Waterfall/issues/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 [email protected] 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 https://github.com/PaperMC/Waterfall/issues/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?
queue scoreboard packets and flush them through
Do you mean storing each server sent scoreboard packet in a list and then sending the destroy packet for them on server switch?