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.

Could we see the ORef file and BcwadsworthWorld.java? It looks like your ItemStack you're registering might be wrong.

You're either trolling, or were dropped on your head as a child. That is not the entire method. That doesn't even validate as java. Reread my post or read the post above this.

You're misunderstanding. For people to help you you'll need to show the entire class, not just that method. playSoundAtEntity() works just fine. Its a vanilla method. If it didn't, than there'd be no sound in the vanilla game. In order to see what is happening to cause it to not work, we need to see the rest of the .java file's contents to understand where the problem is. You can't expect help on something without providing people with the thing you need help on.

Java 9 is getting split into 2 code lines near the end of development, so JRE 1.9 is going to be limited to 1.8 as the new code is being designed. But 1.8 should work back to at least 1.5. (The last major change. More than old enough for MOST java programs out there.) Java 9 is 2 years away though, so... Exactly. Even if you're coding another app in 1.8 there is no need to uninstall 1.6 (or 1.7) since that is the native JDK to Minecraft and thus the best to code in.

Okay so after many frustrating attempts to make the previous code work, I gave up and decided to rewrite my class and came up with the code below. Unfortunately, this is causing some horrible tick-lag and I'm not quite sure what I can do about it. WorldGenModMinable.java package com.tehseph.sephsmod.worldgen; import com.tehseph.sephsmod.block.BlockMeta; import cpw.mods.fml.common.IWorldGenerator; import net.minecraft.block.Block; import net.minecraft.world.World; import net.minecraft.world.chunk.IChunkProvider; import net.minecraft.world.gen.feature.WorldGenMinable; import java.util.Random; public class WorldGenModMinable implements IWorldGenerator { private int dimensionID; private Block replaceTarget; private Block oreBlock; private int veinSize, veinCount; private int minY, maxY; public WorldGenModMinable(int dimensionID, Block replaceTarget, Block oreBlock, int veinSize, int veinCount, int minY, int maxY) { this.dimensionID = dimensionID; this.replaceTarget = replaceTarget; this.oreBlock = oreBlock; this.veinSize = veinSize; this.veinCount = veinCount; this.minY = minY; this.maxY = maxY; } @Override public void generate(Random random, int chunkX, int chunkZ, World worldObj, IChunkProvider chunkGenerator, IChunkProvider chunkProvider) { if (worldObj.provider.dimensionId == this.dimensionID) { if (this.oreBlock instanceof BlockMeta) { for (int metadata = 0; metadata < ((BlockMeta) this.oreBlock).metaNames.length; metadata++) { for (int i = 0; i < this.veinCount; i++) { int randX = (chunkX * 16) + random.nextInt(16); int randZ = (chunkZ * 16) + random.nextInt(16); int randY = this.minY + random.nextInt(this.maxY - this.minY); (new WorldGenMinable(this.oreBlock, metadata, this.veinSize, this.replaceTarget)).generate(worldObj, random, randX, randY, randZ); } } } else { for (int i = 0; i < this.veinCount; i++) { int randX = (chunkX * 16) + random.nextInt(16); int randZ = (chunkZ * 16) + random.nextInt(16); int randY = this.minY + random.nextInt(this.maxY - this.minY); (new WorldGenMinable(this.oreBlock, this.veinSize, this.replaceTarget)).generate(worldObj, random, randX, randY, randZ); } } } } } So, my new problem is this: How can I optimize this to lower the ticking times? EDIT: So it appears after doing some research, the tick-lag is not my fault and is actually poor vanilla code changes made in 1.7.10. This post on the FTB forums has a few JVM arguments that can help combat the lag as well as a mention to FastCraft, a WIP mod written by IC2's Player that helps to greatly improve the ridiculous 1.7.10 chunk loading issues. I've left my metadata block generation code above just in case it helps anyone out who might have come across this thread, but all problems are (kind of) solved now. At least, everything in my code is solved.

It's just an integer, so anywhere from -2^31 to (2^31)-1 unless Minecraft/Forge is specifically restricting it anywhere. (Which it doesn't seem to be. At least not in Minecraft's WorldProvider.java or Forge's DimensionManager.java)

I meant JDK not JRE. Go ahead and uninstall the prior JRE since all newer versions are backwards compatible. But there is no reason to uninstall (or even update) the JDK version because it's best to develop in the same version as the official. Unless you're developing another java app using 1.8, you don't need JDK 1.8 and won't benefit from using it unsupported in your Minecraft mod. If it ain't broke, don't "fix" it.

Switch them back to 1.7. Just because you installed 1.8 doesn't mean 1.7 is gone. (unless you uninstalled it... in which case: why?) As far as I've read Minecraft is built on 1.6, and works on 1.7, but 1.8 messes it up a bit. So until Mojang updates you shouldn't update. Edit: Shouldn't update JDKs, I mean. All JREs should be backwards compatible.

Several of my blocks are using metadata for subtypes, but unfortunately this is causing issues in my worldgen code. Well not exactly causing issues so much as just not working. Only one type of each block is being spawned even though I'm using the meta values in the generation code. I've hit a wall with ideas on how to solve this without rewriting the generation and possibly even quite a bit of my blocks themselves. Any help at all is appreciated. WorldGenModMinable (World Generator) (See post below) ModWorldGen (GameRegistry Registration) package com.tehseph.sephsmod.core; import com.tehseph.sephsmod.worldgen.WorldGenFlatBedrock; import com.tehseph.sephsmod.worldgen.WorldGenModMinable; import cpw.mods.fml.common.registry.GameRegistry; import net.minecraft.init.Blocks; // TODO: Tweak "Experience Ore" vein count & size. public class ModWorldGen { public static void flatBedrock(boolean doFlatBedrock) { if (doFlatBedrock) GameRegistry.registerWorldGenerator(new WorldGenFlatBedrock(), 0); } public static void oreGeneration() { // WorldGenModMineable( int DIMENSION_ID, block REPLACE, block ORE, int METADATA, int VEIN_SIZE, int VEIN_COUNT, int MIN_Y, int MAX_Y ) GameRegistry.registerWorldGenerator(new WorldGenModMinable(0, Blocks.stone, ModBlocks.oreExperience, 0, 4, 4, 0, 64), 1); GameRegistry.registerWorldGenerator(new WorldGenModMinable(0, Blocks.stone, ModBlocks.oreGemstone, 0, 4, 4, 16, 48), 1); GameRegistry.registerWorldGenerator(new WorldGenModMinable(0, Blocks.stone, ModBlocks.oreGemstone, 1, 4, 4, 16, 48), 1); GameRegistry.registerWorldGenerator(new WorldGenModMinable(0, Blocks.stone, ModBlocks.oreGemstone, 2, 4, 4, 16, 48), 1); GameRegistry.registerWorldGenerator(new WorldGenModMinable(0, Blocks.stone, ModBlocks.oreGemstone, 3, 4, 4, 16, 48), 1); } } Full src on GitHub in case it is something somewhere else I'm missing.

Pretty sure the max damage for an item is closer to 32,767 and not 16.