politas

CKAN generates a .desktop file? I've never noticed that. Oh, there it is in Applications. And yes, mine is the same as yours, and it doesn't work under Ubuntu's Unity Desktop either. There's no ckan icon, too.I have a script that I double-click on to launch CKAN. But taking that file and modifying it to this works perfectly: [Desktop Entry] Version=1.0 Type=Application Exec=mono /home/me/Desktop/KSP/ckan/ckan.exe Icon=/home/me/Desktop/KSP/ckan/ckan.png StartupNotify=true Terminal=false Categories=Game MimeType=x-scheme-handler/ckan Name=CKAN Comment=Comprehensive Kerbal Archive Network I created ckan.png from the CKAN logo, resized appropriately, and saved that as a new file ckan.desktop. Note that I have taken out the parameters; they aren't required. - - - Updated - - - What happens if you run these from a command line ? mono /path/to/ckan/ckan.exe version mono /path/to/ckan/ckan.exe --help If they return expected results, try running this: mono /path/to/ckan/ckan.exe ksp forgetto make CKAN forget what it thinks your current installation has and where it is.

Which directory, ~/.local?

I'll assume that you didn't get an error running the mozroots command. Looking again at the output you got, I see that it says [COLOR=#333333]Could not find a part of the path "/home/theersink/.local/share/applications/mimeapps.list" Does that file exist in that location? This doesn't actually look like a certificates error at all, on close inspection. Where did you get your Mono package from?

It's not. It figures out a lot of version number variation quite happily. Yours just happens to be weird in a way that no one predicted.

Just asking for notification, nothing more. We'll do the work. I said "consistency from a computing perspective", not "consistency from a human perspective". But you're not exactly making things easy even for your non-CKAN users. This scheme you're using makes getting correct metadata significantly harder. You say we're causing problems for you? Well, you're causing problems for us, too. And if this is the first you've heard of it then clearly, the CKAN contributors have been dealing with this CKAN problem without forcing you to clean it up.

A couple of notes for things I have discovered recently. Having hard lockups, especially when trying to use Environmental Visual Enhancements? Running on an AMD graphics card? Try loading up the BoulderCo/Clouds PNG files in an image viewer. If you get a lock up on one or more of them, you've hit the same AMD Kernel driver bug I did. The only solution I could find was to replace my graphics with NVidia, since both the Catalyst and open source drivers use it. Now I have no issues. Fixed up Cities: Skyline, too. Trying to run a heavily modded KSP under Steam, and find that you can load KSP fine if you navigate to the folder and run KSP.x86_64, but you run out of memory or fail to load when launching from Steam? Steam launches the 32 bit KSP.x86 instead of KSP.x86_64. Rename it and make a link KSP.x86 -> KSP.x86_64, and you'll get the 64 bit version we all love so much.

This is your alpha-sorted list of versions: FerramAerospaceResearch-1-v0.15.3.1.zip FerramAerospaceResearch-1-v0.15.4.1_Goldstein.zip FerramAerospaceResearch-1-v0.15.4_Glauert.zip FerramAerospaceResearch-3-0.15.4.1.zip FerramAerospaceResearch-3-0.15.5.1.zip FerramAerospaceResearch-3-0.15.5.zip FerramAerospaceResearch-v0.14.3.2.zip FerramAerospaceResearch-v0.14.4.zip FerramAerospaceResearch-v0.14.5.1.zip FerramAerospaceResearch-v0.14.5.zip FerramAerospaceResearch-v0.14.6.zip FerramAerospaceResearch-v0.14.7.zip FerramAerospaceResearch-v0.15.0_Euler.zip FerramAerospaceResearch-v0.15.1_Fanno.zip FerramAerospaceResearch-v0.15.2_Ferri.zip FerramAerospaceResearch-v0.15.3.1.zip FerramAerospaceResearch-v0.15.3_Froude.zip EDIT: Sorry, those are the best job CKAN has been doing with the versions. Here's the actual zip file names you release, again alpha-sorted: FAR_0_15_1_Fanno.zip FAR_0_15_2_Ferri.zip FAR_0_15_3_1_Garabedian.zip FAR_0_15_3_Froude.zip FAR_0_15_4_1_Goldstein.zip FAR_0_15_4_Glauert.zip FAR_0_15_5_1_Hayes.zip FAR_0_15_5_Haack.zip FAR_0_15_Euler.zip FerramAerospaceResearch_v0_14_7.zip And for ModularFlightIntegrator: ModularFlightIntegrator-1.0 ModularFlightIntegrator-1.1.1 ModularFlightIntegrator-1.1 If you can't see why that is inconsistent, then I don't think you understand consistency from a computing perspective. Sometimes you've got two levels of numbers, sometimes three and sometimes four. As a result, they list in a wonky order every time you drop to an extra level. - - - Updated - - - I was going for the least effort from Ferram's perspective. Obviously, If he posted before releasing letting the NetKAN crew know the new zip contents, CKAN could be ready when it goes live. - - - Updated - - - Have you tried running this? mozroots --import --ask-remove That's what updates the certificate store and I believe it is common across all Linux distribs. I'm not sure what the name of the libcurl package is on Arch-based distribs. Does Manjaro use pacman? I found on this page the following comment: And following that are instructions that may help you. If you report back the correct package name, that can be added to future release notes.

This is easy to do. Create an issue on the KSP-CKAN/NetKAN Github when you are releasing a new version asking for someone to check that CKAN is installing FAR correctly after the upgrade. That'll bring your update to the attention of the NetKAN maintainers, exactly the people who can test and sort out any issues.

You'll want to include an abstract for each of the configuration packages to explain what they do (and you can mention that they are optional, too, which is unusual for mod config packs so far)

Not quite. Look at the EVE .netkans, and take a second look at the Planetshine ones. Change your "recommends" to a "depends" on the meta-package (after all, some kind of config is required.) Each of the config netkans should also include this: "depends": [ { "name" : "Arkas-Config" } ],

Searching on these forums can be very difficult. Ok. I see that they both do a small subset of what CKAN does. Neither appears to handle to problems of dependency cross-upgrades, apart from Module Manager. I don't believe we have established that. You keep claiming it, and I've denied it. There's even a special thread that's been created for FAR installed via CKAN, so that support requests can be moved somewhere you don't have to deal with them. CKAN contributors are bending over backwards there just to help you in particular, and you don't appear to even acknowledge that fact (although you have it mentioned in the FAR thread top post.) You have repeatedly said in this discussion that you just wish CKAN would go away. At this stage, I just wish you'd go away, and FAR with you. Clearly, lots of users like your mod and want to use it, so that's not going to happen. I don't know what caused my earlier problems. There were a bunch of realism mods I had installed, including FAR, and the game got a bit wonky, and I tried removing things gradually. FAR wasn't a particular "must-have" for me, so I wasn't too concerned about keeping it. Having now read a lot more of your crusade against CKAN, I think part of the trouble I had might have been the uninstall of FAR not cleaning up the FAR-created files, causing other mods to think FAR was installed when it wasn't. I've been going through the hassle of changing Linux graphics drivers, that involved a lot more serious computer issues for me than whether any particular mod was working. I gather the trouble with the incorrect ModuleFlightIntegrator version was caused by your inconsistent version numbering not alpha-sorting correctly. Of course not. Nothing is guaranteed to be perfect straight away. Especially since your antipathy towards CKAN means you aren't helping CKAN to handle FAR properly.

Except that I have now done a manual uninstall of FAR on that same installation, reinstalled through CKAN, and it's exactly the same. No idea what the heck you're complaining about. It worked perfectly, just like you want.

The big main ones, sure, though so much changed in KSP 1.0 that significant changes have happened in a lot of them, including FAR and DRE. There is a stream of new parts mods showing up on Kerbalstuff, though. They usually don't require a lot of testing, but they almost always require a bit of attention by the NetKAN contributors. Most of which gets sorted out without any bother to the modders. It's hard to get casual gamers to do thorough testing in any case. CKAN's simple uninstall/reinstall mechanism makes it easier to cut out possible confounders. I've never heard of those, and don't know what kind of functionality they provided. Searching the forums has been fruitless. Without that information, I cannot assess their comparative utility. You've made your opinion on that matter clear over and over. I'm not asking you to change your opinion on whether CKAN is needed, I'm asking you simply to accept that they are a big deal for people who are not you. They are a big deal for me. They stopped me be able to enjoy the game. I don't want to spend my leisure time playing the "get a working installation of KSP with loads of interesting mods" game. Because CKAN contributors want CKAN to work exactly right for the exact same reasons you want FAR to work exactly right. It's not an ideal solution from CKAN's perspective, but if CKAN's autodetection can be improved enough that it can recognise and log the version of a manually installed mod, then the issue of dependencies could be handled. Every mod that insisted on manual installation would be a headache for users, of course. Ignore for now whether the CKAN developers would like it; would it be an acceptable compromise for you? A lot of that is already done by a validation program. Exactly how much of it, I'm not sure, since I haven't been involved in the development of that program. I don't think it actually runs a CKAN instance in comparison to a simple unzip to test the download. I'm not sure how effective that would be. If if the "manual install" is based on old CKAN metadata, then I can't see it being useful at all.

I've just added a manual install of FAR to a heavily-CKAN-modded install (somewhere over 140 mods by CKAN's count) and it seems to have worked fine. Flaps and spoilers work as they ought to, a flat spin is basically unrecoverable, landing is bloody hard,... All the stuff I expect from FAR. As an interim step, I might add a note to CKAN's description of FAR recommending manual installation.

We don't test every release of the metadata, certainly. Mods that aren't a single folder with the same name as the mod name generally do get initial testing. But now it's starting to sound like we're getting to the heart of the problem being NetKAN, rather than CKAN itself. I think that's always been the understanding. It is much easier than a perfect manual installation, which is the primary goal. The problem CKAN tries to fix isn't "perfect manual installations", it's "imperfect manual installations". With manual installs, it's very hard to know every mod someone has installed. It's pretty easy to forget mods that aren't in your face. I don't see how CKAN makes any of this worse when users come to you with complaints. Even without CKAN, you can't assume perfect installations. CKAN will at least give users a list of all the mods they've installed with it. I already mentioned that testing every new version release of over a thousand mods is not a practical goal for a handful of time-limited volunteers. What kind of mod manager doesn't need metadata? Well, I've tried to explain all the things I experienced that are the why for me, and your response has been to dismiss each of them as not a problem. * Mod packages are not discreet units and an upgrade to a dependency can break things * Installed mods are not always simple to uninstall (folder names can be pretty random), so I needed to go looking in the downloaded zip file to check where the installed files were * Keeping track of every mod installed meant building my own filing system for tracking things * Every plugin mod has the potential to interact poorly with other plugin mods, so I needed to revisit the entire list of installed mods before installing any new mod and gain some basic level of understanding not simply what each mod was supposed to do, but how it did it, and revisit all of those factors for the whole mod list every time I wanted to try a new mod. The number of comparisons starts to get ridiculous after a while * Mod management was taking up all the time I had available for gaming I can see that. At no point in this discussion have I denied that there is a problem that needs to be dealt with. I don't see the problems CKAN causes as worse than the hell I was getting myself into before I found it, so I'm not interested in solutions that involve getting rid of it. Ouch. Sounds nasty. But I gather that's been fixed? Well, it's not surprising that you haven't come across the worst Linux issue that I came across, a bug in the Linux AMD driver that under some circumstances causes whole desktop lockup on loading certain PNG files, such as the ones in EVE. I could consistently make my computer freeze by loading EVE's kerbin1.png in an image viewer, much less in KSP. (Had to buy a new graphics card to avoid that one!)- - - Updated - - - More than warm, I'd say I think there is perhaps some over-extension. The flood of new mods that have been arriving since the KSP 1.0 release has been taxing the resources and dedication of the NetKAN contributors. You might have a good idea in there to have a metadata flag that stops CKAN doing an automated install for certain complex and/or fundamental mods. That sounds like it would answer Ferram's main concern. I don't think removing automated installs completely would go down well with CKAN users.Ferram, does that sound close enough to the "option to de-list" you were talking about? If so, I'll raise it as an issue and evangalise it.

No, I don't deny that. But that is not what you said that I objected to. You said that when anything went wrong, the first thing the CKAN maintainers do is throw everything on the modders. The discussions I've seen on the NetKAN github do not support that conclusion. Asking a modder to change how they do things or help with the CKAN packaging comes very late in the process. If anything, the problems users are having with your mod through CKAN are probably at least partly due to CKAN contributors trying and failing to fix the metadata themselves without talking to you, while not understanding how your mod actually works. The assumption is that mods stay basically the same, with the same requirements. If the dependencies change radically, then yes, things will get screwed up. That is definitely a flaw in the CKAN model, but testing every metadata change is simply not a practical goal for CKAN maintainers. CKAN is tracking over a thousand mods, and there are only a handful of contributors. The initial metadata addition is tested, although the automated CKAN integration KerbalStuff implemented is somewhat of a hack job, and I'm not sure how thorough the testing of any submissions it puts in that get past the automated verification checks (which is not a lot). But again, you're talking about a different thing than what I said. I was responding to your assertion that CKAN contributors automatically refer any issues that crop up to the modders. I never said anything about testing metadata releases.EDIT: Looking back, I realise that the paragraph I was replying to started out with a comment about testing metadata, so it may have seemed like that was the statement I was saying was not true. It wasn't. It was the final statement in the paragraph. My apologies for the confusion. I didn't say you were lying, I said that your claim was not true; that you were mistaken. I easily believe that users are having FAR installs not working through CKAN. I haven't managed to get a working FAR installation since KSP 1.0 came out, myself. My solution so far is to not use it in the hope that it'll get fixed eventually. I'm sorry that other people are hassling you about it rather than CKAN maintainers. If I cared more about FAR, I'd be trying to fix the metadata myself, or at the very least getting involved in whatever discussions are happening about it on the CKAN Github. Maybe it's been fixed since I started using CKAN. I know that I ended up with two different versions of Module Manager trying to run simultaneously at one point, thanks to a mod that included a ModuleManager.*.*.dll in a subdirectory. That particular problem may well have been fixed by now. All my examples of what drove me to CKAN are out of date, because I've been exclusively using CKAN since KSP 0.25. Well, clearly, you know a lot more about how mods interact with the game than I do. That's obvious, really, since you needed to understand it in order to start modding, and you're an extremely accomplished modder. I just want to be able to use interesting mods on a cool game without having to mess about too much. Alone, no. That's not the point. It's when you are having to deal with dozens of mods that CKAN becomes a necessity, at least for some of us. Why can't you see that? You mean the in-development firespitter.dll that a bunch of modders starting distributing and relying on, forcing CKAN to include it? And so you don't. And sometimes, that adds to the difficulties just a little.

Sorry, Ferram, that's just not true. And every time you make statements like that, denying the efforts of CKAN contributors, you make actual conversations to sort out the problem more difficult, because you annoy everyone who has made attempts to fix things in CKAN. (Sorry for re-ordering your paragraphs, but I'm responding to these two together.)The most egregious example is the fact that many, many mods include their own distribution of ModuleManager.dll (including you), and some of them bury it somewhere in their own mod's directory. So you have to track down every copy of ModuleManager.dll that ends up in the system, hope that all the mods are happy with the newest version while you delete all the old ones and make sure there's only a single copy. The particular mods that really drove me up the wall were the beautification mods. TextureReplacer, Active-Memory-Reduction, Distant Object Enhancements, Planet Shine, Ven's Stock Revamp, Environmental Visual Enhancements, CollisionFX, Reflection Plugin, Smokescreen, CoolRockets, HotRockets, RealPlume, etc. There are a bunch of dependencies and incompatibilities among these mods (and I'll even leave out the disastrous Renaissance Compilation here). Mods that include other mods as part of their distribution (or just one small part of that mod) are common. How many mods throw in a copy of Firespitter.dll? When a new version of the included mod is available, should you upgrade that, or wait until the mod that installed it includes the upgraded version? Add in to this that many mod authors completely ignore non-Windows users in their installation instructions. (You yourself keep talking about "winzip".) Well, could you keep that in mind?

Ferram, I understand why you're annoyed, and I think maybe the CKAN team should be doing more to sort out CKAN's problems with your mods. I agree that you should not have to deal with issues users are experiencing that are related to CKAN rather than your mods. My personal focus is on users, but I don't speak for all CKAN contributors (not even close!) What annoys me is when modders start complaining about CKAN as being "unnecessary", which ignores the lived experiences of many users like myself who have been driven mad by mod incompatibilities. That you don't find something useful or necessary does not mean that other people won't. I'm well beyond merely "literate" with computers. I've been working in programming, infrastructure and administration of computing systems for over thirty years. I don't have the time to read through thousands of pages of forum posts searching out clues about compatibility issues, then spend the time manually installing mods in the correct order to make sure nothing gets over-written that shouldn't be, fix up the flaws less competent modders cause by including dlls from other mods, and still have time to enjoy my game. If the choice is that or stock gameplay, I'll fall back to stock gameplay. In some ways, I almost wish Squad had gone the Steam Workshop route or something similar and insisted that all mods be installed through some defined system that KSP understands. Unfortunately, they've chosen not to do that, and so CKAN is in the terrible position of trying to get the effect of enforced standards to get mods to play nice together without any moral authority to actually enforce standards. Ultimately, no one is forcing you to do anything about CKAN, because no one has the authority to do so. You have the ability to ignore CKAN completely. The CKAN contributors that are engaging with you are also your users, or they are working on behalf of your users. They are asking you to help them. But they are only asking, and you can choose to help or not, or exactly how much time and effort you wish to contribute to improving the experience of using mods on KSP.

No. Like I said, you aren't one of the modders that created the problem CKAN solves. The critical phrase there is "when the modder provides perfect instructions". There's too many instances where that is not the case. Too many modders that think their mod is the top of the pile, that users will install above all others. This is not about you, Ferram. As a user, I found manual installs failed regularly and often, having followed all instructions as faithfully as I could. Not individual mod installs, but when I started getting into the "several dozen" mod territory, I'd end up with a completely b0rked game that wouldn't run, and no way to fix it. CKAN sorted out those problems. When a mod overwrites something in the Gamedata/Squad file structure, "delete folders" is not a valid uninstall. And yes, I have had mods do that. Well, I don't know how much of the discussions in the NetKAN repository you're reading, but I guess I see the discussions very differently. Most of the talk I see is CKAN contributors trying to work with the mods as uploaded without going to the developers. Only when it becomes really difficult to sort out the issues are developers approached. 90% of mods are handled by CKAN with no need for the mod authors to do anything. Sometimes a suggestion like "can you use one of the standard licence options Kerbalstuff offers?" might be made, especially when a modder has chosen "other" and then written a slightly different lettering of one of the options. Now, I'm only a minor contributor who tries to pick up some of the easy issues, so I'm only seeing a particular slice of the discussions myself. I am one of the users who has made the "if it's not in CKAN, I'm not using it" decision. And I've taken it because it made mods work for me, where before, they were becoming a nightmare. I started contributing to the CKAN metadata repository in order to help get mods I wanted to use into CKAN. So for me as a contributor, my aim is to help users primarily, not modders. After some early wrangling with a couple of particularly cantankerous modders, I've gone back to just doing the best I can to get things sorted out in CKAN without bothering anyone.

I hate to see you guys having issues with CKAN, because you did not create the problems CKAN solves. There are other modders out there who are far less professional, give incomplete and inadequate installation instructions, change base game files willy-nilly, and make it very easy for someone trying in good faith to follow all the instructions to end up with a completely b0rked game install. Particularly troublesome is the lack of uninstall instructions, for when a mod turns out to be incompatible or undesired. Please don't let commentors on the forums speak for the CKAN developers. Their conversations happen on Github.

Looks like the mod author changed his numbering scheme and then changed it back. Unfortunately the list of versions now goes: KerbalPlanetaryBaseSystems-0.2.6.ckan KerbalPlanetaryBaseSystems-0.2.7.ckan KerbalPlanetaryBaseSystems-0.2.8.ckan KerbalPlanetaryBaseSystems-v0.2.7b.ckan Because "v" comes after "0", that's showing as the latest version. I'll see if I can work out how to fix it. You can do a short term fix to get it installed by hacking your registry.json file, which is in the CKAN directory under your KSP install directory. First, make sure your CKAN is not set to refresh the repository on startup, then open registry.json in a text editor and search for "KerbalPlan" to find the mod. You'll see a bunch of sections for each version, starting with "v0.2.7b" "KerbalPlanetaryBaseSystems": { "module_version": { "v0.2.7b": { "abstract": "This mod adds stock like parts that are designed to build bases on the surface of planets. ", "description": null, "kind": null, "author": [ "Nils277" Remove the v in that string so that line becomes "0.2.7b": { Save and exit your text editor, then reload CKAN. You don't have to worry about changing the order of the sections; CKAN will figure out the correct latest version. EDIT: This issue has now been fixed properly. As long as the mod author doesn't get too wild in his numbering, it should sort correctly. - - - Updated - - - I'm guessing you're running Windows from the window decorations, but what version? Is your .net installation up to date? I'm afraid I don't know much about .Net/Mono on Windows. Googling "Could not load type System.Runtime.CompilerServices.IAsyncStateMachine from Assembly" seems to imply that you are running .Net 4, and CKAN is compiled against the Mono equivalent of .Net 4.5, so upgrading your .Net should fix it.

Try Installing CKAN on OSX for the specifics, and of course the User Guide for general usage information. Welcome to CKAN!

I'm out of definite suggestions. I run the latest Mono (4.0.4) from mono-projects.org, and that works for me, though I am on Ubuntu 14.04 rather than 15.04. I'm actually a little surprised they haven't moved up to Mono 4.x in 15.04. The instructions for moving to latest stable Mono are here if you want to try that.

Blow away your directory and re-copy to get your CKAN folder back, add the new install to CKAN, set it as default, and then run ckan repair from your command line (or mono ckan.exe repair for Linux/Mac). If that doesn't work, more drastic issues may be required, such as a fresh install and adding of only the mods you want followed by copying over the savegame.- - - Updated - - - It's probably being sneakily installed by one of the mods you've selected. Have a thorough look through the Contents tab for all your mods and you'll probably find toolbar.dll somewhere. Let me know where you find it, and we can fix that mod's metadata to prevent it being installed.- - - Updated - - - Two questions:1. Have you run apt-get install libcurl4-openssl-dev and mozroots --import --ask-remove like the release notes ask? (Run them both with sudo, if that's not obvious) 2. What version of Mono are you running? You can find out by running mono --version. - - - Updated - - - From that link: Did you? You're their customer, after all, and you're the one that their software is causing a problem for. Unless you think that CKAN actually is malware, which would seem very unlikely, given its open-source nature. In any case, their dispute process would presumably involve them analysing CKAN more thoroughly, so it would be a win-win.

Try using the "Refresh" button on both installs. That should get both up to date. The downloaded modlist is stored in the CKAN directory, so it's install-specific (and dependent on the KSP version).