Jump to content

IceMetalPunk

Members
  • Posts

    402
  • Joined

  • Last visited

Posts posted by IceMetalPunk

  1. I actually did have it separate; I only chained them up here for shorter code. I'm 100% sure (because I just checked) that those property-setting methods, including setTextureName(), are chainable (they return the instance itself). Either way, even if I split it, it doesn't fix the problem.

     

    As for the material, I want iron pickaxes and better to harvest it faster, but I still want it harvestable overall with anything, including a hand. I thought setHarvestLevel() would override that; if not, do I need to use a different material and then override isToolEffective()? If I do that, how can I get the level (wood, gold, iron, diamond, etc.) of the tool, since it looks like that method only takes the type and the metadata?

  2. I have a block called BlockWeatherDetector. I want it to be harvestable with any tool, including an empty hand, and drop itself when harvested. I thought it would be as simple as calling .setHarvestLevel(null, 0) and setting .getItemDropped() to return the item obtained from the block class, but it's not working. In survival mode, with tile drops turned on, if I break the block without a pickaxe...it doesn't drop anything. Am I doing something wrong?

     

    Constructor:

    protected BlockWeatherDetector() {
    	super(Material.iron);
    	this.setCreativeTab(CreativeTabs.tabRedstone).setHardness(0.5F);
    	this.setStepSound(Block.soundTypeMetal).setBlockName("weatherDetector");
    	this.setBlockTextureName("weatherworks:weather_detector").setHarvestLevel(null, 0);
    }

     

    getItemDropped:

    	@Override
    public Item getItemDropped(int metadata, Random rand, int fortuneLevel) {
    	Item item=Item.getItemFromBlock(WeatherWorks.weatherDetector);
    	System.out.println("Item dropped: "+item);
    	return item;
    }

     

    Intantiation/Registration (in WeatherWorks.java):

    public static final BlockWeatherDetector weatherDetector = new BlockWeatherDetector();
    // ...skipping irrelevant code...
    GameRegistry.registerBlock(weatherDetector, "weather_detector");

     

    The console log is never output unless using a pickaxe, so I know getItemDropped() isn't even being called when breaking it with your hand.

     

    What am I doing wrong?

  3. After some debugging, I got it working...though I have no idea how. It looks identical to the code I tried before, but now it works when it didn't then. I don't know.

     

    For anyone's future reference, this is the working code I'm using:

     

    package com.IceMetalPunk.weatherworks;
    
    import net.minecraft.block.Block;
    import net.minecraft.tileentity.TileEntity;
    
    public class TileEntityWeatherDetector extends TileEntity {
    
    private int outputLevel=0;
    
    public void updateEntity() {
    	if (this.worldObj==null || this.worldObj.isRemote) { return; }
    	int temp=this.outputLevel;
    	if (this.worldObj.isThundering()) { this.outputLevel=15; }
    	else if (this.worldObj.isRaining()) { this.outputLevel=7; }
    	else { this.outputLevel=0; }
    	if (this.outputLevel!=temp) {
    		BlockWeatherDetector myBlock=(BlockWeatherDetector)(this.worldObj.getBlock(this.xCoord, this.yCoord, this.zCoord));
    		myBlock.updateOutput(this.outputLevel);
    
    		this.worldObj.scheduleBlockUpdate(this.xCoord, this.yCoord, this.zCoord, myBlock, myBlock.tickRate(this.worldObj));
    		this.worldObj.notifyBlocksOfNeighborChange(this.xCoord, this.yCoord, this.zCoord, myBlock);
    	}
    }
    }

  4. Those are two very different questions. If you want to completely replace the overworld with your own biomes, the only way I can think to do that is to have your generator clear out the entire chunk with air, then re-generate your custom terrain as needed (and register it with a high weight so it comes after other generators). If you want players to just spawn in your custom dimension, but still have a way back to the overworld, you can just check the public Entity.dimension value on all EntityPlayer entities, and if it's not your custom dimension ID, call Entity.travelToDimension(int dimension_id) on them to move them there. You may also want to keep a map of everyone you've done that to, so you don't force them into your dimension every time they try to leave it.

  5. Things just keep getting weirder with this bug. I left the update scheduling in as above, but I figured I'd also add a direct notification to the surrounding blocks, like this:

     

    this.worldObj.notifyBlocksOfNeighborChange(this.xCoord, this.yCoord, this.zCoord, myBlock);

     

    This is definitely getting called, but it didn't help. So for debugging, I put two of these blocks next to each other and put some console output in their onNeighborBlockChange() method. The output never gets logged. Meaning somehow, even with the line of code above, it's still not even calling the onNeighborBlockChange() method. I don't understand how this is possible. Does anyone know?

  6. I have a tile entity which updates a value in its corresponding block based upon the weather. This value is returned in the isProvidingWeakPower() method. Everything works, except the adjacent redstone requires an additional block update before it updates its state. I'd rather it update the signal strength immediately. I'm trying to use the World.scheduleBlockUpdate() method to trigger a block update and get the redstone signal updated, but it doesn't seem to work. This is what I'm using now, as the TileEntityWeatherDetector.java code:

     

    package com.IceMetalPunk.weatherworks;
    
    import net.minecraft.block.Block;
    import net.minecraft.tileentity.TileEntity;
    
    public class TileEntityWeatherDetector extends TileEntity {
    private int outputLevel=0;
    public void updateEntity() {
    	if (this.worldObj==null) { return; }
    
    	int temp=this.outputLevel;
    	if (this.worldObj.isThundering()) { this.outputLevel=15; }
    	else if (this.worldObj.isRaining()) { this.outputLevel=7; }
    	else { this.outputLevel=0; }
    	if (this.outputLevel!=temp) {
    		BlockWeatherDetector myBlock=(BlockWeatherDetector)(this.worldObj.getBlock(this.xCoord, this.yCoord, this.zCoord));
    		myBlock.updateOutput(this.outputLevel);
    		this.worldObj.scheduleBlockUpdate(this.xCoord, this.yCoord, this.zCoord, myBlock, myBlock.tickRate(this.worldObj));
    	}
    }
    }

     

    I also tried using two nested for() loops to schedule a block update at all adjacent blocks, and that didn't work, either. I'm sure I'm just misunderstanding how to schedule updates; how can I make the adjacent redstone dust change its signal strength immediately after the block updates its output?

  7. Have you ever seen a massively efficient iron farm in vanilla Minecraft, such as the Iron Titan, and wondered why everything can be automated...except you still have to manually craft the ingots into their storage blocks? Doesn't that seem a bit...annoying? Well, this mod fixes that. Third in the series of "lightweight mods to improve vanilla inconveniences", Compactify adds two new blocks to the game: the Compactor and the Extractor.

     

    (Download the mod here: https://dl.dropboxusercontent.com/u/11662651/Minecraft/Mods/Compactify.zip )

     

    Compactor

     

     

    The Compactor is crafted as you see in the image above: redstone in the middle, a piston above and below it, and iron ingots filling the sides. It has one input slot and one output slot; it will try to craft its input into the correct storage block, assuming one exists and you have enough items in the input to craft it. It will immediately craft once the conditions are satisfied, meaning if you have an item that can be crafted 2x2 or 3x3, it will craft the 2x2 by default unless you put in a stack of at least 9 at one time, in which case it will craft the 3x3 version first. Hopper automation puts one item in at a time, meaning the 4x4 option will be used with hoppers; other mods may introduce ways of automating the input of 9+ items at one time, which you can use to your benefit if you want.

     

    Extractor

     

     

    Crafted with redstone in the middle, a sticky piston on either side, and iron ingots filling the top and bottom rows, the Extractor is the opposite of the Compactor: any item in its inventory that can be crafted alone for expansion into its parts will be crafted as such. For example, a block of iron as input becomes 9 iron ingots in the output.

     

    Automation

    Both the Compactor and the Extractor can take input from the top and all five sides, and will output to the bottom. They won't push automatically, though, so you'll need something to pull the results out, like a hopper or an Extra Utilities transfer node or something. Lots of options.

     

    Helper Recipes

    Compactify also adds two minor recipes that I feel Minecraft should already have: 1 wool will craft itself into 4 string, and 1 glowstone block will craft itself into 4 glowstone dust. Every other storage block works this way, so why not these two? :D

     

    Mod Compatibility

    The way this mod works, it is fully compatible with storage blocks from any other mod. Any items that can be crafted 2x2 or 3x3 will properly be compacted and extracted, so automate away! :)

     

    Here's the download link once more: https://dl.dropboxusercontent.com/u/11662651/Minecraft/Mods/Compactify.zip

  8. For the second mod in what seems to be a pattern of "super lightweight, tiny fixes to what Minecraft should be", I present SmartPlates! A SmartPlate is a weighted pressure plate, with the additional intelligence to separate grouped-up item stacks. For example, a normal Light Pressure Plate will count a grouped stack of 10 items as a single entity and output a signal strength 1; a Light Smart Pressure Plate will output a signal strength of 10 there, counting each of the 10 items in the stack separately. No more worries about your devices breaking if items group up! :D

     

    Crafting a SmartPlate is easy: just craft either weighted pressure plate with a comparator to get the appropriate Smart version. They look like their normal counterparts, only with a checkerboard pattern on top, making them easy to differentiate from the usual plates, but still intuitive to know what they are.

     

    Download link here: https://dl.dropboxusercontent.com/u/11662651/Minecraft/Mods/SmartPlates.zip

     

    Note: I may one day combine all my mini-mods into one mod of random Minecraft improvements, but until then, I'll be posting each separately. So you can choose which improvements you want and which you'd like to keep Vanilla :)

  9. The lightweight Ender Hoppers Mod is designed to fix a small nuisance with vanilla hoppers: they can't transfer items to or from Ender chests! There are mods like Ender Storage which attempt to solve this problem, but in doing so, they also fail to work with normal Ender chests, and their chests are only private if you spend a diamond per chest! All for a simple fix.

     

    The Ender Hoppers mod was made for 1.7.10 and designed to be lightweight, so you can use it alongside your favorite mods that have yet to update to 1.8 (or even just add it to a vanilla world to fix Mojang's design flaw :P ). It should work fine with tech mods, though there's currently no dust or liquid equivalents for the ore this generates.

     

    Download link: https://dl.dropboxusercontent.com/u/11662651/Minecraft/Mods/EnderHoppers.zip

     

    What Does Ender Hoppers Add to Minecraft?

    With Ender Hoppers installed, you can now find Ender Iron Ore generating inside the main End Island. It generates unusually, in chunks rather than veins. Each chunk is a 4x4x4 cube which contains between 1 and 13 Ender Iron Ore blocks. 10 chunks will generate per world chunk, though some may overlap, so don't expect 130 ore per chunk! Also remember that this isn't 1.9--the End only has one island, so your supply of Ender Iron Ore is limited! Use it wisely :)

     

    Smelting an Ender Iron Ore gives you an Ender Iron Ingot, as you might expect. You can craft 9 Ender Iron Ingots together to create an Ender Iron Block, which is a decorative blue block. Right-clicking a placed Ender Iron Block causes it to emit Ender particles, and right-clicking it again stops the particles; it's your choice if your blocks are sparkly or not :D (You can of course craft the Ender Iron Blocks back into ingots at any time, making them storage blocks as well.)

     

    The main thing this mod adds, though, is the Ender Hopper. Crafted with the same recipe as a vanilla hopper, only using Ender Iron Ingots instead of normal iron ingots, a blue-green Ender Hopper remembers the player who placed it down as its "owner". In addition to working like a normal hopper in every way, it will also interact with its owner's Ender Chest inventory. So if there's an Ender Chest above an Ender Hopper you placed, it'll pull from your Ender Chest inventory, but no one else's; and if there's one at the output end, it'll push into your Ender Chest inventory. It won't interact with *anyone's* Ender Chest inventory except the player's who last placed it in the world.

     

    (Side note: someone could, if they were malicious, put an Ender Chest above an Ender Hopper *you* placed and a regular chest under it to steal your items. So when placing an Ender Hopper, if you don't trust your friends, be sure to put it somewhere safe!)

     

    Well, what are you waiting for? Isn't this what vanilla hoppers should always have been since Ender Chests were added? Download it! :D

     

    Here, let me remind you of the link: https://dl.dropboxusercontent.com/u/11662651/Minecraft/Mods/EnderHoppers.zip

  10. The cooldown is fine to be shared by all blocks. It's only there so that holding right click too long doesn't toggle the effect multiple times.

     

    I'm not getting off-by-1 issues with the y-coordinate, only the z...also, it's in the block's z-coordinate that's off, not the player's.

     

    I added the @SideOnly annotation because when both the client and the server were executing the code, it would toggle twice--once on the client, once on the server--effectively resetting the metadata. If there a better way to make it toggle only one time when activated?

  11. Fair enough :)

     

    So what I'm trying to do is make a simple solid block (an "Ender Iron Block") that's purely decorative. When you right-click it, it should toggle between emitting particles and not emitting particles. In my first tests, it worked, except the z-coordinate had to be shifted by 1 (as mentioned above). But then, I realized it wasn't even doing that consistently; sometimes, it seems to just not toggle at all. The debug output shows that it seems to need the z+1 still (the coordinates that are output are off by 1), but even with that, it seems to randomly decide when to toggle, and usually decides not to.

     

    Here's the EnderIronBlock.java code:

     

     

    package enderhoppers;
    
    import java.util.Random;
    
    import cpw.mods.fml.relauncher.Side;
    import cpw.mods.fml.relauncher.SideOnly;
    import net.minecraft.block.Block;
    import net.minecraft.block.material.Material;
    import net.minecraft.creativetab.CreativeTabs;
    import net.minecraft.entity.Entity;
    import net.minecraft.entity.player.EntityPlayer;
    //import net.minecraft.entity.item.EntityItem;
    import net.minecraft.world.World;
    
    
    
    
    public class EnderIronBlock extends Block {
    private byte cooldown=0;
    public EnderIronBlock(Material material) {
    	super(material);
    	setHarvestLevel("pickaxe",2); // 0=wood/gold, 1=stone, 2=iron, 3=diamond
    	setBlockName("enderIronBlock");
    	setHardness(5.0f);
    	setResistance(30.0f);
    	setStepSound(Block.soundTypeMetal);
    	setCreativeTab(CreativeTabs.tabBlock);
    	setBlockTextureName("enderhoppers:ender_iron_block");
    }
    
    @SideOnly(Side.CLIENT)
    @Override
        public void randomDisplayTick(World world, int x, int y, int z, Random rand) {
            if (world.getBlockMetadata(x, y, z)==1) {
                this.particle(world, x, y, z);
            }
            if (this.cooldown>0) {
            	--this.cooldown;
            }
        }
    
    @SideOnly(Side.CLIENT)
    @Override
    public boolean onBlockActivated(World world, int x, int y, int z, EntityPlayer player, int pInt, float px, float py, float pz) {
    	if (this.cooldown<=0) {
    
    		if (world.getBlockMetadata(x, y, z)==0) {
    			System.out.println("Set ("+x+", "+y+", "+z+") to 1!");
    			world.setBlockMetadataWithNotify(x, y, z, 1, 3);
    		}
    		else {
    			System.out.println("Set ("+x+", "+y+", "+z+") to 0!");
    			world.setBlockMetadataWithNotify(x, y, z, 0, 3);
    		}
    		this.cooldown=5;
    	}
    	return super.onBlockActivated(world, x, y, z, player, pInt, px, py, pz);
    }
    
    private void particle(World world, int x, int y, int z) {
    	if (world.getBlockMetadata(x, y, z)==0) {
    		return;
    	}
    	Random rand=world.rand;
    	double d0 = 0.0625D;
    
            for (int l = 0; l < 6; ++l)
            {
                double d1 = (double)((float)x + rand.nextFloat());
                double d2 = (double)((float)y + rand.nextFloat());
                double d3 = (double)((float)z + rand.nextFloat());
    
                world.spawnParticle("portal", d1, d2, d3, 0.0D, 0.0D, 0.0D);
            }
    
    }
    }
    

     

     

    Any ideas what's going on here?

  12. Just taking the raw values. And there's a new strangeness I just discovered: this only happens in the test environment. Once I build the mod and load it into the normal Forge client, the parameter values are correct (I know this because my z+1 code, which worked in the test environment, is now setting data 1 block too *high* on the z-axis). Could the testing environment have anything to do with it? (I'm using Eclipse, by the way.)

  13. *EDIT* The problem has been updated. See this post below.

     

    *Original post below saved for archiving*

     

    While adding a new block, I noticed something strange. It seems the z-coordinate parameter for all the built-in methods (onBlockActivated, randomDisplayTick, etc.) are 1 too low. In other words, if the block is at (0,0,0), the parameter values are passed as (0,0,-1) instead. It caused some issues with my code, since I'm checking World.getBlockMetadata(), which requires accurate coordinates.

     

    I've fixed it by simply adding 1 to the z-coordinate, but this feels like it shouldn't be happening. Is this a known quirk of these methods and I should continue using z+1 everywhere, or is this unheard of and I should be looking for problems with my code?

  14. *EDIT* Oops! I figured out the problem...I had canInteractWith returning false constantly, which stops the container from showing up >_< . Fixed it all now! Thanks for your help; the LockedSlot class idea is definitely more elegant than my EmptyInventory technique :)

     

    *Original post below saved for the archives...*

     

    Ah! That sounds like a good idea. And yet, it still doesn't work :( It doesn't mess up the player's inventory anymore, but it still doesn't show the GUI. Here's the code I've updated from the original above, plus I've deleted the EmptyInventory class:

     

    EnderHopperGui.java:

     

    	@Override
    public Object getServerGuiElement(int ID, EntityPlayer player, World world, int x, int y, int z) {
    	// TODO Auto-generated method stub
            TileEntity tileEntity = world.getTileEntity(x, y, z);
            if(tileEntity instanceof TileEntityEnderHopper){
            	if (ID==0) {
            		return new ContainerHopper(player.inventory, (TileEntityEnderHopper) tileEntity);
            	}
            	else {
            		return new ContainerLockedEnderHopper(player.inventory,  (TileEntityEnderHopper) tileEntity);
            	}
            }
            return null;
    }

     

     

    ContainerLockedHopper.java:

     

    public ContainerLockedEnderHopper(InventoryPlayer p_i1814_1_, IInventory p_i1814_2_)
        {
            this.field_94538_a = p_i1814_2_;
            p_i1814_2_.openInventory();
            byte b0 = 51;
            int i;
    
            // Hopper slots
            for (i = 0; i < p_i1814_2_.getSizeInventory(); ++i)
            {
                this.addSlotToContainer(new LockedSlot(p_i1814_2_, i, 44 + i * 18, 20));
            }
    
            // 3x9 inventory slots
            for (i = 0; i < 3; ++i)
            {
                for (int j = 0; j < 9; ++j)
                {
                    this.addSlotToContainer(new Slot(p_i1814_1_, j + i * 9 + 9, 8 + j * 18, i * 18 + b0));
                }
            }
    
            // Hotbar slots
            for (i = 0; i < 9; ++i)
            {
                this.addSlotToContainer(new Slot(p_i1814_1_, i, 8 + i * 18, 58 + b0));
            }
        }

     

     

    LockedSlot.java:

     

    package enderhoppers;
    
    import net.minecraft.entity.player.EntityPlayer;
    import net.minecraft.inventory.IInventory;
    import net.minecraft.inventory.Slot;
    
    public class LockedSlot extends Slot {
    
    public LockedSlot(IInventory p_i1824_1_, int p_i1824_2_, int p_i1824_3_, int p_i1824_4_) {
    	super(p_i1824_1_, p_i1824_2_, p_i1824_3_, p_i1824_4_);
    }
    
    @Override
    public boolean canTakeStack(EntityPlayer player) {
    	return false;
    }
    
    }

     

     

    Not sure why the UI isn't even showing up at all...

  15. The container code is not necessary. RANKSHANK is correct: your getStackInSlot() method is trying to return this.slots[2], which is the third element in the slots array, but you've initialized slots to only have 2 elements. Hence your index of 2 is out of bounds.

  16. I'm a long-time programmer, but very new to Forge (and somewhat new to Java). I'm working on a small mod to get myself into the language and API, and it's all going well, except I've hit a roadblock.

     

    The mod is supposed to add "Ender hoppers" with a slightly different functionality from the regular ones, which it does. These hoppers store the UUID of the players who place them in an ownerUUID member variable, then are able to pull/push to and from their owner's Ender Chest inventory. This is all working just fine.

     

    However, I'm trying to make it so that if a player opens the hopper's inventory, if they're not the owner, they won't be able to use any of the hopper's slots--it'll be "locked", effectively. I figured this would be easy enough by making a separate Container class and GUI class for a "locked" Ender hopper and displaying that one if the activating player isn't a match. If they're both passed a 0-slot inventory (i.e. a new class that simply implements IInventory but doesn't ever set any slots), it *should* display an unusable inventory, right?

     

    At least, that was what I thought. Instead, if a non-owner player right-clicks on the Ender hopper, no GUI shows up. Even worse, their player inventory gets all screwed up, with items moving around to seemingly random slots, including armor, inventory, and hotbar slots. I can't seem to figure out what I'm doing wrong here.

     

    Here's the relevant code (imports excluded for brevity):

     

    EnderHoppers.java (main mod class) GUI registration:

     

    NetworkRegistry.INSTANCE.registerGuiHandler(this, new EnderHopperGui());

     

     

    EnderHopperGui.java:

     

    public class EnderHopperGui implements IGuiHandler {
    
    @Override
    public Object getServerGuiElement(int ID, EntityPlayer player, World world, int x, int y, int z) {
    	// TODO Auto-generated method stub
            TileEntity tileEntity = world.getTileEntity(x, y, z);
            if(tileEntity instanceof TileEntityEnderHopper){
            	if (ID==0) {
            		return new ContainerHopper(player.inventory, (TileEntityEnderHopper) tileEntity);
            	}
            	else {
            		return new ContainerLockedEnderHopper(player.inventory, new EmptyInventory());
            	}
            }
            return null;
    }
    
    @Override
    public Object getClientGuiElement(int ID, EntityPlayer player, World world, int x, int y, int z) {
            TileEntity tileEntity = world.getTileEntity(x, y, z);
            
            if(tileEntity instanceof TileEntityEnderHopper){
            	if (ID==0) {
                    return new GuiHopper(player.inventory, (TileEntityEnderHopper) tileEntity);
            	}
            	else {
            		return new GuiLockedEnderHopper(player.inventory, (TileEntityEnderHopper) tileEntity);
            	}
            }
            return null;
    }
    
    }

     

     

    (EmptyInventory is just a class which implements IInventory and returns 0, null, or false appropriately for all methods.)

     

    BlockEnderHopper.java onBlockActivated method:

     

        public boolean onBlockActivated(World p_149727_1_, int p_149727_2_, int p_149727_3_, int p_149727_4_, EntityPlayer p_149727_5_, int p_149727_6_, float p_149727_7_, float p_149727_8_, float p_149727_9_)
        {
            if (p_149727_1_.isRemote)
            {
                return true;
            }
            else
            {
                TileEntityEnderHopper tileentityhopper = func_149920_e(p_149727_1_, p_149727_2_, p_149727_3_, p_149727_4_);
    
                if (tileentityhopper != null)
                {
                	if (p_149727_5_.getGameProfile().getId().equals(tileentityhopper.getOwner())) {
                		p_149727_5_.openGui(EnderHoppers.instance, 0, p_149727_1_, p_149727_2_, p_149727_3_, p_149727_4_);
                	}
                	else {
                		p_149727_5_.openGui(EnderHoppers.instance, 1, p_149727_1_, p_149727_2_, p_149727_3_, p_149727_4_);
                	}
                }
                return true;
            }
        }

     

     

    (getOwner() returns the tile entity's ownerUUID, which I've verified is correct. GUI 0 is a normal, unlocked Ender hopper, which works; GUI 1 is a locked Ender hopper, which does not work.)

     

    GUILockedEnderHopper.java:

     

    @SideOnly(Side.CLIENT)
    public class GuiLockedEnderHopper extends GuiContainer
    {
        private static final ResourceLocation field_147085_u = new ResourceLocation("enderhoppers:textures/gui/container/locked_ender_hopper.png");
        private IInventory field_147084_v;
        private IInventory field_147083_w;
        private TileEntityEnderHopper hopper;
        private static final String __OBFID = "CL_00000759";
    
        public GuiLockedEnderHopper(InventoryPlayer p_i1092_1_, TileEntityEnderHopper hop)
        {
            super(new ContainerLockedEnderHopper(p_i1092_1_, hop));
            this.field_147084_v = p_i1092_1_;
            this.field_147083_w = hop;
            this.allowUserInput = false;
            this.ySize = 133;
        }
    
        /**
         * Draw the foreground layer for the GuiContainer (everything in front of the items)
         */
        protected void drawGuiContainerForegroundLayer(int p_146979_1_, int p_146979_2_)
        {
        	String name=((TileEntityEnderHopper)(field_147083_w)).getOwnerName();
            this.fontRendererObj.drawString("Bound to "+name, 8, 6, 4210752);
            this.fontRendererObj.drawString("Bound to "+name, 8, this.ySize - 96 + 2, 4210752);
        }
    
        protected void drawGuiContainerBackgroundLayer(float p_146976_1_, int p_146976_2_, int p_146976_3_)
        {
            GL11.glColor4f(1.0F, 1.0F, 1.0F, 1.0F);
            this.mc.getTextureManager().bindTexture(field_147085_u);
            int k = (this.width - this.xSize) / 2;
            int l = (this.height - this.ySize) / 2;
            this.drawTexturedModalRect(k, l, 0, 0, this.xSize, this.ySize);
        }
    }

     

     

    (The getOwnerName() method returns the string name of the owner of the hopper. I'm 100% sure the texture is loading properly as it worked before I tried making it 0-slots.)

     

    ContainerLockedEnderHopper.java:

     

    public class ContainerLockedEnderHopper extends Container
    {
        private final IInventory field_94538_a;
        private static final String __OBFID = "CL_00001750";
    
        public ContainerLockedEnderHopper(InventoryPlayer p_i1814_1_, IInventory p_i1814_2_)
        {
            this.field_94538_a = p_i1814_2_;
            p_i1814_2_.openInventory();
            byte b0 = 51;
            int i;
    
            // Hopper slots
            for (i = 0; i < p_i1814_2_.getSizeInventory(); ++i)
            {
                this.addSlotToContainer(new Slot(p_i1814_2_, i, 44 + i * 18, 20));
            }
    
            // 3x9 inventory slots
            for (i = 0; i < 3; ++i)
            {
                for (int j = 0; j < 9; ++j)
                {
                    this.addSlotToContainer(new Slot(p_i1814_1_, j + i * 9 + 9, 8 + j * 18, i * 18 + b0));
                }
            }
    
            // Hotbar slots
            for (i = 0; i < 9; ++i)
            {
                this.addSlotToContainer(new Slot(p_i1814_1_, i, 8 + i * 18, 58 + b0));
            }
        }
    
        public boolean canInteractWith(EntityPlayer p_75145_1_)
        {
        	return false;
            //return this.field_94538_a.isUseableByPlayer(p_75145_1_);
        }
    
        /**
         * Called when a player shift-clicks on a slot. You must override this or you will crash when someone does that.
         */
        public ItemStack transferStackInSlot(EntityPlayer p_82846_1_, int p_82846_2_)
        {
            ItemStack itemstack = null;
            Slot slot = (Slot)this.inventorySlots.get(p_82846_2_);
    
            if (slot != null && slot.getHasStack())
            {
                ItemStack itemstack1 = slot.getStack();
                itemstack = itemstack1.copy();
    
                if (p_82846_2_ < this.field_94538_a.getSizeInventory())
                {
                    if (!this.mergeItemStack(itemstack1, this.field_94538_a.getSizeInventory(), this.inventorySlots.size(), true))
                    {
                        return null;
                    }
                }
                else if (!this.mergeItemStack(itemstack1, 0, this.field_94538_a.getSizeInventory(), false))
                {
                    return null;
                }
    
                if (itemstack1.stackSize == 0)
                {
                    slot.putStack((ItemStack)null);
                }
                else
                {
                    slot.onSlotChanged();
                }
            }
    
            return itemstack;
        }
    
        /**
         * Called when the container is closed.
         */
        public void onContainerClosed(EntityPlayer p_75134_1_)
        {
            super.onContainerClosed(p_75134_1_);
            this.field_94538_a.closeInventory();
        }
    }

     

     

    I tried setting canInteractWith() to always return false, thinking that would do my job without needing the EmptyInventory class, but it didn't seem to do anything at all no matter what it returned, so I moved on to trying the EmptyInventory method.

     

    Can anyone see where I've gone wrong, or maybe a better/easier way to get this functionality working?

×
×
  • Create New...

Important Information

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