Notunknown

Its passed the (initially empty) list in the deprecated getDrops. All you need to do is populate it.

You dont unless you want to override dropBlockAsItemWithChance, which you most likely dont.

Use NonNullList<ItemStack>#add(ItemStack). Look at the example that I provided earlier.

Yeah, so basically dont use getDrops(IBlockAccess, BlockPos, IBlockState, int) as it will probably be removed entirely by 1.13 and doesnt do anything important, either. As for dropBlockAsItem and dropBlockAsItemWithChance, for most blocks you will not need to override either of those.

Ah, the old getDrops just creates a NonNullList and then calls the new getDrops before returning the list.

Oh, and onBlockDestroyedByPlayer and onBlockDestroyedByExplosion are empty, so only override them if you need some functionality to occur in those situations (such as giving an advancement or something, presumably)

No, dropBlockAsItem calls dropBlockAsItemWithChance, which calls getDrops. Override getDrops and it will affect the other two, but you can override them all if your situation requires it.

I doubt the list would be in the Block, but in whatever function calls getDrops. Your drops should be added to the NonNullList provided. For example: public void getDrops(NonNullList<ItemStack> drops, IBlockAccess world, BlockPos pos, IBlockState state, int fortune) { super.getDrops(drops, world, pos, state, fortune); drops.add(new ItemStack(Items.IRON_INGOT)); drops.add(new ItemStack(Items.GOLD_INGOT)); drops.add(new ItemStack(Items.DIAMOND)); }

For these types of functions the list would simply be passed in already created (you dont have to make it yourself with 'new') and you simply add the drops to the list provided. Because its passed by reference then the list will be the same once your function has completed, ready for forge to drop the items onto the ground (or more likely go through the event system first so other mods can make changes to the drops) So just add a, b and c to drops

Well, I have just decided to store the data in the ItemStacks NBT data instead, so I guess I wont need an answer.

Should I even be using Capabilities for this? When should I store data in Capabilities and when should I just store it in NBT?

I have packets - as I said, when a player has the item in their inventory it syncs, it's just that it is flickering when it does this, and I don't know what methods to use to ensure it syncs in all situations.

So I am creating a Capability for an ItemStack and have two major issues and a couple of questions: The first issue is that the capabilities appear to sync fine, but the data flickers back to the default values on the client what appears to be randomly. On the server the values are always correct, however. I am thinking this is a serialization issue, but the serialization issue that I had in the past manifested itself differently to this (not being random). I have checked the incoming packets used to sync the data, and they are correct. The second issue is that I cannot figure out how to sync the item data for other players than the player who is holding the item. What is the best method for syncing this data to all players, regardless of whether the ItemStack is on the ground, in a container or being held by something? Finally, I have a few questions regarding Capabilities and some other information: First, the onUpdate for my Item is fairly simple and could be run on the client (at least partially). It only needs to be synced when the player picks up the ItemStack, drops it or opens a UI (all of which seem to also cause deserialization, so that would be the perfect time to sync). However, I cannot seem to figure out how to do this. Secondly (not a Capabilities question, but doesn't seem worthy of a separate thread), are proxies still needed? I have references to client-only classes (such as a reference to Minecraft in the sync message) without the server exploding.

Also, is that the exact way we should be structuring our mods? I have taken a different approach: giving the Mod.EventBusSubscriber annotation to CommonProxy , and Mod.EventBusSubscriber(Side.CLIENT) and SideOnly(Side.CLIENT) annotations to ClientProxy , the providing each with the necessary events. It works (at least it does not crash when I launch clients or servers). Or maybe I am being an idiot and should just do what was suggested.

That does not make much sense, so I am going to assume that Forge is doing something under the hood. Is there any documentation on how any of this actually works? Learned to read. EDIT: Also, @SideOnly(CLIENT) - is this not "forbidden"?