Choonster

The latest log is the one we want. Always post it when you have an issue. I recommend uploading the log to Gist and linking it here rather than including it in your post. You're running Minecraft 1.8, but Better Sprinting requires 1.8.8.

That message just means that Microsoft Edge won't run websites that use the Java plugin. You can still download and install Java to run Java applications like Minecraft.

Microsoft Edge is a web browser and has nothing to do with Forge. This wiki page explains how to install Forge.

You can register models in init using the overloads of ItemModelMesher#register , yes.

The RenderItem instance is created between preInit and init, so you can't use it in preInit. To register models in preInit, use ModelLoader.setCustomModelResourceLocation and ModelLoader.setCustomMeshDefinition .

You installed FML by itself. FML has been merged into Forge itself, so remove FML and just install Forge from files.minecraftforge.net.

All recent versions of Forge support Java 8 without issue, only 1.7.2 versions and old 1.6.4 versions don't (1.6.4-9.11.1.1345 fixed the Java 8 incompatibility). If it's not working for you, upload your FML log to Gist or Pastebin and link it here.

You have a few problems: Your item textures are in textures/item instead of textures/item. You're registering your models in init. ModelLoader.setCustomMeshDefinition only works if called before init. You're returning a ModelResourceLocation with the default "normal" variant from your Deadmau5MeshDefinition , but the builtin/generated model only provides the "inventory" variant. I've forked your mod on GitHub and fixed these problems. You can see what I changed and/or merge the changes here.

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]