Choonster

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.

Minecraft couldn't find your item model or blockstates file. Are you sure they're at src/main/resources/assets/lbm/models/item/blockbeef.json and src/main/resources/assets/lbm/blockstates/blockbeef.json respectively? Post a screenshot of one of these folders in File Explorer with the address bar visible. You should't be registering your models from a common class like ModBlocks or by calling ItemModelMesher#register. Instead, register them from a client-only class called from your client proxy by calling ModelLoader.setCustomModelResourceLocation/setCustomMeshDefinition (these take the same arguments as the two overloads of ItemModelMesher#register). Do this in preInit (if you register your Blocks and Items in preInit) or in ModelRegistryEvent (if you register your Blocks and Items in RegistryEvent.Register [this is the recommended way to register them]). You can read more about the registry events here.

Post the FML log (logs/fml-client-latest.log in the game directory), your JSON files (including their path relative to src/main/resources), the code where you register your models and the code that calls it (back to your @Mod class).

Your file isn't really following the format properly, you're treating the first part of the specifier as the mod name instead of the group ID. I explain each part of the specifier format in more detail here. Instead of Aroma1997s-Dimensional-World:1.9.4:1.2.0.6, use aroma1997:Aroma1997s-Dimensional-World:1.9.4-1.2.0.6. This will be mapped to <repositoryRoot>/aroma1997/Aroma1997s-Dimensional-World/1.9.4-1.2.0.6/Aroma1997s-Dimensional-World-1.9.4-1.2.0.6.jar.

Each specifier must be composed of either three or four parts separated by colons. The parts can contain any other character (that the OS allows in a file name). That exception means that you've got a specifier with less than three parts to it. Could you post the entire FML log and the mod list file that caused that error?

That's correct. Cables and machines acting on adjacent blocks generally use the EnumFacing they're attached to to ensure they get the right inventory, tank, energy storage, etc. If a block has an energy storage that can only be accessed from the bottom, you wouldn't expect a cable attached to the top or side to access it. If there's a block like the furnace that has different slot groups, you wouldn't expect a hopper on the side to put items into the bottom slot group.

Only expose it for the non-null EnumFacings that are appropriate for your block (e.g. only EnumFacing.DOWN), but also expose it for the null EnumFacing so it can be accessed by things that aren't directly interacting with a side of your block. Adjacent blocks like power cables or machines should only use the EnumFacing that they're attached to, they're not likely to use null. That's pretty much all there is to it.

Use IWailaDataAccessor#getTileEntity to get the TileEntity, then use either ICapabilityProvider#getCapability or your own method to get the Tesla/Forge energy storage from it. ICapabilityProvider defines an EnumFacing of null to represent "internal" or "self". Hwyla doesn't interact directly with any specific side of a block, so it uses null as the EnumFacing when getting capabilities. I recommend exposing your capabilities for the null EnumFacing (in addition to any existing non-null EnumFacings) and using this when getting them in the Hwyla HUD handlers.

If all of your energy-using blocks extend a common class or implement a common interface, you can pass this type as the second argument when calling IWailaRegistrar#register[Head/Body/Tail]Provider(IWailaDataProvider, Class). The IWailaDataProvider will be used for any block that extends/implements that type.

You're getting that error because the launcher is passing --modListFile as a JVM argument. On closer inspection, it looks like Mojang's launcher only lets you set the command-line options for the JVM but not for Minecraft. The only way to add command-line arguments for Minecraft seems to be to create a new version and specify them there. If you don't want to do this, you can save your file to one of the paths that FML automatically checks: mods/mod_list.json or mods/<minecraft_version>/mod_list.json.