Choonster

The version of BoP you're using hasn't been updated to the recommended build of Forge and is still using the old names of some classes. This was fixed in BoP 1.12-7.0.0.2279, so update to the latest version.

It looks like this is a known issue.

Yes, you'll almost certainly need to update to a 1.12 mappings version. You can find the latest mappings on the MCPBot website.

You need to update ForgeGradle to 2.3 to use Minecraft 1.12.

Open the game directory by selecting your profile in the "Launch options" tab of the launcher and then clicking the "Go to folder" button next to the "Game directory" option. Open the logs directory in the game directory. Find the fml-client-latest.log file. Upload it to Gist or Pastebin and link it here.

If you want the mob to spawn in every single biome rather than biomes of a certain type, use IForgeRegistry#getValues to get a List of every registered Biome. You then need to convert this to an array and pass it as the vararg parameter of EntityRegistry.addSpawn.

I don't think you can get the full help list at once, but you can run the /help command once for each help page and copy the output from the log (logs/fml-client-latest.log in the game directory).

No, the ForgeRegistries class was first added in 1.9 and the Biome registry has been in it since then.

All of the registries for vanilla types are stored in the ForgeRegistries class. As @Jacky2611 said, use the BiomeDictionary (specifically BiomeDictionary#getBiomes) to get the Biomes with the specified Type.

You need to use the registry name of the item, which is in the format <modid>:<name>. You can view this in-game by enabling advanced tooltips with F3 + H. A copper ingot is ic2:ingot with metadata 2.

It's not required, but it's easier than manually registering the event handler. In 1.12, registry events are fired between preInit and init rather than before preInit as they were in 1.10.2-1.11.2.

Forge will automatically load every recipe file in the recipes directory, but you can use conditions to enable/disable them as they're loaded. Set the "conditions" property to an array containing the conditions. Each condition is an object with the "type" property specifying the condition type and any other properties required by the condition type. You can see the Forge-provided conditions in CraftingHelper.init (the CraftingHelper.registerC calls). For custom conditions, implement IConditionFactory and specify the condition type and class name in _factories.json.

You can if you extend ItemBlock and register an instance of that class. You don't have to use ItemBlock directly.

It's a text file with the same name as the installer in the same directory.

There is no "server" version of Forge, only the universal version that works on both the client and the dedicated server. This also works as the host of a LAN game. The only difference between the client and server options in the Forge installer is how they're installed: The client is installed in a way that allows the launcher to use that version of Forge and download the required libraries, the server is downloaded directly into a folder with the vanilla server JAR and the required libraries. The same version of Forge is installed in both cases.

Post the full FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

Use ModelLoader.setCustomModelResourceLocation/setCustomMeshDefinition as before, but do it in ModelRegistryEvent instead of preInit.

That looks correct, yes.

It looks like you'd need to create your own IConfigEntry with similar behaviour to BooleanEntry but different display text or use an enum value instead of a boolean.

Your recipe is structured incorrectly, this has nothing to do with ore dictionary ingredients (which can be mixed with any other ingredient types). Shaped recipes require the value of the "key" property to be an object with the characters from the pattern as keys and the ingredients as values. You have this inside the "ingredients" array property, which isn't used by shaped recipes. Look at vanilla shaped recipes for examples or at the CraftingHelper.init method to see how the factory for each recipe type is defined.

The substitution alias system was replaced by the override system with the registry overhaul in 1.12.

Forge will automatically try to load the model you've specified for an Item from a blockstates file when it can't find an item model with that name. I have a more detailed description of the model loading process and how ModelResourceLocations are mapped to models here. Are you sure you have a blockstates file called assets/test_mod/blockstates/item_variants.json with the variants test_mod:item_variants_a, test_mod:item_variants_b and test_mod:item_variants_c? Variants don't usually have a domain, they're just a single string. Post your blockstates file and its path.

Item#getSubItems is now called for every Item on every creative tab, you need to call Item#isInCreativeTab and only add the items to the list if it returns true. It's also no longer a client-only method, you should remove the @SideOnly annotation from it.

If you use the values from ModConfig directly, you don't need to worry about when to copy them to the other fields; they'll always be up-to-date. If you really need to use separate fields, copy the values in preInit and when ConfigChangedEvent.OnConfigChangedEvent is fired for your mod (after calling ConfigManager.sync). These should be the only times the values are changed by code outside of your mod.

ConfigManager.sync will apply the changes made in the Configuration by the GUI to the fields of ModConfig, so you should call it before changing the depth buffer setting.