CKAN (The Comprehensive Kerbal Archive Network); v1.28.0 - Dyson

[Murdabenne]

If I have the version of CKAN locked to KSP 1.3.0, the 1.3.1 mods do not show. if I open it up, then I get tons of updates for 1.3.1 that interfere with my ability to maintained my 1.3.0 game (some of the 1.3.1 are not backward compatible due to an API signature or something like that).  And I have, in the past, had the JSON get corrupted by going back and forth in the same install.  My current solution is to have a 1.3.0 install in one directory (I'm actively playing this as a career game), and a 1.3.1 (not being used) in another -- so they don't trash each other in CKAN.  Problem with that is I still have to sort through mods I haven't yet installed and see ones I do not intend to install at all in the 1.3.1 directory.  Plus all the wasted space, etc.

I wish I could just export my installed list from the stable version where I have my career game, then run a check against that list, then display the list with a go-noGo next to each, and an overall Red light if one or more are not ready, or a Greenlight if all are ready.  More or less a loadout checker for mods and game versions.

Edited October 10, 2017 by Murdabenne

[HebaruSan]

9 minutes ago, Murdabenne said:

If I have the version of KSP locked to 1.3.0, the 1.3.1 mods do not show.

Hmm, I tried the method from my previous reply in an old 1.2.2 install, and I see 1.3.0 and 1.3.1 under "Max KSP version" for mods that have such updates. Most of them do not have a checkbox in the "Update" column because the update isn't compatible with KSP 1.2.2. What do you mean that the 1.3.1 mods do not show, or that they interfere with your 1.3.0 install?

9 minutes ago, Murdabenne said:

Problem with that is I still have to sort through mods I haven't yet installed and see ones I do not intend to install at all in the 1.3.1 directory.

Interesting, so you're not just trying to update your current mods, but effectively planning to transition from one set of mods to another?

[Murdabenne]

Let me clarify if I can. I meant that I want only to see updated/new KSP Version X capable mods on my  KSP-X install, which CKAN handles well - giving me any KSP-X updates, and also listing KSP-X+1 that are backward compatible.  Also when there are mods that have 2 simultaneous update/releases,  then leave out the KSP-X+1, but listing the KSP-X compatible.   As far as I know locking CKAN to the exact (1.3.0 vice 1.3) current version does this.

But I also want to be able to track a whole set (identical more or less) to my installed set, except that I want to know when all of them are KSP-X+1 approved, disregarding any backward compatibility - i.e. the update does not need to be backward compatible (unlike above).

The problem is when I open up the version in CKAN to additionally allow for KSP-X+1 on my current KSP-X install, I can get some updates that break because they are not backward compatible.  Or else I get only the KSP-X+1 release which masks an update/release for my current KSP-X+1 mod.  Setting it to only allow the exact KSP-X+1 version that may show me only the KSP-X+1 mods, but it will not show me in a readily checked list, exactly which mods I am waiting for before I take the leap and move my career game over.  Also, doing this, in the past, has resulted in breaking the current state of my CKAN install when I go back to exactly updating off my previous KSP-X  selection in CKAN.

[HebaruSan]

@Murdabenne, can you please address directly the suggestion of using the "Max KSP version" column for this? It still seems like a solution to me, and I don't think that additional hypothetical explanations of your requirements will help me to understand why it is not.

I think it's a solution because it allows you to determine when it's safe to update your main KSP version. Once all your installed mods have 1.3.1-compatible updates available, you can update and install them. Until then you would only take updates compatible with 1.3.0.

What scenarios, past or current, are you encountering where this is not effective? Is it just a matter of the inconvenience of scrolling through the list and checking the values?

[Murdabenne]

As I said in my original post, this really isn't a functional addition, Its pretty much a preference so I can know, without having to alter my setup in CKAN, which mods I am waiting on.  It is not a functionality thing, it is more of a "I'd rather not have to sift thru all this" in order to see whats left before I can switch versions - right now I set it to 1.3.1 and sort, its still scattered because of the 1.2.2 stuff that's still current (but the metadata isn't updated) - like the SVE textures, or various configs.  Or addons that are "1.3" with no .0 or .1

And that also leaves open a massive "have to reinstall everything" problem if I forget that I'm set to 1.3.1 and not 1.3.0, and add all available updates - it will break my current install pretty badly.  So that's a risk I'd rather not have present.

Another thing I had in mind was that I'd like to be able to tag an interesting add-on that's not compatible (yet?) that I do not have installed, but that I would like to know when it updates so I can give it a try.  Or an old addon that I moved on without but would like to add back in once it works.  There's no way I know of, at present, to track a mod that you don't have installed and isn't current for your version settings.  Call it an "interested" tag, like the Spacedock "follow" functionality.  When there were a lot fewer mods, this wasn't an issue, but with the metric buttload of mods now, it is not that easy.

Edited October 11, 2017 by Murdabenne

[politas]

8 hours ago, HebaruSan said:

What about sorting by the checkbox column in the GUI (to float your installed mods to the top) and then inspecting the "Max KSP version" column? Once the entries in that column all say 1.3.1 or higher, it should be safe to upgrade.

Or just use the "Installed" filter, for that matter, then click on Max KSP version to sort by that, grouping the non-upgraded mods together.

[Galileo]

@politas could you update scatterers Netkan so my pull request for my mods will go through please? Scatterer works fine in 1.3.1 but I can’t get my netkans to go through for my visual mods because scatterer isn’t compatible currently via ckan  thanks!!!

[politas]

2 minutes ago, Galileo said:

@politas could you update scatterers Netkan so my pull request for my mods will go through please? Scatterer works fine in 1.3.1 but I can’t get my netkans to go through for my visual mods because scatterer isn’t compatible currently via ckan  thanks!!!

Been working on sorting out the dependencies for that PR for the last half hour. 

Aaaaand, it's done!

Edited October 11, 2017 by politas

[Galileo]

4 minutes ago, politas said:

Been working on sorting out the dependencies for that PR for the last half hour.

Oh man, sorry if it is causing an issue  

i see you committed my PR. Thanks a bunch!

Edited October 11, 2017 by Galileo

[Loren Pechtel]

17 hours ago, HebaruSan said:

 

Interesting, so you're not just trying to update your current mods, but effectively planning to transition from one set of mods to another?

It's a simple question:  Can I upgrade KSP without breaking my mods.  It's a question every CKAN user wants answered at times.  Currently, CKAN makes it very hard to figure that out.

[kcs123]

52 minutes ago, Loren Pechtel said:

Can I upgrade KSP without breaking my mods.

Most probably not. It strongly depends on mods that you have installed.

You might rather want to copy whole KSP game elsewhere and keep older copy of KSP and mods that works properly on that version of KSP. Do not update mods either on that install.

After that do a fresh install of latest KSP and install only compatible mods there.

[Loren Pechtel]

2 hours ago, kcs123 said:

Most probably not. It strongly depends on mods that you have installed.

You might rather want to copy whole KSP game elsewhere and keep older copy of KSP and mods that works properly on that version of KSP. Do not update mods either on that install.

After that do a fresh install of latest KSP and install only compatible mods there.

I was explaining what the issue was here with the versions.  CKAN has all the information to say if it would be possible to upgrade but it won't cough up the answer.  You see the max KSP version supported by the version of the mod you have installed, not the version supported if you were to upgrade everything.

[SpaceCube2000]

Hi, I can't install Stock Visual Enhancements on CKAN because Environmental Visual Enhancements isn't available on CKAN. 

It's fixed now, thanks. 

[kcs123]

1 hour ago, Loren Pechtel said:

I was explaining what the issue was here with the versions.  CKAN has all the information to say if it would be possible to upgrade but it won't cough up the answer.  You see the max KSP version supported by the version of the mod you have installed, not the version supported if you were to upgrade everything.

Alternative to CKAN and what it can offer is to install everything manualy. You can also try to upgrade KSP on existing older moded KSP instance, but that will most probably result in broken game and broken mods. You will have to find and remove broken mod by hand until you settle up with stable working set of mods. You will probably going to be on your own here, because even modders would not provide support until they update their mod for latest KSP version.

Asking for mod authors for additional variables in version files, to tell what mod version works and it is supported for each KSP version will be way too much. They already devote quite a lot of their limited free time to deliver mods to community and all that for free. Similar goes to folks that maintain CKAN. They do whatever is possible to do and to automatize most of tasks. And in automatized tasks falls both, metadata collection and delivering and install proper version of mods that works.

Considering amount of mods made for KSP and pretty much frequent updates of core game that often breaks stuff with mods in each update, CKAN works reasonably well.
It is far from perfect, but hey, whole world is not perfect and things goes in direction to improve everything. Just don't expect that everything can be solved overnight and use what already exist in best possible way, knowing all pros/cons from using it.

[Loren Pechtel]

1 minute ago, kcs123 said:

Alternative to CKAN and what it can offer is to install everything manualy. You can also try to upgrade KSP on existing older moded KSP instance, but that will most probably result in broken game and broken mods. You will have to find and remove broken mod by hand until you settle up with stable working set of mods. You will probably going to be on your own here, because even modders would not provide support until they update their mod for latest KSP version.Asking for mod authors for additional variables in version files, to tell what mod version works and it is supported for each KSP version will be way too much. They already devote quite a lot of their limited free time to deliver mods to community and all that for free. Similar goes to folks that maintain CKAN. They do whatever is possible to do and to automatize most of tasks. And in automatized tasks falls both, metadata collection and delivering and install proper version of mods that works.

I think CKAN already has all the information--look at a mod, click "versions" and you'll see what versions and what versions of KSP they are for.

[politas]

2 hours ago, Loren Pechtel said:

I was explaining what the issue was here with the versions.  CKAN has all the information to say if it would be possible to upgrade but it won't cough up the answer.  You see the max KSP version supported by the version of the mod you have installed, not the version supported if you were to upgrade everything.

That's not quite correct. The "Max KSP" value is drawn from the most recent version of a mod, not the installed version. It will show you which of your installed mods are ready for an upgraded KSP if you switch to the "Installed" filter. Clicking on the Max KSP column header to sort will group all the incompatible mods together. Messing with your KSP version compatibility is not required.

18 hours ago, Murdabenne said:

Another thing I had in mind was that I'd like to be able to tag an interesting add-on that's not compatible (yet?) that I do not have installed, but that I would like to know when it updates so I can give it a try.  Or an old addon that I moved on without but would like to add back in once it works.  There's no way I know of, at present, to track a mod that you don't have installed and isn't current for your version settings.  Call it an "interested" tag, like the Spacedock "follow" functionality.  When there were a lot fewer mods, this wasn't an issue, but with the metric buttload of mods now, it is not that easy.

Unfortunately, we don't retain local information about mods that aren't installed. When you refresh, the client replaces all of its information about mod versions from the repository, so there's no way to handle local, personal tags.

Edited October 11, 2017 by politas

[nobodyhasthis2]

3 hours ago, politas said:

That's not quite correct. The "Max KSP" value is drawn from the most recent version of a mod, not the installed version. It will show you which of your installed mods are ready for an upgraded KSP if you switch to the "Installed" filter. Clicking on the Max KSP column header to sort will group all the incompatible mods together. Messing with your KSP version compatibility is not required.

Agreed. I don't think people realise how much hangs on accuracy of the version data handed in. However may I ask a question. Are we not always bound to the limits of MAX and MIN version setting?

    VERSION - Required
    The version of the add-on.
    KSP_VERSION - Optional, Required for MIN/MAX
    Version of KSP that the add-on was made to support.
    KSP_VERSION_MIN - Optional
    Minimum version of KSP that the add-on supports.
    Requires KSP_VERSION field to work.
    KSP_VERSION_MAX - Optional
    Maximum version of KSP that the add-on supports.
    Requires KSP_VERSION field to work.

If the MIN/MAX is not provided correctly the wrong mods get listed. People can come all up with all sorts of alternative methods of sorting but the bottom line is still in the accuracy in data supplied. I still think people should be reading the mod updates notes first before accepting the supplied version data. Even if says mod update is both MIN 1.3.0 and MAX 1.3.1 compatible in CKAN.

I also find using the forum link to greatest CKAN feature ever for working out if a mod upate is safe for an old KSP install. If am not sure about a mods version control. I jump in to the forum and see if people are encountering problems. I also jump to the source page and read up developer notes. If things are looking good at this point I still export the installed mods to a test build to prove the supplied version data.

Is this the right way to go about things or I am wasting my time here double checking the up date process?

 

[politas]

7 minutes ago, nobodyhasthis2 said:

Agreed. I don't think people realise how much hangs on accuracy of the version data handed in. However may I ask a question. Are we not always bound to the limits of MAX and MIN version setting?

    VERSION - Required
    The version of the add-on.
    KSP_VERSION - Optional, Required for MIN/MAX
    Version of KSP that the add-on was made to support.
    KSP_VERSION_MIN - Optional
    Minimum version of KSP that the add-on supports.
    Requires KSP_VERSION field to work.
    KSP_VERSION_MAX - Optional
    Maximum version of KSP that the add-on supports.
    Requires KSP_VERSION field to work.

If the MIN/MAX is not provided correctly the wrong mods get listed. People can come all up with all sorts of alternative methods of sorting but the bottom line is still in the accuracy in data supplied. I still think people should be reading the mod updates notes first before accepting the supplied version data. Even if says mod update is both MIN 1.3.0 and MAX 1.3.1 compatible in CKAN.

I also find using the forum link to greatest CKAN feature ever for working out if a mod upate is safe for an old KSP install. If am not sure about a mods version control. I jump in to the forum and see if people are encountering problems. I also jump to the source page and read up developer notes. If things are looking good at this point I still export the installed mods to a test build to prove the supplied version data.

Is this the right way to go about things or I am wasting my time here double checking the up date process?

 

Those are the KSP-AVC rules. CKAN operates a little more loosely. Some mod releases have just a ksp_version_min, because the mod authors feel the interfaces they are using are intended to be stable. Also, in CKAN metadata, ksp_version is not required for min/max; they are treated as alternatives. The full CKAN spec is here.

Possibly the biggest issue CKAN has with KSP compatibility is Spacedock mods that have no KSP-AVC .version files. Spacedock does not support multiple KSP release compatibility, so mod authors are forced to select, say, 1.3.0, even if what they want to say is 1.3.

Edited October 12, 2017 by politas

[nobodyhasthis2]

1 minute ago, politas said:

Those are the KSP-AVC rules. CKAN operates a little more loosely. Some mod releases have just a ksp_version_min, because the mod authors feel the interfaces they are using are intended to be stable. Also, in CKAN metadata, ksp_version is not required for min/max; they are treated as alternatives.

Ok good to know.

What I was thinking about is mod authors handle it as individuals. There are no hard and fast rules here. Spacedock also only has one KSP version number as well to work with ?

I could be wrong but there still think a mod with assumed compatability. Say max KSP 1.3.99 should be listed as available to a KSP 1.3.0 install. That bit is alright and it has been done this way for a long time. However when the mod updates and the notes only say "recompiled for KSP 1.3.1". There would be absolutely no way we can tell if it still works in 1.3.0 without testing it. So the upgrade box appearance here is at risk.

Unless the the mod author explicitly says mod update not backwards compatible to an early version of KSP. In which case the upgrade option box should not appear at all on those early versions. The installed version is then the highest we can go without a full reinstall to the next KSP build.

Just for clarity here. I am one of those people that sit on old KSP versions until nearly all mods get released for the new game. Since I normally play with around 100 - 175 mods. It takes a while to move across. I get mods in the available pile that are not compatible. There always some uncertainty leading up to a KSP change over.

[politas]

1 minute ago, nobodyhasthis2 said:

Ok good to know.

What I was thinking about is mod authors handle it as individuals. There are no hard and fast rules here. Spacedock also only has one KSP version number as well to work with ?

I could be wrong but there still think a mod with assumed compatability. Say max KSP 1.3.99 should be listed as available to a KSP 1.3.0 install. That bit is alright and it has been done this way for a long time. However when the mod updates and the notes only say "recompiled for KSP 1.3.1". There would be absolutely no way we can tell if it still works in 1.3.0 without testing it. So the upgrade box appearance here is at risk.

Unless the the mod author explicitly says mod update not backwards compatible to an early version of KSP. In which case the upgrade option box should not appear at all on those early versions. The installed version is then the highest we can go without a full reinstall to the next KSP build.

Just for clarity here. I am one of those people that sit on old KSP versions until nearly all mods get released for the new game. Since I normally play with around 100 - 175 mods. It takes a while to move across. I get mods in the available pile that are not compatible. There always some uncertainty leading up to a KSP change over.

Mod authors are generally focused on ensuring support for the latest KSP release. I think assuming that a new mod release will work with older KSP releases (as opposed to relying on what the mod author specifies in a KSP-AVC .version file) is fraught with danger

I would say if the notes on a release only say "recompiled for KSP 1.3.1" you can assume that a) the previous version doesn't quite work with 1.3.1 and b) there is no real change in functionality between the two releases. If I was fixing up any metadata with such information, I'd cap the ksp_version_max of the previous release to 1.3.0, and set the ksp_version_min of the new release to 1.3.1. Staying with an older KSP version means increasing stability of your mod platform. You'll slowly get less and less mods' latest releases being marked compatible.

Getting the KSP compatibility details correct is a significant chunk of the manual edits we do to CKAN metadata. The more people report any cases where the CKAN metadata is either too permissive or not permissive enough, the better we can make the data.

[nobodyhasthis2]

34 minutes ago, politas said:

Mod authors are generally focused on ensuring support for the latest KSP release. I think assuming that a new mod release will work with older KSP releases (as opposed to relying on what the mod author specifies in a KSP-AVC .version file) is fraught with danger

I would say if the notes on a release only say "recompiled for KSP 1.3.1" you can assume that a) the previous version doesn't quite work with 1.3.1 and b) there is no real change in functionality between the two releases. If I was fixing up any metadata with such information, I'd cap the ksp_version_max of the previous release to 1.3.0, and set the ksp_version_min of the new release to 1.3.1. Staying with an older KSP version means increasing stability of your mod platform. You'll slowly get less and less mods' latest releases being marked compatible.

Getting the KSP compatibility details correct is a significant chunk of the manual edits we do to CKAN metadata. The more people report any cases where the CKAN metadata is either too permissive or not permissive enough, the better we can make the data.

Is really difficult and it is true that the system is only as good at the data provided. As a case in point I have just been watching the following thread after seeing an odd update note on Github.

My 1.3.0 build is asking for update to 1.2.0.1 which is a 1.3.1 build. The danger is

Quote

Additional Info: Apparently if mods use the Difficulty Settings menu they are causing 1.3.0 to crash if compiled against 1.3.1. As this mod uses that menu, I would expect the new release to not be backwards compatible.

So therefore that update box should not showing. So indeed cap the ksp_version_max of the previous release to 1.3.0, and set the ksp_version_min of the new release to 1.3.1. However change in progress so this may already be getting done. None the less it just happens to be a good example of how things can change between KSP versions.

 

 

Edited October 12, 2017 by nobodyhasthis2

[politas]

6 hours ago, nobodyhasthis2 said:

My 1.3.0 build is asking for update to 1.2.0.1 which is a 1.3.1 build.

That's a definite error. EarnYourStripes 1.2.0.1 in the CKAN metadata is only marked as compatible with KSP 1.3.1 It may have accidentally had wider compatibility at an earlier stage? That's really hard for us to prevent, I fear, when we scrape the data from an author-supplied KSP-AVC .version file.

[Loren Pechtel]

18 hours ago, politas said:

That's not quite correct. The "Max KSP" value is drawn from the most recent version of a mod, not the installed version. It will show you which of your installed mods are ready for an upgraded KSP if you switch to the "Installed" filter. Clicking on the Max KSP column header to sort will group all the incompatible mods together. Messing with your KSP version compatibility is not required.

Then it's getting confused somehow.  I've seen stuff where the max KSP version is not right based on the data I find in the version tab of CKAN.  Such cases always involve the versions being listed out of order.

[Murdabenne]

Since the CKAN GUI-app doesnt keep a full set of metadata locally (thus tags become problematic), would it be possible to write a CKAN addon that would handle tags for non-installed mods?

Also, maintaining mods manually really isn't an option once you pass 100 mods - or possibly as few as 50 or 75.  Thats a non-starter for a lot of us who "mod it till it crashes". CKAN is indispensable.

Also, it would be good to have a way to take a manually set up install (the full set of mods done manually), and let CKAN scan them and then take over maintaining them (apart from incorrectly installed or conflicting installed).

 

 

Edited October 13, 2017 by Murdabenne

[politas]

4 hours ago, Murdabenne said:

Since the CKAN GUI-app doesnt keep a full set of metadata locally (thus tags become problematic), would it be possible to write a CKAN addon that would handle tags for non-installed mods?

Also, maintaining mods manually really isn't an option once you pass 100 mods - or possibly as few as 50 or 75.  Thats a non-starter for a lot of us who "mod it till it crashes". CKAN is indispensable.

Also, it would be good to have a way to take a manually set up install (the full set of mods done manually), and let CKAN scan them and then take over maintaining them (apart from incorrectly installed or conflicting installed).

We welcome plugins, and have a plugin API available. 

Believe me, I'm completely with you on manual maintaining of mods being infeasible for large mod collections (though there are a few people who insist that it is not a problem and all, and don't understand why anyone feels the need for the CKAN. I generally try to ignore those people.

There has been a past attempt to write a plugin to get CKAN to take over a set of manually installed mods, which was not successful. If someone can figure it out, we'd welcome a plugin or code contributions!