Investigate switching to Configured for Fabric mod config menu

[squeek502]

Currently the Fabric version of AppleSkin uses autoconfig + clothconfig for its config file and mod menu config screen integration. This works fine, but it means that AppleSkin includes a copy of Cloth as a jar-in-jar, which accounts for most of the size of the AppleSkin jar (1.1MiB jar with cloth, 76.7KiB without it).

Configured, instead, works more like ModMenu, where it automatically generates mod config screens for supported configs and is installed separately. For the NeoForge/Forge versions of AppleSkin, Configured works out-of-the-box.

However, to use Configured on Fabric, AFAICT AppleSkin would need to either:

• Use a supported config system; it lists Framework or JEI
  • Not a fan of this option, as it'd mean taking on a (different) dependency that we'd likely have to include in the AppleSkin jar
• Use the Configured API to provide config information
  • This should mean that we only need to build against the Configured API with no runtime dependency

Just something to consider.

Other notes:

• Would also want to make sure any existing config files can be transferred over to the new system transparently
• Would want to make sure the localizations can be used with Configured

[Fuzss]

Hey, just pointing out that Forge Config API Port exists for using the NeoForge / Forge config API on Fabric. It includes config screens for Mod Menu. :)

[squeek502]

Cool, it's a bit hard to understand the intended usage for a Fabric mod from first glance:

1. Is the intention that a mod using it would mark Forge Config API Port as a (separate) required dependency?
2. Is the intention that a mod using it would include Forge Config API Port as a jar-in-jar?
3. Is the intention that a mod using it would have a config that works without Forge Config API Port installed, but if it is installed, the config would be able to integrate with config screens (i.e. Forge Config API Port would be an optional dependency)?

I'm not sure (1) would be an improvement, and (2) would be similar to what AppleSkin uses now (but with the potential benefit of allowing other config screen mods to integrate).

(3) would be ideal.

[Fuzss]

It's a normal Fabric mod, meaning either (1) or (2) are possible. (3) is something unique to Cloth Config I'm afraid due to it using Java types directly if I remember correctly.

The advantage of FCAP is being able to copy your ModConfig class from NeoForge directly to Fabric, no need to adjust anything in the class itself or any calls to it. It's that simple. If you ever do plan on moving to a multi-loader development setup the advantage becomes even bigger, as the config can exist only in common then (see example below).

You can find examples for mods using FCAP here. An example for (2) would be this one.

[Fuzss]

Oh, and NeoForge has had opt-in config screens for a while now, not sure you are using them? https://docs.neoforged.net/docs/misc/config/#configuration-screen There is really no need for Configured anymore on any platform.

[squeek502]

If (3) is possible with Cloth Config then I'm not aware of it. I don't think (3) is a use-case anyone but me cares about (which is understandable, I just like the idea of reducing the size/required dependencies of the AppleSkin jar).

Thanks for all the info/examples!

Will double check that the NeoForge version is handling that config screen stuff correctly.

[Fuzss]

If file size of your mod jar is a concern of yours (1) is certainly an option, as FCAP is already present in most Fabric installations as it's widely used. Although the same can be said for Cloth Config. There really is no reason for mods to JiJ libraries that are this common.

[Fuzss]

Regarding (3) and Cloth Config, I did a quick experiment and this is how you make Cloth Config fully optional. Rest of your code remains unchanged, besides updating ModMenuIntegration to check for Cloth Config being present.

[squeek502]

Just released new NeoForge versions that properly integrate with the config screen stuff, thanks for the nudge on that.

Going to hold off on doing anything different with the Fabric version for now, but appreciate the info about what options are available.

[Fuzss]

Would you mind bumping the Fabric version number as well? It's been a bit annoying in the past having to deal with different version numbers for AppleSkin when working with the API and getting it from Maven. Yours is like one of the only mods that doesn't keep version number parity between loaders. 😬

[Fuzss]

Also out of curiosity, why do you use Yarn for Fabric development and official mappings for NeoForge? Doesn't it make cross-platform development needlessly complicated? 😅

[squeek502]

It seems some sort of shared codebase setup is pretty common these days, but I basically treat the versions for different mod loaders as fully separate. My modding practices are pretty much a holdover from like the 1.12.2 era and I've just been maintaining a few mods (and now just AppleSkin) since then, so I just went with whatever worked at the time for each new Minecraft version and haven't revisited those choices since.

Sorry about the versioning, I'm reluctant to release a new version when nothing has changed for a given mod loader.

[Fuzss]

Well, let me know if you ever consider modernizing the codebase and switching to multi-loader development. I can assist with that.