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

[stali79]

Hey guys a couple of issues to raise.

 

OPT Spaceplane Parts isnt showing up in my search in the repo list yet the legacy pack is (which i never put on ckan to begin with)

 

Also i am noticing that ckan seems to take a good few minutes of 'not responding' every time it encounters an issue.  Its taken me 4 hours just to get to the point where it tries to install the mods its downloaded because of the 'not responding' issue.

 

EDIT: Forgot to remove files from the ships thumbs folder....  so ANOTHER 5 odd mins of ckan being unresponsive. I cleared the folder so ckan could install and clicked apply etc.  suddenly its deciding it wants to redownload 680Mb of mods that it has ALREADY DOWNLOADED an hour ago

 

EDIT2: all I wanted to do was clean out my game and fly some planes...  if I had known it would take THIS long I would have not even bothered with CKAN.

 

Edited September 14, 2017 by stali79

[Blackline]

I do not like alle the "CKAN won't delete files..." as well. Why is there no manual override button?!?

And please add a way to integrate "manually installed mods" (marked as AD). And i quote that because the JSON registry was somehow dead and i had do delete it, so alle the mods that were installed by CKAN are now recognized as AD... horrible...

[Beetlecat]

There seems to be something amiss with the entry for Back in Black that appeared in CKAN yesterday: 

 

The "add-on" part of the mod seems to work fine, but (in using the GUI) checking the "install" box on this mod, it doesn't get added to the change set. Checked to make sure I don't have the mod installed, and have restarted/refreshed the repository multiple times. Thanks!

Edited September 17, 2017 by Beetlecat

[Dunbaratu]

I'm having difficulty with getting CKAN to support the idea of a mod that has two active public releases on github, one for KSP 1.2.2 and one for KSP 1.3.  Can someone help me by either:

1 - Helping figure out what I'm doing wrong.

or

2 - Saying flat out that CKAN doesn't support this idea so I stop trying.

The situation is this:  We just released an update for kOS.  I wanted it to be available both to people working in KSP 1.3 and to people still stuck on KSP 1.2.2 (realism overhaul people, mainly).  I have two variants of the kOS project set up, one with KSP 1.3 DLLs and one with KSP 1.2.2 DLLs, so I can compile both ways.

So the order in which we did things was this:

Step 1: Make the KSP 1.3 variant, updating all the relevant version files and cutting a ZIP and making a release/tag on github.  This ended up being release kOS-v1.1.3.0, at this URL (click here).

Step 2: Make the KSP 1.2.2 variant as a "back port", in which we take the working kOS-v1.1.3.0 made in Step 1 and add a few edits on top to put it back into a state that will compile on KSP 1.2.2 (mostly KSP 1.3 added an additional argument to all dialog boxes that KSP required - I took those edits back out again so it would compile for KSP 1.2.2)  These edits ALSO included changing all the version number mentions in the code (the AssemblyInfo stuff for C#, as well as the version files for AVC and CKAN), so this version is called kOS-v1.1.3.1 (as opposed to kOS-v1.1.3.0).  This version was released the next morning at this URL (click here).

It may seem a bit odd that the kOS release with the larger version number (1.1.3.1) is for the KSP with the lower version number, but this is because that more accurately reflects the chronological order the releases were done in.  We did the KSP 1.3 one first, then added edits for KSP 1.2.2 on top because this was far ,far easier than selectively adding all PR's *other* than the ones for KSP 1.3 changes to the older version.

Now, I checked, and the tag v1.1.3.1 on our github project (the one for the KSP 1.2.2 release that came out later) does have it's version of the GameData/kOS/kos.version file set up for KSP 1.2.2 and NOT for KSP 1.3.  I also checked and this is the same as in the ZIP file we attached to release v1.1.3.1.  The kos.version file definitely says this version is for KSP 1.2.2.

But it looks like CKAN is still culling kOS-v1.1.3.1 from the list when viewing an install for KSP 1.2.2.  It doesn't appear no matter how many times I refresh, and I assume that if I've waited more than 24 hours that means CKAN should have updated by now, so clearly it's not working (and yes I did refresh my local CKAN).)

Is there something I've set up wrong here, or is this an idea that CKAN just doesn't really support?

 

Edited September 21, 2017 by Steven Mading

[HebaruSan]

19 minutes ago, Steven Mading said:

I'm having difficulty with getting CKAN to support the idea of a mod that has two active public releases on github, one for KSP 1.2.2 and one for KSP 1.3.

Kopernicus does the same thing, so those devs might have some useful insights. It can work, but there are quirks. Most notably, CKAN will only check the most recent release each time it crawls Github, so if you upload them too quickly (which apparently does not apply in your case), intermediate versions can be skipped. For what it's worth, your versioning scheme sounds reasonable in principle (though I'm not a CKAN dev).

19 minutes ago, Steven Mading said:

Is there something I've set up wrong here [...] ?

I see two problems. First, both downloads' kOS.version files say:

  "KSP_VERSION_MIN": {
    "MAJOR": 1,
    "MINOR": 0,
    "PATCH": 0
  },

... which is being imported into CKAN's registry. So technically, both versions are marked as compatible with 1.2.2 (and 1.1.X, and 1.0.X), which could confuse things. I would suggest updating these to reflect the actual minimum KSP versions supported by each release (presumably 1.2.0 and 1.3.0), or just remove the _MIN and _MAX clauses completely since you do have regular KSP_VERSION in there.

Second, the version number for 1.1.3.1 was mis-entered in Github:

... which was also pulled into CKAN's database. So if you're looking for "1.1.3.1", that's going to show up as "1.3.3.1" instead. But I'm not sure whether that's what you're seeing from your description.

[Dunbaratu]

1 hour ago, HebaruSan said:

Kopernicus does the same thing, so those devs might have some useful insights. It can work, but there are quirks. Most notably, CKAN will only check the most recent release each time it crawls Github, so if you upload them too quickly (which apparently does not apply in your case), intermediate versions can be skipped. For what it's worth, your versioning scheme sounds reasonable in principle (though I'm not a CKAN dev).

I see two problems. First, both downloads' kOS.version files say:

  "KSP_VERSION_MIN": {
    "MAJOR": 1,
    "MINOR": 0,
    "PATCH": 0
  },

... which is being imported into CKAN's registry. So technically, both versions are marked as compatible with 1.2.2 (and 1.1.X, and 1.0.X), which could confuse things. I would suggest updating these to reflect the actual minimum KSP versions supported by each release (presumably 1.2.0 and 1.3.0), or just remove the _MIN and _MAX clauses completely since you do have regular KSP_VERSION in there.

Second, the version number for 1.1.3.1 was mis-entered in Github:

... which was also pulled into CKAN's database. So if you're looking for "1.1.3.1", that's going to show up as "1.3.3.1" instead. But I'm not sure whether that's what you're seeing from your description.

Yeah that can be a problem and I sadly don't know if I can fix it.

But I'm seeing neither 1.1.3.1 nor 1.3.3.1 in CKAN.  CKAN shows 1.1.0 for KSP 1.2.2 installs, which is quite old.

EDIT: I fixed the 1.3.3.1 just now to 1.1.3.1 but I doubt that will be enough to deal with it.

EDIT: I also edited the MIN version as you suggested for all relevant branches that go with those tags, however the tags themselves can't be changed because they're a snapshot of what the branch used to look like at the time they were made.  I'm not fluent enough in Git magic to know if I can engage in a bit of historical revisionism and change a tag's snapshot of what the branch looked like back when the tag was made.  But even so, the problem that this would have caused would be (I assume) CKAN thinking the release applies to old versions when it doesn't.  The problem I have is the opposite.  CKAN is *refusing* to allow a release to show up for an old version that should allow it.

 

Edited September 21, 2017 by Steven Mading

[HebaruSan]

3 hours ago, Steven Mading said:

But I'm seeing neither 1.1.3.1 nor 1.3.3.1 in CKAN.  CKAN shows 1.1.0 for KSP 1.2.2 installs, which is quite old.

I'm actually seeing ".1.1.0", with an extra period at the beginning. It seems to think that's the newest release for 1.2.2. I don't know why it would sort them that way, but that's also how it was entered in Github:

Hopefully renaming it to 1.1.0 will help: https://github.com/KSP-CKAN/CKAN-meta/pull/1292

[Dunbaratu]

Does CKAN get the version info by reading the kos.version file live from GitHub repo from the release tag, or does it get it by extracting the release's ZIP file and reading the kos.version file from inside the ZIP?

It matters because if it reads it from the tag, then it's impossible to fix this without making a new release because I can't retroactively change what kos.version looked like back when the release tag was created.

EDIT: Oh, I see - your PR was a PR to the CKAN repo, for manually editing CKAN's database, not a PR to the kOS repo.  Thank you for doing that.

 

EDIT: I ended up having no choice but to entirely delete the old release v1.1.0 (which was mis-labeled as v.1.1.0) from our github page.  Now let's see what CKAN thinks of that and if it will *now* find the correct v1.3.3.1 release for KSP 1.2.2).  I had to delete it because Github was lying in its user interface.  When you click "edit release" there are several fields to edit.  Most of them when you edit them they cause the release to edit in-place.  But not the topmost field.  The one that names the release (v.1.1.0), when you edit it, does NOT edit the release like Github claims.  It then replaces the old tag with a brand new tag with the new name, and deletes the old release and replaces it with this new one, which would be fine, but then it claims the resulting release is now the "Latest Release" when it's not.  That's not the same thing as "editing' a release at all.  After that screwup, I had to remove v1.1.0 entirely otherwise the releases page contained the lie that v1.1.0 was the "Latest Release" when it wasn't.  It was an edit of an earlier release but it got reported to the user like it was new.  Leaving it there would have caused users to download a very old release instead of the more recent one because github was lying about which one was the "latest" release.  Apparently github has no way to change the order of releases to make that "new" release look older like it really actually is.  I'd rather remove it entirely than be telling people to download an obsolete release as if it was new.

Edited September 21, 2017 by Steven Mading

[JK_Kerbineer]

I know this is probably the wrong place to post this question, or this has already been answered, but if it was, I could not find it, so I will ask anyway.

I bought KSP from Steam. but is now hopelessly broken, so I have to play on a copy of it. So, when I install CKAN it immediately adds itself to my steam game. How would I make CKAN run on a different KSP install?

[Loren Pechtel]

9 minutes ago, JK_Kerbineer said:

I know this is probably the wrong place to post this question, or this has already been answered, but if it was, I could not find it, so I will ask anyway.

I bought KSP from Steam. but is now hopelessly broken, so I have to play on a copy of it. So, when I install CKAN it immediately adds itself to my steam game. How would I make CKAN run on a different KSP install?

Why not simply wipe and reinstall the broken one so it will update properly in the future?

[JK_Kerbineer]

@Loren Pechtel That's the thing, when I try to reinstall KSP it pauses the download because access is denied. When I try to uninstall and reinstall Steam it leaves every single file there. When I try to delete it, it says I need to be the creator to do that. When I try that trick where you go as deep as you can into the files and then delete it, it says access is denied, and won't let me go any further. It's pretty much done for...

Edited September 22, 2017 by JK_Kerbineer

[Chakat Firepaw]

To begin with answering your basic question:  File>Select KSP Install>Add New

13 hours ago, JK_Kerbineer said:

@Loren Pechtel That's the thing, when I try to reinstall KSP it pauses the download because access is denied. When I try to uninstall and reinstall Steam it leaves every single file there. When I try to delete it, it says I need to be the creator to do that. When I try that trick where you go as deep as you can into the files and then delete it, it says access is denied, and won't let me go any further. It's pretty much done for...

This sounds like there is either a usage lock, (Windows¹ has a habit of getting stuck thinking that a file is still in use), or a file ownership issue, (the 'need to be creator' thing implies the latter).  See if you can find out which user owns the files and delete using that user account or try to force deletes with an administrator account.

One thing to try is to move/rename the directory so that Steam thinks it is gone.

 

1: I'm assuming you are using Windows because that sort of thing can't stop a "sudo rm -rf Kerbal\ Space\ Program", if you have sudoer privileges.

[strudo76]

14 hours ago, JK_Kerbineer said:

@Loren Pechtel That's the thing, when I try to reinstall KSP it pauses the download because access is denied. When I try to uninstall and reinstall Steam it leaves every single file there. When I try to delete it, it says I need to be the creator to do that. When I try that trick where you go as deep as you can into the files and then delete it, it says access is denied, and won't let me go any further. It's pretty much done for...

Sounds like you might have bigger problems than just KSP.

[A_name]

Is CKAN working on KSP 1.3? Sorry if this has been asked before.

[Brigadier]

1 hour ago, A_name said:

Is CKAN working on KSP 1.3? Sorry if this has been asked before.

Yes, although it's not a mod of the game but a utility to handle mods.

Edited September 23, 2017 by Brigadier

[politas]

On 22/09/2017 at 3:57 AM, Steven Mading said:

Does CKAN get the version info by reading the kos.version file live from GitHub repo from the release tag, or does it get it by extracting the release's ZIP file and reading the kos.version file from inside the ZIP?

It matters because if it reads it from the tag, then it's impossible to fix this without making a new release because I can't retroactively change what kos.version looked like back when the release tag was created.

EDIT: Oh, I see - your PR was a PR to the CKAN repo, for manually editing CKAN's database, not a PR to the kOS repo.  Thank you for doing that.

 

EDIT: I ended up having no choice but to entirely delete the old release v1.1.0 (which was mis-labeled as v.1.1.0) from our github page.  Now let's see what CKAN thinks of that and if it will *now* find the correct v1.3.3.1 release for KSP 1.2.2).  I had to delete it because Github was lying in its user interface.  When you click "edit release" there are several fields to edit.  Most of them when you edit them they cause the release to edit in-place.  But not the topmost field.  The one that names the release (v.1.1.0), when you edit it, does NOT edit the release like Github claims.  It then replaces the old tag with a brand new tag with the new name, and deletes the old release and replaces it with this new one, which would be fine, but then it claims the resulting release is now the "Latest Release" when it's not.  That's not the same thing as "editing' a release at all.  After that screwup, I had to remove v1.1.0 entirely otherwise the releases page contained the lie that v1.1.0 was the "Latest Release" when it wasn't.  It was an edit of an earlier release but it got reported to the user like it was new.  Leaving it there would have caused users to download a very old release instead of the more recent one because github was lying about which one was the "latest" release.  Apparently github has no way to change the order of releases to make that "new" release look older like it really actually is.  I'd rather remove it entirely than be telling people to download an obsolete release as if it was new.

Ah. You have your own Netkan. That makes it a little trickier for me to fix. The 1.3.3.1 release is going to be messing up all your KSP 1.2  CKAN users, and simply deleting the .ckan from the repo won't fix things. I'll do a PR to your .netkan file.

 

[linuxgurugamer]

22 minutes ago, politas said:

Ah. You have your own Netkan. That makes it a little trickier for me to fix. The 1.3.3.1 release is going to be messing up all your KSP 1.2  CKAN users, and simply deleting the .ckan from the repo won't fix things. I'll do a PR to your .netkan file.

1.3.3.1, do you know something that we don't? I thought the next version was 1.3.1

 

[politas]

On 23/09/2017 at 12:47 AM, JK_Kerbineer said:

I know this is probably the wrong place to post this question, or this has already been answered, but if it was, I could not find it, so I will ask anyway.

I bought KSP from Steam. but is now hopelessly broken, so I have to play on a copy of it. So, when I install CKAN it immediately adds itself to my steam game. How would I make CKAN run on a different KSP install?

In CKAN, use File - Select KSP Install and click on Add new to add another KSP instance.

Edited September 25, 2017 by politas

[dvp]

I just want to say this thing is freakin' slick. Very nice work and thank you very much.

[Galileo]

@politas @linuxgurugamer I'm looking for some clarification on an issue I'm getting when doing a pull request for CommunityTerrainTexturePack. Currently, CKAN requires you to download OPM in order to use CTTP, but I recently  made a repo for it and made the necessary changes to the netkan. However, when it goes through the checks, the console shows its still downloading OPM to get CTTP. 

All of the checks have passed in my pull request so I assume that when my pull request is merged, it will use my repo instead of sourcing it from OPM? It's just confusing because it seems the console ignored my repo when doing the checks. If this is normal behavior, and I just need to be patient, let me know please.  

Edited September 27, 2017 by Galileo

[linuxgurugamer]

Try changing the name locally.  I wonder if it is still using the global metadata 

[HebaruSan]

FYI, as of the past day or two or three, the GitHub repo for CKAN reports over one million total downloads (1,000,269 when I checked).

Congrats to all involved.

[Poodmund]

Does the NetKAN repository get any attention nowadays?

EDIT: On a serious note, the NetKAN checks seem to fail if I state a max version of KSP higher than a max version of KSP that a dependent mod states. During the check, it tries to pull the dependent mod at the higher version number of your own mod and therefore fails.

i.e. My mod - max version 1.9

Dependent Mod - max version 1.0

NetKAN check - can't find Dependent Mod that is compatible with v1.9; fail.

Isn't this bad logic?

I have set up my max versioning in this way to ensure that when KSP updates, I do not have to upload a new distribution with a new KSP AVC file to get CKAN to reindex new metadata.

Also, thanks Olympic for the merge.  

Edited September 28, 2017 by Poodmund

[politas]

On 29/09/2017 at 6:00 AM, Poodmund said:

Does the NetKAN repository get any attention nowadays?

EDIT: On a serious note, the NetKAN checks seem to fail if I state a max version of KSP higher than a max version of KSP that a dependent mod states. During the check, it tries to pull the dependent mod at the higher version number of your own mod and therefore fails.

i.e. My mod - max version 1.9

Dependent Mod - max version 1.0

NetKAN check - can't find Dependent Mod that is compatible with v1.9; fail.

Isn't this bad logic?

I have set up my max versioning in this way to ensure that when KSP updates, I do not have to upload a new distribution with a new KSP AVC file to get CKAN to reindex new metadata.

Also, thanks Olympic for the merge.  

The issue there was that we didn't have an override for 1.3.9, since most people use .99 as the <end of version> marker. Should be fine, now.

[TrooperCooper]

I am unable to download ckan.exe from Github.

It starts with super slow download rate and then always aborts.

Anyone else having trouble? Or is it a problem on my end?

 

EDIT: nevermind, was a rooter issue

Edited October 3, 2017 by TrooperCooper