coolAlias

You can use the HarvestDropsEvent to change drops: @SubscribeEvent public void onBlockHarvest(HarvestDropsEvent event) { event.block // the block broken event.drops // the list of itemstacks that may drop; event.drops.clear() will remove all the items in there already event.harvester // the player, may be null so check for that as well as if the held item is correct }

Every time I go to report a bug, I get to the point where it asks me to create a new account and I stop. Call me lazy, but I think it's ridiculous to need an account just to report a bug, and being unable to use the one we already have with Mojang is even more ridiculous. So I just end up never reporting bugs. I know, it's petty, but it pisses me off every time I go there. Just one of those random things...

I don't know if you noticed, but Draco was using a custom IItemRenderer that takes his custom TileEntity as an argument, and registering that ItemRenderer. It does not only work with items, it works with whatever code you put inside of it, since it is just an interface.

Right, you're sending it from a GUI, that's fine, but you're not using the value that you send. Did you not read my comments? And when you send your packet back to the client, you don't do anything with it, so of course you're not going to see an updated value in the GUI.

Try reading the changelog. And no, there are still tons of func_ names. If you can't handle that, you should mod for 1.6 until 1.7 is more accessible.

Personally, I always use the recommended builds, and ONLY the recommended builds. Currently that is 1024 for 1.7.2. That doesn't mean the newer versions aren't worth upgrading to, it's just a decision I made that makes my life easier as well as those using my mods, as they can always just use the recommended version and know that it will work.

@Override // why are you handling the server side only, or at all, when you should just be setting the server side // data directly via a method to setXP? Are you setting xp on the client side and then sending a packet? public void handleServerSide(EntityPlayer player) { NBTTagCompound nbt = player.getEntityData().getCompoundTag(EntityPlayer.PERSISTED_NBT_TAG); // and here, you are only adding 1 rather than the exp amount from the packet // so it doesn't matter what you "set" the packet xp to nbt.setInteger("EnderStorageExp", nbt.getInteger("EnderStorageExp") + 1); // here you send a packet to the client, but you never handle that packet EnderStorage.packetHandler.sendTo(new PacketRefreshExp().setExp(nbt.getInteger("EnderStorageExp")), (EntityPlayerMP) player); } @Override public void handleClientSide(EntityPlayer player) { // see? nothing here... } Can you show the code where you add or set the xp initially, rather than just your packet class? Where are you sending this packet from?

Each version of Forge has fewer 'func_' names than the last, but there are still lots of them in there. As for tutorials, I doubt most of us are using tutorials to update our code to 1.7. The vanilla code is a more than sufficient example to follow when you get stuck if you're familiar at all with coding for Minecraft, just like in 1.6.

It's a bug in the vanilla code: // Entity.getExplosionResistance: public float func_145772_a(Explosion p_145772_1_, World p_145772_2_, int p_145772_3_, int p_145772_4_, int p_145772_5_, Block p_145772_6_) { return p_145772_6_.getExplosionResistance(this, p_145772_2_, p_145772_3_, p_145772_3_, p_145772_4_, posX, posY + getEyeHeight(), posZ); } Notice how the parameter 'x' is used for both x and y when getting the block's explosion resistance, and the y parameter is used for z.

Well, thanks to Draco's suggestion, I found out the source of the problem: // vanilla method: public void onBlockExploded(World world, int x, int y, int z, Explosion explosion) { world.setBlockToAir(x, y, z); onBlockDestroyedByExplosion(world, x, y, z, explosion); } // my "fix": @Override public void onBlockExploded(World world, int x, int y, int z, Explosion explosion) { if (world.getBlockMetadata(x, y, z) < 0x8) { super.onBlockExploded(world, x, y, z, explosion); } } That solves the blocks getting destroyed when they shouldn't, though I'm not very satisfied with it. This method is the same as in 1.6.4, so I'm not sure what else has changed to cause this discrepancy, so if anyone else has insights, I'd love to hear them. Likewise, I'll post my findings if I discover anything more about this.

It prints that it's an air block, and yet it's calling the method from my block class. Looks like explosions have changed the way they work to blow up blocks before calling the method that should determine whether they can be destroyed or not... great...

getExplosionResistance(entity) is what vanilla blocks call from the multiple parameter getExplosionResistance method, which ultimately just returns blockHardness / 5.0F. The print statements in clickBlock show the correct metadata, in my test it was 12, and previously (1.6.4) getExplosionResistance(args[]...) would also show the correct metadata; now, however, it always prints 0 zero for the metadata in that method, so of course my block is destroyed when it shouldn't be.

I'm getting abnormal behavior from getExplosionResistance - it seems to ignore the real world metadata values or the real world metadata gets changed before getting the explosion resistance: @Override public void onBlockClicked(World world, int x, int y, int z, EntityPlayer player) { // printing the values I would expect from the block placed, e.g. 12 System.out.println("Block metadata: " + world.getBlockMetadata(x, y, z)); } @Override public float getExplosionResistance(Entity entity, World world, int x, int y, int z, double explosionX, double explosionY, double explosionZ) { // printing the world meta here prints ZERO?!?! it just printed 12 when I clicked the block a second ago... System.out.println("Block meta: " + world.getBlockMetadata(x, y, z)); if (world.getBlockMetadata(x, y, z) < 0x8) { return getExplosionResistance(entity); } else { // never prints, obviously return 500F; } }

How are proxies outdated? It's simply a design decision to use them or not - it has nothing to do with this or that update. The reason many mod authors use proxies is because they greatly facilitate distinguishing between client and server side during mod initialization, which is important for doing things like registering render classes, key handlers, etc., all of which you'd have to do manually otherwise.

The method "public int getHealth()" does not exist in the Entity classes; it returns a float. Putting @Override above your methods will enable some extra error-checking in your IDE that will tell you when your methods don't match any methods in the parent class, which will help prevent mistakes like this. EDIT: Of course, only put @Override above inherited methods, not ones that you create yourself.

Stop creating new blocks!!! Just reference the block you already created in your main mod: (new WorldGenBigNetherMushroom(Tutorial.cellulosBlock).generate(world,random,x,world.getTopSolidOrLiquidBlock(x, z),z); Why on earth would you create a new block each time? That makes no sense, and nowhere in Wuppy's code do I see him do that.

Rails I just set the metadata manually on a second pass; I store all such blocks in a temporary array of BlockData objects (stores position, id, meta) so I can go back and fix them after all is said and done. Guess I've never had to worry about the piston base dropping, as I'm usually either just setting or removing, never copying. Seems you're stuck on that one with either doing a 3rd pass (1 - copy, 2 - set, 3 - erase) or checking for those blocks as you go and, when encountered, scanning the adjacent neighboring blocks to pick up the data you need.

Mwa ha ha ha!!! I finally tracked it down in RenderItem.renderItemOverlayIntoGUI(args...) if (par3ItemStack.isItemDamaged()) { int j1 = (int)Math.round(13.0D - (double)par3ItemStack.getItemDamageForDisplay() * 13.0D / (double)par3ItemStack.getMaxDamage()); int k = (int)Math.round(255.0D - (double)par3ItemStack.getItemDamageForDisplay() * 255.0D / (double)par3ItemStack.getMaxDamage()); GL11.glDisable(GL11.GL_LIGHTING); GL11.glDisable(GL11.GL_DEPTH_TEST); GL11.glDisable(GL11.GL_TEXTURE_2D); // HERE: alpha and blend are disabled: GL11.glDisable(GL11.GL_ALPHA_TEST); GL11.glDisable(GL11.GL_BLEND); Tessellator tessellator = Tessellator.instance; int l = 255 - k << 16 | k << 8; int i1 = (255 - k) / 4 << 16 | 16128; this.renderQuad(tessellator, par4 + 2, par5 + 13, 13, 2, 0); this.renderQuad(tessellator, par4 + 2, par5 + 13, 12, 1, i1); this.renderQuad(tessellator, par4 + 2, par5 + 13, j1, 1, l); GL11.glEnable(GL11.GL_TEXTURE_2D); GL11.glEnable(GL11.GL_LIGHTING); GL11.glEnable(GL11.GL_DEPTH_TEST); // HERE: they are not re-enabled GL11.glColor4f(1.0F, 1.0F, 1.0F, 1.0F); } EDIT: disabling blend and alpha_test screws up the creative tab rendering; just enabling them is enough Re-enabling them before I draw my icons (and then re-disabling them afterwards) brings everything back to normal Seems like an oversight / bug on the part of Mojang there. I wonder if it will or has been fixed in versions after 1.7.2?

Ooooh, that looks neat!!! I will have to give that a whirl and see what I can see, thanks!

That's what I figure is going on as well; somehow the rendering of the damage bar over the ItemStack is screwing up the colors, but no matter what I try I can't seem to get it to normalize... Here's an interesting picture when I change it to just render the first icon: Note how the background is brownish colored for the bags; that goes away if I highlight the bag slot or any slot intervening the bag and the damaged stack. Very odd. Rendering multiple icons of course makes it turn grey like the previous screenshot. I've been looking through the inventory render code to see if they do anything prior to rendering each stack, such as enable/disable standard lighting, etc., but none of those have had any effect when I've tried them... the search continues

Turns out they're public: package net.minecraft.network.packet; public static void writeItemStack(ItemStack par0ItemStack, DataOutput par1DataOutput) throws IOException // so you can write your ItemStack to the output stream like this: Packet.writeItemStack(itemstack, out);

Your problem is exactly what you suspect: do NOT set data on the client side, you MUST send a packet to the TileEntity to correctly set its inventory contents on the server. The ItemStack and Packet classes already have some handy methods for doing so: // out is a ByteArrayDataOutput, in is a ByteArrayDataInput writeNBTTagCompound(stack.writeToNBT(new NBTTagCompound()), out); stack = ItemStack.loadItemStackFromNBT(readNBTTagCompound(in)); You may have to copy the code for read and write NBTTagCompound from the Packet class to make it accessible, but it's there.

My doors and pistons work just fine; it's not an issue of flag 2 for those, it's an issue of when you place them. Doors, for instance, will break if there isn't a block underneath them, so you have to place the lower layers first. As for pistons, you can place the base first, then after it's placed, you have to manually set the metadata once again to get the correct rotation / head state. Same goes for any block that auto-sets metadata when placed; e.g. chests and the like. EDIT: Actually, for piston heads, I set those as a separate block and then, like the base, manually set the metadata after it's placed. That's only necessary if you want it extended right away without needing a redstone update.

Sadly, no, it turns grey like the gui background, except one of the digits will still render. I wasn't able to take a screenshot with the inventory screen open, but the effect is the same if I remove the stone block and highlight the slot instead, and if neither of the bags will render correctly if nothing intervenes between them and a damaged stack.

You know, I've never tried that, but it should be able to. I use flag 2 when setting blocks so it doesn't update neighbors, meaning the sand should not fall. I've placed torches hanging in mid-air this way.