Logs:
Server: http://puu.sh/EkPKJ/2166c5a066.log
Client: http://puu.sh/EkPLA/6dafd81fa4.log

Screenshots:
http://puu.sh/Ekm8u/9e325dfe3d.png

Will add more info as needed or if things change

[00:18:54] [Netty Local Client IO #0/WARN]: Failed to handle packet fabric:registry/sync! java.lang.RuntimeException: Tried to read NBT tag that was too big; tried to allocate: 2097164bytes where max allowed: 2097152

Looks like registry sync might need to split up its registry sync into multiple packets if there are too many things registered.

Also, there's a big red flag that so many blocks are logging Adding <id> to saved/remote registry, since it looks like that's only supposed to happen when there's a problem. I'm not quite sure what's causing it in this scenario.

I will update logs etc next time i preform updates etc to keep info current to pack changes etc :)

log: http://puu.sh/EvwOa/215996578c.log
wait is this crashing single player now too
Failed to handle packet fabric:registry/sync!
java.lang.RuntimeException: Tried to read NBT tag that was too big; tried to allocate: 2097256bytes where max allowed: 2097152

Now affecting singleplayer

Yeah, the solution to this is to split up sync packets if needed. Shouldn't be much of an issue.

Not really, you can cut down a lot on the packet size by using proper compression. Experiments have been made, but sadly I don't think any has made its way into a PR.

@JamiesWhiteShirt?

The current packet is unnecessarily bloated and should not be using NBT. It was likely made this way for parity with registry persistence. The solution is more likely optimizing it for compression, which I have already experimented with.

In my experiments, the blocker is really how to make the server and client agree on a new version with regards to backward compatibility. We'll have to solve this problem no matter how we approach this. If we want to support backward compatibility, the server needs to somehow know if a client supports a new format or not, which would likely involve some kind of handshake.

I think for backwards compatibility we have to use a 2nd channel registry/sync2 and use C2SPacketTypeCallback.REGISTERED to react to whatever the client sends. The client has to handle both registry/sync and registry/sync2 and parse accordingly.

edit: C2SPacketTypeCallback of course. The extra delay may be a problem or maybe we can send on both channels at the same time..