Draco18s

Yes, that is correct. (player's guide to using it: http://reasonable-realism.wikia.com/wiki/Filtering_Hopper ) I could pass a non-null world, but it wouldn't make a difference as the TE's author would (reasonably) assume that the block-at-the-TE's-position was its own block. I know my own code says "hold on, this isn't me" and allows full access to all slots, same as if a null side was passed (to handle cases like blocks being set to air before the block has a chance to drop all the TE's contents--because that was a problem at one point) but that may not be universally true (as I think aforementioned issue was fixed). The other reason my millstone block does that is that it needs to do that before requesting properties from the blockstate, as to not cause an InvalidPropertyException (or whatever it actually throws when you try to get/set a property that doesn't exist). I suppose that I could use two different TEs for my millstone block (one for the edges that accepts items and one for the center that processes and allows extraction) but I originally coded it to just be the same TE and use the Sided interface nature of things to make the distinction. But again, the point is, "if I managed to do this in this way, someone else might do it too." And it wasn't until I was coding my filter block that I realized that my getCapability method was insufficiently built to handle possible problems (took me three attempts to properly make sure that what I was doing would work).

And your goal is...? (Also, you're not entirely correct)

new Configuration(event.getSuggestedConfigFile())

Yes. Which I am. That is also not the problem. The problem is not the TE creation but invoking getCapability as I've said three times now. getCapability DOES NOT PASS A STATE

Sorry, it's Block.REGISTRY

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.