Open Krarilotus opened 2 months ago
This does not fit in the current dependency logic. Extensions depend on other extensions, activating a dependency extension activates its configuration.
Allowing multiple configurations per extension would also need clarity on the following:
If clutter is the problem, I suggest we remove clutter as much as possible with #236 and #237 and not complicate the dependency graph.
If clutter is the problem, I suggest we remove clutter as much as possible with https://github.com/UnofficialCrusaderPatch/UCP3-GUI/issues/236 and https://github.com/UnofficialCrusaderPatch/UCP3-GUI/issues/237 and not complicate the dependency graph. So des that mean, it would require like say 10 extensions for making configurations for just one extension that has actual files in it? The clutter here is not the clutter on the UCP-GUI side, but the clutter starts, when people have to create tens and hundreds of repos for just one mod they want to provide with some preconfigured options on how to use it
I would argue, it makes more sense, to have this clutter removed on the backend, than adding it to the frontend and just filtering it out.
Hence my original suggestions stands with its implications!
-> It would need restructuring of the config. I would tho: Say that if a dependency doesn't specify a certain configuration or specify explictly 'no configuration' in their dependency, then it should use the default configuration of a plugin:
That way we can keep all existing logic, and just add onto it, by giving the dependency another property, that should work in a yaml, if i understand it correctly?
Currently it is like this:
dependencies:
A: ">= 1.0.0"
I think you want:
dependencies:
- extension: A
version: ">= 1.0.0"
configuration: "default"
We need to tackle these three things:
An extension should be able to depend on a specific configuration from another extension. Can an extension define different dependencies for different configurations they supply? Can a user activate multiple configurations from the same extension?
Currently, what you propose only tackles the easy situation: when no configuration is asked for, it defaults to a default configuration.
Situation A Let's start with this one, given the list of extensions below in order of high priority to low priority. In this situation, extension B depends on A's config1, and extension C depends on A's config2 configuration, they both depend on D's config1 configuration. How should this be resolved?
- name: C
dependencies:
- extension: A
version: ">= 1.0.0"
configuration: "config2"
- extension: D
version: ">= 1.0.0"
configuration: "config1"
- name: B
dependencies:
- extension: A
version: ">= 1.0.0"
configuration: "config1"
- extension: D
version: ">= 1.0.0"
configuration: "config1"
- name: D
Options
GUI In general, what name should be displayed in the GUI for a config? These configs should be descriptive or else people don't know what to expect, but they should be short otherwise they don't fit in the GUI.
If option 1 or 3 is preferred, the GUI can be relatively simple: extension A would display which of their configs are currently selected. This displayed config name can change if extensions are activated that make a different dependency-demand. If option 2 is preferred, the GUI cannot be simple: both config1 and config2 are active in some fashion. At best, the extension A can display "(merged)" or "(custom)" as the currently active configuration, but that isn't very descriptive to the end user.
Situation B The same as situation A, except extension A released a version 1.1.0 with a new config1 with some new required values that conflict with config2. What should happen? If option 2 was chosen in situation A, this can mean that the same config people had (e.g. the currently presented one) doesn't work anymore.
Options
It would be great for certain plugins, if we had the option to preconfigure multiple configurations or be even able to just load them as files. Currently we have two plugins for this, say any of the AI plugins, they have a normal version, containing just files and one with just the configuration, named 'applied' -> This clutters up the list of plugins and also confuses users
It would be better if we had the option to define multiple configurations for a plugin, and even have the option to load a plugin without its configuration. I would also be neat if the plugin creator could then define a default configuration to be loaded and how the other options are called and if they are available. Most of the time it comes down to loading plugins just for their files to use them in other plugins and dropping the configuration.
I would propose the option of another dropdown just like with the version number of the plugin. I would say picking a configuration for the plugin can come after its activation, but ofc. we could also make it save the user selected configuration per plugin within the overall UCP / GUI status file which we already need for launch parameters to be saved.