TehSeph

Make sure to use @Override.

If you're going to use copy-paste code at least clean up the parameter names, delete the unused bits, and try to understand it. Nobody is going to help you until you do. It makes it difficult for us to read and difficult to give help. It also makes it difficult for you to understand that help if you don't even understand your own code.

The answer is obvious when you do as Chibill said and then look at what you just posted. Don't be an ass just because you don't know what you're doing and are being told that you don't. (Edit: I even made an attempt to point it out for you.)

Try passing the block you want to check and the block you want to match as itemstacks to OreDictionary.itemMatches(targetBlock, inputBlock, false).

You can't possibly expect to know every name for every save and have a different icon for the infinite number of possibilities. What exactly is it you are trying to do and are you sure there isn't a better way to do it? Even if you're not sure if there is, someone here might know a better way than relying on a save name determined by the end user. I'm not sure I understand what you plan to do with the name you receive. (But, how you were trying to get it should have been working)

Yikes! That's some top-priority generation!! Instead of using an absurd weight, try registering your generator in your mod's initialization stage instead of your pre-initialization stage. That way your WorldGen gets registered AFTER the vanilla generators and is weighted only against other mods' generators who have done the same.

Sounds like you want something like "Overworld", or "Nether", or "End" not the actual save name. Am I correct? Try Minecraft.getMinecraft().thePlayer.getEntityWorld().provider.getDimensionName();

The reasoning for two separate methods is clear as day right there in your code snippet from ItemDye's applyBonemeal(). The methods are split because of the split between logic on the server and client side. The 2nd and 3rd methods are called only on the server side while the 1st is called on both sides. I'm guessing the boolean in the first method was used back when the client and server were separated and is now leftover because of that. All the logic might have originally been in a single method (or two: canBonemeal & doGrowth), but because of the (semi-)recent changes to the client/server and how bonemeal works the methods were split for a cleaner, more side-dependent code. Just guesses, since this is how I would do it and I wager Mojang knows quite a bit more about java coding than I do.

Close. You're right on the 2nd bit, but the first method will always return true so long as you're allowed to use bonemeal on the block. There should never a time when you use bonemeal without consuming it. If you were using your own custom item instead of bonemeal, you would ignore the first method completely (and possibly the 2nd method if you always wanted a 100% growth chance).

Because well coded java means you will always preform all 3 functions in any classes implementing the methods. Here is a more in-depth look at the functions and why they differ in each class. BlockCrops checks the block metadata in canBonemeal() and returns false if the crop is fully grown because the 2nd method is called at the same time the bonemeal is used. This makes it impossible to reach the 2nd method and waste bonemeal on a fully grown crop. BlockCrops always returns true in doBonemeal() because every time a bonemeal is used there will always be growth. BlockCrops then calls another function inside of doGrowthTick() which is essentially growRandomAmount() and changes the block's metadata to a random metadata that is between 2 to 5 higher than the current and lower than or equal to the max. BlockSapling on the other hand will always return true in canBonemeal() because there is never a time you can't use bonemeal on a sapling. BlockSapling's doBonemeal() returns true only if rand.nextFloat() < 0.45D. This means bonemeal is always consumed but growth is only occurring randomly at a 45% chance. Finally, in doGrowthTick() BlockSapling increases it's metadata by 1 until it reaches 8 growth ticks (or a metatdata bitwise-similar to 8 ticks) and then uses the metadata to grow a tree depending on the sapling type. The reason most blocks return true in canBonemeal() is because they will always allow bonemeal to be used. Once growth has completed the block is generally replaced with another block type which either doesn't implement IGrowable or disallows the use of bonemeal. BlockCrops is different in this sense because even fully grown it is still an instance of BlockCrops and is never replaced, so it uses this method to check if it is fully grown and if it is it then returns false. The reason most blocks return true in doBonemeal() is because growth-ticks are generally 1:1 with bonemeal usage. Each time a bonemeal is used you will always get some sort of growth. BlockSapling and BlockMushroom are the only 2 vanilla classes that ever return false here because they only have a random chance (45%) for growth to occur, but still bonemeal is always consumed so the 1st method returns true. Sorry about the long-winded post. I tried to format and color code it to be more readable. Pretty sure I failed. But, I hope that clears up a bit of confusion though.

Use getStackInSlotOnClosing(), not getStackInSlot(). The former removes the items after returning them. The later doesn't. The vanilla crafting table does exactly what you're trying to do and it took 5 seconds to look up. From ContainerWorkbench: public void onContainerClosed(EntityPlayer p_75134_1_) { super.onContainerClosed(p_75134_1_); if (!this.worldObj.isRemote) { for (int i = 0; i < 9; ++i) { ItemStack itemstack = this.craftMatrix.getStackInSlotOnClosing(i); if (itemstack != null) { p_75134_1_.dropPlayerItemWithRandomChoice(itemstack, false); } } } } EDIT: And your error above is because you never actually set worldObj, so it is null... I sense a lot more errors in the future.

Looking at the code you provided I would agree with shieldbug and assume func_149851_a is canBonemeal() which returns true if you can use bonemeal and func_149852_a is doBonemeal() and returns true at the same time the bonemeal is used since underneath it the stacksize is unconditionally decremented, and I assume the itemstack is a valid stack of bonemeal. Plus the second and third functions are only done server-side (I think? isRemote confuses me at times) and it would make sense to only do growth logic server-side but check if something can grow on both sides. This is all just based off the snippet you posted. I haven't actually looked into IGrowable lately. EDIT: After actually looking at IGrowable and it's implementations; If I had to guess, these would be my guesses: func_149851_a = canBonemeal(worldProvider, posX, posY, posZ, defaultValue): returns true if bonemeal is allowed or defaultValue (true on client, false on server). func_149852_a = doBonemeal(worldProvider, randomProvider, posX, posY, posZ): returns true at the same time bonemeal is used if conditions for a growth-tick are acceptable. func_149853_b = doGrowthTick(worldProvider, randomProvider, posX, posY, posZ): processes the actual growth-tick logic, which is usually increasing metadata or replacing the block.

READ MY POST My problem is that i cannot move items when the inventory is open, NOT that the inventory is not opening. (aka it is opening) He did read your post. He's telling you exactly why it opened but you're not able to interact with it. Maybe YOU should read HIS post, instead of being an ass when someone is helping you.

It's possible, but difficult for a few reasons. What are you wanting to add? Can it be added in-game or does it NEED to be in the main menu? Generally it's frowned upon to alter the existing menus as it: 1) Requires a coremod. (Which are last resort.) 2) Only keeps the last mod to change it's changes. 3) Can just be plain annoying depending on what you're changing. But if you're only adding functionality and not removing any and you're not too intrusive about it, people might be willing to help.

EDIT: If you read what I had said here, forget it. I was thinking of the compiler, not JVM. The below statement should still be true, though. It shouldn't matter which JRE the end user has installed. So long as you're only using functions that exist among all Java versions, any JRE that can run Minecraft will also run your mod just fine. Your project given to you by gradle should be set to compile in 1.6 compatibility regardless of which JDK you're using, and all JVMs are backwards compatible when running code. So 1.7 code -> compiled in 1.6 compatiblity -> runs on 1.6+. Java 9 might change this, but it's still 2 years away and hopefully Mojang/Forge will both have updated to 1.8 (the only other version the 1.9 JVM will be compatible with) by then. Or we can just have multiple JREs installed, which there really isn't any harm in aside from the usual "older versions are always less secure" crap.