Tile Entitry Extracting on One Side Only

[Ronaldi2001]

I have a machine that works perfectly fine until you put a hopper under it, the hopper extracts from all three slots instead of just the output. how do I only set the output slot to be extract only and the input slots be input only?

 

Thanks in advanced!

[tebreca]

If you use capabilities, which is what I'm guessing you are;

use a switch to check the facing, and return the corresponding slots.

Spoiler

@Override
	public <T> T getCapability(Capability<T> capability, EnumFacing facing) {
		if(capability == CapabilityEnergy.ENERGY) {
			switch(facing) {
			case DOWN:
				//all the slots the hopper underneath needs
			case EAST:
				//all the slots the hopper connected to the east needs
			case NORTH:
				//all the slots the hopper connected to the north needs
			case SOUTH:
				//all the slots the hopper connected to the south needs
			case UP:
				//all the slots the hopper on top needs
			case WEST:
				//all the slots the hopper connected to the east needs
			}
		}
		return super.getCapability(capability, facing);
	}

 

 

 

[Ronaldi2001]

When I return a slot I want, it says says "change method to return int"? Also I deleted the line about energy I don't use that.

[V0idWa1k3r]

8 minutes ago, Ronaldi2001 said:

When I return a slot I want, it says says "change method to return int"?

You can't just return 1 when the method wants you to return a T where T is an instance of your capability. This is basic java. You need to return a wrapper around your capability that only allows access to certain slots.

[Ronaldi2001]

I can't get my head around capabilities could you please give an example?

[V0idWa1k3r]

23 minutes ago, Ronaldi2001 said:

I can't get my head around capabilities

This has very little to do with capabilities. Again, in TileEntity#getCapability method you need to return a wrapper around your capability that doesn't allow inserting/extracting items based on the side. You can have one wrapper that does it all, or you can have one wrapper per side, it doesn't matter. Look at the javadocs of IItemHandler to see what you need to return in insert/extractItem to provide a "noop" implementation.

 

Edit: well, sure, here is a small pseudo-code example:

Quote

public <T> T getCapability(Capability<T> capability, @Nullable EnumFacing facing)
{
    if (capability == ITEM_HANDLER_CAP)
    {
        switch(facing)
        {
            case UP:
            {
                return new InvWrapper(this.inventory)
                {
                    @Override
                    public ItemStack extractItem(int slot, int amount, boolean simulate)
                    {
                        return ItemStack.EMPTY;
                    }

                    @Nonnull
                    @Override
                    public ItemStack insertItem(int slot, @Nonnull ItemStack stack, boolean simulate)
                    {
                        return slot == 0 ? super.insertItem(slot, stack, simulate) : stack;
                    }
                };
            }
            
            default:
            {
                return this.inventory;
            }
        }
    }
}

 

Edited November 7, 2018 by V0idWa1k3r

[Cadiboo]

Capabilities are just a way provide a good API for getting stuff from a thing.

 

They are pretty much a better & more compatibile method than using interfaces 

 

For example:

Using interfaces (example: “IHasInventory”)

public class Thing implements IHasInventory {

@Override

public Inventory getInventory() {

// return this thing’s inventory

}

 

}

 

With the previous example, using this:

if(thing instanceof IHasInventory) {

// do stuff

}

is the same as doing this (with capabilities)

if(thing.hasCapability(INVENTORY_CAP)) {

// do stuff

}

 

I’ll go through & Edit this with my computer later, but the point I’m trying to make is:

Capabilities and Interfaces are two different approaches to a problem, with capabilities being the newer and “better” approach.

 

using instanceof with interfaces is the same as using hasCapability with capabilities

 

using ((Interface)object).getThing() with interfaces is the same as using getCapability with capabilities

 

capabilities also allow for extra data to be passed in (like facing in the case of forge’s implementation) which is one of the major advantages of capabilities over interfaces.

Also interfaces were designed for something different.

Also capabilities use the OOP principle “composition over inheritance” which is what code in all OOP languages globally is changing too.