Jump to content

Tile Entitry Extracting on One Side Only


Ronaldi2001

Recommended Posts

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);
	}

 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by V0idWa1k3r
Link to comment
Share on other sites

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. 

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.