Dazpoet

Tried this using both GUI and CLI in windows and linux and am unable to reproduce this behaviour. Please do as mgsdk asks: If we can get the registry.json both before and after you uninstall ModularFlightIntegrator that'll make it possible for us to track this down. Also what is your version of CKAN, what OS are you running and what KSP version are doing this with?

These sound like rather horrendous bugs in our relationship resolver. Please give examples and reproduction steps because this is one of the most critical issues I can imagine! EDIT: Also supply OS, CKAN version and KSP version please.

Answer the parts I think I have a clue about, leaving the rest for people more knowledgable than me. What if that file is a config file for the mod with your personal settings in it? I'm on slippery ice here but I _think_ this would mean that our upgrade process (as it works right now) would remove autocreated config files with personal settings if they lived in the same folder during upgrades. Just making a note of it here so pjf or some other dev can comment on if this is the case or not. Right now the clients will give you a list of all mods that will be uninstalled every time you ask it to remove mod X. Say that you attempt to uninstall Modular Flight Integrator, the client will then ask if you want to remove it, FAR and DRE since they depend on it. You want this to be a more explicit system somehow? No.3 is already in effect if I understand you correctly. E.g when installing TAC-LS you will be asked if you want the RO or Stock config, choosing one nullifies your ability to install the other one. Similarly if a mod in 0.90 depended on AerodynamicModel the users got to choose between FAR and NEAR, upon choosing one the other one became impossible to install. This system is used pretty heavily to get some of the visual mods to work with eachother. I very much recommend getting a github account since it makes issues and ideas much easier to track for us.

Better late than never but... this problem should no longer exist for KSP versions later than 0.90 as of https://github.com/KSP-CKAN/NetKAN/pull/1428 which was just merged.

Would be awesome, there's an open issue about it here https://github.com/KSP-CKAN/CKAN-core/issues/10

I'm assuming this will mean updating and adding to the 9 NetKAN entries we currently have for NearFuture, CryoEngines and Stockalike Stationparts rather than writing 12-13 new ones?

Based on the discussion so far in this thread I cannot see any need for this, I think you have misunderstood how the filtering works, stuff does not need to be in seperate folders to be filtered, you can filter on a file level. We currently use -Core for Cryogenic engines since it then matches the exact composition of the Cryogenic Engines .zip downloaded from KerbalStuff. Construction should be the same but I don't have that one in as fresh memory. We currently have all the hydrogen conversion configs in a seperate mod named NearFuturePropulsion-Extras which is suggested (not recommended, but that is easily fixed) as was approved here http://forum.kerbalspaceprogram.com/threads/52042-1-02-Near-Future-Technologies-%28NFSolar-NFSpacecraft-NFConstruction-hotfixed%29?p=1807385&viewfull=1#post1807385 I will admit it's currently batch-installs all the conversion configs at once, I wasn't aware doing so would be a problem (is it?) but it should be easily resolved with some smart filtering. You can, as zengei points out below, easily filter the .dll without having it in a seperate folder. You might find https://github.com/KSP-CKAN/NetKAN/pull/938 relevant which was closed since we couldn't guarantee a certain version of KSPAPIExtensions but https://github.com/KSP-CKAN/CKAN-core/pull/120 will resolve that problem once it's merged. KSPAPIExtensions is something of a headache but currently we list no mods which conflict with it so that part isn't a problem at this and shouldn't be until the version resolver code is in. I agree here, please open a github issue and reference the reports of faulty installs so we can fix whatever is broken.

Converting AD mods over to CKAN is a gamble at best. There's an old migration tool plugin somewhere in this forum which might still work and can seamlessly convert AD to CKAN handled mods. The best solution is to remove all AD mods manually, run a Refresh and then (after they're no longer there) install them through CKAN. If you've already installed other mods through CKAN which depend on AD mods though you'll run into Krakens which also require the removal of those mods before you can properly refresh. TL:DR; CKAN is best used on installs without any manually installed mods. EDIT; Discussion on AD mods can be found e.g. at https://github.com/KSP-CKAN/CKAN/issues/949 Need more information, what version of Firespitter and Firespittercore are you attempting to install? What mod is it you're attempting to install? What version of CKAN and KSP are you using? What is the exact error thrown? Same questions for Infernal Robotics. EDIT: Unable to reproduce on an empty 1.0.2 install, are you by chance updating firespitter rather than installing it?

I'd recommend an issue over at github if you haven't already opened one, I think you'll get much better answers there to all questiosn related to the code and what the different assemblies are. There is a non-optimal and dirty workaround found in https://github.com/KSP-CKAN/CKAN/issues/847 The best way to not get this problem is to not manually install mods together with CKAN handled ones. If you want a mod added please open an issue over at github

What version of CKAN are you using and with which version of KSP? Do you have any manually installed mods, if so which ones? What is the output of 'ckan list --porcelain'? Can you upload your registry.json somewhere so we can have a look at it?

I'm not sure what you mean with management overhead here, once you create .netkan files which inflates the .ckan files into our metadata repository the only management you'll ever need to do is if something fundamentally changes such as the folderstructure or new dependencies. You create a single .netkan file which describes where to scrape for new versions of the mod and how they should be installed (For NF mods this seems to be KerbalStuff) and every time a new version is released our bot picks it up and push a new .ckan file for that version to our users who can then choose to update to that new version through the client. I highly recommend furher questions are placed into the NetKAN repo where it's easier to track this issue than in a forum thread. I do very much want NF mods to work perfectly through CKAN since I use and love them so please bombard away with questions

NearFuture Props is grabbed directly from inside Stockalike Stations parts, aka we download the .zip from https://kerbalstuff.com/mod/351 and break out the Props folder and install that. Since the folder is needed by 2 of the mods and CKAN cannot, will not and don't want to overwrite anything it has been broken out into its own module even though it is grabbed from within the original mod. There is no magic apart from someone adding it this way. See https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/NearFutureProps.netkan You'd need to specify which mod add Extras, if you're refering to Near Future Propulsion and the modified nukes we've solved this by adding a NearFuture Propulsion Extras modentry like this https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/NearFuturePropulsionExtras.netkan which in turn depends on https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/NearFuturePropulsion.netkan . If you mean another of the NF mods I don't think we have any Extras installs for them but would love adding them if there's a need. As it stands right now when you install Near Future Propulsion it suggests to the user that they install the Extras for converting nukes, as was approved by Nertea here: http://forum.kerbalspaceprogram.com/threads/52042-1-02-Near-Future-Technologies-%28NFSolar-NFSpacecraft-NFConstruction-hotfixed%29?p=1807385&viewfull=1#post1807385 Is it very possible to create as many or as few NF extra modules as you want in CKAN and tell it exactly what dependencies are needed for each Extra, tell the user what that extra config does and have CKAN handle any conflicts between configs. You can also have the original NF mods prompt the user with both recommended and suggested (the latter being a weaker recommend) configs for each mod. If you'd like to learn how to add something you can start by looking at https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN and reading https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md or just look at examples in the NetKAN repository. I'd recommend opening an issue over at https://github.com/KSP-CKAN/NetKAN/issues/new detailing what you want to achieve and any and all problems you've seen so far so we can fix them. Adding the optional files in a .zip inside the .zip file would acctually be _extremely_ detrimental since that means we cannot grab them and install seperatly. If they're just laying about we can filter them out and create a seperate module to install them.

Would someone be able to post a picture/explanation of some of the grand tour contracts? I'm setting up my 1.0.2 modded save and am considering adding some of these contract packs but can't find any real explanation of what they add.

Looking extremly much forward to once again doing all these missions, but now in 1.0.2 Keep up the amazing work! Any chance of future additions of Hi-Res scans? I seem to recall them being worked on but never implemented?

Aww yiss! I've been wanting this sooo bad! It just updated on CKAN so it's out there now Since I'm very selfish in the case of this contract pack I'd like to point to http://forum.kerbalspaceprogram.com/threads/108097-1-02-Contract-Pack-SCANSat-v0-5-0-2015-01-22?p=1805510&viewfull=1#post1805510 which I'd love to see fixed, or pointed out as intended in which case I guess I'll work around it somehow.

I could have sworn that CKAN used to have '--force-opengl' as its standard start-up command but at least my install doesn't seem to have it anymore, could be due to me tinkering with it though. The addition of a memory usage field have been discussed briefly and aborted due to complexity at https://github.com/KSP-CKAN/CKAN/issues/922 As for categories there is a small issue opened about it here https://github.com/KSP-CKAN/CKAN-GUI/issues/93 which I recommend adding to as to get the discussion going if this is something many users want If you are into coding and feel like creating your own new tab with something in it I recommend looking into https://github.com/KSP-CKAN/CKAN/wiki/Guide-to-developing-CKAN-GUI-plugins and/or sending a PR which the devs can take a look at

I loved using DBT85s scansat contracts and now that I plan on starting a new save it seems this is the way to go. I'm confused though, it says at the starts there are only 2 contracts and I assume those 2 contracts can be generated for each body? One of them is obviously LoRes scanning, is the other one Biome? Am I understanding it correctly that I need to orbit a body for new contracts to show up? Do the contracts require new launches or could I send a probe with scansat equipment out to the Joolian system and massive amounts of dv and then grab contracts as I orbit the different bodies and cash in on contracts without new launches?

You are running into this issue http://forum.kerbalspaceprogram.com/threads/24867-1-0-2-FASA-May10th-1-0-2-Release-v5-34?p=1885707&viewfull=1#post1885707 Between uninstalling and re-installing do a refresh and everything should be fine and dandy

Yay Dazpoet has internet again and will now try to answer a bunch of questions! Sorry if I miss something and/or answer something that has already been answered. A quick reminder that the best way of getting answers is usually posting on github where many devs hang out. There is another program called KSP ModAdmin in this same forumpart, also I think there's something called TinkerTime or similar. I've never used either of them but maybe they are more to your liking? If you're on linux I assume you know your way around commandline? Using CKAN with '--debug' often generates very helpful error reports which our devs can look at. Please open a github issue, if you haven't already, detailing what problems you are running into and include the error reports, your registry.json file and reproduction steps so our team can look into it. You need to select the Stock config to install TACLS because of a weird interaction in how CKAN handles dependencies that aren't updated for the current KSP version. Installation through commandline works as it should. There is a fix to this in the works. A temporary workaround is to use 1.6.15 for now. Please open a github issue in the CKAN-meta repository and I'll have a look at this. 1) I recommend you use the autoupdate function so you won't have to download every release yourself, it will grab the latest version and circumvent this problem. 2) This is a tough one acctually. CKAN is all about consistency and taking control of a mod you manually installed isn't as easy as one might think. CKAN need the mod to be exactly as it would be if CKAN installed it to handle it and it also needs a way to autodetect it (which is done using ModuleManager naming scheme). All mods don't have identifiers = MM names and as such can't be located. Our spec only defines that an identifier _should_ be the same as the MM name and as such CKAN can miss out on a lot of mods. The plugin for migration by nlight can fix some mods but not all, same limitation with MM syntax. The best experience with CKAN is always to start with a clean install and handle all modinstalls with CKAN. pjf has mentioned that one thing he'd like to have working better is the ability for CKAN to take over manually installed mods but this is something that probably won't be at the top of the list right now. If you get KSP crashes I recommend you look into RAM usage and check for error reports for certain mods in your logs, CKAN does not do anything with your KSP except add mods to GameData and start the game. If your errors appear to be related to mods being installed in inproper ways and that is leading to errors then we'd love getting a report about it though. See earlier answer on this issue. There's an open github issue about this problem aswell, hoping a dev will get to it soon enough. This isn't the first time I see this requested and I think there are open github issues about it, I recommend you check github for issues about this and add your thoughts to them. As for mod profile it sounds like you're looking for metapackages, more information on those are available in the CKAN wiki in the CKAN-support repository over at github Working on it! Our buildbot is napping for the last day or so but once it wakes up your mod is a priority for me since I totally want it added aswell! There's a github issue about this open somewhere, please add to it because this sounds awesome! D'oh, this is due to how metapackages save things. I'll need to have a look at your installed-default.ckan file to help you and strongly recommend opening an issue over at github for tracking this issue since I think we'll need some discussion to work around it. This discussion is good even though an outburst of sorts started it. I'll be the first to point out what an abnormous pain in the behind it is for us, esspecielly those of us maintaining metadata, that not all error reports are posted in this thread (or in an ideal world, on github). Browsing every single modthread looking for CKAN issues is impossible and this is also why mods which are used by metadata maintainers are often the most updated ones since we have a personal interest in those mods and therefore read their respective forum threads. Some mod-makers also have their own liasons of sorts into CKAN staff/contributors meaning they poke that person when something isn't working and we fix it as painlessly and fast as possible. Of course some modmakers will for various reasons not want to associate themselves or their mods with CKAN, which is their right, but might see their mods added by third parties when that wish isn't known by CKAN staff. A solution which was proposed earlier in this thread and peaked both my own and dev interest was the ability to add a maintainer field to mod metadata where it can be pointed out who to hassle when stuff isn't working. If this was easily available in both the clients and our metadata it might lessen the load on mod-developers a lot since people adding mods will be the ones responsible for making sure they work. However the same people spamming "omg when 1.0 compatibility !!11!!elventyone!" for the umpteenth in threads will probably not care so some overhead will always exist. If the solution with a maintainer field sounds acceptable I'll see if I can find an issue report and if none exists I'll create one and bump the severity a few notches and see how hard it would be to get it fixed. However updating the metadata (we're currently indexing ~600 modules) won't be done over night even if this is added. As for automation only so much can be done right now, we do get updates from Kerbalstuff when new mods are added which desire to be on CKAN and we do our very best to get them onto CKAN in a timely manner. The files we generate are written in JSON though so a web frontend for adding them is far from impossible if someone feels like writing one. Lately a lot of discussion on irc and, to some degree, github have been about improving infrastructure and creating effective workflows and improved processes. We're currently in an ongoing process of making sweeping changes in how our github repositories are set up which will free up devtime and make it easier for us to field error reports and provide faster and better support. When it comes to maintaining metadata and making sure it's up to date the best thing would be if all users experiencing issues posted them onto github or atleast to this thread. Therefore if we want to work ourselves away from this problem I kindly ask each and every person reading to this to *please* point everyone reporting mods having CKAN issues, no matter how small, to github or atleast to this thread so the right people are blamed when stuff breaks. Pretty sure there's a request to add it on github but I'm awaiting a small fix before it can be merged, aka it'll be out soon. Do you have Kopernicus and/or KopernicusTech installed? If so remove it and try again. As for reporting repository issues the best place is github and will most probably always be github, at least for the forseeable future. This thread works but things are a lot more prone to be missed. Irc also works but if noone is around to instafix it chances are it'll be forgotten. I agree that some magical other place for these issues would be good but can't think of a better issuehandling system than github for metadata specific questions. D'oh, thanks for reporting it! I'll poke pjf on irc to fix it. EDIT: Aaaand it's fixed Need more information, please give the entire error message and the output of 'ckan list --porcelain'

What mods are not playing nice with Firespitter? Assuming it's KAX please see https://github.com/KSP-CKAN/NetKAN/pull/1217 This is very weird, I checked out the .netkan and see nothing wrong with it. I'll see if I can give it a nudge this weekend. EDIT: Fixed by mgsdk Have your friend refreshed his client and/or ran 'ckan update'? Does it work through command line using 'ckan install -c path/to/.ckan/file'

Not a solution as much as a workaround... You could grab the installed-default.ckan file from the CKAN folder in the KSP root directory. Copy it to some other place so you have a backup metapackage of all your mods. Open a terminal and run 'ckan remove --re *.?' To remove all mods. Manually remove ModuleManager. install all your mods again by installing the metapackage you copied in the first step. the above is an obnoxious workaround but should save you some of the trouble.

It is the partmanagerplugin messing with you, remove it and everything should work again. I Know of no workarounds for this problem.

if deleting them is a problem you might want to use autopruner which deletes them in an easily revertable way?

did you use CKAN before? If so you need to also clean out the CKAN folder since it now tells CKAN you have mods installed. Another way might be using commandline and issuing CKAN Scan followed by CKAN update. Settings -> KSP Commandline you can change the .exe and arguments for it there.

Devs are aware and working on a solution. 1.6.14 was marked down to a pre-release when the bug was found so we won't auto-update more people to a bugged client.