Let's talk mod loading

[fabricmc]

Let's talk mod loading

[Prospector]

fml.json (Fabric Mod Loader, of course)

Edit: also petition to rename ModInitializers to Fabricators... come on

[asiekierka]

I'd say, for 0.2.0:

• add ClientModInitializer/ServerModInitializer interfaces
• Rename mod.json to fabric.mod.json (support the former until 0.3.0)
• Remove semver getVersion(), keep String getVersionString() (figure this out for 0.3.0)
• No ServiceLoaders

Who's with me?

[ChloeDawn]

fabric_mod.json

_ > -

[liach]

we can even just define source sets including client main and test, then using clientApi gradle configuration to add the client code to client source set dependency

[modmuss50]

I like the idea of the ClientModInitializer as well as the other 2. This keeps things clearly separated in code. As long as it doesnt try to load any of the client classes called from within then it should be fine.

Using the current system and not loading classes when things dont exist I think is a good idea. How ever what happens if something critical was removed (either in fabric or a mod that is depended on) the mod would just slienly fail.

Service loader, its great for what it does, but not so good for stuff it doesnt do. Having multiple instances of the same class imo is something we dont want. One idea that was mentioned was implementing a custom service loader that uses the same files/locations (so IDE support) but provides what we want.

[asiekierka]

@modmuss50 "How ever what happens if something critical was removed (either in fabric or a mod that is depended on) the mod would just slienly fail."

We could use an annotation, or we could mark it in the JSON. Open to ideas here.

[asiekierka]

Another question: Should we use "mod.json" or "META-INF/mod.json" or something else altogether?

[modmuss50]

Not META-INF imo, doesnt really add anything. I dont see anything wrong with the current mod.json file name.

[kashike]

I'd prefer fabric.json or fabric-mod.json to avoid any conflicts with other platforms.

[NikkyAI]

i would also not use META-INF unless there is some killer feature that requires it.. but it seems to be more restrictive than just the mod.json

i wonder if it would be possible to have split dependencies for Client/Server
so that modders cannot compile with references to the wrong one
i am imagining a structure using multi module builds common, client, server
gradle multi project builds

[LemmaEOF]

I do think changing it to fabricmod.json or similar will help clear things up a lot, since if I recall forge is moving to a json-based system too.

[oliviathevampire]

@Boundarybreaker not json but toml https://github.com/MinecraftForge/MinecraftForge/blob/1.13-pre/mdk/src/main/resources/META-INF/mods.toml

[asiekierka]

Done as of 0.2.0. New breakage should go into new issues.