DasSkelett

To clarify, CKAN doesn't really need installing. It is just a single .exe file that you download and save somewhere you want and have write access to without needing administrator privileges. That means, somewhere in "C:/Program Files" or "C:/Program Files (x86)" does not work in most cases. Missing write access could explain the failing update. That means when you restarted it, you didn't open the newly downloaded ckan.exe, but the old one. Where is your ckan.exe saved? How do you open it, via shortcuts? Check where they are pointing to.

So do you want us to change the kref (download and metadata source) back to GitHub? Or freeze it until you have fixed the mod? It sounds like you want the latter. In this case I would ask you to drop us a note once we should thaw it again.

Can you give a reason why? Shall we freeze the .netkan?

No, CKAN is only able to determine that at install time. So to use the feature (that means autoremoving the dependencies, when the dependents are removed) for already installed mods, you can go through your mod list and manually check the boxes. You can also uncheck them whenever you want, if you say you want to keep that mod even if the dependents are uninstalled. Yep. Only difference, in CKAN it is more accessible ^^ You mean the ckan.exe file? That is where you saved it. Many save it in the CKAN folder of the main KSP instance. If you can't find it, or lost it in the OS reinstall, just download CKAN again. And remember where you save it to

On Linux you can change the locale by setting `LC_ALL=en_GB.utf-8` before `mono ckan.exe`. However I suspect you are using Windows, and I'm not sure if there's a way apart from creating another users with different language settings, and launching CKAN as that user. So I think we should add an option in CKAN to set the language.

First, did you also check the list of all mods, not only the compatible ones? It might be that this mods is per se available on CKAN, however not marked as compatible with the version of KSP you are playing with. If you find it there, and to be able to install it nevertheless, you can tell CKAN to also let you install mods for other KSP versions: Go to 'Setttings' > 'Compatible KSP versions' and select which versions you want. If you are playing with KSP 1.7, 1.5 and 1.6 should be safe to select. However, make sure to check the forum thread for these mods first, whether there's something posted if they work with the latest KSP version, especially don't ask for support (or if, mention your KSP version) if it isn't stated as compatible. Now if your mod really isn't available on CKAN: Do you mean install? Because if you already have the zip folder, you probably already downloaded it. CKAN can't install not-indexed mods for you, so you have to do it yourself. So if you have this zip folder, first check the forum thread and/or SpaceDock page to get some informations on how to install. Normally it is explained there. In most cases it's just a GameData folder in the zip file, then copy the contents of this GameData folder into your KSP/GameData folder. That should be it. But make sure to check if there are dependencies you have to install too. Here is a longer written tutorial on how to install mods in the KSP wiki. Does this help you?

Yeah, as I said, feel free to ask questions here in this forum thread or in Discord. We'll be happy to answer them. Just tell us where exactly you can't get further.

Where exactly do you have problems? We can help you here too (or in our new Discord server if you want). Video-wise, there might be a few on YouTube, just search for 'KSP install mods CKAN' or alike. But keep in mind that some of them are quite dated and some things don't necessarily work the same anymore. Also just to make sure, you looked at this paragraph in our wiki? That should explain the bare basics.

You need to select either the `buildID.txt` or the `buildID64.txt` in your KSP folder.

GitHub had an outage earlier: https://www.githubstatus.com/ Everything should be working again by now.

Done. Thanks for bringing it to us.

Hey @blackheart612, your last release includes an invalid Firespitter.version file. To be precises, it's an offline copy of this webpage, https://github.com/snjo/Firespitter/blob/master/For release/Firespitter/Firespitter.version, so actually html content. If I have to take a guess, somebody didn't click on 'Raw' before he hit ctrl + s For that reason, the last release fails to be indexed on CKAN.

That sounds reasonable and doable. Right now the status bar is hidden at startup and only shown once there is something to show, error messages, info messages or the like. I can't find the PR where it was done right now to see what's the reasoning behind it, but probably design choices. But if we put the current instance name and path there, it wouldn't be empty any more most of the time. I'll open a feature request on GitHub to gather some opinions from the team. Thanks for the suggestion! Edit: request created, if you want to add something, feel free to comment there and participate in the discussion @AlexO!

Hey! The instance managing dialog is a bit tricky. It sets the default instance when you click the 'Select' button. This means that you have to highlight the instance that should be the default one, mark the checkbox, and then click 'Select'. CKAN now reloads the modlist and stuff. Problem is, if you now want to change to the other, non-default instance and open the dialog, the 'default instance' is reset to none. So when you restart CKAN now, the window opens at startup and wants you to select an instance to work with, because it "forgot" which one is the default. We should change the logic of the dialog to set the default instance when checking the checkbox (not when clicking the button), and to not reset it every time you open it. I'll look at that the next days. For now you have to do some switch-around

In short, unfortunately not. If you want a long read about why it is not possible yet, take a look at #949. It is planned for a long time, but really not easy to implement. For now, you have to delete the manually installed mod files/folders first, and download + install the mods via CKAN afterwards. Do only a few at a time, starting with dependencies, then the dependents, to make sure you got every mod and that everything works.

Okay @Jognt and @Tekaoh, I don't think you will get anywhere with this discussion. If there's still a need to discuss this please do that somewhere else. At this point it has nothing to do with CKAN anymore, and just adds noise to this thread and spams everyone following it. Thanks.

There's the problem. You need to mark KSP v1.6 as compatible, ModularFlightIntegrator (a dependency of Kopernicus) is only compatible with KSP up to v1.6.9 in CKAN.

You most likely need to set your compatible KSP versions under "Settings" > "Compatible KSP versions" and mark "1.6", because, as @Nils277said, the two dependencies are only officially compatible with KSP up to 1.6, but they should work fine nevertheless on 1.7.

Well, that's definitely possible. At least it works again for all future releases, but if there are already some missing, we don't know that I can't think of an easy way to find missing versions right now, maybe it's possible with the Spacedock API. Something like checking whether the download link of every release uploaded after the domain change of every mod marked for CKAN indexing is present in one .ckan file in the metadata repository? Or maybe the API supports hashes? Or find releases uploaded in a time frame smaller than 4 hours? Have to take a look at that. But for now, the best would be if users (or mod authors) spot missing versions and bring it on us.

We backfilled the missing versions: https://github.com/KSP-CKAN/CKAN-meta/pull/1453. Also the Spacedock hook is fixed, so it should work in the future. Fixed in https://github.com/KSP-CKAN/NetKAN/pull/7212, thanks for bringing it to us.

No, that works fine. A lot of mods use a semantic-versioning-like style, and that specifically dictates an independent increase of each element. CKAN supports going from .9 to .10, in fact, that's CKAN-wise the correct way. There's something written in our spec: https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#version-ordering, extract: The version string is split, comparing non-digit parts lexically and comparing digit parts numerically. For this mod, this means we have ABCDEF (or AB.D.F) (= v4.0.10 and v4.0.9 for example). First part, A: it's the v. the v is compared lexically. It stays the same, so returns an "equals". Second part, B: it's the 4 in each case, compared numerically, returns "equals". Third part, C: it's the first ., not a digit, compared lexically (not really, has some special handling), returns "equals". Fourth part, D: it's the 0, returns "equals". Fifth part, E: Another dot. Sixth part, F: in the first case the 10, in the second case the 9. Compared numerically, 10 > 9: returns "greater than".

There are versions missing in CKAN. It's only the "last" release of every group that's indexed. The others are missing. A quick investigation shows that this is the case since 1.20.14: That was indexed/released on: So after the ksp-ckan.org domain expired. Version 1.20.13 was released one day before, that one had luck So I strongly believe that due to https://github.com/KSP-SpaceDock/SpaceDock/issues/192 CKAN doesn't get notified for new mod releases on Spacedock, and when the bot runs every four hours, he only gets the latest release. So to back-fill the missing versions we need to do some handwork, I think. For future versions, @HebaruSan, should we re-enable staging? Edit: The automatic --releases run would have a use case here too.

See The Spacedock servers are moving currently, it comes to outages. Just wait and retry

So my second solution should work. Even if it would work, problem is we don't know if KJR Continued won't go to v4.X.X one day. Normally you don't need it, but since you don't want KJR - Next to be a conflict, which also provides KerbalJointReinforcement, we have to fiddle around a bit. What my second solution does, is marking every mod that provides KerbalJointReinforcement as conflict up to version v3.3.3 > i.e. only the original KJR, because neither KJR Next nor KJR Continued have a version number that low. Now we still want to have a conflict with KJR Continued > Add its identifier too. KJR Next is still not a conflict.

Actually, some more testing revealed, it works in some cases, probably because how versions are compared in CKAN. But still, I don't think it's a good/stable/reliable way. Thanks, that helps. Does IR Next work with KJR Continued? If yes, you could set (in IR Next's netkan): "conflicts" : [ { "name": "KerbalJointReinforcement", "max_version": "v3.3.3" } ], This would only trigger a conflict with the original KJR, and KJR Next/Continued can still be installed. If no, this should work: "conflicts" : [ { "name": "KerbalJointReinforcement", "max_version": "v3.3.3" }, { "name": "KerbalJointReinforcementContinued" } ],