-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conditional dependencies #464
Comments
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 ( 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. |
The usual solution is |
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 |
its coming close to a year now, is there any updates on this? Still an issue for many mods. |
#370 proposes to add an environment field to a mod dependency. #461 (comment) 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?
The text was updated successfully, but these errors were encountered: