Add ClientboundSetChunkCacheCenterPacket to respawn related packet list

[Ingrim4]

Description

Add missing ClientboundSetChunkCacheCenterPacket to respawn related packet list in sync injector.

Related Issue

closes #475

How Has This Been Tested?

Not tested

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[DasLulilaan]

This does not solve the infinite loading issue #475 with ItemsAdder.

Even without this patch the packet ordering seems correct without ItemsAdder installed:

1. ClientboundRespawnPacket = PacketType.Play.Server.RESPAWN
2. ClientboundSetChunkCacheRadiusPacket = PacketType.Play.Server.VIEW_DISTANCE
3. ClientboundSetSimulationDistancePacket = PacketType.Play.Server.UPDATE_SIMULATION_DISTANCE
4. ClientboundSetChunkCacheCenterPacket = PacketType.Play.Server.VIEW_CENTRE

Upon adding a ProtocolLib listener to ClientboundRespawnPacket the ordering is the following:

1. ClientboundSetChunkCacheRadiusPacket
2. ClientboundSetSimulationDistancePacket
3. ClientboundSetChunkCacheCenterPacket
4. ClientboundRespawnPacket

This is probably incorrect as the client's chunkcache is recreated with the respawn packet thus keeping it's center at (0,0). This might also be what ItemsAdder does because the only relevant packet I could find it registers with ProtocolLib is the ClientboundRespawnPacket. (https://gist.github.com/DasLulilaan/e41196fba89286d4daf1e0f410532f3e#file-dump-2026-04-25_13-10-19-txt-L161)

The same bug can also be triggered using ProtoclLib's debug command: /packet add play server 80 true (packet id 80 for 1.21.11 is PacketType.Play.Server.RESPAWN according to /packet names play client)

Could this have something to with that packet being "downgraded" to being synchronous because of that non-async listener (either ItemsAdder or debug command) thus pushing it into the next tick?

[Ingrim4]

In ProtocolLib, every packet that is processed asynchronously is assigned a packet sending index. This index represents the absolute order in which the packet would have been sent to the player if it had been processed synchronously. Using this index, ProtocolLib ensures that all asynchronously processed packets are ultimately sent in the correct order.

If asynchronous processing is canceled by a synchronous listener, the packet simply falls back to synchronous handling and is sent immediately.

We rely on this behavior to preserve correct packet ordering during respawns. When switching between dimensions (e.g., overworld to nether), differences in world height can cause the client to disconnect if chunk data does not match the new world. To avoid this, we temporarily capture all packets sent after the respawn packet and process them asynchronously until the next tick. This ensures the correct ordering while minimizing additional delay.

Regarding your observations: are you saying that you ran /packet add play server 80 true without ItemsAdder installed and were still able to reproduce the behavior?

That would be unexpected. Packet listeners in ProtocolLib are normally executed strictly in priority order. Unless a packet is explicitly canceled and re-queued for later processing, the presence of additional listeners should not affect packet ordering.

Relevant code:
https://github.com/dmulloy2/ProtocolLib/blob/9404ce32db76b975ea02b73a979dad6604133559/src/main/java/com/comphenix/protocol/injector/collection/PacketListenerSet.java#L105-L135

[DasLulilaan]

I just downloaded fresh jars of everything and ran them on a fresh papermc server. With ProtocolLib 4.5.0 (i had some dev build before) the packet ID is now 75 but the same problem stil occurs. As soon as i run /packet add play server 75 true i can't switch worlds. When i run /packet remove play server 75 true the problem disappears. The test server is running only ProtcolLib and Orebfuscator. I am clueless

sha256sums of the files to be sure:

25eb85bd8415195ce4bc188e1939e0c7cef77fb51d26d4e766407ee922561097  paper-1.21.11-130.jar
7d8a37ae3d126891e4003fe34ff380d717d1b9788013cea0af90a37b49a582da  orebfuscator-plugin-5.6.0.jar
ee2e7ab9b5386f2d103081c4d108e61b1035df2ca692b53d6e2409fb1f5caccf  ProtocolLib.jar

[Ingrim4]

Thank you again for your findings. I will review this in more detail over the next few days, as I am currently unable to fully explain the observed behavior.

[Ingrim4]

It looks like the issue is caused by ProtocolLib. After async processing, ProtocolLib delays a packet by one tick if at least one sync listener requires the packet to be handled on the main thread.

As far as I can tell, this only affects MONITOR packet processing. I’ll flag this as a bug and fix it directly in ProtocolLib, since MONITOR listeners should not be able to modify packets. Because of that, I don’t see a reason to delay packet execution in this case.