Options to mod install inside CKAN window

[JustinKerbice]

What do you think about adding an options to CKAN mods, to add options ?
It could be:

in ckan meta files:

"options": [
        {
            "name"       : "high-res texture",
            "type" : "bool",
           "dir" : "GameData/some/thing",
          "default" : false
        }
    ]

So instead of having a "mod" named "high-res tex for mod XYZ" which depend of "mod XYZ" (which will pollute the CKAN mods list, by adding to much stuff in it), users could see in the mod window some options, boolean would be the most easiest (like high-res/low-res tex, adding craft examples, ...).
Later, some other kind could be added (radio buttons style for various tex res: low, med, high), multiple choices (various colour schemes or subset of parts,for big sets like B9).

[TeddyDD]

A good goal but a bad solution. What if you want to create package that depends on high-res texture pack? Or you want to create package for third-party texture pack for some mod (or alternative config)? And you still need to think about CLI users.

However I agree that all sub-packages with different configs and textures are polluting list of mods.
My idea is to add to spec new optional field like this

    "auxiliary": true // false by default

Mods with that flag set to true could be just hidden in mods list (of course user could turn them on if will)

[JustinKerbice]

:) that kind of Squad style thought (all or nothing or "binary"), we could have both with your suggestion.

For CLI users, an Aptitude style UI, if it doesn't exists already, would be the best, and I have to add, CLI users made their choice.

[Dazpoet]

I approve of the ability to hide mods (with an option to stop hiding them). I do think this kind of implementation would require some discussion beforehand to figure out what kind of mods should be hidden and which shouldn't.

A glaring example could be FirespitterCore which seems to be maintained and updated assymetrically to Firespitter, if only primary mods where shown a user might miss an important update to FirespitterCore simply because they can't see it. A GUI button doing the equivalent of ckan upgrade --all might solve that problem though.

In a perfect world I would wish that users upon opening the CKAN GUI and hitting refresh would only see a list of mods they can directly relate to. So no Astronomers pack - thisandthat, but rather only the Astronomers pack and then recommendations and suggestions would lead from there to installing what they want. Having done some tinkering with netkans and metadata files though I'd say we're still some way away from having a system like that, esspecially in GUI.

As for CKAN files dealing with subsets of partmods I think @Ippo343 had a very good point here

[TeddyDD]

In a perfect world I would wish that users upon opening the CKAN GUI and hitting refresh would only see a list of mods they can directly relate to. So no Astronomers pack - thisandthat, but rather only the Astronomers pack and then recommendations and suggestions would lead from there to installing what they want

This is what I had in mind.

[mheguy]

Closing in favour of #1021