Choonster

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.

If the recipe is for your custom crafting table, does that mean you're calling CraftingHelper.findFiles yourself to load the recipes? If so, you could check that the recipe's output is non-empty between loading and registering it.

Use the minecraft:item_exists recipe condition to prevent a recipe from being registered if an Item doesn't exist.

I don't think that's the right part of the log. The section you're looking for will start with this line (the first thing logged by the version checker Thread when it starts the check for a mod): [screenshotuploader] Starting version check at http://darkeyedragon.me/mods/updates/screenshotuploader.json Could you please post the whole log using Gist?

Judging by the log output you posted, it looks like an exception was thrown while processing your mod's version check. The version checker (the Thread created in ForgeVersion#startVersionCheck) logs the received version check data and any thrown exception at the DEBUG level, which is only visible in the FML log and not in the IDE's output window. The FML log will probably tell you what's going wrong.