Choonster

Your IStateMapper implementation only specifies a model for the default state, but not for any of the other states. It's probably easiest to extend StateMapperBase, this will call StateMapperBase#getModelResourceLocation for each state of the Block. All you need to do is return the same ModelResourceLocation from this method every time, ignoring the FACING property.

That's the crash report, not the FML log. As I said previously, the FML log is the logs/fml-client-latest.log file in the game directory. Did you select the correct Forge version in the launcher profile? Post the full FML log (the actual FML log, not a different log or a crash report) from a session where this happens.

Ah, I forgot that they're different instances rather than states of the same instance. You can still use Forge's blockstates format, you'll just need to create a blockstates file for every colour (or register an IStateMapper to map them to variants of the same blockstates file).

In future, please post the entire FML log. The snippets you posted appear to be from a different log. You appear to be running FML without Forge, but your mod uses at least one class from Forge (and using FML by itself isn't supported). Forge includes FML, so use Forge. You should be able to download a 1.8 version of Forge from the main Files site.

You don't need to create 16 models if you create an empty model and use Forge's blockstates format to specify the "particle" texture for each state.

Scala is likely to be removed at some point in the future, so Forge probably won't be including newer versions of it.

Vanilla hardcodes this for shulker boxes in BlockModelShapes#getTexture, but I think you'll need to create a model without any elements that specifies the "particle" texture and use it instead of registering an IStateMapper to ignore all states.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin. How exactly did you build you mod?

You can see some examples in my mod's init classes.

Minecraft calls BlockModelShapes#registerBuiltInBlocks for the shulker box Blocks, which means that BlockStateMapper#getBlockstateLocations and BlockStateMapper#getVariants return an empty Set/Map respectively when called with one of the Blocks. You can achieve the same result by implementing IStateMapper#putStateModelLocations to return an empty Map (using Collections.emptyMap) and registering an instance in ModelRegistryEvent using ModelLoader.setCustomStateMapper.

You're checking if the Block is both replaceable and is equal to Blocks.GRASS, which will never be true because Blocks.GRASS isn't replaceable. You can use the && (and) operator to combine multiple boolean expressions (like the conditions of the four if statements) into one. Don't call World#getBiomeForCoordsBody directly, call World#getBiomeForCoords instead. This allows the WorldProvider to return the appropriate Biome (this may or may not call World#getBiomeForCoordsBody). Don't compare to Blocks.AIR directly, use Block#isAir to support modded air-like blocks.

You needed to change the blockstates file and the model, not the registration class. RegUt.registerBlocks and RegUt.regItems are broken since they only register the Blocks/Items on the physical client, but this needs to happen on both physical sides. Model registration must be done in a separate client-only class to avoid crashing the dedicated server. You should be using registry events instead of registering things in preInit. GameRegistry.register is no longer accessible in 1.12, so this will make it easier to update. The log you linked isn't the FML log.

Items load their models from either an item model file (the normal location) or a variant of a blockstates file (the blockstate location). You need to provide at least one model for every item. That's correct. Display transformations are rotation, translation and scale operations applied to the model when it's rendered as an item in various contexts (e.g. left/right hand, GUI, item entity, etc.).

You need to include your mod ID as the domain of the model and texture paths, i.e. "<modid>:<model_name>" and "<modid>:<texture_path>". Textures need to in PNG format, not JPEG. Is the block called fooblock or memeblock? Your files are apparently called fooblock, but the blockstates file uses the memeblock.json model and the model uses the memeblock.png texture. In future, the FML log (logs/fml-client-latest.log in the game directory) will tell you why models/textures failed to load. If you don't know how to interpret the errors, post the full log using Gist or Pastebin when asking for help.

Override Block#getDrops to do the following: Write the TileEntity to NBT. Create the ItemStack that will be dropped. Set the "BlockEntityTag" key of the ItemStack's compound tag to the compound tag containing the TileEntity data. Add the ItemStack to the drops list. The TileEntity is normally removed from the world before Block#getDrops is called, so you need to delay its removal by overriding BlockFlowerPot#removedByPlayer and BlockFlowerPot#harvestBlock. See Forge's patch to BlockFlowerPot for an example of this. When an ItemBlock (or ItemBlockSpecial) is placed by a player and the ItemStack has a compound tag at the "BlockEntityTag" key, it will automatically call TileEntity#readFromNBT with the compound tag (unless TileEntity#onlyOpsCanSetNbt returns true and the player isn't an op).

Which version of Forge are you using? Post your code and the full stacktrace of the exception.

The recipe registry (unlike other registries) is modifiable, so you can actually remove a recipe using IForgeRegistryModifiable#remove. Any advancement that rewards the recipe will throw a syntax exception (spamming the log) if you do this, though.

You need to have a solid understanding of Java before making a mod. As it says in this section's description, we're not here to help with basic Java problems. Java has a tutorial on parameters here.

Do you know what a parameter is? This is a basic Java concept.

The logging of missing models was broken in Forge 1.12-14.21.0.2363 (commit dc043ac) and fixed in Forge 1.12-14.21.1.2390 (commit ede05a2). After updating Forge, it was easy to identify the issues with the turret blockstates file: You were using strings instead of integers for the x and y rotations. The first variant was misspelled (facung=up rather than facing=up). The first variant has an invalid block/ prefix in its model location. Some other issues I noticed: There's no item model for the turret in the repository. IanusIncHq uses Java's Logger instead of log4j's (which is what Minecraft uses). CustomBlock has a missing semicolon. The turret and small super condensator models extend minecraft:block/cube_all but override its elements and don't specify the all texture. They should extend minecraft:block/block instead, since it provides the standard display transformations without providing any elements. The other non-cube models don't extend any model and don't specify any display transformations, they should extend minecraft:block/block. I've fixed these issues and pushed the changes to GitHub. You can view and/or merge the changes here.

It was renamed to Biome in 1.9.

Edit the first post of a thread and you'll be able to edit the thread title, including adding [SOLVED] to it. There's no actual mechanism for marking threads as solved, it's just editing the title.

That's not the case.

Which Minecraft version are you using? I'm guessing you're using a version where Block#isOpaqueCube has an IBlockState parameter, which your isOpaqueCube method doesn't. Always annotate override methods with @Override so you get a compilation error when they don't actually override a super method. You should also use your IDE to auto-generate override methods with the correct signature and annotation. In future, please post code using a code block (the <> icon) or on Gist/Pastebin.

I've submitted an issue for this here. Being able to override an object from your own mod doesn't make much sense, so it should crash with a more obvious exception when you attempt to do so.