DasSkelett

Hey y'all, the problem arose from @Lisias reuploading the zip three times in very short succession combined with SpaceDock taking some time to update the caches of its web servers. See here and the linked PRs for the technical details. In any case, with some trickery I managed to make the bot index the metadata according to the zip of the latest reupload. If you hit "Refresh" in CKAN now and retry the installation, it should succeed.

The final major update, KSP 1.12.0, is now added to SpaceDock. May it be easy on your mods, so that you only have to press "Yes, update automatically", not "No, update manually". Edit: And the first hotfix, KSP 1.12.1, has been added as well. May your saves no longer break without Making History DLC installed. Edit: And the second patch release, KSP 1.12.2 has been added as well. May all your bases belong to us be anchored to the ground.

Sure, we can wait with indexing until the mod is stable and fully published, no problem. That's what most authors prefer. I don't want to index the mod before finding the cause of the visual bugs I experienced anyway, because it's possible that it's caused by how CKAN installs it in combination with the other visual mods, which would mean all CKAN users would suffer from the same problem, and that would obviously be bad. I've just tested again with only Homeworld, Kopernicus, MFI, ModuleManager and the DLCs installed on KSP 1.11.2, and all planets still have this bright "overexposed" effect. So I can at least rule out interference from any other mod.

Hey @smushanoob , I'm looking at this mod for addition to CKAN after we received the automated PR from SpaceDock. While trying to figure out the relationships of this mod, I decided to play-test it to make sure I got everything right, and it appears to me that this mod has a hard dependency on Scatterer. Is this possible? Without Scatterer and its default configs the planet textures and lightning are buggy, see the images I've posted here. Also I've noticed your release zip includes a .git directory, you might want to exclude that, it takes up space, increases loading times (because KSP needs to scan every file and folder inside to determine whether it's something it wants to load), and could potentially reveal secrets or other things you don't want to be public. The license of the whole mod? In this case you should update the forum post and the SpaceDock page, I'll adjust it in the CKAN metadata as well.

No, you can't overwrite that, they conflict for a reason. If you have ReStock(+) installed, you need Waterfall ReStock, otherwise Stock. Waterfall ReStock includes configs for the stock engines. Why do you want to install them both together?

You need to select the buildID.txt or buildID64.txt file, see the user guide. Is the path we can see in the picture already the new path, or the old one? If it's the old one, remove this instance and add a new one with the updated path (again, see the link above on how to do that).

Hey @Shadowmage, we've got a a request to add a mod to CKAN that depends on SSTU. To index it, we would need to index SSTU as well, but we don't index any mod without the approval of the author. I've seen some older comments from you, saying that you don't want it on CKAN, mostly because it's still very WIP. I see that it's still marked as WIP, and most releases on GitHub are pre-releases as well. Do you consider it still too early to put it on CKAN? Or if you say you don't want it indexed at all at any point in time, that would be okay as well, of course. Otherwise we'd be glad to index it. Once caveat: CKAN can't index GitHub pre-releases, so we'd only index 0.9.44.156 as latest version, until there's a new full release.

Chrome on Windows works fine for me. Firefox on Windows and Linux as well. This might or might not be a caching issue, since I know Chrome behaves differently there, and would explain why you see something that no one else sees. But we can't help you further without screenshots, we need to see and understand what's going on. If for whatever reason you don't want to or are able to post images in the forum thread, you can open a issue in the SpaceDock repository and show us there.

Okay, we will de-index and remove all HumanStuff releases from CKAN's metadata repositories, since we respect the wishes of the author. However, it is not possible to retroactively relicense a software (version) as ARR that has previously been released with an open source license (CC-BY-SA-4.0, in this case). We mirror all open source licensed / redistributable mods to archive.org, and those mirrored releases won't be deleted for this reason. Neither can we remove HumanStuff content from the PCs of CKAN users if they have it in their cache or installed in a KSP instance. Also an FYI, by European copyright law personal copies are always allowed, even of ARR work. In any case, wish you well for the future, wherever it carries you next.

The CKAN client v1.30.4 "Hubble" is released! Changes since v1.30.2 After we launched the previous release, a serious defect was identified, so we've sent a servicing mission. Features [ConsoleUI] Make current instance settings easier to find in ConsoleUI (#3385 by: HebaruSan; reviewed: DasSkelett) [GUI] Show game instance selection dialog if default is locked (#3382 by: HebaruSan; reviewed: DasSkelett) Bugfixes [GUI] Invoke GUI update calls in SetupDefaultSearch() descendants (#3380 by: DasSkelett; reviewed: HebaruSan) If you disabled the automatic repository refresh at startup, you can enable it again after updating. Check "Update repositories on launch" in the settings. Notes CKAN releases are built in clean-room conditions and do not contain viruses. If your virus scanner reports a problem, it's a false positive. Please report it to the company that produces your virus scanner, not us, since it's their software that's not working properly. This release of the CKAN has not been tested on Mono releases prior to 5.16.0. We highly recommend that Mac and Linux users upgrade to the latest stable release of Mono from mono-project.com. You will need the equivalent of the mono-complete package for your OS. Release image under public domain (created by NASA), courtesy of Wikipedia https://github.com/KSP-CKAN/CKAN/releases/tag/v1.30.4

Thanks, that sounds like a report we already got on Discord. It looks like a threading issue that only happens on some systems, and only when "Refresh on startup"/"Update repositories on launch" is enabled. Can you try editing the file "<KSP>\CKAN\GUIConfig.xml" (where <KSP> is the path to your KSP installation) and change "<RefreshOnStartup>true</RefreshOnStartup>" to "<RefreshOnStartup>false</RefreshOnStartup>"? From <RefreshOnStartup>true</RefreshOnStartup> to <RefreshOnStartup>false</RefreshOnStartup> Don't touch the "<RefreshOnStartupNoNag>" setting, just "<RefreshOnStartup>". If you have multiple KSP installations registered in CKAN, you might have to repeat this with the GUIConfig.xml of each KSP instance. Yeah, another bug that needs a config file edited to work around, sorry for that.

The last version that CKAN has indexed is v2.7.20201221, which seems to match the latest version on SpaceDock. Downloading the zip from SpaceDock, it also contains a file "~$Simplex Calculations THis One.xlsx", is this the one you are speaking of? Should we exclude that from installation through CKAN?

The CKAN client v1.30.2 "Hawking" is released! Changes since v1.30.0 Features [GUI] Add pt-BR localization (#3340 by: gsantos9489; reviewed: DasSkelett, HebaruSan) [GUI] Multiple search boxes with OR logic in GUI (#3323, #3374 by: HebaruSan; reviewed: Olympic1, DasSkelett) Bugfixes [GUI] Update dialog was too small for French localization (#3313 by: vinix38; reviewed: HebaruSan) [Build] Suppress nightly debs with even builds, push release debs to s3 first (#3317 by: HebaruSan; reviewed: DasSkelett) [GUI] Handle renamed modlist columns in sort list gracefully (#3319 by: DasSkelett; reviewed: HebaruSan) [Core] Fix AD mod upgrading, add tests, and fix all warnings (#3315 by: HebaruSan; reviewed: DasSkelett) [Core] Reset cache dir to default if creation fails (#3334 by: HebaruSan; reviewed: DasSkelett) [GUI] Tell user if instance addition fails (#3332 by: HebaruSan; reviewed: DasSkelett) [Core] Tell SharpZipLib to use Unicode when opening zips (#3345 by: DasSkelett; reviewed: HebaruSan) [GUI] Make incompatible mods warning dialog use newlines instead of commas (#3346 by: DeltaDizzy; reviewed: DasSkelett) [Core] Fix crash when overwriting manually installed files (#3349 by: HebaruSan; reviewed: DasSkelett) [Core] Skip modules with parse errors in deserialization (#3347 by: HebaruSan; reviewed: DasSkelett) [ConsoleUI] Update or refresh ConsoleUI mod list after repo or compat changes (#3353 by: HebaruSan; reviewed: DasSkelett) [Multiple] Replace repo-reinst with kraken, handle in UIs (#3344 by: HebaruSan; reviewed: DasSkelett) [Multiple] Make ModuleInstaller a non-singleton (#3356 by: HebaruSan; reviewed: DasSkelett) [Core] Better recovery when registry.json is corrupted (#3351 by: HebaruSan; reviewed: DasSkelett) [CLI] Fix installation of metapackages on cmdline (#3362 by: DasSkelett; reviewed: HebaruSan) [Multiple] Fix installation of AVP while removing EVE default configs (#3366 by: DasSkelett; reviewed: HebaruSan) Known Bugs CKAN can get unresponsive on startup if automatic repository (Workaround; Bug report) Notes You don't need to download AutoUpdate.exe. This is used internally by CKAN when a new version is released. Windows: users must have .NET 4.5 installed. Simply download the ckan.exe file and either store it in your game directory or somewhere in your filesystem where you have non-admin write access. Never run the CKAN client as Administrator! The .dmg is for installation on systems running macOS. The .deb file is for installation on Debian-based Linux distributions - Use dpkg-install/apt-get/apt to install the .deb file and you will then be able to run CKAN with just ckan. All required libraries should be pulled in as dependencies. You can also install from our APT repo for automated updates: sudo curl -sS -o /etc/apt/trusted.gpg.d/ksp-ckan.gpg https://raw.githubusercontent.com/KSP-CKAN/CKAN/master/debian/ksp-ckan.gpg sudo apt-add-repository -u -y 'deb https://ksp-ckan.s3-us-west-2.amazonaws.com/deb stable main' sudo apt install ckan The .rpm file is for installation on rpm-based distros like Fedora or OpenSUSE. Use rpm/yum/dnf/zypper to install the .rpm file and you will be able to run CKAN with just ckan. All required libraries should be pulled in as dependencies. Arch-based Linux users can install the CKAN client from the Arch User Repository, if it doesn't work install mono, download the ckan.exe and run with "mono ckan.exe". Mac/Linux/Mono users: please use the cert-sync tool to update mono's certificate store if required. This release of the CKAN has not been tested on Mono releases prior to 5.16.0. We highly recommend upgrading to the latest stable release of Mono from mono-project.com You will need the equivalent of the mono-complete package for your OS. CKAN releases are built in clean-room conditions and do not contain viruses. If your virus scanner reports a problem, it's a false positive. Please report it to the company that produces your virus scanner, not us, since it's their software that's not working properly. Release image under public domain (created by NASA), courtesy of Wikipedia https://github.com/KSP-CKAN/CKAN/releases/tag/v1.30.2 Please send some love towards two new contributors, helping to make CKAN better! @DeltaDizzy making the incompatible mods warning dialog more readable @gsantos9489 providing a Brazilian Portuguese translation for the GUI

See the following for why the forks ended up in CKAN as they are now: And how we suggested the situation to be solved: And see the following for where the forum thread link comes from: We can remove the link from the netkan, then it will be filled in from SpaceDock. Not our fault the new author decided to not create a new forum thread, but instead hijack the existing one.

I'm not sure how I should understand this question. I don't think I could motivate anybody outside the CKAN core team to work on this feature. It is a huge effort, and requires deep knowledge of CKAN's relationship resolver. Anyone not already familiar with it would likely have to spend a lot of time figuring out how it works, before they could get to work. And no, this is not because the code is written badly or anything, it's just complex in its nature (I don't know any other package manager that has such an exhaustive resolver, and I've seen quite a lot, being a full-time Linux user). I'm pretty sure this one's on us, me and/or @HebaruSan. And right now, you are doing your best to demotivate us from working on it. I'm sorry for that user. But as a developer, you sometimes have to weigh the importance of user complaints. And frankly, a <100 KiB unnecessarily installed mod that does nothing when installed doesn't really warrant dropping everything else and spending days to weeks on a difficult new feature. Don't take me wrong, this is still a feature I'd love to see in CKAN, but it's not enough to prioritize it over everything else. Totally agree with that. And yes, this case makes such a new feature more valuable. But aside the fact that we didn't know that it only was a conditional dependency back then (as mentioned above), we hoped that this was just a temporary bug that would be resolved quickly in the next release of the mod. Nobody knew it would stay around that long. And truth is, I still hope that this gets fixed "upstream" rather soon, especially now that there's work on a unified repository where all interested devs can contribute to.

This is simply not true. Fullstop. We are implementing new features all the time in CKAN. And yes, we even discussed and thought about conditional dependencies again after our recent discussion with you. We might implement them at some point. But the relationship resolver is huge and complex, something like this can't be done from one day to another, it takes a lot of work. And somebody needs enough time and motivation to do it. YOU as a mod author should really know this. Nobody every said that we won't implement this feature in CKAN, did we? Instead, we all agreed on adding the KSP-Recall dependency, and only afterwards you came to us, starting a discussion about new CKAN features and what not. However we are here to discuss fixing B9PW, not KSP-Recall. You talked like you, or we, could. But we can't. It isn't. You don't fix the relationship resolver through a GUI plugin. At the very least because it could only be used by GUI users, and leave out all commandline and console UI users. Dependencies resolving differently depending on which UI the user uses to interact with CKAN? That sounds like debug hell, you have to admit that. It's been a long time ago, so I might misremember. But I don't think we knew that this only affected users who also had MechJeb installed. If you look at what @HebaruSan wrote back then: For all the CKAN team knew and with the amount of users mentioning problems in this thread, it affected all of B9PW. Yes, going backwards I can see that we could've gotten the idea that it only affects MJ users, but we simply didn't understand it that way back then. Since there was no separate forum thread for this fork where we could have gotten clear information, and honestly the whole fork situation being a big mess (it still is, really), that's all we could do.

Hey @BobTheKerbal, a small request: Could you give your releases more uniform version numbers? They are currently all over the place, some of them having a "V" prefix, some not, some just being a random sentence, some having a random word suffix: "1.0" "OH_MY_GOD_IM_SO_SORRY" "V1.1" "1.1_-_Minor_Fix" It tends to confuse users who try to figure out what the latest version is and whether they need to update what they have installed. Furthermore, CKAN tries to sort mod releases by their version number in a natural sort order. When you get rid of the "V" prefix from one version to another, it would sort below the older version. Fortunately we have some safeguards in place to catch this, and can "epoch" the version to make sure it sorts above all existing releases. However this requires manual actions, and thus also delays the time until a new mod release shows up in CKAN (especially if it happens while all of us are asleep or otherwise busy). Take a look at https://semver.org/, it has some good recommendations on how well-formatted version numbers should look like. The important thing would be to stick to either prefixing or not prefixing a "V" (or "v" or variations thereof), and preferably replacing suffixes like "_-_Minor_Fix" with ".1", ".2" etc. ("1.1.1" would sort above "1.1").

Unfortunately not. For one, one netkan file per KSP release would be a maintenance nightmare. And replaced-by would break as soon as a user adds more KSP versions to the list of compatible ones, because... It doesn't work as you expect. "ksp_version_strict" never really worked at all, it was an unfinished feature not thought through. You'd think it changes the compatibility checks to ignore user selection, but the only KSP versions it does something is with is KSP 1.0.3 and 1.0.4. To make sure I understood the new problem: The issue is that users are confused why CKAN installs it all the time while the forum thread only says it's a dependency? Also while we're on it: it looks like your last release on SpaceDock has a typo in its version number, it says "Version 0.1.08". I suspect it should be "Version 0.1.0.8" instead, as on GitHub and all the previous releases? If you're changing back to the old format with the next release, it'll trigger an epoch bump PR, which needs to be merged manually. Thus there could be a small delay until it shows up in CKAN, depending on whether someone of the team is currently online or not.

You can either open an issue in our NetKAN repo to let us know, and we'll take care of it: https://github.com/KSP-CKAN/NetKAN/issues Or you create a pull request yourself to edit the .netkan file, which takes some work from us, but it's not required. Or you let us know via a forum post on this thread, just like you did now Anyway, thanks for letting us know, already on it! Edit: Done! What is "everything else"? There are two possible reasons for CKAN unsinstalling other mods along the one you want to remove: 1) The other mod depends on the one you want to remove; without the dependency satisfied it must be removed as well 2) The other mod has been installed as dependency of the one you want to remove; CKAN sees that no other mod depends on it anymore and stages it for removal as well, since you probably no longer want it. If you do want to keep it, uncheck the "Auto-Installed" checkbox (second column) for this mod. In both cases CKAN tells you the reason in the changeset overview tab.

It is mostly a tool for us CKAN devs and mod authors, and especially for our CI infrastructure. We can use fake instances to test complex relationships, check if mods install successfully, and test features of the client in general without needing several full throw-away game installations (which can become heavy on disk space). Our CI uses it as well to test any metadata changes we want to do before merging them, to make sure we didn't break anything major.

@GregroxMun why do you keep deleting old mod releases from SpaceDock? This creates problems for CKAN users on older KSP versions, since CKAN tries to download the mod release matching their KSP version. Their downloads are failing with 404s. Same applies to manually installing users, they won't be able to find older releases for older KSP versions.

It does, there's "PlanetShine - Default configuration". Like PlanetShine itself it is only marked as compatible with KSP up to 1.10, but if you can install the core PlanetShine, you should be able to install the default configs as well. Otherwise, try selecting KSP 1.10 as compatible.

Hey @Lisias! So recently I've been made aware that TweakScale needs KSP-Recall on KSP 1.9 and 1.11. However this is currently not reflected in the CKAN metadata. The problem is that we can't make dependencies KSP version specific. The simplest solution would be to just add it as dependency for all KSP versions. Would this create any problems for users on KSP 1.4.4-1.8 + 1.10?

The official installation guide is very newbie friendly if you follow it very closely step by step. It also explains everything you need to do in CKAN. https://github.com/KSP-RO/RP-0/wiki/RO-&-RP-1-Installation-for-1.10.1

This means that CKAN can't reach GitHub to download the current mod repository. This is often caused by bad anti-virus software or firewalls going crazy. Check if you have something of that sort activated, and try again after disabling it. Also check if you can reach https://github.com/ and https://github.com/KSP-CKAN/CKAN-meta/archive/master.tar.gz in your browser and whether the second one successfully downloads a file.