Adrian Brock

> Should Fabric API consider virtualizing argument types so that server-only argument types can be used? See ````CommandTreeS2CPacket.ArgumentNode.write()```` and ````CommandTreeS2CPacket.readArgumentBuilder()```` where it uses the rawId of the registered argument serializers...

But if you change the client code to uses "Identifiers" instead of rawIds then client only fabric installations won't be able to talk to vanilla servers?

There is a mod that "fixes" the mojang bug: https://www.curseforge.com/minecraft/mc-mods/xl-packets-fabric By "fixes" I mean it moves the goal posts to allow a larger number of recipes/blocks/etc to be sent over...

> This mod doesn't solve the problem sadly :( I think thats because you linked the wrong minecraft bug - this one looks more relevant? https://bugs.mojang.com/browse/MC-117850 A quick search gives...

This issue does appear to be caused by a size limit, but it is in the ````net.minecraft.network.SizePrepender```` Here it limits the size to a "VarInt" of length 3 - that...

> it might make sense to use this as a server-side opt-in, client-side opt-out feature. Forge handles it based on the packet size. If there are no large packets nothing...

Here's an example log4j config file that is used by fabric loom when starting development environments. https://github.com/FabricMC/fabric-loom/blob/dev/0.12/src/main/resources/log4j2.fabric.xml It defines a debug log file. To actually use it, copy it to...

So this isn't the vanilla packet at all ```` Last vanilla packet here (2788 is the vanilla recipes) [14:57:18] [Netty Server IO #1/DEBUG] (net.minecraft.class_2545) OUT: [PLAY:102] net.minecraft.class_2788 [14:57:18] [Server thread/INFO]...

Do you have the debug log? However, for the last debug log I only identified nbt crafting because it did its own logging to say it was sending a packet....

As I predicted there is nothing in the log to say which packet is causing the problem. It does look like a login packet for one of your mods. Looking...