Draco18s

Oh *I* can get the blockstate from an item stack. That's not the problem. The problem is I want to instantiate the tile entity associated with that state and invoke getCapbability. I have no control over what someone else's getCapbability does...such as doing worldObj.getBlockState(this.getPos())

Among other things.

Also don't implement ITileEntityProvider. You want the hasTileEntity and getTileEntity methods that exist in the Block class (hint: the one you're using is wrong).

Blocks.REGISTRY

That doesn't actually solve the problem, because if the TE uses that world, it's BlockPos is still 0,0,0 and it itself doesn't exist there, so it will fail to retrieve its own blockstate.

How fire works: Every time it receives a block update tick, it increments its metadata value by 1. When it reaches 15 (or its raining, or some other checks) it deletes itself.

Considering that Minecraft doesn't have an existing weight concept, you're going to need to use a HashMap<Block,Float> in your own class and look up the value every time.

So a block I had in 1.7 worked really quite well with utilizing the ISidedInventory interface. The basic premise was that the block would store phantom items, specifically blocks with inventories (when trying to insert to a particular set of slots, I'd check to see if the Item was a block, and if that block implemented IInventory). Then when any other item was attempted to be put into the primary inventory slots, it was checked to see if it was possible to insert that item into the stored block from a given side (top, bottom, side). If the item was allowed to be inserted, then my block would allow the insertion to its own inventory. Because of the way the ISidedIventory interface allowed access to inventory slots, it was exceedingly rare for a block to throw a Null Pointer Exception trying to test-insert items (I never once saw it happen, but I wrapped the sole method of failure in a try...catch anyway, just in case). However, now that Capabilities are a thing, that's grown a little more...tenuous. hasCapability doesn't pass a blockstate and it would not be unreasonable for a block to differentiate slot validity based on blockstate (for example, my own millstone, which allows insertion on the edge blocks of a 3x3 square, and extraction from the center). Depending on how any given author decides to implement their has/getCapability methods, they may not handle their TE having a null worldObj. So this code (that I have now) is not fail proof (and one of three or four possible failure points, instead the original one): ItemBlock ib = (ItemBlock)stack.getItem(); IBlockState state = ib.block.getStateFromMeta(ib.getMetadata(stack)); if(ib.block.hasTileEntity(state)) { TileEntity te = ib.block.createTileEntity(null, state); return te.hasCapability(CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, null); } Is there anything I can do to reduce the chance of error? Or do I need to just accept it, and wrap all three/four spots in a try...catch?

This will never work if you're passing things to constructors. NEVER

Ehm, those brackets are wrong. It should be 3+(0*3)+0 = 3 3+(0*3)+1 = 4 3+(0*3)+2 = 5 .... 3+(3*3)+3 = 15 The first TE_INVENTORY_SLOT_COUNT in that calculation just doesn't make sense there... Correction: 9+(0*3)+0 = 9 9+(0*3)+1 = 10 9+(0*3)+2 = 11 .... 9+(3*3)+3 = 21

Don't use BlockContainer. It was never the best way to do TileEntities even in 1.7, and now that you've updated to 1.10, the createNewTileEntity method is just flat wrong (int meta? What block metadata? we operate on states now!). Use the hasTileEntity and createNewTileEntity methods present in the Block class.

Actually, its not. See my post.

int slotNumber = TE_INVENTORY_SLOT_COUNT + y * TE_INVENTORY_SLOT_COUNT_COLUMN + x; Run that math through your head again.

remove display and make parent item/generated

Given that I've seen people (try to) pass the item to their block, and the block to their item...I'm not so sure.

Override public AxisAlignedBB getBoundingBox(IBlockState state, IBlockAccess source, BlockPos pos)

crateRegistration() in your client proxy doesn't call super() so your block is never created.

Directly modifying the entity's health won't affect the Death Event: the entity will still die, fire the event, which could still cause the entity to heal (canceling the event is not sufficient). If you want to prevent people from dickering with events, then subscribe to the event and dicker with it yourself, setting your priority to lowest.

So make a custom damage source.

While true, it completely misses the point. A static reference can only be used with non-instances. An instance reference cannot use static references. You can pass instances to a static method, but a static method does not magically contain the information from an instance just because they're the same class.

You're creating your items before creating your blocks, which causes your BlockCrop reference to be passed as null. This is an ungodly common problem that gets posted about very super frequently (like, twice a month).

Not null? Of course those are easy to find. Derp. Distracted and such. I probably retyped half the post twice.

Debug your code. You have an object that is not null. These are very easy to find.