quilted-fabric-api icon indicating copy to clipboard operation
quilted-fabric-api copied to clipboard

Published 20 hours ago • verified publisher icon QuiltMC

Timeout when connecting to Quilt + QSL server behind Velocity proxy

Open unilock opened this issue 3 years ago • 35 comments

I'm trying to run a Quilt server behind Velocity.

When QSL is installed on the Quilt server, attempting to connect (through Velocity) results in the client hanging on the "Joining game..." screen for a few moments, followed by a "read timed out" error.

("the client" being a vanilla Minecraft client)

What does work:

  • Connecting to the Quilt server directly (bypassing Velocity)
  • Connecting through Velocity without QSL installed on the backend
  • Connecting through Velocity to an otherwise identical Fabric server (substituting QSL+QFAPI for the Fabric API)

The only thing that stands out to me in the logs is the following, printed to the client log when attempting to connect to the server:

[20:04:14] [Render thread/WARN]: Unknown custom packed identifier: qsl:registry_sync/handshake
  • Client log: https://mclo.gs/2nCYdNG
  • Quilt server log: https://mclo.gs/EI40G0x
  • Velocity log: https://mclo.gs/dXmIbRM

unilock avatar Nov 25 '22 01:11 unilock

Update: The same configuration under Minecraft 1.18.2 works fine!? QSL: qfapi-1.0.0-beta.28_qsl-1.1.0-beta.26_fapi-0.67.0_mc-1.18.2.jar

unilock avatar Nov 27 '22 03:11 unilock

I thought https://github.com/QuiltMC/quilted-fabric-api/commit/d92a7d9e91bfea24b69733653cf69f44a7cf0a1e might have something to do with this issue, but qfapi-4.0.0-beta.1_qsl-3.0.0-beta.2_fapi-0.58.5_mc-1.19.1.jar (for 1.19.1), which includes said commit, also works fine!?

Frustrating!!!

unilock avatar Nov 27 '22 13:11 unilock

I had the same issue while running this on my server, a specific qfapi version "fixed" it, with the main problem being that it locks me on updating mods on my server. qfapi-4.0.0-beta.7_qsl-3.0.0-beta.10_fapi-0.59.0_mc-1.19.2.jar (as seen at https://github.com/roridev/soberana-server-mods/commit/61b60b2e426b1afe9b61607fda8073c401b86d1a) I expect that a change in fabric api prior 0.59 broke compatibility with Velocity.

As I could personally "fix" the problem I delayed reporting this problem cause there was a patch for it and it seemed to be a very specific edge-case that no one else would need.

Fixing it by replacing it with fabric api isn't a possibility for me due to the server using switchy, which requires qsl.

Keeping it with this patch is also unwanted since that'd lock me into the current modpack, unable to update or add mods without fiddling with specific mod versions, likely also locking the server to 1.19.2, since anything with a hard dependency prior to fabric api 0.6 is incompatible.

Important notes from my experiments:

  • Quilt Server + Fabric API also works

alikindsys avatar Nov 30 '22 00:11 alikindsys

I can confirm that qfapi-4.0.0-beta.7_qsl-3.0.0-beta.10_fapi-0.59.0_mc-1.19.2.jar works, while the next (published) release, qfapi-4.0.0-beta.8_qsl-3.0.0-beta.13_fapi-0.59.0_mc-1.19.2.jar, does not.

Here's a diff between the two versions: https://github.com/QuiltMC/quilted-fabric-api/compare/4.0.0-beta.7+0.59.0-1.19.2...4.0.0-beta.8+0.59.0-1.19.2

I suspect the issue has something to do with https://github.com/QuiltMC/quilted-fabric-api/commit/1fa160819ba22769bf1be1aa399ed7d759fd6e0b and/or QuiltedRegistrySync.java... but what do I know?

unilock avatar Dec 01 '22 20:12 unilock

In theory Quilt's registry synchronization was built to be compatible with proxies, but I guess we can't exclude the possibility that something went wrong.

LambdAurora avatar Dec 01 '22 20:12 LambdAurora

This is probably known, but qfapi-4.0.0-beta.23_qsl-3.0.0-beta.22_fapi-0.68.0_mc-1.19.2.jar, the (current) latest release of QSL, does not work :(

I would test 1.19.3, but Velocity doesn't support it quite yet, so no such luck...

EDIT: It should be mentioned that having QSL installed on the client-side as well makes no difference. (other than Unknown custom packed identifier: qsl:registry_sync/handshake not appearing)

EDIT: Not fixed with 1.19.3 / Quilt 0.18.1-beta.23 / QSL qfapi-5.0.0-alpha.3_qsl-4.0.0-beta.1_fapi-0.68.1_mc-1.19.3.jar. :(

unilock avatar Dec 04 '22 23:12 unilock

Hmm, this issue is probably better-suited for the quilt-standard-libraries issue tracker, but I don't know how to move issues 🤷‍♀️

unilock avatar Dec 09 '22 11:12 unilock

This seems to point to registry sync but I think I'd like a confirmation that it is indeed caused by QSL alone and not QFAPI before moving the issue.

If someone can grab the test mod JAR of off QSL's GitHub Actions runs and test that would be appreciated!

LambdAurora avatar Dec 09 '22 12:12 LambdAurora

This action? https://github.com/QuiltMC/quilt-standard-libraries/actions/runs/3653399966

I feel like I may have done something wrong... https://gist.github.com/unilock/02e845517fea20fa7a212272c3d28109 (This is with only qsl-4.0.0-beta.2+1.19.3-testmod.jar in the mods folder. I also tried with all the libs from the build added as well, but ran into the same error.)

EDIT: Note that I'm using Java 17. I see there's a workflow for building with Java 19 as well; maybe that's part of the issue?

unilock avatar Dec 09 '22 12:12 unilock

I think your error is most likely a Quilt Loader issue, try updating it?

I also know that on Fabric to make Velocity work well an additional mod was required on the servers iirc

LambdAurora avatar Dec 10 '22 11:12 LambdAurora

That was on the latest version, unfortunately. Unless there's something newer than 0.18.1-beta.23?

Maybe you're thinking of FabricProxy-Lite? That (should) only be required when Velocity is set to "modern forwarding" mode, which I've disabled for the sake of testing.

unilock avatar Dec 10 '22 13:12 unilock

Unfortunately, the issue still exists in Minecraft 1.19.3, Quilt Loader 0.18.1-beta.58, and qfapi-5.0.0-alpha.9_qsl-4.0.0-beta.5_fapi-0.72.0_mc-1.19.3.jar :(

This time, however! I was able to get the QSL test mod up and running. (from this action)

I recorded two logs from a Minecraft 1.19.3 / Quilt Loader 0.18.1-beta.58 server with only that mod; one in which I connected to the Quilt server through Velocity, and the other in which I connected directly.

With Velocity Without Velocity

So I guess it is a QSL issue after all?

unilock avatar Jan 24 '23 03:01 unilock

It is certainly a qsl issue.

I managed to "port" QForward to 1.19.3 in a very scuffed way, believing that was a problem with the way FabricProxy-Lite did modern forwarding, and since QForward explicitly targets quilt that wouldn't happen if the issue was on FabricProxy-Lite.

Neither QForward or FabricProxy-Lite work with QSL/QFAPI, but both of them work without QSL/QFAPI.

All of my tests were done in 0.17.10 and 0.18.1-beta.58 on minecraft 1.19.3.

This is a blocking problem from server networks that want to use quilt-loader. We can't use the "outdated qsl/qfapi version that doesn't timeout" trick in 1.19.3 (and all subsequent versions) cause mods are using newer versions of fapi/qfapi.

Of note is that QForward requires quilt_base, but I may be reading too much into this.

modImplementation(libs.quilt.qsl.core.base)

alikindsys avatar Jan 24 '23 13:01 alikindsys

I did some more testing connecting to the server with a Quilt client with the test mod installed.

Client log: Quilt client -> Quilt server with Velocity Client log: Quilt client -> Quilt server without Velocity

Server log: Quilt server -> Quilt client with Velocity Server log: Quilt server -> Quilt client without Velocity

(also I got the server logs from testing with a vanilla client yesterday)

Server log: Vanilla client -> Quilt server with Velocity Server log: Vanilla client -> Quilt server without Velocity

unilock avatar Jan 25 '23 11:01 unilock

This should fix it for now. At least I hope as I didn't test it. Just change .zip into .jar

quilt_velocity_patch-0.0.0+1.19.3.zip

Patbox avatar Jan 26 '23 18:01 Patbox

@Patbox With your mod installed, I'm able to connect to the Quilt server through Velocity! But I can't interact with anything (placing / breaking blocks, hitting mobs, etc.), and I'm constantly clipping into blocks, a la when a block is present on the server but not on the client - except the blocks are visible, and it happens with all blocks. Chunks generate and mobs spawn and move around, at least.

Also, the Quilt server sometimes prints the following error when a player tries to join, followed by the player being kicked:

[16:43:48] [Netty Server IO #10/ERROR]: Received class net.minecraft.class_2828$class_2830 that couldn't be processed
java.lang.ClassCastException: class net.minecraft.class_3248 cannot be cast to class net.minecraft.class_2792 (net.minecraft.class_3248 and net.minecraft.class_2792 are in unnamed module of loader org.quiltmc.loader.impl.launch.knot.KnotClassLoader$Separate @1a5d0d94)
    at net.minecraft.class_2828$class_2830.method_11054(class_2828.java:16) ~[transformed-mod-minecraft.i0:0/:?]
    at net.minecraft.class_2535.method_10759(class_2535.java:167) ~[transformed-mod-minecraft.i0:0/:?]
    at net.minecraft.class_2535.method_10770(class_2535.java:152) ~[transformed-mod-minecraft.i0:0/:?]
    at net.minecraft.class_2535.channelRead0(class_2535.java:50) ~[transformed-mod-minecraft.i0:0/:?]
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) ~[netty-handler-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:?]
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:?]
    at java.lang.Thread.run(Thread.java:833) ~[?:?]
[16:43:48] [Server thread/INFO]: PLAYER[/127.0.0.1:52313] logged in with entity id 801 at (70.71692527738146, 70.06815128297653, -242.27902987058494)
[16:43:48] [Server thread/INFO]: PLAYER joined the game
[16:43:48] [Server thread/INFO]: PLAYER lost connection: Server sent an invalid packet
[16:43:48] [Server thread/INFO]: PLAYER left the game

...but sometimes I can join just fine, and no error is printed.

This is with Quilt Loader 0.18.0-beta.60, qfapi-5.0.0-alpha.9_qsl-4.0.0-beta.5_fapi-0.72.0_mc-1.19.3.jar, and FabricProxy-Lite-2.4.0.jar.

unilock avatar Jan 26 '23 21:01 unilock

Try installing polymer too, might fix that

Patbox avatar Jan 27 '23 07:01 Patbox

@Patbox That works!!
The below seems to be working fine:

  • Interacting with blocks / mobs
  • Generating chunks
  • Chat ("can't be verified", as expected)
  • Commands
  • Joining / Leaving (consistently)
  • ...Getting kicked / banned (via /kick / /ban)

(I haven't tested with more than one player)

However, after having installed a few mods (that are required both client-side and server-side), the Quilt server prints the following error:

[08:07:04] [Netty Server IO #3/ERROR]: Received class net.minecraft.class_2828$class_2830 that couldn't be processed
java.lang.ClassCastException: class net.minecraft.class_3248 cannot be cast to class net.minecraft.class_2792 (net.minecraft.class_3248 and net.minecraft.class_2792 are in unnamed module of loader org.quiltmc.loader.impl.launch.knot.KnotClassLoader$Separate @3af6d7a7)
	at net.minecraft.class_2828$class_2830.method_11054(class_2828.java:16) ~[transformed-mod-minecraft.i0:0/:?]
	at net.minecraft.class_2535.method_10759(class_2535.java:167) ~[transformed-mod-minecraft.i0:0/:?]
	at net.minecraft.class_2535.method_10770(class_2535.java:152) ~[transformed-mod-minecraft.i0:0/:?]
	at net.minecraft.class_2535.channelRead0(class_2535.java:50) ~[transformed-mod-minecraft.i0:0/:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) ~[netty-handler-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:?]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]

The mods common between the client and server:

The mods on the server only:

unilock avatar Jan 27 '23 13:01 unilock

I'm unable to replicate @unilock's results using the Quilt-Velocity patch.

Quilt Loader 0.18.1-beta.60

latest.log

ls ./mods/ -1
fabric-api-0.73.0+1.19.3.jar.disabled
FabricProxy-Lite-2.4.0.jar
polymer-bundled-0.3.7+1.19.3.jar
qfapi-5.0.0-beta.1_qsl-4.0.0-beta.9_fapi-0.73.0_mc-1.19.3.jar
quilt_velocity_patch-0.0.0+1.19.3.jar

Quilt Loader 0.17.10

2023-01-27-6.log

ls ./mods/ -1
fabric-api-0.73.0+1.19.3.jar.disabled
FabricProxy-Lite-2.4.0.jar
polymer-bundled-0.3.7+1.19.3.jar
qfapi-5.0.0-beta.1_qsl-4.0.0-beta.9_fapi-0.73.0_mc-1.19.3.jar
quilt_velocity_patch-0.0.0+1.19.3.jar

alikindsys avatar Jan 27 '23 20:01 alikindsys

Whats on client

Patbox avatar Jan 27 '23 20:01 Patbox

The client is using Adrenaline 1.12.0+1.19.3.quilt, which shouldn't impact testing.

I can confirm that a vanilla client has the same issues on both quilt loader versions.

alikindsys avatar Jan 27 '23 20:01 alikindsys

quilt_velocity_patch-0.0.0+1.19.3.zip Test this one

Patbox avatar Jan 29 '23 09:01 Patbox

Was able to connect using the second patch on the minimal server case. Will test with my other mods to see if its fully fixed. (on quilt loader 0.17.10, haven't tested the beta)

image

Edit: The second test mod seems to have fixed the problem fully, on both the minimal case (for 0.17.10 and 0.18.1-beta.60) as well for my specific server use case (mostly server-sided mods with some support for optional client side mods). Haven't tested any content mods tho.

alikindsys avatar Jan 29 '23 15:01 alikindsys

That patch seems to have fixed the (very few) content mods I was using 👌 (note that I've been using Quilt Loader 0.18.1-beta.59) More testing should probably be done with more mods. I can get to that later.

unilock avatar Jan 30 '23 13:01 unilock

what is the status on this issue? im using latest quilted fabric api alongside all the needed mods and velocity. on 1.19.4 and i still have such issues

TheNukeLore avatar Mar 21 '23 02:03 TheNukeLore

Someone reported the same issue in FabricProxy-Lite, but I believe this is caused by your mods, because the timeout occurs in the PLAY phase, not the LOGIN phase that FabricProxy-Lite affects.

If this cannot be fixed at the moment, I suggest mentioning in the mod's description that it does not work with Velocity.

james58899 avatar Apr 13 '23 02:04 james58899

As an update: quilt_velocity_patch is still working fine with my "vanilla-compatible" Quilt server after updating to 1.19.4. EDIT: Spoke too soon; players without Quilt installed themselves are kicked for having an "incompatible client" (as in, not modded). Then the server crashes with an exception related to Quilt's registry sync function?? EDIT2: The "incompatible client" error doesn't seem to be related to quilt_velocity_patch, but the fact that the server crashes after encountering said error probably is.

@james58899 Yes, this is an issue with Quilt / Velocity; it's unrelated to FabricProxy-Lite.

unilock avatar Apr 13 '23 13:04 unilock

Since this issue has been confirmed(?) to be related to QSL's registry sync networking code specifically, might it make sense to move this to its issue tracker instead? (QuiltMC/quilt-standard-libraries) (I am making the assumption that the issue does indeed have to do with QSL, because @Patbox's "quilt_velocity_patch" mixes into org.quiltmc.qsl.registry.impl.sync.ServerRegistrySyncNetworkHandler, and doesn't touch QFAPI at all.)

unilock avatar Apr 23 '23 21:04 unilock

It is yes, but honestly it's more of an issue on velocity side of things

Patbox avatar Apr 23 '23 21:04 Patbox

Should an issue be opened on their tracker, then? I assume this has already been discussed elsewhere, given the member names in quilt_velocity_patch (haha), but I can't find where that might've happened?

unilock avatar Apr 23 '23 22:04 unilock