Mod name

Respackopts

Curseforge link

https://www.curseforge.com/minecraft/mc-mods/respackopts

Other links

https://www.modrinth.com/mod/respackopts
https://gitlab.com/jfmods/respackopts

What it does

Adds configuration support to resource packs, allowing resource pack developers to support custom configs in their packs.

Why should it be in the modpack

• The main appeal of this pack (at least, to me) is the performance boost of CaffeineMC and other fabric mods, while also keeping the aesthetic modifications that Optifine supports. Respackopts allows for further aesthetic customization in the same vein as Optifine, and is being used in a few packs already.

Why shouldn't it be in the modpack

Most resource packs don't utilize Respackopts yet, so it wouldn't find use by many players. (Although I do believe that it's inclusion in this pack would lead to further adoption by resource pack devs.)

Categories

New feature

Additional details

No response

This was also suggested by its creator and my response was:

Yeah, the lack of popularity is the main concern
If there would be something equivalent already popularized and yours was compatible with it, I could see it being useful
but right now the modpack isn't that popular to make your mod popular for resource pack makers as well
especially because there is no Forge equivalent

Some other points:

• no known resource packs use it today apparently Lumi Lights does... which is a Canvas shader pack
• resource packs were added for this point exactly - to keep it modular, so I don't see a need for a custom mod to achieve the same

The only pro I see is Bedrock parity, as Bedrock has the same feature.

Actually, changed my mind as I now noticed you mentioned some packs. Going to mark this as "on hold" and will consider including once I see adoption from a bigger resource pack (say, one with 100k downloads) or several small ones (say, 20). Also suggesting the dev to track the packs that include it.

Redstone Tweaks uses it. https://www.curseforge.com/minecraft/texture-packs/redstone-tweaks

Thanks for the heads up.

two packs meeting the 100k downloads criteria seem to have adopted optional respackopts configurations now

Okay, I believe you. But neither of them actually mention the mod, nor the features that it would unlock. Therefore the mod doesn't grow and nobody even expects the packs to have additional options...

several other smaller packs have used it as well

Yes, that's what you should do. Mention all packs that you can find to support your mod, and don't hide it in the wiki, do it right in your mod's description. Because if the packs themselves don't advertise you, at least you should advertise them to show that your mod is used in resource packs.

Also, I have concerns about your releases in general. 2.10.2 is still in beta, 1.19+ versions are "highly experimental", with 1.19.2 version being released only today. The back and forth mod size variance from 51 to 898 KB looks very suspicious.

There are still ways to go...

Since this issue is still open: two packs meeting the 100k downloads criteria seem to have adopted optional respackopts configurations now, and several other smaller packs have used it as well.
Others likely use it as well, since (like the ones above), they may not mention the compatibility in their descriptions.
(FYI: any pack containing a /assets/respackopts/conf.json or /respackopts.json5 file supports respackopts)

Okay, I believe you

The reason I added the FYI was so that you could verify that claim. Those packs include the relevant files.

1.19+ versions are "highly experimental"

I agree that leaving all the latest versions marked as experimental is probably problematic from your perspective.
The reason for this is the fact that the latest versions all contain major overhauls (as mentioned in the changelogs), so I didn't feel comfortable marking them as stable, even after I manually verified that all known packs work (which I do after each major change, btw).
I guess I should mark such versions more accurately in the future.

The back and forth mod size variance looks very suspicious

Originally, the mod bundled cloth and used a very small but inflexible condition system and a hacky internal representation. Over the course of later versions, I switched to a cleaner (but larger), tree-based representation, stopped bundling cloth, instead listing it as an external dependency, later included μScript for conditions and switched to LibJF configs. The file sizes vary accordingly.

I found the mod really great but when trying to port my modpack (ɴᴏᴛ ꜰᴏ) over to quilt i noticed it didn't work because LibJF goes really deep in fabric loader.
So we just need to not forget that if we at some point need to move to quilt this mod will be dropped. (unless someone decide to make LibJF Unsafe compatible with quilt)
Otherwise this mod is really great it allow to make incredibly more user friendly Resource Packs with toggleable features, like having the choice between light, transparent and dark UI or enabling and disabling emmissives etc
As a Resource pack maker for me and my friend it allowed me to solve the problem of having smth like 10+ resource pack variants just to be able to give everyone liked features only.

Some work has already gone into decoupling libjf-unsafe from the loader internals for stability.
However, data-manipulation (the backend of respackopts) is dependent on functionality which is impossible to implement without loader-dependent hacks.
If I understood the relevant comments correctly, the plan is to move to quilt only after a significant portion of important mods do so. If that ever happens, I will likely investigate Quilt compatibility either way, but for now the maintenance and compatibility testing burden of supporting an additional platform is too much for no real benefit.