Starless Posted September 21, 2016 Share Posted September 21, 2016 I have an inventory TileEntity. How do I make sure no automation mods can interact with it (like BuildCraft pipes)? Quote Link to comment Share on other sites More sharing options...
Starless Posted September 21, 2016 Author Share Posted September 21, 2016 So if I don't expose it, players will still be able to interact with it? And should I implement IItemHandler , IItemHandlerModifiable and INBTSerializable<NBTTagCompound> ? Quote Link to comment Share on other sites More sharing options...
Starless Posted September 21, 2016 Author Share Posted September 21, 2016 So Minecraft itself doesn't use the methods defined by those interfaces? Quote Link to comment Share on other sites More sharing options...
desht Posted September 21, 2016 Share Posted September 21, 2016 If you don't expose an IItemHandler capability on any side, there will be no automated interaction with your TE's inventory (or inventories), but players can of course still interact via any GUI you choose to attach to it via a Container. What do you mean by "implement IItemHandler..." ? Your TE shouldn't be doing that at all; your TE should contain an object implementing IItemHandler (commonly just an ItemStackHandler) for each inventory it has, and, if it wants to make those available to other mods (and vanilla!), return those from getCapability(), like I do here: https://github.com/desht/ModularRouters/blob/master/src/main/java/me/desht/modularrouters/block/tile/TileEntityItemRouter.java#L156 (Note that vanilla items like a hopper have been retrofitted with capability awareness and will interact with any inventory you expose via capabilities). You don't need to explicitly implement INBTSerializable; the TileEntity class implements that anyway, and the implementing methods just call readFromNBT() and writeToNBT(), which are the methods you should normally be overriding. Quote Link to comment Share on other sites More sharing options...
Starless Posted September 21, 2016 Author Share Posted September 21, 2016 I talked about implementing those interfaces because my TileEntity is a chest Quote Link to comment Share on other sites More sharing options...
desht Posted September 21, 2016 Share Posted September 21, 2016 "is a chest"? You mean, you're directly extending TileEntityChest, or you're creating a tile entity with chest-like functionality? Have you looked at the code for TileEntityChest (note, it gets tricky because of double chests). You'll see that even vanilla chests implement getCapability() & hasCapability() for ITEM_HANDLER_CAPABILITY. But I think the short answer to your question is no: you don't need to implement any of those interfaces. Quote Link to comment Share on other sites More sharing options...
loordgek Posted September 21, 2016 Share Posted September 21, 2016 public class Tilelol extends TileEntity { ItemStackHandler itemStackHandler = new ItemStackHandler(5); @Override public void readFromNBT(NBTTagCompound compound) { itemStackHandler.deserializeNBT(compound.getCompoundTag("llo")); super.readFromNBT(compound); } @Override public NBTTagCompound writeToNBT(NBTTagCompound compound) { super.writeToNBT(compound); compound.setTag("llo", itemStackHandler.serializeNBT()); return compound; } } is this what you want ? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.