pjf

It looks like you had an older version of FAR installed, and while the files in GameData were removed, the ships were not. CKAN will never ever overwrite existing files. I'm not sure which version you're using, the newer ones should provide a more helpful error message if they try. Solution: remove the old ships that were installed with FAR and try again.

One of the core designs of the CKAN is that it works without mod author involvement; they don't need to change their files, or embed metadata in their own mods. Lots of mod authors have added their own mods to the CKAN, but still more have been added by fans of those mods, often working with the mod author to ensure their assumptions are correct. The very same guide. Provided there's a way to explain to the CKAN client how to install a mod and how it relates to other mods and KSP itself (all of which is done using our metadata format), then the mod can be added to the CKAN. ~ Paul

For everyone wondering how they can get their favourite mods on the CKAN, there's a guide for that.

This is purely a hunch, but can you try installing it via the command-line? ckan.exe install FerramAerospaceResearch ? I'm going to guess that: (1) FAR is having a conflict because CKAN is trying to overwrite previously installed craft in the ships folder, and (2) the GUI client isn't telling you of the error even though it should.

Do you like GUIs? Upgrades that don't suck? Faster loading code? Great! We have a new pre-release! Download v1.1.3 aka Puffy Planet GUI changes GUI now supports new upgrade functionality, making upgrades much faster, more reliable, and with fewer side-effects. GUI is now significantly faster, especially when loading. Autodetected pre-CKAN mods cannot be selected for uninstall or upgrade. Courageous users can no longer switch their KSP install to nothing Command-line changes CmdLine waits for 'enter' after Y/N prompts, and now also works under Cygwin. Fixed instances of lines being double-spaced under Windows. NetKAN changes NOTE: NetKAN is a tool used by meta-data authors. Regular users do not require it. NetKAN escapes URLs before writing download links. NetKAN no longer tries to write out empty homepages in resources. NetKAN can be passed an auth token for github API calls. NetKAN more gracefully fails if a project has made no releases.

Firstly of all, a huge thank-you to everyone who has been fielding questions, you're all fabulous people! Secondly we have a new pre-release! This not only adds a much better upgrade system, but also has a GUI with improved stability and better error reporting. As a pre-release this will still have some rough edges, but the GUI is now much better at walking you through dependencies and module relationships, and the upgrade system will no longer try to uninstall mods which depend upon what you're upgrading. (Also yes, we definitely have plans for a ckan upgrade --all; expect that feature in 1.2.0!) Note that the GUI does not yet use the new upgrade framework. It may still try to uninstall mods which depend upon whatever you're upgrading; that's why this is still a pre-release. This will be fixed when we make our v1.2.0 stable release, and possibly before. CKAN v1.1.2 - pre-release - Cryovulcanism Download here. Upgrade functionality (command-line only) ckan upgrade no longer tries to remove modules which depend upon the upgrading module. Upgrades can take a version number. Eg: ckan upgrade MyMod=1.25. This also allows downgrading or re-installing of existing mods. ckan list provides visual indications as to each module's status. GUI upgrades Fixes to CKAN settings More flexibility in setting KSP start options Fixed a bug where the mod list columns wouldn't get resized properly on repo update Users are prompted to install suggested modules Errors are more consistently shown to users Download speeds are more accurately reported User can no longer inappropriately move to other tabs during installs Dialog windows disappear less frequently under Linux and OSX GameData is re-scanned when the user updates their mod-list NetKAN NetKAN supports --cachefile= allowing the user to use an already downloaded file for inflation. Internal CKAN cache is more compatible with external tools We more consistently ensure files are downloaded before starting installs. Preparation for adding additional free licenses to CKAN metadata. Preparation for adding support relationships to CKAN metadata. Preparation for targeted installs to GameData Image courtesy NASA/JPL/Space Science Institute.

I'm actually working on a better upgrade system right now. If you're feeling adventurous, then this branch supports a better upgrade system (you'll need to compile it yourself), this post has a preview, and this ticket is where we'll collect most of the dev work on this (although that probably won't show up until I make a pull request). So in a nutshell, you'll see upgrades a a stable feature in v1.2.0, and as an unstable feature potentially as early as 1.1.2. (Watch our releases page or this thread for updates.)

A quick suggestion if nobody else has made it... Procedural Parts provides both regular tanks and balloon tanks. The latter are lighter, but much more fragile, and collapse if they lose pressure. This would be a perfect interaction for DangIt. Balloon tanks can have a higher failure rate, and those which fail can leak at a higher rate. Balloon tanks that are empty of fuel and are leaking have a chance of deconstructing under powered flight or if landed, as the tanks lose structural integrity. (Although I haven't thought through all the deconstruction scenarios, so I'd consult someone with more rocketry experience for actual conditions.)

Tiny bug report. In RT2MM.cfg the stanzas activate off `RemoteTech2`, however as the mod now uses the name `RemoteTech`, these no longer appear to activate. I believe changing them to NEEDS[RemoteTech] would restore functionality, but I've not quite tested this yet. Edit: Tested this change, and it works great! Happy to send pull-requests if you're on github. ~ Paul

Omg i love you.

Apologies for this being a short post. Those of you on OSX having GUI problems may wish to check our FAQ here. Apparently it's a known bug with mono for OSX, and a fix/workaround is available.

Apologies, I seem to have fallen ill today, so I'm not going to be able to respond to everything, however... Yes. The terms of service expressly forbid harvesting content to create derivative works (emphasis mine):

Our latest unstable (testing) release is out! This has a GUI which is much more stable, especially under OSX and Linux, and handles relationship resolution much better! Hats off to nlight for doing an amazing job with this! Download v1.1.1 - Lorenz Attractor

Hooray! Time for another round of Q&A: This looks a problem with the metadata, as right now RealismOverhaul doesn't suggest anything. It almost certainly should! I'd suggest chiming in on this thread with suggestsions, although if you're comfortable with git and send us a pull-request, we *love* those. It just needs GameData and a README with a KSP-looking version number in it. Here's the directory we use for testing. CKAN is almost certainly getting confused with the spaces. You can quote the directory string, but then your shell won't do tilde expansion for you. $HOME instead of ~, or just cheating and moving ckan.exe into your KSP directory itself. (It always checks where it's installed first.) To adjust Ippo's suggestion: ckan ksp add ChooseAName "$HOME/Desktop/KSP 0.25 MAC/KSP 0.25 MAC" techman83 is dead on here. Those will be pre-existing mods. Sometimes if a mod has multiple libraries it ships with, then you'll see some funny names, but they're otherwise harmless. We search for these to try and not install mods you've already installed. If you ever remove them by hand, then running a `ckan scan` will help the client realise that, although future versions should be better at figuring this out on their own. All the best! ~ Paul

Also I'm excited about how easy it's going to be to spot when new releases are available and upgrade your mods. This is still very much a work in progress, but my initial results are very promising. This will be part of the v1.2.0 client. Notice the beautiful unicode indicators, and `ckan update RealChute` (output not shown) worked like a charm. Edit: For those wondering, yes, I hope to have both `ckan list --upgrades` and `ckan upgrade --all` commands, to make things even easier.

Thank you. The GUI is all nlight's amazing work, and the new GUI (which is currently in development, but you can build from git) is even nicer! (And fixes a lot of issues we were having under Linux. Nlight rocks!)

Just a quick note that v1.0.1 aka Protium is out. This is a bugfix stable release which better supports redirecting the output of `ckan available` to a file, pipe, or other non-console device. You can always find the latest stable release linked to from the top post, or at https://github.com/KSP-CKAN/CKAN/releases/latest. ~ Paul

Popping this in the FAQ right now, but if you're running Ubuntu/Mint/Debian, try: sudo apt-get install libmono-i18n-west2.0-cil libmono-i18n-west4.0-cil Apparently mono doesn't come with everything we'd expect. I'd love to find a way to bundle these in with the executable. If you're not on Linux, can you open an issue on this? We'd love to find a way to make sure everyone can use the CKAN regardless of locale. ~ Paul

Oh my! Lots of questions. I'll try to answer them all, but apologies if I miss one. Let me know if I do! Oh no! Can you report that on our issue tracker linked to in the top-post? I'm guessing it's just using a default install stanza (which looks for the mod name and copies the directory), but this is an easy fix with a custom install stanza. Thank you! I'll add that to our FAQ! By design, the CKAN does not allow the overwriting of files, nor does it allow installation order to be specified. This not only gives us a number of strong mathematical assurances (we can analyze dependencies as a set, rather than a graph), but it also means we can immediately detect conflicts, and we don't have to worry about mods installed "earlier" in the install overwriting those from "later" in the install when they're upgraded. The ideal solution (when you can't use ModuleManager) is to this is to split configuration from content. TACLS is a great example here; TACLS give you the core, but depends upon the virtual "TACLS-Config" package. That can be provided by TACLS-Config-Stock, or TACLS-Config-RealismOverhaul, which both conflict and provide TACLS-Config, which means that you can only have one installed at a time. If you're running RealismOverhaul, then it depends upon TACLS-Config-RealismOverhaul, so you get the right one. And if you're not running RO, then you'll get the stock config, because the RO config depends upon RO. Note that this makes it absolutely clear which package owns which files. If you were to upgrade TACLS, you'd still keep the RealismOverhaul configs for it if they were installed. Of course, the module authors haven't split their configuration from their content at all; instead our metadata documents specify the TACLS config file that comes with TACLS for "Stock", and the one that comes with RealismOverhaul for RO. No extra files are downloaded, but the end result is we still have strong assurances as to file ownership and consistency. A future version of the spec will probably support a "replaces" keyword, so one can say that "64K replaces Astronomers". This would effectively allow file overwriting, but in a much more intelligent way. If A replaces B, then we always take A's version of the file. Even if B is upgraded, then A's file remains. The big question here is what to do if A is removed; the goal goal of the CKAN is to provide a consistent install, and if A is removed then B is left without files that it originally had installed. I don't think we have a good solution for that yet. In Debian land, "replaces" used in this way is a packaging smell; it almost always indicates that a package hasn't undergone separation of parts, which is much cleaner solution. Our next spec revision (v1.2) is likely to have a much wider range of keywords to allow the selecting and exclusions of particular types of files, so it will be easier to say that `Foo-Core` installs everything except the textures, and `Foo-Textures-Default` installs only the textures. I know that EVE is already looking at splitting config from core, so we're on the right track there already. Our roadmap will be including support for child documents before we support 'replaces'. This means that you can have a top-level document which describes a mod, which contain sub-documents which inherit the parent's meta-data. That means producing metadata documents for when an existing mod should be split into core, config, and texture elements are *much* easier, so separation will become much less difficult than it might first appear. It's my hope that we'll never actually have to implement 'replaces', as it does pose a threat to our consistency model, and that means a lot of increased complexity (and potentially bugs). I might have misinterpreted this question, so if I'm going to try and answer all interpretations. If I've missed the intended one, let me know. If you're currently releasing everything as a single zip, then you can almost certainly continue doing that. CKAN documents are very good at selecting sub-sets of files, and it's both acceptable and encouraged to have multiple docs refer to the same underlying zip (which we'll only download once). Having a single zip makes things easy for non-CKAN users, as they just download and go. If you're looking at replacing multiple zips, then we index those fine from KerbalStuff (if they have different IDs), but our bot gets very confused if we're indexing from github; it doesn't yet understand two mods being released from the same repo. If you have big texture packs (like RSS does), and the user can choose between them, then those are probably good things to split out, especially if they don't tend to change between releases. However we certainly don't require it; it's just a little easier on the user's bandwidth. If changes can be made via MM, then that's always the best way to do things. It works via the CKAN or not, it never overwrites files, things will always get applied in the correct order. Where MM doesn't work, but overwriting was previously required, we'll try to see if there's a way that we can split an install into related components, as that means another mod can say "hey, I'm providing the textures here". ~ Paul

I love ScienceAlert *so much*, thank you. Also, as the easy install fairy, you can now install it with: ckan update ckan install ScienceAlert Many, many thanks! ~ Paul

Ah! We've been trying to figure out which packages people need under Ubuntu/Linux! Thank you so much for helping with this! Tellion, could you try `apt-get install libmono-system-core4.0-cil` and see if that provides any relief? ~ Paul

I'm taking a day to *play* KSP for the first time in months, with a 100% CKAN installed system. However meta-packages (which depend upon other packages, but don't install anything themselves) are something we hope to have operational for v1.2.0, along with being able to do a `ckan upgrade` to bring all your mods up-to-date for whatever version of KSP you have installed. The current milestone is here, but the contents may change a bit when I'm back from space, and will likely gain a number of bugs we want fixed. In any case, meta-packages are definitely on their way. (And possibly the ability to subscribe to additional metadata sourcesâ€â€similar to Ubuntu ppasâ€â€so the main repo isn't flooded with mod-packs, and developers can have repos which index test releases if folks want to try things early.) ~ Paul

Just a quick note that `ckan.exe update`, `ckan.exe install RP-0` now works, and installs RP-0 along with its dependencies. Although it's crazy-hella-alpha right now, and apparently NathanKell thinks I should be using various mods from git.

Hooray! Nertea, thank you so much! We're using this for RP-0, and so your release timing is perfect! I'm going to be playing a game with this tonight. I'm also delighted to say the CTT is indexed in the CKAN, and will pull in both ModuleManager and TechManager for you automatically: ckan.exe update ckan.exe install CommunityTechTree Thank you again! ~ Paul

Just a few minutes ago, we passed 100 mods indexed and installable via the CKAN. You are all amazing. Especially Raptor831, who just found and fixed a bug in our Stockalike RF Engine Config metadata.