Choonster

Post the FML log, like the massive warning on the home page tells you to.

Override TileEntity#shouldRefresh to return true when oldState.getBlock() is not equal to newSate.getBlock() (like the base method does for vanilla TileEntity s).

That particular GUI's text just hasn't been updated since it was first added in 1.3.2. The file name in the message is hardcoded, it's not determined from the current logging configuration. It's probably worth reporting this as a bug, though. Edit: Reported here.

IRecipe provides the getRecipeOutput method, there's no need to check for specific implementations of it like you are now. This will allow any recipe type to be removed. You can add a ShapedRecipe / ShapedOreRecipe as a replacement for a MekanismRecipe ; but it won't have the ability to check for specific gas/energy values, item tiers or factory types and it won't transfer energy/gas from the input items to the output item. If you want this functionality, add Mekanism as a dependency and add a MekanismRecipe instead of a standard shaped recipe.

We're not psychic, we can't help you unless you post logs.

You could do that, but do you need to? If your block renders in EnumWorldBlockLayer.SOLID (i.e. it returns that from Block#getBlockLayer ), transparent pixels will be rendered as black. This is how vanilla handles it.

You could call BlockLeaves#setGraphicsLevel with the return value of Minecraft.isFancyGraphicsEnabled every time the fields set by it are queried. I don't think there's any other way to do this apart from inserting a callback/event using ASM.

ContainerWorkbench doesn't interact with the Crafting Table block at all except to check if the player is still in range of it. The Crafting Table doesn't have a TileEntity , it doesn't store any items; ContainerWorkbench creates its own temporary inventories to store the ingredients and result and drops these on the ground when the GUI closes.

The JRE is irrelevant in this case, there's no need to have it any environment variable. If JAVA_HOME is pointing to your JDK path and it's still not working, run gradlew setupDecompWorkspace again and post the new output.

Do you have the JDK installed in that directory? JAVA_HOME is an environment variable that tells Gradle where to look for the Java compiler. You set it to the path of the JDK like you would any other environment variable.

Don't set it to the JDK's bin directory, set it to the JDK directory itself (C:\Program Files\Java\jdk1.8.0_60).

The log file is called fml-client-latest.log for 1.7+. ForgeModLoader-Client-0.log was the pre-1.7 name. Most mods have a thread on Minecraft Forum with download links. Many mods host their downloads on Curse/CurseForge.

You need to set the JAVA_HOME environment variable to the path of your JDK, not your JRE.

Use BON to deobfuscate mods before decompiling them with a decompiler like JD-GUI, FernFlower, Procyon or CFR.

See this thread for discussion of the issue and solutions. It looks like the easiest solution is to switch to ForgeGradle 2.0-SNAPSHOT instead of the stable 2.0.2.

For 1.7.10 and earlier (ForgeGradle 1.X), you need to use deobf/dev versions of the mods or install CodeChickenCore to deobfuscate mods at runtime. For 1.8+ (ForgeGradle 2.X), you can do the same thing or add the mods as deobfCompile / deobfProvided dependencies and ForgeGradle will deobfuscate them for you. According to this issue, this currently doesn't work for local files or Ivy dependencies (I assume it works for Maven dependencies). Edit: As of Forge 1.8.9-11.15.0.1696 (commit 9a737b0), FML will automatically deobfuscate mods at runtime without the need for CodeChickenCore or a ForgeGradle dependency.

The installer should have created a log file with the same name as itself, post this log in a [nobbc]

Extra Utilities requires a newer version of ForgeMultipart than the one you have installed.

Update AromaBackup.

You're iterating through the key set, which is a Set<String> . If you want keys and values, iterate through the entry set instead; this is a Set<Entry<String, Float>> . There's no need to use an Iterator and remove values here, just iterate through the entry set with a for-each/enhanced for loop and leave the message's map intact. It will simply be garbage collected with the message object itself when it's no longer referenced by anything.

Subscribe to FMLNetworkEvent.ServerConnectionFromClientEvent to be notified on the server when a client connects. All subclasses of FMLNetworkEvent are fired on a Netty thread, so you need to schedule a task on the main thread using the appropriate IThreadListener like you do for message handlers*. This will give you an INetHandlerPlayServer from the FMLNetworkEvent#handler field which you can cast to NetHandlerPlayServer to get the player from the NetHandlerPlayServer#playerEntity field. You can then send whatever data you need to this player. You'll probably want to subscribe to FMLServerStartingEvent (this is a state event handled by an @Mod.EventHandler method in your @Mod class) and repopulate the data from the JSON if it's an integrated server. This is because the client and integrated server are two threads running in the same JVM, they share an instance of your @Mod class and anything created in it. For this same reason, it's probably not necessary to handle FMLNetworkEvent.ServerConnectionFromClientEvent in the integrated server. * I'm not entirely sure whether or not it's safe to use a SimpleNetworkWrapper from a Netty thread.

You'll need to send a packet to the client containing the server's settings. Forge's Read the Docs site has a section on networking here, you'll want to use the Simple Network Implementation.

Look at GuiCrafting to see how the vanilla Crafting Table creates its client-side Container and renders the GUI. You can use the same code, but create an instance of your Container class instead of ContainerWorkbench . BedrockMiner has a tutorial on the GUI Handler system here.

ItemPickupEvent is fired after the ItemStack is added to the player's inventory with InventoryPlayer#addItemStackToInventory , which sets the ItemStack 's stack size to 0. You'll probably want to subscribe to EntityItemPickupEvent instead, since it's fired before the ItemStack is modified.

BlockWorkbench.InterfaceCraftingTable opens ContainerWorkbench , which overrides Container#canInteractWith to return false if the block at the specified position isn't a Crafting Table. This is called every tick in EntityPlayer#onUpdate , if it returns false the Container and GUIScreen are closed. You'll need to create your own Container that extends ContainerWorkbench and overrides Container#canInteractWith to return true if the player can interact with it (if there's no restrictions, just return true every time) and your own GuiScreen that extends GuiContainer , creates an instance of your Container class and renders like GuiCrafting . Use FML's IGuiHandler system to open your GUI.