Choonster

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.

You could copy CycleValueEntry (since you can't extend it) and override CycleValueEntry#valueButtonPressed and CycleValueEntry#setToDefault to call the super methods and then modify the Depth Buffer setting. I'm not sure exactly how you'd do this, you'd need to work this out yourself.

Forge is documented by the community, you can submit a Pull Request here to add/modify documentation. I think you'd need to make your own IConfigEntry for this. If the Depth Buffer setting is solely controlled by the Break Animation setting, is there any reason to have it user-configurable at all?

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). Update Forge and run Minecraft again to see the model errors.

Forge's blockstates format only allows you to specify the effects of individual property values or fully-defined variants, you can't specify the effects of a subset of properties (e.g. two of three properties). You also can't specify the x and y rotation separately, if you specify one then the other will be 0 for that variant. You could use an IStateMapper to have a different blockstates file for each value of one of the properties or use Vanilla's multipart blockstates format; but I think you may be best off with a single Forge blockstates file with fully-defined variants.