Connecting through velocity plugin gives error

[Phelms215]

Using Velocity Plugin I received the "Unable to connect: Server requires client to have Data Attributes version 1.1.5" but 1.1.5 is already installed on both client & server. Connecting around the proxy works fine.

If I take this mod and the mods that use DataAttributes out the server connects fine.

[CleverNucleus]

Hi there, I don't know much about plugins, nor Velocity specifically - so I can't promise anything.

After some searching I have a fairly good idea about what's happening: many mods nowadays use datapacks for configuration - this is great for most things, but it often means that mods send a tremendous amount of data to/from the client when joining. Depending on the datapack, Data Attributes and PlayerEx specifically can send an enormous amount of data when joining. For PlayerEx/Data Attributes, the server sends a big packet to the client, and if the client acknowledges it, a feedback packet is sent to the server. If a) the client has the incorrect version or b) the server does not receive the feedback packet, login is terminated.

This is a long winded way of saying that I'm uncertain whether Velocity is a advisable for modded environments, specifically mods like PlayerEx. I suggest you try using Velocity with Origins, as it has a very similar login/packet system to Data Attributes/PlayerEx. If it works fine, it's a problem on my side and I'll do my best to fix it. If Origins also doesn't work, then you may instead need to take the issue up with Velocity. Do let me know either way though.

Hope that helps, Thanks.

[Phelms215]

You are correct, appreciate your insight. It doesn't appear to be specific to your mods as it'll happen with others including Origins.

I've reached out to the folks at Velocity & CrossStich to see if they have any ideas

[CleverNucleus]

Thanks for the feedback. In that case I won't close the issue, but I'll add an external label.

[purejosh]

As far as fixing this, the only way you could do it is by asking if the destination server has PlayerEX/DA, and if so, start the datapack packeting procedure. Possibly even use a packet limited process that slows the packeting speeds and shows a splash screen while waiting for it to complete? I don't know, these are just ideas.

With Velocity directly supporting modded fabric servers, the only limitations seem to be mod side, however I don't believe it natively supports larger than standard join packet sessions. It's unfortunate. I've reported a similar issue to Velocity, hoping they can fix it.

Also, for what it's worth, if the mod is checking for a server side mod and disconnecting when failed, that will directly conflict with velocity modded servers. If that behavior can be altered, that would be beneficial.

[purejosh]

[purejosh]

I've just been told by the developers of Velocity, the same as Paper, that enabling larger than 4mb packets will require a rewrite of the code IN velocity itself, not possible to modify using a velocity plugin. Here is their comment:

Bigger packets breaks protocol specification and is therefore unsupported. You would have to edit velocity itself to extend the maximum general hard limit for the frame decoder.
The packet sent here absolutely dwarfs the protocol specifications by over three times the maximum data.
Keep in mind that the normal maximum data limit per packet is around 4mb
We obviously can’t support protocol hacks that break vanilla specifications in ways we can’t deal with

That being said, your mod (and subsequently, any other mod that uses a similar large packet on join setup) will never work on servers using velocity proxy with a fabric modded setup.

This is a great disappointment to me, as there's really no other alternative to fabric modded servers behind a proxy. Velocity is really your only option.

If it's possible to code a "slow mode", or a way to disable the datapack checking feature entirely (for those who are really desperate), it would be cool. If not, I don't blame you. Coding such a system would be nothing short of a nightmare and I wouldn't wish that on an enemy.

[purejosh]

For what it's worth, I've used Origins on a modded fabric server, through my Velocity proxy. I don't know how it worked, as I'm not technically trained like you are. But it's possible that Origins packets aren't as big as originally thought.

[briarss]

Potentially including a check if the target server is velocity and stopping the data reloading could do it. That is an interesting idea. Not sure how feasible it is though.

[CleverNucleus]

Output releases for 1.18.2 and 1.19.2 that may resolve this issue - have not had the chance to test as the primary motive for latest version was not compatibility with Velocity.

If anyone is able to verify compatibility with Velocity as of Data Attributes versions 1.3.1 and 1.4.1, please let me know here.

[Vigilans]

Running on either 1.4.1 and 1.4.2 on velocity server, the issue still occured:

[CleverNucleus]

Hi @Vigilans, Thank you for confirming that the issue persists - even after custom packet compression, looks like too much data is sent on join :/

[Johni0702]

May or may not be related but an error suspiciously similar to above screenshot also happens when trying to open a replay in ReplayMod with data-attributes installed:

[22:49:03] [replaymod-async-sender/INFO]: [STDERR]: java.lang.IndexOutOfBoundsException: readerIndex(236070) + length(4) exceeds writerIndex(236070): UnpooledHeapByteBuf(ridx: 236070, widx: 236070, cap: 236070/236070)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at io.netty.buffer.AbstractByteBuf.readInt(AbstractByteBuf.java:809)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at net.minecraft.network.PacketByteBuf.readInt(PacketByteBuf.java:1242)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at net.minecraft.network.packet.s2c.play.GameJoinS2CPacket.handler$fbl000$data_init(GameJoinS2CPacket.java:522)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at net.minecraft.network.packet.s2c.play.GameJoinS2CPacket.<init>(GameJoinS2CPacket.java:60)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at net.minecraft.network.NetworkState$class_4532.createPacket(NetworkState.java:433)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at net.minecraft.NetworkState.getPacketHandler(NetworkState.java:485)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at com.replaymod.replay.FullReplaySender.deserializePacket(FullReplaySender.java:471)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at com.replaymod.replay.FullReplaySender.channelRead(FullReplaySender.java:421)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at com.replaymod.replay.FullReplaySender$2.run(FullReplaySender.java:1048)
[22:49:03] [replaymod-async-sender/INFO]: [STDERR]:     at java.base/java.lang.Thread.run(Thread.java:833)

The reason for this is that ReplayMod needs to read, modify and write the GameJoin packet (and it does so with custom code, i.e. not using the vanilla class because it works with multiple game versions), but data-attributes adds extra data to this packet, and that data gets lost because RM doesn't know about it. It's been a while but iirc Velocity too rewrites and/or synthesizes JoinGame packets when switching/joining servers.

Depending on what this extra data is, it should probably be sent in a custom payload packet instead of modifying vanilla packets.

[CleverNucleus]

Ah you're right @Johni0702 that could well be it - thanks for your insights, I'll see if I can maybe use custom payload here instead.

[CleverNucleus]

This issue may have been fixed with latest release: 1.4.5+1.19.2. However, Since I'm not actively testing this I won't close the issue.

@Johni0702 Incompatibility with ReplayMod should now be fixed - was likely not the same issue as with the Velocity plugin.

[sammyshear]

Unsure if this is directly related because I don't receive any actual errors in the logs on the velocity proxy, the backend, or the client other than a network communication issue. I have tried it with and without PlayerEx and DataAttributes and as far as I can tell it only occurs with those two mods installed. What's interesting is when I try to connect around the proxy it gives me the error: Server sent an impossible command tree, and I'm not sure if that's even related to either of these issues. I guess if it's not a velocity problem then that's good, but something is still going on that I'd like to try to figure out.

[WDNMDSKL]

Can you tell me how to fix the conflict between version 1.18 and replay mod? I need to play with 1.18, and if you can, you can provide a beta version of the file

此问题可能已在最新版本中修复：1.4.5+1.19.2。但是，由于我没有积极测试，因此不会关闭该问题。

现在应该修复与 ReplayMod 的不兼容 - 可能与 Velocity 插件的问题不同。