Choonster

The error is coming from Tinkers' Construct, report it to the authors.

You have a lot of syntax errors in your JSON files. Fix some of these and you'll start to see the additional 55 errors that FML suppressed.

That's essentially what diesieben07 told you to do, except you're using the vanilla method instead of the Forge method.

I'd recommend using a list of compound tags, each one containing a key-value pair.

Are you using 1.8 like you original log says you are, or are you using 1.7.10 like the new log says you are? 1.7.10 is no longer supported on this forum.

The second argument of NBTTagCompound#getTagList is the type ID of the tags contained in the list. Use the IDs from the Constants.NBT class. For a list of compound tags, pass Constants.NBT.TAG_COMPOUND as the second argument.

Use NBTTagList#tagCount to get the number of tags in the list and NBTTagList#getCompoundTagAt to get the compound tag at the specified index of the list. There are several other specialised NBTTagList#get[Type]At methods that return the number/array/string at the specified index and a general-purpose NBTTagList#get method that returns the NBTBase at the specified index.

UUID.randomUUID

There is no existing UUID for a Knockback Resistance potion's AttributeModifier because there is no existing Knockback Resistance potion. Just generate a new UUID once and use that.

I've forked your repository and pushed the fixes for the issues I mentioned. You can view and/or merge these changes here.

I cloned your repository to debug this locally, but I encountered an issue: You're manually adding the Tesla and JEI JARs in the libs directory as dependencies, but your repository doesn't include these files. You should prefer using Maven/Ivy dependencies as these will be automatically downloaded by Gradle when setting up the workspace. JEI's Developer Wiki explains how to add it as a Maven dependency here, Tesla's readme explains how to do this here. After fixing this, I narrowed down the source of your problem. The issue is that you're calling ModelLoader.setCustomStateMapper for your fluid Blocks before they've been registered, which ModelLoader doesn't support. You need to call it after they've been registered. In general, it's not entirely safe to pass around a Block or any other IForgeRegistryEntry before it's been registered. The technical explanation is that ModelLoader stores the registered IStateMappers in a HashMap<RegistryDelegate<Block>, IStateMapper>. HashMap uses Object#hashCode and Object#equals to determine if two keys are equal and RegistryDelegate.Delegate implements these using its name field, which is only set when an IForgeRegistryEntry.Impl instance (e.g. a Block) is registered. Before registration, all RegistryDelegates are equal to each other. When you call ModelLoader.setCustomStateMapper with a Block that hasn't been registered, the IStateMapper is stored in the HashMap with a null-named RegistryDelegate as the key. When you call it again with another unregistered Block, the HashMap considers the two null-named RegistryDelegates to be the same key, so it replaces the old IStateMapper value with the new one. When you call ModelLoader.setCustomStateMapper with a Block that has been registered, its RegistryDelegate will have a unique name (the Block's registry name) and be considered a distinct key in the HashMap from any other Block's RegistryDelegate.

The console editions of Minecraft use a completely separate codebase to the desktop edition. In addition to this, it's either impossible or very difficult to mod games on consoles. These two factors mean that it's extremely unlikely that Forge (and Forge mods) will be ported to any of the other editions of Minecraft.

It's very difficult to read the log you posted, please upload the full log (logs/fml-client-latest.log) to Gist or Pastebin and then link it here.

Post the FML log, it should say why the fluid blocks don't have a model.

I explain how to use nullability annotations to help avoid null ItemStacks here.

The doc comment for Block#isWood says that it returns "true if the block is wood (logs)", it's not meant to check for other types of wooden blocks. The name could probably be clearer, though.

You shouldn't be using or implementing IInventory or storing ItemStacks in arrays, create an IItemHandler field for each of the TileEntity's inventories and expose them using the Capability system. If you just need a temporary collection of ItemStacks without a formal inventory, use a NonNullList (created by calling NonNullList#withSize with ItemStack.EMPTY as the second argument) instead of an array. This will help to eliminate any potential null ItemStacks.

There are methods in the Block class for exactly this purpose: Block#isLeaves and Block#isWood. These return true if the block is leaves or a log, respectively. The right-hand operand of instanceof must be a type, but Blocks.LOG and Blocks.LOG2 aren't types, they're values. This is basic Java knowledge. Blocks.LOG is an instance of the BlockOldLog type and Blocks.LOG2 is an instance of the BlockNewLog type, these both extend BlockLog.

Somehow the InventoryCraftResult#stackResult NonNullList has an instance of Arrays.ArrayList as its delegate list but null as its default element. This shouldn't be possible unless the protected NonNullList(List<E>, E) constructor was called directly rather than being called through NonNullList#create or NonNullList#withSize. Does ContainerHunterBench use the vanilla InventoryCraftResult class? Post the ContainerHunterBench, TileEntityHunterBench and InventoryCraftResult (if it's your own) classes.

It's in the Minecraft JAR. Forge doesn't allow this texture to be replaced by resource packs.

Did you set a condition for the breakpoint like I said? If you did, it should only trigger when you right click on the block to open the GUI. That's not the field I told you to look at. It's normal for that field to be null. It is valid, though not normally needed. That snippet of code is from vanilla, not the OP's mod.

You still have a null ItemStack somewhere in the inventory used by the Container. To narrow it down, set a breakpoint inside the for loop Container#getInventory with the condition inventorySlots.get(i).getStack() == null (i.e. the Slot's ItemStack is null). When the breakpoint is hit, look at the Slot's inventory (Slot#inventory or SlotItemHandler#itemHandler) and index (Slot#slotIndex) to see which inventory slot contains the null ItemStack. Once you know where the null ItemStack is, you can figure out where that slot is set from and why it's being set to null. To help avoid errors like this, annotate any ItemStack return value or parameter with @Nonnull. Your IDE will warn you when you return a nullable value from a @Nonnull method or pass a nullable value to a @Nonnull parameter. If you copy the package-info.java file from a vanilla package into your own packages, the @MethodsReturnNonnullByDefault and @ParametersAreNonnullByDefault annotations will tell your IDE that the methods and parameters in that package are @Nonnull by default. Use @Nullable if a method can return or accept null values.

This exception is thrown when GuiContainer tries to render a Slot with a null ItemStack in it. MHFCCraftingManager is still using null ItemStacks in several places, you need to fix this.

MHFCCraftingManager#findMatchingRecipe is returning null (presumably because there's no matching recipe), which is no longer a valid value for an ItemStack. Instead of returning null, return ItemStack.EMPTY.

You're calling IInventory#setInventorySlotContents with a null value (returned by MHFCCraftingManager#findMatchingRecipe), which is invalid. ItemStacks can no longer be null in 1.11.x, the default value is now the empty ItemStack (i.e. any ItemStack that returns true from ItemStack#isEmpty). The ItemStack.EMPTY field contains an ItemStack that's always empty.