Closed liach closed 5 years ago
From a programmer's perspective I like this setup.
How this structure is communicated to players and non-modders, though, will be what makes or breaks it.
(edit: the first 2 also apply to any other sort of modularization)
We had been thinking of splitting the api into a few parts based on features.
One example would be a registry module, having this module installed in the game would most likely require the client to also have it installed and would allow for adding things to the registry, for example blocks and items.
There would then also be modules for commands for example, only mods that add commands would need to contain it, this would allow server side only mods to work as closely to vanilla as possible.
By splitting it up by features you end up with more modules, but then this allows for less changes to the game at run time. I can see this being a bit annoying for modders to keep track of what modules they would need to have enabled, this could possibly be solved by having clear docs on the modules that exist.
Or possibly the default modding workspace having access to all modules and then loom figures out what modules the modder wants? Could be a bit complex however.
I like your idea on the 4 different levels however some features might be hard to categorise or they might fit in 2 categories. For example the resource loading would fit in both the client and the server.
This proposal doesn't make much sense, sorry. It doesn't really benefit anything and is really just a pretty pointless artificial modularization.
I think fabric should return to the mass modularity it used to have once we have jar in jar working. fabric-registry, fabric-resources, etc.
That said, there may be room for additional fabric-client and fabric-server modules for specific things that clienside-only or severside-only modding would find useful.
Back in 2016, Fabric had a modularization plan, which it splits resources, network, registry, commands, etc. to different projects. This attempt did not see much success.
we are waiting for loader 0.4 that enables jar in jar to "modularise" fabric as right now a user should not be expected to download 10 jars (they find 2 hard)
This setup appears to be more realistic than the previous one. However, this setup still has a hodgepodge of API content within a single module
If you look at the code here, https://github.com/FabricMC/fabric/tree/master/src/main/java/net/fabricmc/fabric/api they are very clearly set out, anything outside this api should not be used by a modder. This extends onto the mixins and the implementation of these apis.
This increases Fabric's competitiveness as a server-side modding API on snapshot versions
Right now this is tottaly possible, the modder just has to take care.
Going on to the actual impl of this, gradle 5.3 includes a new thing called "feature variants".
Taken from the Gradle release page:
Often a library needs to express that some dependencies are only required if you use a specific feature of the library. Those dependencies must not be there unless you use that feature and therefore are often flagged as "optional" in Maven.
This sounds like something loom could take use of to make the lives of modders easier.
That said, there may be room for additional fabric-client and fabric-server modules for specific things that clienside-only or severside-only modding would find useful.
Modules would be marked if they could work server/client side only, Some basic client mod validation could slove some issues we are seeing right now.
For @quat1024 https://github.com/FabricMC/fabric/issues/134#issuecomment-479690376:
For @Prospector, you probably haven't played much hypixel or other plugin servers with client-only mods like minimaps. For those players, what they really need is just the client installation. You probably have not played with ForgeEssentials, dynmap, or FTBUtils that only requires installation on the logical server. As far as I see, you would just use the Game part, but that does not mean there is no one using the Client and the Server part.
In fact, there is even a case where both Client and Server would be used but the Game: the carpet mod by @earthcomputer. It explores vanilla mechanisms so it needs both components but it does not all these advanced registry tools, etc.
You can already use Fabric API on the clientside just fine though
You can already use Fabric API on the clientside just fine though
Same goes for forge, but who wants to load all those energy api, inventory caps, and initialize obj model loader when you just want to add an autofish capability based on sound events
The whole idea of jar in jar is that only the necessary components will load. With your proposal, everything on the clientside will load whether you need it or not.
I like this proposal, and I would that add that Fabric and its distributions should consist only of these modules and each module should be as minimal as possible. All other APIs and extensions would be independent of the Fabric project itself - though I think our forums and wiki should help create visibility and feedback for development and adoption of external libraries.
This would mean things like #65 shouldn't even be part of Fabric - and I say that as the person who wrote that PR (with a lot of help). This is a change of heart for me, and merits some explanation:
Unlike Forge, Fabric does not have a full-time maintainer, and it seems unlikely it ever will. This is not meant as a slight to @asiekierka or @modmuss50 and other contributors who have done and continue to do more than anyone can reasonably expect to move the project forward. The point is that Fabric is already barely sustainable. A small handful of part-time contributors cannot maintain an ever-expanding scope and also meet the high bar that has been set by work already done.
The end result is that the project stalls. PRs languish or are never put forward. Mod authors cannot develop or release their content because they are waiting for that "one last thing" that has to happen before the thing they need. Therefore I would prefer to see the Fabric project focus on being a great toolchain and leave library development to the community.
Jar-in-Jar serves as an example. It's a nice feature that does belong in Fabric proper and I will make use of it when it gets here. But strictly speaking we don't need it to release content. And yet, much is waiting on it. That choice makes sense - and is arguable necessary - for the Fabric distribution itself. But it means everything that is or may be a part of the Fabric distribution is constrained by it.
Limiting Fabric's scope does necessarily mean we will have competing standards - at least until a consensus emerges - but that is already the case. We have an entire discord channel dedicated to debating configuration and still no official config API. If we're going to go that way, I say let mod authors with the interest publish their best effort and let the market decide.
I'll admit this isn't ideal, but it is practical. At least we will have solutions to choose from. And it's often good to have more than one option. Needs aren't all the same.
Well, fabric has been modularized. I'd say this has been superseded
Modularization plan of Fabric
History
Back in 2016, Fabric had a modularization plan, which it splits resources, network, registry, commands, etc. to different projects. This attempt did not see much success.
Current Situation
Now, fabric groups by mod loader and modding api components. We now have:
This setup appears to be more realistic than the previous one. However, this setup still has a hodgepodge of API content within a single module (Fabric mod, hence I opened the issue here)
Proposal
The Loader, Kotlin support, and Scala support parts will remain the same. The fabric mod will be split to these portions:
Distribution
Even though we will have four modules, we will only have 3 distribution: the Client, the Server, and the Game. Client: Liteloader-like, for client-side aid mods installation/development, like autofish, dynamic lights, optifine, etc. Server: Sponge/Bukkit-like, for server-side mods similar to forgeessentials, worldedit, and dynmap Game: Big and true mods that add items, blocks, entities, etc. like TechRebornX, Towlette, more stairs, trapped shulker boxes, etc.
In my opinion, this setup can best serve these three groups of users/developers and make game load faster as well.
Reason
Notes
This is not fully finished yet and is subject to modification and addition. However, I wish to hear your opinions on improvements for this model.
For integrated server, I desire to put it in server instead of client, as it would drastically increase client distribution size without offering much real benefit to client-only mods (like liteloader).