[1.10+] ItemHandler Output Slots

[Draco18s 2414]

So something occurred to me recently.

 

ItemHandlers need to be exposed for both input and output.

 

In order to prevent an item from being inserted into an "output" slot, setting up a custom ItemHandler class to always return the item inserted into it seems to make sense.  Expose for extraction, forbid insertion, seems reasonable.

 

However.  Now that means that a machine itself can't put items into its own output slot (other than by using

setStackInSlot()

which requires that it calculate the stack size manually).

 

There's got to be a better way than this...what am I missing?

[Animefan8888 741]

So something occurred to me recently.

 

ItemHandlers need to be exposed for both input and output.

 

In order to prevent an item from being inserted into an "output" slot, setting up a custom ItemHandler class to always return the item inserted into it seems to make sense.  Expose for extraction, forbid insertion, seems reasonable.

 

However.  Now that means that a machine itself can't put items into its own output slot (other than by using

setStackInSlot()

which requires that it calculate the stack size manually).

 

There's got to be a better way than this...what am I missing?

I kinda cheated when doing this, but for a furnace (something that has a specific output slot(s) I made it have an internal ID for properly inserting and if it was the normal id then I had it do nothing.

@Override
		public ItemStack insertItem(int slot, ItemStack stack, boolean simulate) {
			if (slot == 2) return stack;
			if (slot == 3) slot--;
			if (canInsert(stack, slot)) {
				if (stacks[slot] == null) {
					if (!simulate) stacks[slot] = stack;
					return null;
				}
				if (stacks[slot].getItem() == stack.getItem() && stacks[slot].getMaxStackSize() >= stacks[slot].stackSize + stack.stackSize) {
					if (!simulate) stacks[slot].stackSize += stack.stackSize;
					return null;
				} else if (stacks[slot].getItem() == stack.getItem()){
					int difference = stack.stackSize - (stacks[slot].getMaxStackSize() - (stacks[slot].stackSize + stack.stackSize));
					if (!simulate) stacks[slot].stackSize += difference;
					stack.stackSize -= difference;
				}
			}
			return stack;
		}

Feel free to optimize and give feedback (first time with IItemHandler).

[Draco18s 2414]

Should just be able to call super.insertItem() at that point, no?

[Animefan8888 741]

Should just be able to call super.insertItem() at that point, no?

This was straight from the interface ie

new IItemHandlerModifiable() {
     // Methods
};

 

Edit: But yes you should be able to.

[Draco18s 2414]

This was straight from the interface ie

 

Ah, gotcha.

[desht 91]

How about having two ItemHandler objects: a private one (not exposed via capabilities), and a public one (exposed so that hoppers etc. can extract).  The private item handler just allows items to be inserted normally, and that's what your machine would use to put items into it; a simple ItemStackHandler might suffice.  The public handler would be a custom IItemHandler implementation which delegates everything to the private handler, with the exception of inserting items, which you make a no-op.  And in your GUI, connect any Slots as needed to the public item handler to prevent manual insertion of items.

[Draco18s 2414]

Hmm.  That sounds pretty reasonable, actually.