Originally created by: Madis0
TL;DR: Fabulously Optimized will not move to Quilt soon, but it is something that has to be considered long-term if it becomes widespread.
Here is a FAQ of why Quilt matters to Fabulously Optimized, and what has to be done to accommodate it.
What is Quilt?
The site describes it as
The Quilt project is an open-source, community-driven modding toolchain designed primarily for Minecraft. By focusing on speed, ease of use and modularity, Quilt aims to provide a sleek and modern modding toolchain with an open ecosystem.
...but it is essentially a fork of Fabric Loader and API because of conflicts within its management team.
Why does it matter?
Because some current Fabric mod devs are planning to move over to it, dropping support for Fabric altogether. And others, well, aren't. Who knows, how many mods will be affected in the long term.
When does it matter?
Possibly when more launchers and Curseforge supports it.
The first beta released on 2022-04-20 and Modrinth had the mod listing support from the start. Then some launchers followed, and... will see.
Can Quilt load Fabric mods?
In most cases, yes. As Quilt is a fork, most Fabric mods should be compatible with Quilt initially – but this may not be the case forever.
Can Fabric load Quilt mods?
No. Quilt mods are distinct from Fabric mods, and not defined in the same way.
Can I install Fabulously Optimized and replace Fabric with Quilt now?
Probably, while Fabric mods are still supported in it, but do not ask for support regarding that.
How long will backwards compatibility for loading Fabric mods last?
Quilt will likely continue to support Fabric mods directly for quite some time – at least until Quilt is properly established. However, at that point, we do plan on dropping first-party support for Fabric mods – although, there’s no reason the community can’t continue to maintain that support, and we’ll provide the required resources if someone else decides to continue that part of the project after we stop maintaining it.
So what if Fabulously Optimized wants to move to Quilt?
The mod list issue?
Edit: read this comment for an update
So what if Fabulously Optimized will stay on Fabric?
What about both?
Maintaining two modpacks is too much for me.
Sources:
Originally posted by: Kichura
Replying to this as it seems relevant to my personal needs:
and while i do recognize that this would reduce cheaters to a minimium - this would in turn cause server owners/quilt developers have to whitelist/blacklist multiple mods in hopes this would be effective which...unfortunately isn't. it would in fact make things worse for novice/experienced modders as they must obey on what the server owners want people to use. (malicious or not)
The compatibility mode is helpful so that mod developers have more time to decide on rather they wanna make the jump to quilt in it's entirety or not as it is considered fair similar to forge -> fabric jumping. Although i am not sure on how many developers are considering this as some of them haven't seen this yet or just aren't ready for it due to burnouts and all that - but i assume documentations could help this a bit but who knows?
I am looking forward to the beta obviously. although with the two things i have discussed along with madis; this would be considered questionable in some ways as i cannot be sure on how well the migration will turn out - even if i decline it; i just cannot guarantee the final result(s) of it.
Originally posted by: surfaceflinger
Privacy issues can be easily resolved by adding a mod that would make the client look like vanilla. Wurst already has this as a module, but not standalone + it would create the same concerns as their zoom mod.
Originally posted by: Kichura
Well the main problem with this is that people can still figure out what your client is regardless of brand name so this won't change anything - it needs a more prior approach when trying to reduce exposure.
Originally posted by: TiboOpGithub
The problem isn't that they see you using quilt (I think) but as long as you can make sure the server doesn't see all your mods by having a mod it seems like a good solution.
Originally posted by: maximumpower55
As a quilt dev... I Just want to add something quickly here about the common assumptions about the modlist sending in quilt, it will not be in the loader, it will be in the qsl networking module and i highly doubt any mods in FO right now use the networking module from at least fabric.
Originally posted by: Madis0
Alright, but if any single mod uses that, the module still sends the entire modlist, right?
Originally posted by: maximumpower55
Yes.
Originally posted by: maximumpower55
Instead of just adding reactions to my comment i think it would be better for you to actually join the quilt discord to have a good ol' chat since github issues is not a good place to explain this, https://discord.quiltmc.org/.
Originally posted by: maximumpower55
Also you will be fully able to patch this out
Originally posted by: maximumpower55
This isn't meant to be a anticheat, also if the server doesn't allow you to use like a zoom mod for a example just don't play on that server
Originally posted by: maximumpower55
Also this might be a bit off topic, but forge does this exact same thing and no body seems to care about that
Originally posted by: Madis0
@maximumpower55
I did it last year, it initiated a long discussion: https://discord.com/channels/817576132726620200/847158608524345394/857245880466145280
The result was: https://discord.com/channels/817576132726620200/847158608524345394/857601674167975966
Feel free to ping me there if you want to add anything to that discussion.
[sarcasm]Indeed I don't care about that as
[/sarcasm]...but that's not the point. People want an alternative to Optifine and I provide that.
I do my best to choose the best mods but I know that if someone would get a feature nerfed on a server (or maybe the server not liking the mod list altogether), they will want to or be forced to return to said Optifine. And that behavior is unhealthy for the entire modding community - getting blamed just because you're using the wrong thing, not because you broke any rules with that thing.
Originally posted by: gdude2002
Hello! Quilt community manager here.
I just woke up so this may not be the most fantastic of responses, apologies.
The mod list packet is not designed to be an anti-cheat solution. Quilt will not be providing any mechanism to filter users based on it, nor will it be taking steps to make it difficult to patch out. As mentioned earlier, it will be part of the QSL networking module and, as it's a standard plugin channel packet, will require the server to be listening for it before sending anything.
The main reason the packet exists is to ease moderation in Quilt community spaces where the intention of a mod developer is ambiguous. It was a response to the long-winded issue about how to define cheat/utility mods - for grey-area mods, this will give us a yardstick to figure out whether the mod developer intends for their mod to be used on servers that do not want their mod to be used there.
Most of us completely agree that this isn't an ideal solution, and we'd love to get some suggestions on better approaches. That said, it's been an awful long time now, and we haven't really seen anything reasonable other than "screw what you need, remove it". Ultimately, we accept that some servers do not have competent or reasonable staff members, and that is the main drawback - but I also personally believe this is possible to mitigate with a good community solution to blacklisting categories of mods, rather than forcing server owners to do it themselves (although, as mentioned before, Quilt as an org will not be providing ways to action these packets).
Essentially:
I think that's about all for now - I am unlikely to reply to this issue for a while since I have a pile of stuff to do before the beta on the 20th, but I do appreciate people's concerns here and would love to see a better solution to this problem post-beta. Feel free to hit me up on Discord if needed.
Originally posted by: Madis0
@gdude2002 Thanks for the reply.
In my opinion, a reasonable solution would be to broadcast only the mods that use said networking API instead of all mods the client has. Because obviously the server needs to communicate with the mods that network and this would preserve the privacy of mods that do not network at all or use a different method (like a different API).
Originally posted by: gdude2002
That's an interesting solution - how would you go about denoting this?
Originally posted by: Madis0
Perhaps the API could provide a listener and all mods that register on it get their list sent at once?
Originally posted by: gdude2002
Doesn't that just make it opt-in? Kinda defeats the point
Originally posted by: TheMadHau5
It doesn't really help against "grey-area" mods either.
A common pattern in 1.8 cheats was to co-opt a well known "good" mod (say, keypress or cps mods) and then patch it with cheat functionality and distribute that.
This system (like Forge's) is completely ineffective to that.
Originally posted by: Madis0
Hmm no, I meant like if they want to use the abilities of the API, they must notify the API of their presence first and then the API records that and provides the methods.
Like instantiating a class, though that's a bit different concept.
Originally posted by: gdude2002
I feel like this wouldn't work out for a number of reasons:
Either way, probs better to have this discussion in a Quilt space - I'm not a Quilt dev (the Community Team is completely separate) and I doubt most of the devs are aware of this thread
Originally posted by: gdude2002
This isn't an anti-cheat! This is about moderation issues in Quilt spaces. I've said that a couple times.
Originally posted by: Madis0
@gdude2002
Could you refer to the most appropriate place for this discussion (e.g. specific thread in Quilt's discord)?
Don't really want to post in the wrong place and get an answer "this has been discussed already".
Originally posted by: gdude2002
Probably the best thing to do is make a thread on the toolchain server entitled "modid list alternatives" or something like that, in #qsl-general
Originally posted by: RaptaG
https://github.com/PolyMC/PolyMC/issues/406 Support from PolyMC (?)
Originally posted by: gdude2002
We've confirmed support in both ATLauncher and PolyMC so far, yes.