fabulously-optimized
fabulously-optimized copied to clipboard
Fabulously-Optimized
Quilt Loader impacts
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?
- First and foremost, (widespread) launcher support is needed
- Hosting is needed (Curseforge and Modrinth are now supported)
- Enough mods moved over to be worthwhile
- ~~Telemetry must be fully removed or have an easy opt-out~~ removed since 0.19.5
- ~The mod list issue needs to be resolved (probably with a separate mod)~ Seems like this won't be an issue.
The mod list issue? Edit: read this comment for an update
~Quilt, similar to Forge, is using a system where a list of all used mods must be sent to the server. That means the server can see all mods you use and disallow you if you are not using the mods server allows (regardless of whether the mods you use provide the same features or not).~
~Fabulously Optimized deems that as an invasion of users' privacy and freedom. No one should be banned because they use "too many mods" or "not the right zoom mod". The servers can already ban any cheaters or rule disobeyers with existing, heuristical plugins, they do not need to see the names of the client mods for that (nor do the cheat mods announce themselves anyway). Quilt has said there will be no configuration or opt-out for that system, so one must hope there will be an external mod that can opt this out.~
So what if Fabulously Optimized will stay on Fabric?
- Short-term, nothing will happen
- Long term, the list of available mods may decrease drastically and Quilt would have to be considered to keep up with it. If done, efforts will be made to make the transition as seamless as possible to users.
What about both? Maintaining two modpacks is too much for me.
Sources:
- https://quiltmc.org/about/faq/
- https://quiltmc.org/about/faq/developers/
- https://discord.quiltmc.org/
Replying to this as it seems relevant to my personal needs:
-
The privacy context is the top priority and that i do not wish for everyone to be affected by a blocking-wall in a sense that for example being that you are only allowed to use sodium instead of optifabric / canvas renderer due to the server owner choosing this type of path instead of letting the user decide on what they want to use in this respect,
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.
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.
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.
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.
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.
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.
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.
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.
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.
Alright, but if any single mod uses that, the module still sends the entire modlist, right?
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.
Alright, but if any single mod uses that, the module still sends the entire modlist, right?
Yes.
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/.
Fabulously Optimized deems that as an invasion of users' privacy and freedom. No one should be banned because they use "too many mods" or "not the right zoom mod". The servers can already ban any cheaters or rule disobeyers with existing, heuristical plugins, they do not need to see the names of the client mods for that (nor do the cheat mods announce themselves anyway). Quilt has said there will be no configuration or opt-out for that system, so one must hope there will be an external mod that can opt this out.
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
Also this might be a bit off topic, but forge does this exact same thing and no body seems to care about that
@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/.
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.
Also this might be a bit off topic, but forge does this exact same thing and no body seems to care about that
[sarcasm]
Indeed I don't care about that as
- I no longer use Forge
- I do not make a Forge modpack
- I do not play on servers that do this
[/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.
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:
- The mod-list packet is not anti-cheat, is deliberately not designed to be resilient enough to be used as anti-cheat, and largely exists to help our moderators resolve grey area mod reviews in official Quilt spaces only
- Yes, the approach has undeniable drawbacks. Got something better? I'd love to hear it.
- I personally don't feel this is as large an issue as some people make it out to be - even though it is undeniably an issue, I believe we can get pretty far by educating server owners, and working with the community to come up with a good tool for category-based filtering that doesn't encourage server owners to inspect users' mod lists
- If you're not developing a mod that could be considered cheating by conventional standards, we likely won't think to check for a patch - but we'd like to stress that including one makes it much easier for malicious mods to work around server restrictions
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.
@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).
@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).
That's an interesting solution - how would you go about denoting this?
Perhaps the API could provide a listener and all mods that register on it get their list sent at once?
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.
Doesn't that just make it opt-in? Kinda defeats the point
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.
I feel like this wouldn't work out for a number of reasons:
- It'd make the API surface incompatible and generally worse
- Most of the grey-area mods I'm thinking of wouldn't be using the networking API in the first place
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
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.
This isn't an anti-cheat! This is about moderation issues in Quilt spaces. I've said that a couple times.
@gdude2002
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
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".
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
@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).
Spoiler alert, this is standard Vanilla protocol... At the time it was called Plugin Channel, but the idea is every custom packets that are defined there have an identifier, meaning that if a mod uses the networking API for a packet you'll have a channel with the mod id as the namespace.
@LambdAurora
Spoiler alert, this is standard Vanilla protocol... At the time it was called Plugin Channel, but the idea is every custom packets that are defined there have an identifier, meaning that if a mod uses the networking API for a packet you'll have a channel with the mod id as the namespace.
So why won't Quilt use it? Or maybe I'm misunderstanding your point.
I think the point was that your solution isn't really any better than what vanilla already offers - the idea exists because that wasn't enough on its own.
I don't understand why quilt has to add that if fabric can work without it.
Considering it was about moderation concerns and Fabric has minimal moderation at best, that's not really much of a statement haha