Make Forge and Fabric mods' files different

[PiyanistMinecraft]

Basically, add 2 additional folders into the mods folder. The Forge mods should stay in the folder for forge, and the others in the folder created for fabric. This way, coding should be easier, as your code already has the info on which is which.

[OracleHisty]

I agree with this, this is a simple way to fix the biggest issue of forcing abstraction amidst existing compatibility.

I don't like the idea of returning to CoreMods, but having a dedicated folder for core apis and extensions/abstractions would be very nice to have as well.

[Su5eD]

This way, coding should be easier, as your code already has the info on which is which.

I'm not sure how mod folder separation relates to this?

[OracleHisty]

Mainly for adding an pseudo-abstraction for cross-compatibility apis.

When they existed, coremods were what mixins used to be, but instead having dedicated folders among them for apis that load FIRST so that all issues later go away.

It was a suggestion I had for a One-Loader-Fits-All situation, having the Fabric Api, Forge Api, Quilt Libraries, Neoforge Api, etc all in its own folder so they update independantly from their platform's mods, allowing near direct abstraction so that people can stop complaining about how they dont agree with something a modloader maker SAID and making another loader like we have now.

Bring it all under one loader and have their own abstraction layer for it all at once.

Granted that would be the IDEAL scenario...

Regarding the seperation, it would make it so the api applies the mods as if they are co-dependant instead of totally abstracting to forge. The inbetween needs to fill the gaps of the loaders.

[Su5eD]

Bring it all under one loader and have their own abstraction layer for it all at once.

Architectury API exists for this use case. Fabric API can also be used on forge via FFAPI.

[OracleHisty]

Architectury API exists for this use case. Fabric API can also be used on forge via FFAPI.

Architectury is also a completely different codebase. It is only a layer. If the developer won't learn and/or can't port without breaking all previous versions. (which is a skill issue even I have)

At this point the only closed source piece of Minecraft is the game itself, why is all of the modloaders so focused on independance from one another?

Fabric is designed to be compatible with all java games and has already been implemented into an (open source) minecraft clone. That is quite the mark of a well designed futureproof modloader.

Not everybody likes having to change tiny syntax issues in FML in a per-version basis. Literally a grammatical change at that point.

Neoforge is justified up until it truly splits, but another issue on the surface is new competing standard.

I know I am barking to a proverbial steel wall, but seriously. There were more splits for Minecraft Modding than CALL OF DUTY RELEASES in the past 4 years...

[RainbowTabitha]

bad for modpacks, shouldnt be a required feature

[OracleHisty]

I would say we don't need 5 different modloaders with different philosophies, but here we are. Fabric was justified during a time where forge took forever to update due to internal issues, fabric and forge created such a massive rift (no pun intended) in the community that CAUSED more issues than it fixed... then Quilt and its mess. Now the only justifiable split for forge in a while.

I would argue that as-is is worse for modpacks. Its great for mod developers