Choonster

The only method you need to remove is WhiteCoralBlock#getCollisionBoundingBox, though BlockCoral#getCollisionBoundingBox can also be removed because it does the same thing as the super method (i.e. returns the same value as getBoundingBox). Remove WhiteCoralBlock#getCollisionBoundingBox and BlockCoral#getCollisionBoundingBox while leaving BlockCoral#getBoundingBox in place. If this doesn't work, post your new code.

Variants in ModelResourceLocations and blockstates files are simply strings (despite Forge's format providing a way to specify per-property behaviours in any order), they need to match exactly. Minecraft always sorts properties in alphabetical order to form variant strings (unless you provide an IStateMapper that does otherwise) and Forge's blockstates format also performs this sorting for the properties you specify.

Because your model doesn't contain any elements and doesn't extend a model that contains any elements. There's nothing for Minecraft to render. The "parent" attribute is more like the extends keyword, since it specifies the model that the current model should inherit its properties from. Side note: In future, please leave your original question in tact after it's been answered so people with similar issues can see both the question and the answer. Appending the answer to the original post is fine.

When I said "remove the override", I meant "remove the method that overrides this method". Removing the @Override annotation is pointless, since it doesn't actually affect whether or not one method overrides another.

Edit the first post and add [Solved] to the thread title.

Post the latest versions of your three Block classes.

You can separate category names with periods ( . ) when you call Configuration#get to create nested categories, e.g. config.get("general.nested_general", "property_in_nested", 2)

Are you using the @Config annotations or are you using the Configuration class?

Yes, you need to create your own model or extend an existing one.

The Forge documentation explains how to set up a workspace here. It explains some of the basics about Blocks here and Items here. Registering things like Blocks and Items is explained here. If you have any specific questions, you can create a topic in the Modder Support section.

Remove WhiteCoralBlock's override of Block#getCollisionBoundingBox and the AABB returned by CoralBlock#getBoundingBox should be used as the collision bounding box.

That should work, though the AS local variable is pointless. This needs to be in a client-only class that's registered to the Forge event bus (e.g. annotated with @Mod.EventBusSubscriber). When using @Mod.EventBusSubscriber with classes that only exist on one physical side, make sure to pass Side.CLIENT or Side.SERVER to the annotation as appropriate so Forge only loads and registers it on that side.

Now that your Block actually has a property, there are 16 variants that your blockstates file doesn't define a model for. You could define a model for each variant, but there's not much point in this because they'd all be the same. Instead, you should tell Minecraft to ignore the BlockLiquid.LEVEL property when loading models by registering an IStateMapper for your Block in ModelRegistryEvent. The easiest way to create an IStateMapper is by creating a StateMap.Builder, calling StateMap.Builder#ignore to ignore the property and then calling StateMap.Builder#build.

Your model extends from builtin/entity, which means Minecraft expects it to be rendered by a TileEntitySpecialRenderer. Since you don't have one, nothing renders. Ideally you should use a regular baked model for the shield rather than a TESR.

This hasn't changed since 1.8, you need to include the BlockLiquid.LEVEL property in your Block's state (by overriding Block#createBlockState) before you can set the value of it. I have a block that does this, you can see that in both 1.8 and 1.12.2 I override Block#createBlockState.

Use EntityList.getTranslationName to get the unlocalised name of an entity type (rather than an individual entity), you can then translate "entity." + unlocalisedName + ".name". See Entity#getName and ItemMonsterPlacer#getItemStackDisplayName for examples of this.

The MCP Mappings version is completely independent of the Forge MDK version; you can set the mappings property in the minecraft block of build.gradle to change the Mappings version. There's a snapshot version of the MCP Mappings released automatically every day, but Forge rarely updates to new Mappings versions.

You can use CraftingHelper.findFiles to iterate through files in a specific path for a mod and process each one in some way. Forge uses it to load recipes in CraftingHelper.loadRecipes(ModContainer) and advancements in ForgeHooks.loadAdvancements(Map<ResourceLocation, Advancement.Builder>, ModContainer).

If you use the WorldGenMinable(IBlockState, int) constructor, your ore will only generate in the "natural" variants of Blocks.STONE (i.e. Stone, Granite, Diorite or Andesite; but not the Smooth variants). These don't normally generate in the Nether, so your ore won't generate either. To generate your ore in other blocks, you need to use the WorldGenMinable(IBlockState, int, Predicate<IBlockState>) constructor and supply a Predicate that returns true for the block(s) your ore can generate in. Vanilla provides several Predicate<IBlockState> implementations in the net.minecraft.block.state.pattern package, you can also specify your own using a lambda or method reference.

As I discovered in this topic, you need to set Block#useNeighborBrightness to true. For some reason, Vanilla does this in Block.registerBlocks instead of in the constructors of the appropriate Block classes.

I've encountered a similar issue again while testing a PR. When attempting to run the Minecraft client from the Forge development environment with either JEI or TestMod3 in the mods directory, the game crashes with a ClassNotFoundException for a class that definitely exists in the corresponding mod JAR. This doesn't happen outside of the Forge development environment (neither in my TestMod3 development environment nor when launching Minecraft from the Mojang launcher). This was tested using Forge 1.12.2-14.23.2.2619 (commit 49be9b2) with JEI 1.12.2-4.8.5.147 and TestMod3 1.12.2-5.1-2ce586d (in separate runs). You can view the FML logs from these runs here. Does anyone have any idea why this would happen or how to fix it?

Use the eye icon in the post editor. Delete the FML log and then run the server again, making sure to use Java 8. If it still crashes, post the new FML log.

The sub-events of PlayerInteractEvent are fired when the player interacts with the world in various ways; you should be able to subscribe to the individual sub-events and cancel them when this mode is active.

That wasn't in a spoiler or on Gist. There's no error in that log, because you're running the server with Java 8. Your original crash was caused by running the server with Java 9.

You're using Java 9, which isn't supported by Forge. You need to use Java 8 instead. In future, post the FML log (fml-server-latest.log in the server directory) in a spoiler or on Gist.