politas

As far as your CKAN client is concerned, it has its own metadata set that is a combination of all repositories you have selected (at least, that's my understanding), so a conflict just to "KerbalEngineerRedux" ought to work.

I'm afraid I don't have answers for a lot of what you're asking, but I'll answer what I can. We are making KSP1.1 mods available in CKAN as soon as they are released, or we are made aware of their status change for those that don't pick up KSP version from the information available for scraping. KER is a difficult case. CKAN mod curation rules are that we do not list pre-release versions of mods, on the assumption that if a mod author is not willing to call it a release, it's probably going to cause problems, and CKAN's purpose is to present its users with a working KSP install, to the best we can do with the information we have available. CYBUTEK is perhaps on the conservative side when it comes to releases, and we honour his intentions. It's not a release, only a pre-release, so CKAN won't list it. If you wish to run experimental versions of mods, CKAN as we present it is not the tool to do that. That said, we are very happy for anyone who wishes to create a repository with a different set of curation rules, and will happily add it to the list of available repositories. I don't know what exactly is involved in setting up such a repository, but if you wish to do that (either publicly available, or private), asking questions in our IRC channel would be the way to go. For myself, I am certainly happy to provide advice and assistance on specific metadata tweaking, and if you were to create a public repo of experimental mod versions, would most likely be willing to assist in maintaining such.

As far as I know, the only way is to set a default ksp install, then run the repair. Another thing you could try is doing a CLI `ckan install ModuleManager` after removing the dll. Not sure if that would bypass the consistency check that's crashing for you.

There's a review stage in the submission process, where we would catch it and make sure it works. I'm in the middle of re-doing the existing CKAN metadata , making separate install options for the individual packs. Oh, maintaining a single dropbox link for different versions messes up CKAN terribly. Going the Spacedock route would make things much better, and I can easily adjust the files I'm creating to work with a Spacedock source.

I can totally respect that decision.

Actually it looks like your mod should show up as soon as ProceduralParts is available for 1.1. GammaTextures has quite promiscuous KSP version settings (1.04+) If you upload it to Spacedock, we could scrape new versions automatically. Currently, we only have v1.11

I'd love to add that to CKAN, but I can't without a download link, rather than a sharing link. In the meantime, KramaxAutoPilot 0.2 is now set in CKAN as compatible with KSP 1.0.5. If you bring these things to our attention, either on the CKAN Forum thread or through a CKAN GitHub issue, we can fix these things up much faster.

What error do you get on that? CKAN shouldn't care at all if you delete an AD mod. Does a 'ckan repair' help at all?

You could manually reinstall the deleted mod, then delete it via CKAN. You should be able to find the cached file in in CKAN/Downloads if you search for the mod name

I'm getting the same problem, and so was Scott Manley.

EDIT: Ah, sorry, didn't look far enough back.

On Spacedock, go to the Changelog tab, you can find it there. Or if you're using CKAN, you'll get the right version automatically.

latest 1.1 prerelease now has 1.1 in the readme file, we've been told. Can those who have switched over confirm that?

They should be incompatible, yes. Unless they have a .version file which says they are compatible with earlier versions, like Community Resource Pack does.

"All versions" mods should be ok. We only put that on really simple stuff like flags.

So, KSP 1.1 Prerelease is out. CKAN's policy has always been that we do not support pre-releases of mods, because we want to make every effort to present a stable system. KSP 1.1 Prerelease is not a stable system. It can't be. If you've upgraded your Steam KSP to the 1.1 prerelease, mods are going to be broken. Most of them. I can't speak for the whole team, but my initial reaction is to say that CKAN is not useful for the prerelease, and like all KSP releases, even 1.1 full release is going to be pretty dodgy for some time. However, some mod makers are frantically getting 1.1 compatible versions released. So for those users who aren't jumping on the instability bandwagon, my advice would be to put CKAN down and foget about upgrading your mods for a while, unless something is broken. There's a high chance that some mods are going to be patched up to 1.1 without CKAN realising it. be very careful of upgrades!

Another option would be to give the Extras a separate NetKAN, that depends on AsphaltTiles and adds the Extras folder, so users can choose to use it or not. Actually, I think you say in your description that the Extras parts don't actually require the base mod, so just a "recommends".

Like this: "install": [ { "file" : "GameData/KerbalHacks/AsphaltTiles", "install_to" : "GameData/KerbalHacks" }, { "find" : "GameData/KerbalHacks/Extras", "install_to" : "GameData/KerbalHacks" } ] Or you could do this: "install": [ { "file" : "GameData/KerbalHacks", "install_to" : "GameData", "filter" : "License.txt" } ],

I know just how you feel. I want Astronomer's Visual Pack on my KSP 1.0.5, too, but CKAN isn't the block. Can I recommend Stock Visual Enhancements as a temporary substitute? That's what I'm using.

Thanks, @Sigma88

Ah, reading in that other post I have realised that the database change will probably prevent AVC from complaining about the information in the .version file. CKAN doesn't use the AVC database, though, only the information contained in the .version file. I've put in a change to address both mods.

Yes, CKAN is using the included .version file to know which versions of KSP are supported by this mod. I can code in an override so that v1.1.0 is marked as 1.0.5 compatible, but AVC will throw up an incompatibility message for anyone who has it installed.

Oh, wow. I strongly encourage a redesign with a cleaner, smoother interface. Users are far more likely to feel like paying for a premium account when a site looks like it is professionally run. Today, that means either high quality professional artwork, or a minimalistic, simple design ethos. A small colour palette, and text and background colour combinations that are easy on the eyes are the thing you are looking for. Also, a consistent look between screens is important.