Choonster

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.

I'm not going to write your code for you. I've told you exactly which methods to override and call and in what order, you just need to translate that into code. If there's a specific part of my post that you didn't understand, I can try to explain it further.

You'll need to be more specific. Which part didn't you understand?

That should work, yes. You can also use ConfigCategory#getValues to get an immutable copy of the category's property names and properties (and use Map#getValues to get a collection of the Map's values) or ConfigCategory#getOrderedValues to get an ordered immutable copy of the category's properties.

Use the container item system for this, not ItemCraftedEvent. If the sandpaper is returned to the player without change, call Item#setContainerItem with this as the argument in the sandpaper Item's constructor to set it as its own container item. If the sandpaper is changed (e.g. damaged) by the crafting, override Item#getContainerItem(ItemStack) to copy its argument (ItemStack#copy), damage the copy (ItemStack#attemptDamageItem) and return the copy.

You'll need to call Property#setConfigEntryClass on each of those Property objects, yes.

Call Property#setConfigEntryClass with NumberSliderEntry.class as the argument.

That looks correct, yes.

Yes. Forge uses your category names in a regular expression (for String#replaceFirst), so they can't contain any characters that have a special meaning in regular expressions (e.g parentheses).

The actual ore dictionary matching has moved to OreIngredient (forge:ore_dict in JSON), which you can use as an Ingredient in any Vanilla or Forge recipe class. You can create and register recipes in code if you want, but moving to the JSON system is recommended.

Because there's no class with that name. Use World Capabilities or World Saved Data. If you want more help with this, create a new thread. The Item.ToolMaterial and ItemArmor.ArmorMaterial enums control the stats of tools and armour, respectively.

To open a class by name, use Navigate > Class (Ctrl-N) in IDEA or Navigate > Go To > Type... in Eclipse. This will avoid manually searching or asking for the fully qualified name.

There's no method in Item called useItemRightClick, so your method doesn't override anything and is never called. You shouldn't be storing an ItemStack in your Item class, the ItemStack will be provided to most Item methods you override. Always annotate override methods with @Override so you get a compilation error if they don't actually override a super methods. You should use your IDE to auto-generate override methods with the correct signature and annotation. In this case, you'll want to override Item#onItemRightClick and use ICommandManager#executeCommand to execute the command. Use MinecraftServer#getCommandManager to get the server's ICommandManager instance and use World#getMinecraftServer to get the MinecraftServer instance. You should only do all of this on the logical server (when World#isRemote is false).

The full path of the category, not the full path of the field that was used to create it. The default top-level category is general and the frame category is in that, so use "general.frame".

The FML log is the logs/fml-client-latest.log file in the Minecraft game directory.

The Configuration object contains the properties and categories created by Forge from your @Config class. You need it to get the Property so you can set NumberSliderEntry as its config GUI entry type (i.e. use a slider for that property in the config GUI). You get the Property by calling these methods: