Hello,

 

For my mod I need to know if a block can hold items (like a chest or hopper). I'm currently checking if it is an instance of BlockContainer but that doesn't seem to work on modded chests. 

Is there a way to check if a block has an inventory without hardcoding all of the names or something strange like that?

 

edit: I am now using VanillaInventoryCodeHooks.getItemHandler() and checking if the result is null. It seems to work but are there any negative effects I didn't think about?

Edited May 2, 20187 yr by suppergerrie2

All container blocks require Tile Entities to store those items. All of them. Every single one.

So:

1) Get the tile entity

2) Get the tile entity's item handler capability (CapabilityItemHandler.ITEM_HANDLER_CAPABILITY)

3) Done

Ah seems like getItemHandler is doing exactly that! Thanks!

28 minutes ago, suppergerrie2 said:

Ah seems like getItemHandler is doing exactly that! Thanks!

VanillaInventoryCodeHooks.getItemHandler() is the compatibility patch from vanilla style inventory to the Forge Capability system.

So I should do something like this?

IBlockState state = world.getBlockState(pos);
Block block = state.getBlock();

if (block.hasTileEntity(state)) {
	TileEntity tileentity = world.getTileEntity(pos);
	if (tileentity != null) {
		if (tileentity.hasCapability(CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, EnumFacing.UP))	{
			itemHandler = tileentity.getCapability(CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, EnumFacing.UP);
		}
	}
}

 

Ah that makes sense thanks! Yeah EnumFacing.UP was just for testing, will change that later.

7 hours ago, diesieben07 said:

If you are going to call getCapability anyways, do not call hasCapability beforehand. getCapability will return null if the capability is not available.

So, I'm curious, why have hasCapability at all then?

i.e. what's the usecase where you wouldn't be calling getCapability?

I'd assumed it was to query whether or not a cap existed, and if so, get the cap.

Hence my lazy-programmer implementation of has() being return get() != null

21 hours ago, Draco18s said:

I'd assumed it was to query whether or not a cap existed, and if so, get the cap.

Hence my lazy-programmer implementation of has() being return get() != null

 

On 04/05/2018 at 6:10 PM, diesieben07 said:

Good question. I am sure there is some.

Maybe for some small performance benefit when only checking if the capability exists and not actually using the capability? Cases of this would be rare, but not nonexistent. Rendering functions like TESRs and HUDs come to mind