Choonster

You need to tell Forge to only load and register the class on a specific side by passing a Side argument to the @EventBusSubscriber annotation. You can see an example of this here.

Gradle ran out of memory, you need to give it more.

Your post is unreadable on the dark theme, you should use the Tx button to remove the formatting from it. You need to tell ForgeGradle to reobfuscate the shadow JAR, you can see how I do this here.

Does this happen without OptiFine?

I'm not going to write the code for you. Was there a specific part you didn't understand?

Check if the event's IChunkGenerator is an instance of ChunkGeneratorOverworld, then use reflection to access the ChunkGeneratorOverworld#settings field.

Since all of these fields are final, you'll probably need to use the registry override system to replace the Vanilla biomes with your own. Create an instance of the appropriate Biome class (e.g. BiomePlains) with a BiomeProperties that has the desired properties, set its registry name to the same as the Vanilla one (e.g. minecraft:plains) and then register it with IForgeRegistry#register. Since there's already a Biome registered for that name, your instance will override the Vanilla one. Do this in RegistryEvent.Register<Biome>.

The debug info overlay is rendered by GuiOverlayDebug and GuiIngameForge.GuiOverlayDebugForge.

Then you can look for the MCP mapping CSV files in the Gradle cache (~/.gradle or %USERPROFILE%\.gradle); these map SRG names to MCP names. I don't have the full path with me, but look for de/oceanlabs/mcp.

Those are SRG (obfuscated) names. You can use MCPBot to find the corresponding MCP (deobfuscated) names.

Which version of Minecraft are you using? EnumFacing.getDirectionFromEntityLiving was added in 1.11; in 1.10.2 and earlier the equivalent method was BlockPistonBase.getFacingFromEntity. When you want to implement a feature (e.g. set a block's facing based on the placer), you should look for places in the Vanilla or Forge code where similar features are implemented (e.g. pistons).

Open the EnumFacing enum in your IDE and look for the method with the parameters and return type that matches EnumFacing.getDirectionFromEntityLiving. What is its name?

I don't think this is possible. There was a PR to add support for this, but it was never merged because it was so large.

This is incorrect. Despite the name, the method actually has a EntityLivingBase parameter. If you look at the EnumFacing enum in your IDE, what's the name of the method that takes a BlockPos and EntityLivingBase and returns an EnumFacing? It should be one of the last methods, just before the static initialiser block and the start of the EnumFacing.Axis enum. MCPBot tells me that the method is known by its SRG name (func_190914_a) in older MCP mappings.

Forge's registries are already stored in the ForgeRegistries class and you can use GameRegistry.findRegistry to find any other registry. There's no need to store the registry from the registry event for later use.

If you look at the CommandLocate class in your IDE, you'll see that it is.

You're using Java 9, which isn't supported by Forge. You need to use Java 8 instead.

You're using Java 9, which isn't supported by Forge. You need to use Java 8 instead.

Use the TX button (fifth from the right) to clear formatting or use Ctrl-Shift-V to paste as plain text.

You probably could do that. Depending on exactly how your mod works, it may be easier to simply maintain a list of block positions and search that.

It's overridden in WorldServer to call ChunkProviderServer#getNearestStructurePos, which in turn calls IChunkGenerator#getNearestStructurePos. ChunkGeneratorOverworld implements this to look for a hardcoded set of Vanilla structure types, so there's no good way for mods to hook into it. This PR aims to resolve that.

Advancements and other server-side files aren't loaded from resource packs, which are client-only. 1.13 will allow loading of advancements from data packs.

Unlocalised names are controlled by the Item class and translations of those are specified in the lang files, there's no JSON involved. If your variants were displaying their names correctly in 1.11.2, they should still do so in 1.12.2 unless you've changed something. Post your Item class, the class where you register your Items and your en_us.lang file.

It could be useful in some circumstances, but I'm not sure how many people would actually need it. It probably wouldn't hurt to open an issue/PR, the worst that can happen is that it's closed because Lex/mezz don't see a wide use for it.

Then I think the least hackish way to handle this would probably be adding the condition to your recipes. If you really don't want to do that, you could probably integrate with JEI to hide your uncraftable recipes.