DasSkelett

Sure, if you want you can change the KSP_VERSION_MIN. I've just entered what I knew from this thread. Makes sense that the suits don't break often. What do you mean with cross checking?

Either will work. The first one, "1.10" includes all patches falling in the 1.10 range, so it's like "1.10.X". The advantage of this one is, that in case we get to see a KSP 1.10.2 or 1.10.3... ,they'll automatically be included. The disadvantage is, that this new version in theory could break your mod while the version file would still claim it's compatible, however it's very unlikely nowadays. The second one hard sets KSP 1.10.1 as upper limit, so in case there's a KSP 1.10.2 you'd have to update the (remote) version file. I personally prefer the first method, but it's up to you which one you choose. Edit: God dammit I hate that buggy forum text formation.

Don't apologize for not knowing everything as long as you are open to learn new stuff - which you definitely are. You are doing great! Exactly, next step would be releasing a new version on SpaceDock containing HumanStuff.version inside the zip. You can do one on GitHub too, if you want to keep them synced, but at least for CKAN it's not needed. It doesn't matter for CKAN whether you set the version to 1.8.1 or 1.10.1 on SpaceDock, since it extends the compatibility range with the data from the version file either way. However, mod authors usually set the highest compatible KSP version on SpaceDock, since that's what most users use, and to signal them that the mod is updated and works. So in this case, you'd choose 1.10.1. You can write the minimum KSP version (1.8.1 or 1.8.0 in this case) in the changelog and/or the description, so RSS/RO players know that they can also use that release without problems. After you've uploaded this release, the CKAN team needs to add something called the "vref" to the metadata, so that our bot knows that it should look at the version file to get the compatibility info. We only need to do that once, so no worries for future releases. And that's it, after that you only need one release to support a whole range of KSP versions (well, as long as KSP itself doesn't break the mods between its versions...)!

Well, I've decided to take the work off your hands did a PR to include such a .version file in your repository: https://github.com/aazard/HumanStuff/pull/1

Given that they are identical, you could add a so-called version file as defined by AddonVersionChecker (AVC) to the zip, specifying 1.8 as KSP_VERSION_MIN and 1.10 as KSP_VERSION_MAX. CKAN can read this file and gather its compatibility information from it, allowing RO players to install this mod on 1.8.1. This is the usual and preferred way to specify multiple compatible KSP versions, and it's probably also easier to maintain (both for you and for the CKAN team). There's some more (although partially outdated) information about .version files with an example here, or if you prefer a more technical definition, here's the schema. Feel free to ask me or @HebaruSan if you need help setting up a .version file.

Appreciate the advice. Can't make any promises, since none of the CKAN team are lawyers or have otherwise the time to carefully check the legal meaning of every word they type, and I for one am not even a native English speaker. That should be it, then?

That's why we don't claim someone has exerted additional restriction, but someone expressed their displeasure ("They don't want this mod indexed by CKAN"). This is perfectly fine with whatever license you can come up with. Happy?

Thanks for the report. We are aware of the bug and are in the process of fixing it: https://github.com/KSP-SpaceDock/SpaceDock/pull/311 In the meantime, make sure that if you upload PNG images that they have no alpha channel, or upload them as JPEG which doesn't support alpha channels. Then your banner / thumbnail should be generated fine and not get deleted.

As y'all probably already discovered it's working again, Sorry for the interruption.

We're aware of the issue, affects all mods. Working on it. Update: @VITAS is rebooting the server now, so the site is entirely unreachable for the next 30m - 1h. Please stand by.

Heyho @blackrack, did you use a different software to create the zip file for this release than you did in the past? The NetKAN bot gets the following error trying to open the file to index it:

As @Brigadier said, make sure you have selected the correct KSP instance in CKAN. Although if you have put ckan.exe into the KSP directory, it should automatically detect and use this one. Did you also tell CKAN to actually install these mods? You have to check the checkbox on the left for the mods you want to install, the click Apply on the top and follow the installation steps. I'd recommend you to read this guide which explains some basics on how to use CKAN: https://github.com/KSP-CKAN/CKAN/wiki/User-guide#using-the-client

SVE conflicts with EnvironmentalVisualEnhancements-HR, which is the default/sample configuration of EVE. Since SVE is also "just" a configuration for EVE, you can't install it with the stock configs side by side. But SVE doesn't conflict with EVE itself, nor the other way around. To install SVE, you need to remove the default configs (named "Environmental Visual Enhancements - Stock Planet Config files" in CKAN, identifier "EnvironmentalVisualEnhancements-HR") first.

And we are up again! You can download all your favourite mods again! Thank you all for your patience! If you want a quick overview of what changed, read this: https://github.com/KSP-SpaceDock/SpaceDock/pull/301 In short: You can change your password on your profile page now https://spacedock.info/kerbal-space-program/browse/top is now usable. You can see a short mod abstract right below the mod name on a mod page. Everything should be a bit faster than before A lot of work under the hood, both code-wise and infrastructure-wise, hoping that future updates will be easier and faster to do.

Beep boop feedback report received. That sentence really got messed up somehow, the error message is not where it should be, going to fix that. Yes, your guess is correct @JordanLOL, it's the "GUIConfig.xml" that should be moved, so that CKAN creates a new one. You should check the settings after you moved the file and restarted CKAN, since moving/deleting the file will reset them to defaults.

Mods stay in that filter until you refresh the repository and there are changes. Try clicking "Refresh" and see if it's gone afterwards.

There is a big difference between just recompiling the mod (only changing the version lock) and uploading the zipped binaries, and properly forking it, with own repository, own README, own forum thread to give support, changing the mod name (be it only adding "Continued") so users don't accidentally ask for support on the original thread, spending time properly testing it, doing actual development work... The one recompilation you are probably speaking of was of the first type (at least initially), same with the recompilation that is currently passed around. And uploading binaries of LGPL-licensed source code without offering the source code for download IS violating this license, and it's definitely NOT the idea behind the license. On the contrary, it's there to prevent exactly that.

These are nice suggestions and indeed some features that could be added to the CLI. If you want to try implementing them, you would be very welcome! Maybe try to keep the syntax similar to the rest of the commands, so using "--ksp <instance name>" instead of "In <instance name>", and "reinstall" rather than "refresh" (which we use in the GUI for updating the metadata repository in the registry), but I think most of it will take care of itself when you see the source code of the other commands and how it works.

See "ckan.exe install --help" for example. You can specify the instance to work on with "--ksp". If I understand you correctly, "ckan.exe cache --help" does what you want.

This exception is thrown trying to update the repository from GitHub. In the past this was most of the time caused by some weird firewall/anti virus softwares that block access to GitHub.com (yes, even if it was supposed to be deactivated), or outdated Mono versions (if you are on macOS/Linux). Try accessing github.com in your browser, if it also doesn't work that's a hint towards a broken firewall. And if it does work, it might still be a broken firewall ;-) This isn't caused by a metadata change, but while trying to access github.com to update the local repository (see above). I suspect you don't have "Update repositories on launch" activated for these other instances, that's why it doesn't try to update it on launch and thus doesn't throw an error. There's probably not more to be found than the stack trace, which you already seem to have, but yes, you can launch ckan.exe via command line with "ckan.exe --debug". Be careful, this will log a lot lot lot of text to your console. Alternatively, see the instructions here, which make ckan log into a text file: https://github.com/KSP-CKAN/CKAN/wiki/User-guide#logging See above, not needed in this case. Nevertheless, a handy tip when you have to find a broken mod again in the future: You can export a sorted modlist in CKAN. Whenever you have a sorted list, the quickest way to find a certain element in it is to do a binary search. Just remove the second half of mods, see if the error is gone. If yes, reinstall half of the removed modules again, and retest. If not, remove the second half of the remaining mods again. And so forth. Much faster way to find broken modules!

CKAN asks the user to reinstall a currently installed mod if one of the following metadata properties changed: "install" "conflicts" "depends" "recommends" "provides" These are the relevant code lines for this. However, even if a reinstallation is triggered, CKAN still uses the cached zip if possible. We search for a zip in the cache based on three values: The identifier of the mod The version string of the mod release The first 8 chars of the sha256 of the download URL. So to automatically get prompted to reinstall a mod by CKAN after hitting "Refresh" you'd have to change one of the upper properties in the .ckan file, and to not use the already cached zip you would have to change "download" property, that means changing the path or filename of the local zip. I understand this is not very practical. An alternative that came to my mind is putting the following commands in your postbuild script: ckan cache clear ckan remove <mod> # ckan update # this should be called if you change something in the .ckan file ckan install <mod> This would avoid any need to include hacks in the .ckan file or work around the caching logic, by removing all mods from the cache, uninstalling your mod, and reinstalling it again, making CKAN "download" the newly built zip because it is no longer in the cache. It would also eliminate the need to interact with the GUI during the whole process. Attention: This removes _all_ mods from the cache, if you want to keep them cached, you should back up the cache folder first!

It means that our bot doesn't check the mod for new releases. You should still be able to install past releases. We freeze mods mainly for these three reasons: 1) The source where we indexed the mod from has been deleted (e.g. the SpaceDock entry or the GitHub repo). 2) The mod hasn't seen a new release for 3 years. In this case the mod is probably unmaintained and we likely won't see any new releases in the future. We do this automatically nowadays, see here (although it doesn't really work currently, but that's a different problem). 3) Its inflation fails for a long time (months) and it is unlikely that the author will create a new release to fix the problem in the future (i.e. the mod is unmaintained). Normally we try to make the author aware of the problem first and make sure that the author has indeed moved on/the author doesn't maintain the mod anymore. A lot of mods we froze this year and last year were mods hosted only on CurseForge, which we are no longer able to index due to Curse blocking our netkan bot, the CKAN client and other tools that look like bots to them (more information).

It is unfortunately very unlikely that Mono will be updated, you can read up and follow the discussion about that here. We do have planned to somehow restore the GUI functionality on macOS, however it is not yet decided how. This is even more difficult since we don't have any macOS user in the dev team. A few macOS devs tried out programming different concepts for a new GUI, however nothing came up there yet. So we definitely didn't forget all you macOS users, but so far, we don't have any solution, unfortunately.

Yes, that's exactly the reason. macOS droppen 32-Bit support with Catalina, which is need for Mono's WinForms implementation (the thing needed for the GUI) to work. See this pull request for more information.

Thanks! This is known and will be resolved in a new SCANsat release: https://github.com/S-C-A-N/SCANsat/pull/371 https://forum.kerbalspaceprogram.com/index.php?/topic/72679-191-scansat-v200-real-scanning-real-science-at-warp-speed-may-31-2020/&do=findComment&comment=3794796 https://forum.kerbalspaceprogram.com/index.php?/topic/72679-191-scansat-v200-real-scanning-real-science-at-warp-speed-may-31-2020/&do=findComment&comment=3794984