[All platforms] Block entity synchronization attempts fail following blocked block breaks
noobanidus opened this issue ยท 5 comments
This can be resolved on earlier versions by sending a delayed update packet 2 ticks later.
Cross-posted from a message I made in the NeoForge discord:
So I'm not sure if this is a "me" issue or not, but it seems like, on an integrated server, the XXXHooks::onBlockBreakEvent/BlockEvent.BreakEvent has some kind of "race condition" that causes the 1) ClientboundBlockUpdatePacket and 2) BlockEntity::getUpdatePacket to be fired before the block entity & block state have been restored in the ClientLevel.
Using a series of breakpoints in IDEA on the various entityPlayer.connection.send and then having breakpoints on the relevant handler methods for those (which require the former to be triggered before they are enabled), it seems as though the ClientboundBlockUpdatePacket isn't enough to restore the block & block entity.
Hooking into the UpdatePacket, the this.minecraft.level.getBlockState and getBlockEntity for the relevant packet's blockpos return air and null respectively -- which makes sense -- while the BlockStatePredictionHandler contains the correct blockstate, the updateKnownServerState doesn't seem to actually fire and update the client level.
Thus, when the ClientboundEntityDataPacket is handled a short while later, the condition of the level remains the same -- which means that the incoming data is discarded as there's no block entity to update.
I'm not even entirely sure when the block is actually restored, but at that point in time, the block entity seems to become stuck in a kind of "limbo": although a completely new block entity has been created on the client-side (and not updated with the data from the server), it actually seems to become unresponsive to further updates.
The main instance where this is notable is in single-player with Lootr's containers, which change the client state depending on whether or not the current player has opened it before. Breaking the chest thus causes it to revert to its default (unopened) texture. Opening this chest in the future does not then cause it to be marked as "open", until you leave and rejoin the world.
The conclusion I take from this is that, on single-player, the handling to restore a block, especially with the code specifically designed to restore block entity data, doesn't seem to function as expected, or even at all.
While my main digging into this has been on Forge for 1.20.1, the XXXHooks etc code is identical as on 1.20.4... I'm (perhaps incorrectly) assuming that the behaviour is the same.
So, this is a vanilla bug that can be replicated by breaking a sign in a spawn-protected chunk.