politas

Well, the response I hear from most modders is that it does. CKAN's mission is to help users get a fully working installation of KSP with as many of the mods they want that will work together. We want to get it right. I personally spend a significant portion of my week (that I used to spend just playing KSP) correcting CKAN metadata to make it work right.

I've been pretty active in the CKAN team for the last six months or so, and I really do understand the problems that the minority of mod authors being vocal here have with CKAN. The CKAN project is a team effort, and a team that are often time-poor. A major part of the underlying philosphy behind CKAN is the open source movement, and I think this is where Ferram4, Roverdude and others are having conflicts. When you release something as open source, you are relinquishing control of it. That's fundamentally what it means to put something under an open source license. You have freely ceded any control over distribution, other than the specific limitations in the license you choose. To me it is frankly staggering to release something under an open source license and then complain that other people are taking away your ability to control the distribution. You gave that up when you released it as open source. You are opting in to alternate distribution methods when you release a mod as open source. We respect that decision. Now, Roverdude has relicensed all of his art assets as All Rights Reserved, and has clearly stated that he does not wish any of his mods to be listed on CKAN unless he submits them himself. I find that a sad decision, but we will respect it. I will personally make every effort to ensure that none of his mods will be added to CKAN unless he has published the metadata himself. The relicensing of the art assets is a simple thing for Roverdude to do legally. Personally, I wish there was a similar solution for Ferram4, because I'd be happy to never have to deal with him again, but I gather that FAR has many co-contributors and is basically impossible to relicense at this point. If it were simply my decision, I'd de-list FAR from CKAN and direct any complaints to the FAR thread, but I am bound by the project policies. Ferram4's suggestions for auto-checking metadata and improving our processes to cause less problems for mod authors have not been ignored. We have tickets open and discussions and work ongoing to remedy the issues. Unfortunately, between the flood of new mods being submitted to CKAN and Squad pushing out new versions of CKAN, we are often just too busy scrambling to keep things working to make any major architectural improvements. The other factor is that some of the most active contributors to CKAN are only working on metadata, with little coding ability. I really like the idea of a CKAN mod that dumps all information about CKAN installed mods into the KSP log. I wish I had the faintest idea where to start in writing one.

Actually, it is possible to do this, but it would mean extra work by mod authors to create specific details for each release of their mod. Personally, this is the exact problem that caused me to start using CKAN in the first place. I would upgrade a bundled mod because AVC was telling me there was a new version, and suddenly everything broke, and I had no way of managing what I had installed. So the problem you describe is not limited to CKAN, it's inherent in the way that mods use each other as dependencies.

No. it doesn't work that way (though it may in the future).

Not without more information. What version of Windows do you have, what version of .Net framework do you have, and the full text of the message details. Can you raise an issue here?

It's four hours old. Give us a chance to process it.

We have a whole Installing CKAN on OSX page, linked from the user guide. Not sure what more we can do to make it easy for Mac OSX users. What version of Mono do you have currently installed?

Ah, yes. One of the updates in the new version is to start using BuildID.txt instead of Readme.txt as the primary source for KSP version. Rename that file as well as updating Readme and that will work.

Report it in the Spacedock thread. They'll need to make space on the relevant server.

Merged now. Thanks for submitting!

Well, obviously, we have no way to know why or how you selected that option, only that you did. It's worth remembering also that not selecting the CKAN option on Spacedock does not mean that the mod won't be listed on CKAN. If a CKAN user asks for a given mod to be listed, we will generally do so, barring some legal block. Since you have licensed Larinax under CC-BY-SA-NC, you've given us irrevocable permission to distribute it.

It's still on CKAN because you selected the CKAN option when you put it on Spacedock, and it's still there (on Spacedock). Also, the forum thread for it still shows it as being an active mod (though WIP), and that you are seeking a replacement maintainer. Why would we make it unavailable through CKAN when it is still available through Spacedock?

Did you not add this to Spacedock? The CKAN tag was selected, which automatically submits a PR to list it on CKAN.

Righto. I'll cancel the Spacedock submission, if you'd rather it stay quiet for the time being.

If we update CKAN to pick up OPT Spaceplane Parts v1.8, CKAN users will likely have Firespitter 7.2.4. Would be a good idea to upgrade your bundled app to the version that matches the KSP version you're targeting.

Firespitter is up to 7.2.4, while the Firespitter.version in your download says it's 7.1.4 (Which is the last 1.0.5 compatible Firespitter)

Ok. I think it would mess up CKAN's auto-indexing if we tried to use it, though. That's also quite an old version of Firespitter core you have included. Has this been tested with Firespitter 7.2.x?

The .version file in the current Spacedock download has KSP_VERSION_MIN":{"MAJOR":1,"MINOR":1,"PATCH":2}, but "KSP_VERSION_MAX":{"MAJOR":1,"MINOR":1,"PATCH":0}. Not sure what that does to AVC/MiniAVC.

Following this advice, the nascent DestructionEffects-SemiContinued fork has been wiped out. @jrodriguez, if you're willing to take over this mod, perhaps a new thread is in order, so you can maintain an up-to-date OP?

Ok, thanks for clearing things up. It's a bit of a mess, all up. This PR should clear it up for people. Anyone wanting to use @Wicloz' Destruction Effects-SemiContinued will have to uninstall and reinstall. By default, CKAN users will switch to the updated version with the decoupler fix (I always thought that was odd, especially the way the smoke from the decouplers travelled with the accelerating rocket!) EDIT: That change has been merged, now.

It's been on Github for some time: Is there a meaningful difference between the two versions? Given the open source nature, I wonder why @Concodroid is releasing a separate version, rather than working with @Wicloz to make the best version possible. EDIT: Oh, and @jrodriguez has yet another version. Come on, people, how about combining your efforts? Contrary to @jrodriguez's statement on the last page, the version on CKAN is @Wicloz's github release.

KAX 2.6.3 for KSP 1.1.2 was added 12 days ago.

RCS Build Aid 0.8 for KSP 1.1 and 0.7.8 for KSP 1.0.5 are already indexed. I've got a watch on that mod so I get emails when new versions are posted. It should show up if you refresh CKAN.

I would say taniwha is neutral and uninterested, rather than hostile, from that post. Some modders have legitimate complaints about CKAN (which I think they give too much weight to, compared to CKAN's benefits), and some modders seem to have an irrational dislike of the entire concept. As for KSPIE, the Forum thread OP is pretty clear that Tweakscale is required. You could create a customised .ckan file with a slightly different identifier to change that if you want to, but we're not going to second-guess the mod author when such a clear statement has been made. Convince the mod author to change it, and we will, too.