Ckan: Show DLC recommendations in the GUI / Improve handling in commandline

Created on 27 May 2019 · 6Comments · Source: KSP-CKAN/CKAN

Background

CKAN Version:
v1.26.2

KSP Version:
1.4+

Enhancement

Came up in https://github.com/KSP-CKAN/NetKAN/pull/7205.
"Water Launch Sites" seems to be the first mod that recommends a DLC.
Looking at the mod, it makes sense.
It works, it is shown in the relationships tab, and nothing crashes :)
But it is not shown in the recommendations/suggestions tab.

Also, the console outputs the following on installation:

4246 [1] INFO CKAN.RelationshipResolver (null) - MakingHistory-DLC is recommended/suggested but it is not listed in the index,
or not available for your version of KSP.

Question is: do we want to show DLC recommendations in the rec.-tab?
I imagine it as just a text entry, obviously without the ability to mark it for installation.

At least the console output should be changed IMO, to a short heads-up message, not that generic "not available" info, which is wrong in this case.

Cmdline Discussion needed Enhancement GUI

Source

DasSkelett

All 6 comments

If we're going to interrupt the install flow, it would be nice if there was more of a point to it than just displaying the string "MakingHistory-DLC" somewhere and making the user click Continue.

E.g., the KSP store has some pages where you can buy MH. Getting these on-screen would give the user the option to act on the knowledge that it's recommended:

HebaruSan on 28 May 2019

👍1

Maybe we could extend the kind property to allow DLC as an option, and then build an entry in CKAN-meta to hold info for each DLC?

{
    "spec_version": "v1.28",
    "identifier":   "MakingHistory-DLC",
    "name":         "Making History",
    "kind":         "DLC",
    "resources": {
        "homepage": "https://www.kerbalspaceprogram.com/product/kerbal-space-program-making-history/",
        "x_steam_homepage": "https://www.kerbalspaceprogram.com/product/kerbal-space-program-making-history-steam/"
    }
}

That would take care of getting the identifier into the list of available modules, and we could check the kind property wherever special treatment was needed.

HebaruSan on 1 Jun 2019

🚀1

Maybe we could extend the kind property to allow DLC as an option, and then build an entry in CKAN-meta to hold info for each DLC?
{
    "spec_version": "v1.28",
    "identifier":   "MakingHistory-DLC",
    "name":         "Making History",
    "kind":         "DLC",
    "resources": {
        "homepage": "https://www.kerbalspaceprogram.com/product/kerbal-space-program-making-history/",
        "x_steam_homepage": "https://www.kerbalspaceprogram.com/product/kerbal-space-program-making-history-steam/"
    }
}
That would take care of getting the identifier into the list of available modules, and we could check the kind property wherever special treatment was needed.

I really really like that!

We could also save the installation directory name (MakingHistory / Serenity) there, this way we should be able do get rid of the "customised" DlcDetectors,
and eliminate the need to push out a client update for each DLC release in the best case.

DasSkelett on 3 Jun 2019

👀1

Further expansion of the idea...
What if mods also could be "not installing anything, just a message with a link"?
These fake items will appear in the list as any other mods, can be "installed" or "uninstalled", and "installing" it is just showing message to user.

It allows to get around restricted licence of an dependency (NF-Aeronautics),
it makes list of installed mods in CKAN more related to real installed mods, so less mods will be forgotten

A installing routine is:

check a restricted mod in the list, press install
see a message with a link, where it could be downloaded
manually download the mod and put to Gamedata.
mod is installed (probably), CKAN shows it as installed.

A deleting routine is:

uncheck restricted mod
see the message that it is need manual deinstallation
manually remove the mod.
mod is removed (probably), CKAN shows it as non-installed.

yalov on 24 Sep 2019

@yalov's previous comment is very similar to #2957. I don't think it relates to DLC handling, though, since CKAN can't install DLCs, but it can reliably detect DLCs. Those quirks make DLCs a very special case in terms of what functionality can be provided.

HebaruSan on 12 Jan 2020

Getting the DLCs into the database as "kind":"dlc" isn't too hard; with a few code changes, it doesn't even crash if you try to install one:

Left to do:

[x] Display the resource.store and resource.steamstore links somewhere (I decided that resources.homepage wasn't a good fit because we need two links and it's not clear which one deserves more to be homepage)
[x] Make the name column display nicely
[x] Remove / disable that checkbox
[x] Remove / disable the checkboxes in the Versions list in mod info
[x] Update netkan validators for CKAN-meta pull requests
[x] Maybe replace some of the old DLC registry logic to use standard CkanModules instead of a separate list just for DLCs