MineMaarten

You need to override that method, not call it. So in you block class add: public int quantityDropped(Random par1Random) { return 5; } If you want to drop 5 items. That method will be called by others.

You haven't updated your GitHub with the code that's causing you problems.

If just getting a list of every loaded TileEntity in the world is enough for you, you can use the list in World: world.loadedTileEntityList . And you could search for your own TileEntities in there. However, teleportation often is about travelling far (and unloaded) distances so a loaded tile entity list probably doesn't suffice....

Modder Support topic subtitle: "(...) please keep in mind that this is not a Java school. You are expected to have basic knowledge of Java before posting here." Basic Java includes the understanding of OOP logic.

I'm suspecting the path you filled in the @SidedProxy isn't the path your ClientProxy is in. You are sure it's at "stickpeted.elementalStaffs.client.ClientProxy" ?

It's probably unrelated to the problem, but only change the block meta or notify only on the server. The server then automatically will update the client. You might be right here. I guess (not sure!) onInventoryChanged() is being called multiple times when the inventory changed and if every time causes the neighbors to update that can cause a lag spike yes. I would go for the latter. You don't need a TickHandler first of all, you already have one in your TileEntity (updateEntity()). If speed is not really problem, you can set something up that checks if the on/off state changed every so often and if it has changed update the neighbors: private int ticksExisted; public void updateEntity(){ if(!worldObj.isRemote && ticksExisted % 20 == 0){ //check every second if(check if changed){ worldObj.setBlockMetadataWithNotify(xCoord, yCoord, zCoord, newMeta, 3); } } }

I'm sorry to say, but this is a "please learn more Java" situation. If you did know Java you would have known the bold line you've posted never could have thrown a IndexOutOfBoundsException on it's own. If the stacktrace indeed said it was on that line, there should be another trace which points at the actual problem (inside the super method). Also the fact that you don't know exactly in which class you have problem indicates you don't really know what they did in the Youtube video. All in all, I'd recommend to learn more Java, and use http://courses.vswe.se/ as a start. These lectures combine the learning of Java and Minecraft modding. Yes this will take a lot of time, but every good modder has been through this and it pays off.

Sorry to say, but basic java: ItemStack heldItem = new ItemStack(Item.pickaxeStone); if(player.inventory.getCurrentItem() == heldItem){ '==' in this case has an other meaning than you think. It's checking if both objects are the one and the same, meaning they hold a reference to the same location in memory. The solution would be: if(player.inventory.getCurrentItem().itemID == Item.pickaxeStone.itemID) But please learn more about Java before proceding, it will make you life easier .

I think the client's livetime variable is never set so it stays at 0. Then in the update method this line will (also) trigger on the client: if (livetime <= 0) { this.setDead(); } Solution would be to add a server check: if (!worldObj.isRemote && livetime <= 0) { this.setDead(); }

It's a world problem. Not kidding! The method which updates the neighbours is in World, and you can call this from within your TileEntity: worldObj.notifyBlockChange(xCoord, yCoord, zCoord, worldObj.getBlockId(xCoord,yCoord,zCoord); What I would do (if possible) is determining whether it's on or off with the block's metadata. That way, when you change the on/off state, you can automatically notify the neighbors (by using the right flag in worldObj.setBlockMetadataWithNotify(xCoord, yCoord, zCoord, meta, flag)). //Edit: Forgot the word Metadata in the method name!

The fact that you know bitwise operations helps alot in explaining this problem. You'll have to assign bits in the metadata to represent something. Let's say we use the two least significant bits for the direction, and the 3rd bit from the right (the bit representing 4) for the on/off state. You can now use this to manipulate the states: public void setDirection(World world, int x, int y, int z, int direction){ int onOff = world.getBlockMetadata(x, y, z) & 4; //only get the on/off state, as we want to preserve it. world.setBlockMetadataWithNotify(x, y, z, onOff | direction, 3); } public int getDirection(World world, int x, int y, int z){ return world.getBlockMetadata(x, y, z) & 3; //mask the on/off state } pubic void setActivated(World world, int x, int y, int z, boolean activated){ int direction = getDirection(world, x, y, z); world.setBlockMetadataWithNotify(x, y, z, direction + (activated ? 4 : 0), 3); } public boolean getActivated(World world, int x, int y, int z){ return world.getBlockMetadata(x, y, z) & 4 == 4; } The number 3 used in the setBlockMetadataWithNotify() methods are flags that define whether a change of metadata should cause the client to rerender the block, and whether the change of metadata should cause a block update for neighbouring blocks. With the 3 it's doing both, but look in the setBlock() method in Block.java for a detailed explanation of the flags.

block metadata can be translated to item damage for items. So you can use item.getItemDamage() to render every metadata differently

You forgot to call super.writeToNBT(par1NBTTagCompound); In your writeToNBT() method. This is crucial, as it writes to nbt at which x,y,z position the TileEntity is.

Most likely a offset issue. Instead of p.worldObj.setBlock((int)p.posX, (int)(p.posY+player.yOffset), (int)p.posZ, MoreApples.customRedstoneAir.blockID); try p.worldObj.setBlock((int)(p.posX - 0.5D), (int)(p.posY+player.yOffset), (int)(p.posZ - 0.5D), MoreApples.customRedstoneAir.blockID);

No, not if you do it like the tutorials say it should be done. ModLoader.openGUI(player, new mygui(player)); Which is not with a ModLoader method. Use IGuiHandler, and use EntityPlayer.openGui() on the server side only. Like GotoLink said twice, check tutorials.

Apart from what mnn suggested, it could also be the cause of a id conflict. Try removing your config file (if you have one, you should ).

Well if it's triggered after, you could check if the block being right clicked on is an Item Frame (or were Item Frame entities?), and then get the stored item from its TileEntity. But even if this works, you still have the problem that this is not very reliable. You might have missed other vanilla features or other mods could easily add other features that take an item from your inventory by right clicking on something.

You're nearly there yes! You've only covered 3/7 cases though! You forgot to check all the positions on y+1 .

Problem here is that his block is bigger than a block. And then you have that problem that the entity doesn't even check if it's colliding a block if it isn't in the block. I won't just give the other cases of the switch, as I want you to understand my thinking. What I'm doing here is that I'm using metadata to let the ghost block know in what position the ghost block is in relation to the base block. If you look at what happens when the metadata is 0: world.setBlock(x + 1, y , z , GhostBigBoxBlock.blockID, 0, 3);//The block is placed 1 further on the x-axis than the base block So the ghost block now 'knows' that if it has metadata 0 it is placed 1 block further on the x-axis than the base block. So the base block is at x - 1, y, z. So when we break the ghost block, we break the base block as well by doing: world.setBlockToAir(x - 1, y, z); I hope you understand now. This solution isn't finished yet. You now could replace blocks in the world by placing a BigBoxBlock next to it. You can prevent this from happening, and you could look at BlockCactus.java how it's done for the cactus. Look at the canPlaceBlockAt() method.

Well, let me help you then. I think you should know how to create a block that's invisible. So I'm assuming you now have a block called GhostBigBoxBlock. When you place down a BigBoxBlock, you want to place down 7 GhostBigBoxBlocks as well. So in your BigBoxBlock you can override onBlockAdded() : public void onBlockAdded(World world, int x, int y, int z) { world.setBlock(x + 1, y , z , GhostBigBoxBlock.blockID, 0, 3); world.setBlock(x , y , z + 1, GhostBigBoxBlock.blockID, 1, 3); world.setBlock(x + 1, y , z + 1, GhostBigBoxBlock.blockID, 2, 3); world.setBlock(x , y + 1, z , GhostBigBoxBlock.blockID, 3, 3); world.setBlock(x + 1, y + 1, z , GhostBigBoxBlock.blockID, 4, 3); world.setBlock(x , y + 1, z + 1, GhostBigBoxBlock.blockID, 5, 3); world.setBlock(x + 1, y + 1, z + 1, GhostBigBoxBlock.blockID, 6, 3); } As you can see, for every one of the ghost blocks added, I set a different metadata. This we can use in the next part. The next part is the breaking of the block. When you break any of the ghost blocks (or BigBoxBlock) you need to remove every other ghost block as well. And we use the metadata here for the GhostBigBoxBlocks to let them know in which position they are in relation to the BigBoxBlock. And if one of the ghost blocks get broken, we remove the BigBoxBlock which then will remove every GhostBigBoxBlock on his part. To do this override breakBlock() of the GhostBigBoxBlock : public void breakBlock(World world, int x, int y, int z, int blockID, int metadata) { super.breakBlock(world, x, y, z, blockID, metadata); switch(metadata){ case 0: world.setBlockToAir(x - 1, y, z); break; case 1: world.setBlockToAir(x, y, z - 1); break; //TODO do this for every of the 7 cases } } So this will break the BigBoxBlock when one of the Ghost Blocks get broken. Now to break every Ghost block override breakBlock in BigBoxBlock: public void breakBlock(World world, int x, int y, int z, int blockID, int metadata) { super.breakBlock(world, x, y, z, blockID, metadata); for(int i = x; i < x + 2; i++) for(int j = y; j < y + 2; j++) for(int k = z; k < z + 2; k++) world.setBlockToAir(i, j, k); } That's how I would do it, if others have better solutions I'm happy to hear them .

The problem is the getCollisionBoundingBoxFromPool() is only called and used when the entity is within the block. You can verify this by adding a print in the getCollisionBoundingBoxFromPool() method, or placing a breakpoint. So the problem is that the entity isn't realizing that it's colliding with the block when it's outside the normal block bounds. My solution would be to add 'ghost blocks'. Invisible blocks that have a collision box.

How do you mean? You're just replacing the creation of normal Slots by your own slot in your Container class, right? That isn't messy.. Or can you show some code what you think is messy?

If you want to store the gathered items in the block itself, you'll need a TileEntity which will also give you an update method which triggers every tick. If you want to spawn EntityItems on top of the block or something, you can set up timing of the block to get scheduled ticks, or if you want to gather at random intervals you could use the random ticks (which things like wheat use to do their grow logic). So no Tickhandler needed.

Location location = new Location(x, y, z); if(!FirstMod.instance.fishDirts.remove(location)){ Well, you're making a new Location object which you're trying to remove from a list? In that case, you'll always fail to remove it, as the reference of the new object never can be the same as one of the objects in the list. Unless you've correctly overriden the equals() method in your Location class? Also this will not work on the server side, as mentioned before by Draco18s: Minecraft.getMinecraft().theWorld.addWeatherEffect(new EntityLightningBolt(Minecraft.getMinecraft().theWorld, x, y, z));

for (int i = 0; i < this.furnaceItemStacks.length; ++i) { if (this.furnaceItemStacks != null) Really?