[1.10] Prevent automation extract from specific slots

[dakamojo]

I'm creating a te that has a slot for a pickaxe.  I want a hopper or other automation to be able to insert into the slot, but I don't want a hopper underneath to pull the tool out of the slot.  But the player should be able to pull the tool out.

 

So I considered overriding extractItem on my ItemStackHandler to return false.  But I don't see how to tell if it is automation or the player that is trying to extract.

 

Basically slot 0 needs to allow automation in, but not out.  Allow player in and out.  Slot 1 needs to allow automation out, but not in.  Allow player out but not in.

[Choonster]

Create a regular ItemStackHandler to store the inventory and use this in your Container.

 

Create an IItemHandlerModifiable wrapper class that stores another IItemHandlerModifiable and delegates all methods to it except IItemHandler#extractItem. Implement this to always return ItemStack.EMPTY, preventing extraction from the wrapped inventory. Create an instance of this that wraps the regular ItemStackHandler and then expose this via your TileEntity's override of ICapabilityProvider#getCapability.

Edited September 3, 2017 by Choonster

[Draco18s]

You can use this class as an example. It's a wrapper that prevents insertion, but allows for extraction. You'd be doing something similar, but in reverse.

As Choonster mentions, it has a reference to another ItemStackHandler that acts normally so that your machine can insert and extract, but this one is exposed in getCapability:

Instantiation:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L50

GetCap:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L141

Internal use:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L93

[dakamojo]

So if I understand both of you, the trick is in getCapability to return one version of the ItemStackHandler if it is a player accessing it, and another if it is not.  From Draco's code...

 

if(facing == null) {
				return (T) new CombinedInvWrapper(inputSlot, outputSlotWrapper);
			}
			if(facing == EnumFacing.UP) {
				return (T) inputSlot;
			}
			if(facing == EnumFacing.DOWN) {
				return (T) outputSlotWrapper;
			}

 

So if facing is null that is the indication that it is a player accessing it?

[Draco18s]

Facing of Null is used when no specific direction is involved. Typically referred to as "internal use" but it is not necessarily the case that it's the player accessing it. Could be that the block was broken and is dropping its contents, could be a "peek" mod that opens a container to look at the contents.

 

However, automation (hoppers, etc) should always pass in a non-null side.