Open Timongcraft opened 1 year ago
We are just enforcing vanilla protocol limits for the plugin message packet size.
Can you name any reasons on why you need this changed?
E.g. the Axiom Mod (https://axiom.moulberry.com) with the Plugin (https://github.com/Moulberry/AxiomPaperPlugin) is a very useful building mod which sends large custom packets.
They should fix it in my opinion, its not a bungee issue
If you could cancel the kick the packet would still not be read to the end and would get dropped
But why? It works for example with velocity, so why should't it with bungeecord?
I agree that it's not a bungeecord issue, but it's not so easy to fix on my end.
To clear up some confusion, the Paper plugin supports the increased packet size, so the 'vanilla limit' is being bypassed on Paper's side. It's just BungeeCord that won't let the packet through to Paper.
The mod & plugin supports changing the packet size limit here from 0x100000 to Short.MAX_VALUE, which would solve the disconnect on BungeeCord's side.
However, doing so will result in extreme performance degradation due to the large number of packets and reduced compressability of a 32k buffer compared to a 1mb buffer.
As the original poster said, a reasonable middle-ground would be to introduce a config option to change these limits. If this is an acceptable solution, I'd be happy to submit a pull request to this project.
Thanks, Moulberry
I would prefer not making this a regular config option.
I suggest bungee doing one of these things:
Bungeecord version
git:BungeeCord-Bootstrap:1.20-R.02-SNAPSHOT:94ea027:1726 by md_5
Server version
git-Paper-169 (MC: 1.20.1) (Implementing API version 1.20.1-R0.1-SNAPSHOT) (Git: b4e3b3d)
Client version
1.20.1
Bungeecord plugins
none
The bug
If you send large packets you get a exception that "the payload is too large" and get kicked. Which in my opinion should just be managed by plugins and/or controlled by a config value.
Log output (links)
Checking