Choonster

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.

There's currently no way to specify custom config GUI entries for properties created through the annotation-based config system without reflecting the Configuration instance from ConfigManager and calling Property#setConfigEntryClass manually. Could an annotation be added that allows a custom Property.Type or IConfigEntry class to be specified for the generated Property? On a related note, it's currently not possible to use GuiConfigEntries.BooleanEntry, GuiConfigEntries.CycleValueEntry or GuiConfigEntries.ChatColorEntry with Property#setConfigEntryClass because their constructors aren't public. Attempting to do so throws a NoSuchMethodException for the constructor when the config GUI is opened. It's also not possible to extend these and add a public constructor, since the constructors are private or package-private. Edit: Reported this on GitHub here.

Something was null on line 82 of CSBR (in the preInit method). If line 82 is the Property#setConfigEntryClass call, the Property is null. This is probably because you renamed it with @Config.Name, so it's not called animation. No. You want a single value chosen from a fixed set, so use an enum. If you wanted an arbitrary number of Strings, you'd use a String array. I've just discovered that Property#setConfigEntryClass doesn't actually work with GuiConfigEntries.ChatColorEntry because the constructor isn't public. I'll report this shortly, so hopefully it will be fixed. I've reported this here.

Why are you using an indexed for loop? Use a for-each/enhanced for loop like you were before, but iterate through the returned List directly instead of creating a new one. Each call to ConfigCategory#getOrderedValues creates a new copy of the List, so you should call it once and store the result in a local variable rather than calling it every iteration of the loop. You'd need to implement this yourself, I can't really help you with much GUI-related stuff. Using ChatColorEntry is probably easier.

You don't need to create a new List, ConfigCategory#getOrderedValues already returns a List; just iterate through it directly.