fabric-loader

fabric-loader copied to clipboard

#370 proposes to add an environment field to a mod dependency. https://github.com/FabricMC/fabric-loader/pull/461#discussion_r661411557 suggested to make environment field more generic by creating a built-in mod for the minecraft client.

Combining this two, I think we can introduce conditional dependencies, where one dependency is applied only when another one is fulfilled. Thoughts?

I don't think that's a particularly practical example, encouraging client<->server differences sounds like trouble in general.

It'd be fairly easy for me to support even arbitrarily combined dependency expressions (modA:* & !(modB:* | modC:>=2.x)), but that may not be very useful and quite confusing to the end user.

It still wouldn't solve the case where a 3rd party mod is changing the game by e.g. making java 8 run java 16 mods. The mods wouldn't anticipate this in their dep declarations, so we're back to needing a programmatic API to alter other mods' deps.

It still wouldn't solve the case where a 3rd party mod is changing the game by e.g. making java 8 run java 16 mods. The mods wouldn't anticipate this in their dep declarations, so we're back to needing a programmatic API to alter other mods' deps.

I strongly agree.

Back on an extra environment field, should we encourage people to create jar-in-jar for say, a client config-gui compat module, which can have its own mod definition and loading rules, as opposed to complicating the dependencies for the main mod?

If this is the case, we might consider making an example for how to jar-in-jar mod compatibility modules so they can have custom dependency rules handled by the loader.

I want mods to be able to say that they require a certain version of a mod only if that mod is present. And then if that mod is present, that they require another mod be present, etc.

For an example, look at the current Create mod situation where if someone is using Sodium, they need to use Sodium 0.4.10, Indium 1.0.21, and Fabric API 0.88.1. The Continuity mod is another good example. #177 could also assist in such a situation. Currently mod and modpack authors can use No Indium, but it's very specific.

Edit: another example is Syncmatica. When used on a sever it has no dependencies, but on a client environment it requires Litematica and MaLiLib.

they require a certain version of a mod only if that mod is present

The usual solution is "breaks": { "mod": "< required_version" }

I want to add the Connected Glass mod to my server, the mod depends on the Fusion lib to handle connected textures.

Since Fusion is marked as unsupported on the server (because textures don't exist on the server), the server setup script doesn't download the lib and it crashes.

It would be nice to extend base dependencies with client/server dependencies so issues like this one can be solved.

Ill just put my input here, also have this same issue where people have to install my client only library on a server because mods depend on it even though it does not need to be on the server at all as it only does rendering but has to be loaded on the server because you cant declare client only dependencies.

It has come to a point where I am thinking of just removing the FMJ declaration of dependencies in the mods that use the dependency and replace it with code that will just have a screen that only shows up on the client when loaded instead as it happens often where people are asking why they cant load the mod on a server without a client only mod, and such a screen would stop it, but it would better if FMJ supported a format to allow declaring client only mods instead of mod authors having to create dependency workarounds.

Just having something like this would solve a very common issue for mods.

"depends": {
    "modid": {
        "clientOnly": true,
        "version": "version"
    }
}

I already have something similar in the works