politas

You should have the other mod as a dependency. You could set max_version on the dependency instead, to be clear about what has happened..

Are you using AMD graphics? You replied to my comment, where I gave instructions for testing whether you are affected by a specific bug, with a generic response referring to EVE lockups. Can you open the BoulderCo/Clouds PNG files in an image viewer without a lockup? If so, then export __GL_THREADED_OPTIMIZATIONS=1 is probably irrelevant to that bug.

Just fixed up the Kerbalstuffbot submission to CKAN, and looking at the versioning scheme you've been using, there's going to be some problems going forward. Could you increment lower levels with a "." separator? If all the versions on Kerbalstuff were in CKAN, this is the order they'd be in: 0.01 0.1 0.02 0.011 0.012 0.017 0.021 0.022 0.025b 0.026 0.026a 0.027 0.0121 I'm not absolutely certain about the 0.025b and 0.026a, but 0.0121 would be the latest version, since 121 is larger than 27. Leading zeros after a "." are ignored. Your first two versions fall to alpha-sorting, since they are otherwise identical. What would make things much easier for CKAN, causing less headaches for you and us due to users complaining about not seeing the latest version, is something like this: 0.01 0.011 0.012 0.012.1 (instead of 0.0121) 0.017 0.020 (instead of 0.02) 0.021 0.022 0.025 0.025.b 0.026 0.026.a 0.027 The CKAN scraper only grabs the latest version, so it'll start with 0.027. Don't worry about renaming the old versions, but if you could use this more standard <major>.<minor>.<patch> versioning system, there'll be less hassles all round.

It's certainly not impossible. Raise an issue as a feature request. I would suggest doing the feature as a new filter; sorting by popularity.

Kerbal Atomics needs someone to redo the submission; the kerbalstuff automatic submission usually fails to make a functional netkan file. Anyone who has the time to try helping out with mod submissions would be very welcome! Cryogenic Engines is showing 0.2.0 now. CKAN updates take some time.

No, because @RoverDude asked us not to list it for the moment. If it's ready to go on, we can release it.

I've added your comment to the relevant issue. The planet packs needed a big overhaul in CKAN, and that's still in progress. My initial thought is that there's a privacy issue involved in uploading people's active modlists that may be too much of a hurdle. This is not data that is automatically stored on a server and thus easily available for statistical analysis.

That would imply that you're selecting a set of mods that would create a conflict, usually. Try selecting and applying mods one at a time.

Well, it is implemented by way of the KSP install switcher. There's a limit to how many different models of operation can be supported. If you really want to be able to switch a single instance between sets of mods (which I really wouldn't recommend), you can create meta .ckan files with a bunch of "depends", and alternatively install and remove them. If you have only installed a mod as a dependency of a second mod, it should be uninstalled when the second mod is. (But beware upgrading the daughter mods) Change submitted.

There is the "New in Repository" filter, which may be useful, but it's an oft-requested feature and is on the list for enhancements.

CKAN tries to handle all errors that crop up. If you're getting unhandled exceptions, please report them with details, either here or (preferably) as an issue on Github. If you are talking about a mod downloaded for another KSP install, you can share your CKAN cache folders by symlinking the directories to a common location. You have the latest version there already; that's why it won't upgrade. Check out the releases list; it might make the versioning clearer.

Realistically, your best option is to copy your original KSP install and make a separate copy for each set of mods you want to use. Repeatedly installing and uninstalling mods is a recipe for disaster, even with the benefits of CKAN.

You'll need to change "spec" to "v1.4" to allow a "find" stanza in your "install". Like I said, clr.dll is part of .Net, not CKAN. Your .Net installation may be corrupted.

"<modname>/Ships/VAB" will work, though just "Ships/VAB" is easier, since we don't need to filter the Ships directory out from the main install stanza.

Don't know much about the Windows version, but you could try searching the wider Internet for help on clr.dll, since it's not part of CKAN.

You need to upgrade your .Net to 4.5, I think

Lovely. Pleasure working with you.

Something along those lines, but there's also going to be a problem with the licence string. What's the "AU" part for? EDIT: Ah, Australian port for jurisdictional purposes. Looks like they haven't been added to the list of CKAN licences. I'm going to set it to the international version for now, if that's ok and look into getting the schema updated. Don't suppose you'd consider moving up to the 4.0 international version overall? I'll make a start on fixing up the NetKANs. Oh, you also need a dependency for FinalFrontier, of course. This should work.

Depends on whether the ships are in correct SPH and VAB folders. If they are, then CKAN can install them, if not, then it can't so far. There are some ideas for how to handle it, but none have yet been implemented.

Right. Run "mono ckan.exe version" to check whether what you're getting now is a complete ckan problem or a problem specific to your install. If that gives you no errors, and shows "v1.16.0-0-g7206ce5 (beta)", then a few things to try in sequence, one at a time: 1. Run "mono ckan.exe clean" and test 2. Rename the file <your KSP directory>/CKAN/registry.json to something else and test (if this runs, it'll probably show incorrect information) 3. Backup your KSP directory and make a fresh KSP install, then try to run CKAN on that. Sorry this is all taking so long between replies; I keep having to go off to work, or sleep! If you got CKAN running happily after steps 2 or 3, upload your old and new registry.json files, and I'll see if I can fix the original. If even the ckan version failed, go back to the CKAN releases page and download the previous release for now,

Ok, your Mono version was definitely a problem. Mono 4.0 + is required for CKAN, as it says in the initial post (well, not exactly, but Mono 4.0 supports the .NET 4.5 framework). You're having troubles with JSON now, which is an entirely different problem, probably a corrupted CKAN/registry.json file. Why are you running "mono ckan.exe update" rather than just "mono ckan.exe"? @Ranger, can you check your Mono version?

Ok, thanks, @Pamynx, that tells us that MacOSX doesn't use the same directory as Linux for FreeDesktop config, but Mono is trying to do so. What is your Mono version, by the way? You can find that by typing this at a console: mono --version Can you also let me know what files you have in /Users/rleroy/.config and /Users/rleroy/.config/applications (if they exist)? Oh, and what do you get if you run this? echo $XDG_CONFIG_HOME

Ok, at this point, you'll need to go searching Mac forums for "I've accidentally deleted all my .desktop files, how can I recover them?" That directory does not belong to CKAN, it's a shared folder used by various applications. I know very little about MacOSX other than it is BSD based, so sheres a lot of features with Linux and other Unix-like operating systems. Please don't delete files when you don't know what they are.

Ah, I trust you made a backup? That file is supposed to exist. Can you open a command prompt, cd to /Users/rleroy/.local/share/applications and provide the results to this command? ls -al Oh, and the contents of mimeapps.list might also be useful, but it sounds more like a file permissions issue.

Does the file /Users/rleroy/.local/share/applications/mimeapps.list actually exist?