Choonster

I'm not sure exactly what your issue is, but I do see some potential problems in your code: Render classes are generic in 1.8.8+, so don't use raw types ( RenderTerrakon should extend RenderLiving<EntityTerrakon> instead of RenderLiving ) Always use the @Override annotation on override methods

You can tell Gradle to compile your code with Java 8 compatibility by adding these two lines to build.gradle. You may still need to set the compatibility level of your IDE project manually. Compiling a mod with Java 8 compatibility shouldn't interfere with any other mods.

It looks like a Pneumatic Tube is throwing an error while trying to insert into a Buffer. I suggest you report this to the BluePower author(s). In the meantime, either restore from a backup or use something like MCEdit/NBTExplorer to remove the Multipart block (containing a Pneumatic Tube) at 833, 60, -262.

I suggest looking at Forge's patch to EntityFishHook#getFishingResult to see how it uses the Lure and Luck of the Sea enchantment levels to determine which loot category to select from.

Try overriding TileEntitySpecialRenderer#func_181055_a ( isGlobal in 1.9) to return true like TileEntityBeaconRenderer does.

I never told you to use the assignment ( = ) operator or create a new ItemStack . To check the Item and metadata of an ItemStack , you need to do three things: Check that the ItemStack isn't null Check that the return value of ItemStack#getItem is equal to ( == ) the right Item Check that the return value of ItemStack#getMetadata is equal to ( == ) the right metadata Do not call either overload of Item#getMetadata yourself. Item#getMetadata(int) is used to determine the block metadata to place, Item#getMetadata(ItemStack) is used by ItemStack#getMetadata to determine the stack's metadata.

Looking at TileEntityBeaconRenderer , I think you need to override TileEntitySpecialRenderer#isGlobalRenderer to return true .

If an inventory slot is empty, IInventory#getStackInSlot will return null . You need to check that the returned ItemStack isn't null before you can safely call methods on it.

Dependencies are never shaded (included in your JAR) by default, you always need to specify that they should be. For CodeChickenLib, I'd recommend have it auto-download like ChickenBones does: Include the DepLoader class from CodeChickenCore in your code, call it from an IFMLLoadingPlugin specified in your manifest and include a dependencies.info file that specifies CodeChickenLib as a dependency. For examples, search GitHub for DepLoader and limit the search to Java code. For Mantle, don't shade it all. Tinkers' Construct doesn't include it, neither should you. For MySQL Connector, you can shade it using this technique or using a proper shading plugin like shadow.

IChatComponent became ITextComponent , ChatComponentText became TextComponentString . Every other ChatComponent was also renamed to TextComponent .

This is a basic Java error. == checks reference equality, i.e. whether the operands are the same object. An ItemStack from an inventory will never be the same object as an ItemStack you just created. Some classes override Object#equals to check value equality, i.e. whether the two operands represent the same value. ItemStack does not do this, so itemStack1.equals(itemStack2) still checks reference equality. You need to get the Item and metadata from the ItemStack using the appropriate getter methods and compare those to the values you want to check. If you already had two ItemStack s and wanted to check if they were equal, the ItemStack class provides several static and non-static methods to check various forms of equality (e.g. Item and metadata; Item , metadata and NBT). In general, you shouldn't call these if you have to create the second ItemStack at the time of the call. Don't bump your threads. It will only annoy the people who can help you, it won't hasten their response.

Skulls are rendered using TileEntitySkullRenderer both as blocks in the world and items in inventories. This uses the texture of the skull's entity type, so overriding that with a resource pack should change the texture of the entity and its skull. How did you manage to change the model and texture of the block form but not the item form?

The bug being mentioned is this one, which states that chests opening with slabs, stairs, etc over them is a bug. And while Mojang says its not a bug, Lex, not wanting to do more coding work than needed, is deciding to treat it as a bug. So this means Forge will continue to make it so chests cannot be opened when slabs, stairs, etc are over them. But as Lex mentioned in this thread, chests are only supposed to check if the bottom of the block is solid. Placing a slab in the upper half of a block or upside-down stairs shouldn't prevent chests from opening.

I believe this is intentional, see this thread and the threads linked in it.

MCP data from ForgeGradle 2.x (Minecraft 1.8+) workspaces can be found in ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mappings_channel>/<mappings_version> (replace ~ with %USERPROFILE% on Windows).

Yes. It's a JSON file, so it needs to be valid JSON syntax. I can't see your file, so all I can tell is what the error message tells me: It found a string where it expected the start of an array. JSONList and similar tools can probably tell you where you went wrong.

Your mcmod.info file has a syntax error. ItemAxe doesn't yet support custom ToolMaterial s because it uses the ToolMaterial 's ordinal as an index for the ATTACK_DAMAGES / ATTACK_SPEEDS arrays. See this thread where someone had the same problem. Either create a custom axe class or wait for someone to fix the issue. Don't bump your threads, it will only annoy the people who can help you. It's unlikely to speed up their response.

Screenshots are a terrible way to share code and the screenshot of the console cuts off part of the crash report that we need to see: the actual exception that was thrown. Upload your full FML log (logs/fml-client-latest.log) and code with syntax highlighting to Gist and link it here.

You're using Forge 10.13.3.1388, but CoFHCore requires Forge 10.13.3.1448 or newer. Update to the latest version of Forge for 1.7.10.

Upload logs/fml-client-latest.log from your game directory to Gist and link it here.

LivingHurtEvent is fired on the Forge event bus ( MinecraftFroge.EVENT_BUS ) rather than the FML event bus ( FMLCommonHandler.instance().bus() ). Read the documentation for the classes you use. You should also specify which version of Minecraft you're using in the title of your thread.

Forge's Item#getModel method that was previously used for things like bow pulling models has now been replaced with item properties that can be queried from item models. I'm in the process of updating TestMod3 to 1.9, I'll probably know more about this when I finish updating my bow items. Mod spawn eggs are currently broken in 1.9, diesieben07 has opened a pull request to fix them.

If none of your assets are working in the development environment but they're in the built JAR when you run the build task, add this to your build.gradle: // Fix resources not being loaded in IDEA // http://www.minecraftforge.net/forum/index.php/topic,32467.msg169687.html#msg169687 idea.module.inheritOutputDirs = true This code is only for 1.7.10 and earlier. This is built in to ForgeGradle for 1.8+. Side note: Why are you using 1.7.10?

build/libs in your mod's directory.

It may or may not be the source of the issue, but packet handlers are run on a separate thread where you can't safely interact with normal Minecraft classes. You need to schedule a task to run on the main thread, as explained here.