More modloader support across curse without being required to use forge.
Options to chose between modloaders and supported mods/modpacks such as FabricAPI, liteloader, rift and so on.
Each modloader having it's own mods and modpack area as to not mix them up causing compatibility issues without including Forge as we are required to use at the moment (since that has been the only modloader on curse for a long time now)
Thank you for the suggestion, we are looking into this. Please add any additional details that you think would be helpful in the comments! We are Listening!
I would love at least a sort option for Forge mods. As it is now the forge mods are unfilted and are fabric mods are thrown in.
It's very imperative for the distinction to be made.
Another HUGE issue: stop setting a FORGE mod as the "main" download EVERY time. Curseforge does this even if the Fabric version is MONTHS newer (and for a more current version of Minecraft).
This happens every time a mod has versions for both Forge and Fabric.
There really isn't any getting around it anymore, this is absolutely necessary. You can talk about not wanting to support loaders that might go away in the future all you want, but the lack of this feature is the main thing preventing Fabric from getting the support from users that it needs to really be 100% secure in that.
One solution would be to tag at the file level, just like thay are tagged with MC versions. Just add a ModLoaderType tag and let devs tag their files one by one
In other words handle modloader just like MC versions for each file are handled now.
And of course expose that to the user on the site, at the file level
There is already an enum for ModLoaderType lost somewhere in the Curse API/Code, so it seems at one point there was an attempt to tackle this
Any updates on supporting loaders such as fabric i have mods that depend on it
Although it would be nice to be able to sort between forge, liteloader, and fabric mods, curse does support all of them just fine, they all go in the mods folder, thought unlike liteloader, fabric doesn't work with forge.
I like the fact that fabric updates frequently, but that's only because of how little code there is, the mods almost require code injection which is not a good idea unless it's the only option, and with fabric it almost always is.
It's now more than four months since this post has been marked as "under review".
Can you give any updates on the current status of this topic?
Daniel She commented
It has been nearly 3 months since the proposal, Fabric now has over 100 mods and it would be appreciatable to have fabric supported.
This is something that the new dashboard has proved is beyond necessary. Twitch Launcher downloads account for 90-95% of most mods' downloads, so preventing access to Fabric through the Twitch launcher means that people who target Fabric are screwed out of getting almost 19 out of every 20 Curse points they should be.
Raph Hennessy commented
It would be amazing if you could add at least Fabric support to Curse, since the main thing limiting its popularity at the moment is it's incompatibility with the Twitch launcher.
Any Updates about this? with Forge 1.13 and 1.14 Releasing Soon. I would love to know the direction CF plans to take with this.
It would also be helpful if each area would be split in to client side mod, server side mod and install on both.
Robert Seifert commented
I would build this out the same as your java version or mc version selector system. Then do a display filter to reduce by modloader. This way if a mod can work on several loaders it will show on several. Might want to also filter downloads per project as well.
We just need a method beyond the current subcategory. We need a new option for individual jars. I have Fence Jumper for both Forge and Fabric now, but under the same project. What is limiting Fabric atm is Curse/Twitch Desktop. If a pack dev were to make a pack, they should be able to specify the loader, and then be able to choose mods available on that loader. I completely skipped Rift as I saw the issues with it. Fabric is actually viable, and imo, MUCH better than Forge to dev for. There is no one central person everything has to pass through and they are really good at staying up-to-date with the latest snapshots, which gives us mod devs time to test and polish our projects before the official MC version drops. This allows us to have true testers before dumping buggy projects on the community. So, back to what I was saying: We NEED this to be a "per jar" option since I'll likely be maintaining projects for both loaders for the foreseeable future. This issue would/will be exacerbated if/when Forge releases for 1.14, where (with the current setup), it will appear on Twitch Desktop like there is an update available for a Forge mod. Then the user gets a crash, and us devs suffer the false reports.
This could also be helped by being able to mark what loader our mod is compatible with on a per mc and mod version basis I guess that way we can upload one build as say mod-3.8.2-1.12.2 and have that tagged as fabric and the same version on the forge branch could be tagged as forge.
Would prefer all loaders/mod frameworks to be separate categories with ability for mods to be listed in multiple categories.
Some mods might be compatible with both Forge and Fabric, for example, while others might support only one.
Listing mods in multiple categories prevents confusion about what works with what without forcing mod publishers to create duplicate entries.
It would be nice to see some form of category to help find Fabric only mods when this is implemented
As far as I'm aware none of the above are compatible with each other but I can't test that right now, might be best to ask Fabric devs in discord
Robert Seifert commented
I say we only split out loaders that are not compatible with forge. Any loader that can be installed on its on or with forge should just be included with forge mods. Though I think we should have some metadata on the page that notes it requires a different loader than forge.