Leaderboard

That would be done via a capability. You would store the entity type of the model the player is using and whenever that value changes, sync it to all players tracking and self. You will need to sync whenever a new player starts tracking the entity. From there, the rest is just handling the client rendering such that it uses the entity provided in probably RenderLivingEvent$Pre and not the stored instance of your player.

I managed to fix it by serializing the NBT data inside the capability wrapper.

Do you have a line like this? VANILLA_ITEMS.register(FMLJavaModLoadingContext.get().getModEventBus());

setRegistryName("minecraft", "sugar"); You don't need this in your item class. Your deferred register already handles that

1) You aren't providing the required parameters of the constructor. 2) If you already called the super constructor with hardcoded parameters(except for slots), why in your constructor are you requesting these arguments? 3) Your constructor is protected and the two classes are not in the same package. Set it to public.

Make sure the listener is static (L5 https://pastebin.com/rHWc6H6k)

Your cauldron handle does not need a voxel boundary. Its basically irrelevant.

You cannot have a diagonal voxel shape. The closest you can get is approximation. Also, you should use the least amount of voxel shapes as possible. Large amounts of voxel shapes tend to impact the game in a negative way. Finally, I can tell you generated the voxel shape via block bench. This is more of an opinion, but just use VoxelShapes#or instead of constructing the stream. Makes little to no sense to do so in my opinion as the approach is exactly what the method does anyways. If you're talking about the misalignment, that's probably because you need to create a voxel shape for every possible rotation and then change it via it's block state.

Iirc attach capability event is fired on forge bus.

1.12 is not supported on this thread