Leaderboard

And even then, only if the changes in the coremod can not be properly exposed in a non-mod-specific way and PRed to Forge. 99.99% of mods don't need a coremod. 99% of coremods SHOULD be at least attempted to be put into Forge. But most people fail the basic concept of having to explain themselves. 1% Of Coremods are actually doing something useful that is wholey specific for their mods and thus wouldn't fit in the Forge ecosystem. Those mods usually are total conversion or don';t play well in modpacks.

The CSV files can also be downloaded from http://export.mcpbot.bspk.rs/ I also find https://github.com/bspkrs/MCPMappingViewer very handy - a Java-based GUI to search for MCP symbols. As for the changes in KeyBinding, there's no simple solution there other than to study the KeyBinding class in 1.8 and 1.12.2 and work out why the keybinds changed from a list to a map. It's almost certain that the mod's code will need to be adjusted in some way to account for it, although if the mod was simply using it to iterate over, it might be a fairly simple change.

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.

Each field in the @Config class is mapped to either a configuration category or a configuration property depending on its type. If it's a type that implements Map, a category is created and a property is created in that category for each key-value pair in the Map. The Map must have String keys and primitive, primitive array, String or enum values. If it's a type that directly extends Object, a category is created and a sub-category or property is created in that category for each field of the class following the same rules as the @Config class. These classes can be declared anywhere, they don't have be nested in the @Config class. If it's a primitive, primitive array, enum or String, a property is created. If it's any other type, an error is thrown.

The classes could be declared anywhere, it's the fields that use those classes that are mapped to categories.

Each category will be given its own page. Any field of the @Config class whose type is a class that directly extends Object will become a config category, with its fields becoming properties or categories following the same rules as the top-level class. Map fields are also mapped to categories with properties as key-value pairs.

If you use the annotation-based config system, a config GUI will automatically be created for your mod. All you need to do is subscribe to ConfigChangedEvent.OnConfigChangedEvent, check if the event's mod ID is your mod ID and then call ConfigManager.sync to synchronise the changes made to the Configuration object (by the GUI) back to the fields of your @Config class. You can see an example of this here.

You're getting that error because the launcher is passing --modListFile as a JVM argument. On closer inspection, it looks like Mojang's launcher only lets you set the command-line options for the JVM but not for Minecraft. The only way to add command-line arguments for Minecraft seems to be to create a new version and specify them there. If you don't want to do this, you can save your file to one of the paths that FML automatically checks: mods/mod_list.json or mods/<minecraft_version>/mod_list.json.