Joseph Tarbit

I think both are a good idea, performance is definitely a huge issue for large scale servers at the moment especially with chunk loading.

I suppose as long as the parallel tickers do not modify the world's state and the main thread waits until they have all ticked before continuing then there shouldn't be...

> 1. Why is the block entity capabilities its own packet? Why not just enforce or make default saving the data to the update packet? Seems unnecessary to split the...

> The update packet is for syncing data as required for a block entity. It does not serialize the entire block entity, only the position where its located and the...

> > Block entities attach additional data to the ClientboundBlockEntityDataPacket though (usually via getUpdateTag), so if you wanted to synchronize caps you'd always be sending additional data alongside them. >...

> In creative, it seemed like any nbt data that was loaded into a gui on a stack was immediately discarded and synced with the initial value. I believe this...

> > I believe this is because the capability was not serializable (calls to ItemStack#copy will not copy the cap data). > > That seems like a bug that data...

Big fan of this, looks really good.

> As an aside I'd like to ask @Sm0keySa1m0n if you know how much this would impact https://github.com/MinecraftForge/MinecraftForge/pull/8706 > > Would it make it (easier/harder/impossible) to achieve given the new...

> I don't like IComparable for that simply because it also adds copy() on top of compare(). > > > > I'm not sure if we'll ever see a viable...