Jump to content

The Comprehensive Kerbal Archive Network (CKAN) Package Manager; v1.18.0 [19 June 2016]


pjf

Recommended Posts

Hi Guys,

Not sure if I'm missing something obvious or I stumbled across an issue... I have two installs of KSP (both 1.0.4) running off the same CKAN exe and just noticed they are reporting different mod lists.

Does anyone know what could be causing this? Thanks!

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).

Link to comment
Share on other sites

I keep getting this error when starting from Ubuntu 15.04:

27327 [1] ERROR CKAN.AutoUpdate (null) - WebException while accessing https://api.github.com/repos/KSP-CKAN/CKAN/releases/latest: System.Net.WebException: Error getting response stream (Write: The authentication or decryption has failed.): SendFailure ---> System.IO.IOException: The authentication or decryption has failed. ---> Mono.Security.Protocol.Tls.TlsException: Invalid certificate received from server. Error code: 0xffffffff800b010a

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.RemoteValidation (Mono.Security.Protocol.Tls.ClientContext context, AlertDescription description) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates (Mono.Security.X509.X509CertificateCollection certificates) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 () [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () [0x00000] in <filename unknown>:0

at (wrapper remoting-invoke-with-check) Mono.Security.Protocol.Tls.Handshake.HandshakeMessage:Process ()

at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage (Mono.Security.Protocol.Tls.TlsStream handMsg) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0

--- End of inner exception stack trace ---

at Mono.Security.Protocol.Tls.SslStreamBase.AsyncHandshakeCallback (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0

--- End of inner exception stack trace ---

at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0

at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename unknown>:0

at System.Net.WebClient.GetWebResponse (System.Net.WebRequest request) [0x00000] in <filename unknown>:0

at System.Net.WebClient.ReadAll (System.Net.WebRequest request, System.Object userToken) [0x00000] in <filename unknown>:0

at System.Net.WebClient.DownloadDataCore (System.Uri address, System.Object userToken) [0x00000] in <filename unknown>:0

27344 [1] WARN CKAN.SettingsDialog (null) - Exception caught in CheckForUpdates:

System.Net.WebException: Error getting response stream (Write: The authentication or decryption has failed.): SendFailure ---> System.IO.IOException: The authentication or decryption has failed. ---> Mono.Security.Protocol.Tls.TlsException: Invalid certificate received from server. Error code: 0xffffffff800b010a

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.RemoteValidation (Mono.Security.Protocol.Tls.ClientContext context, AlertDescription description) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates (Mono.Security.X509.X509CertificateCollection certificates) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 () [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () [0x00000] in <filename unknown>:0

at (wrapper remoting-invoke-with-check) Mono.Security.Protocol.Tls.Handshake.HandshakeMessage:Process ()

at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage (Mono.Security.Protocol.Tls.TlsStream handMsg) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0

--- End of inner exception stack trace ---

at Mono.Security.Protocol.Tls.SslStreamBase.AsyncHandshakeCallback (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0

--- End of inner exception stack trace ---

at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0

at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename unknown>:0

at System.Net.WebClient.GetWebResponse (System.Net.WebRequest request) [0x00000] in <filename unknown>:0

at System.Net.WebClient.ReadAll (System.Net.WebRequest request, System.Object userToken) [0x00000] in <filename unknown>:0

at System.Net.WebClient.DownloadDataCore (System.Uri address, System.Object userToken) [0x00000] in <filename unknown>:0

In addition i keep getting a version mismatch error when trying to load from a .ckan file. I get a failed to fetch master list when trying to get new Metdata repositories as well.

Any help would be appreciated.

Link to comment
Share on other sites

Problem: To ease up on the RAM limit, I copied my entire KSP install to a new folder. I had intended to use CKAN to then go an uninstall all non-parts mods that aren't necessary for the ship builds. Then I will have a lot more RAM at my disposal, and can take more than three KVV grabs before the game crashes. CKAN detects the correct copied and renamed folder. It sees the mods. It loads the mods. It doesn't change anything.

Any unchecking of any mod in CKAN doesn't give me the option to apply the changes. I can't seem to get it to do anything with the new folder. It just petulantly sits there. If I delete the CKAN folder and rerun CKAN, it detects all the mods again as manually added, and still doesn't do anything.

How do I get CKAN to uninstall mods in the copied and renamed directory? Any help would be greatly appreciated.

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 - - -

Frustrating question... is there any way to prevent CKAN from downloading a specific mod? It keeps installing Blizzys toolbar (amazing mod, but not wanted in this save) even though I don't have it selected, and I don't have any mods dependent on it. It doesn't show up in any windows of CKAN but it still downloads it. Even individually searching through Relationships and Contents doesn't bring anything up.

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 - - -

I keep getting this error when starting from Ubuntu 15.04:

27327 [1] ERROR CKAN.AutoUpdate (null) - WebException while accessing https://api.github.com/repos/KSP-CKAN/CKAN/releases/latest: System.Net.WebException: Error getting response stream (Write: The authentication or decryption has failed.): SendFailure ---> System.IO.IOException: The authentication or decryption has failed. ---> Mono.Security.Protocol.Tls.TlsException: Invalid certificate received from server. Error code: 0xffffffff800b010a

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.RemoteValidation (Mono.Security.Protocol.Tls.ClientContext context, AlertDescription description) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates (Mono.Security.X509.X509CertificateCollection certificates) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 () [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () [0x00000] in <filename unknown>:0

at (wrapper remoting-invoke-with-check) Mono.Security.Protocol.Tls.Handshake.HandshakeMessage:Process ()

at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage (Mono.Security.Protocol.Tls.TlsStream handMsg) [0x00000] in <filename unknown>:0

at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0

--- End of inner exception stack trace ---

In addition i keep getting a version mismatch error when trying to load from a .ckan file. I get a failed to fetch master list when trying to get new Metdata repositories as well.

Any help would be appreciated.

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 - - -

Norton Antivirus rates CKAN as "BAD" and "There are many indications that this file is untrustworthy.".

A little digging indicates that this is flagged as "WS.Reputation.1" detailed here: http://community.norton.com/en/forums/clarification-wsreputation1-detection

tl;dr...

The file is basically unheard of and hardly anyone has seen it in the wild so Norton instantly distrusts it.

Perhaps the author could see about digitally signing their executable before releasing it in future, that would reduce this problem.

From that link:

you can submit a dispute at https://submit.symantec.com/dispute/

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.

Edited by politas
trim excess quotes
Link to comment
Share on other sites

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).

Thank politas! Stupid oversight by me, I had the repository refreshing on start-up so I thought I was good, but as you said its install specific so my 2nd install was getting outdated without me realizing it. All is as it should be now, thanks again.

Link to comment
Share on other sites

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.

1. Yes to the first no to the mozroots. I will try that.

2. Mono version 3.2.8

Ran the mozroots command still same error.

Edited by theersink
Link to comment
Share on other sites

1. Yes to the first no to the mozroots. I will try that.

2. Mono version 3.2.8

Ran the mozroots command still same error.

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.

Link to comment
Share on other sites

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.

4.0.4 did the trick. Although I couldn't get it to install from the page you gave me so I found this PPA:

sudo add-apt-repository ppa:keks9n/monodevelop-latest

apt-get update

apt-get install mono-complete

In case anyone else has similar issues.

Link to comment
Share on other sites

It's been ~30 hours since Kerbal Planetary Base Systems updated from 0.2.7b to 0.2.8, but CKAN has yet to recognize that an update is available. Any idea what the problem is?

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 seem to have a problem every single time I try to install a mod. It doesn't matter which mod I choose. Has anybody encountered this?

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.

Edited by politas
Update
Link to comment
Share on other sites

today I ran into an issue where 2 different mod authors who both make several mods created updates to one of their mods that included updates to one of their other mods. CKAN called this out as a violation because the file to be updated didn't already belong the the mod package updating it. While this is an understandable safety feature, is it possible to override this feature and force the update to happen? If it isn't possible, can you add that in the next update, or create some sort of something that allows several mods to fall under the same owner? it seems that some authors are starting to get understandably frustrated when CKAN tells the mod's users, "No, I'm not going to let you do that!" and then the users go complaining to the mod author because of something CKAN did. One author just plain pulled his update off CKAN, the other probably doesn't know about the problem yet.

Link to comment
Share on other sites

Hopping in here for a bit.

Because what I am starting to see is a mounting backlash against CKAN from the content creators, because you are causing us ridiculous amounts of work.

When CKAN first came out, the outreach was excellent. The CKAN Elves would IM me or ping me on IRC if they saw something amiss, and stuff got sorted. It was as if, at that time, CKAN realized that modders were their main customer... probably because they needed as much stuff on CKAN as possible for it to be viable, and modder participation was critical to it's survival.

Now, fast forward. The screw ups and support hassles are mounting. The only thing I get from CKAN is support issues, and those are increasing. CKAN has in my opinion lost it's focus and now that they milked what they wanted from the modding community (that is, a solid catalog that makes the service valuable to users) they can safely abandon focusing on the modders since, as one user earlier in this thread put it, we either have to get on board or be left behind. This is a complete 180 from the prior attitude.

If you make it painless for the modders and focus your support on the content, things will be fine and everything else will fall into place. Abandon them, and you're just going to see the backlash and animosity intensify.

Now for you guys. That ChangeLog file in the root of UmbraSpaceIndustries belongs to USI Core, along with it's version file. Right now Karbonite is screwed up on CKAN, and I expect soon enough the rest of my mods will follow suit. Oh... and all of them that use USI Core have already been updated, so there is no conflict. Also make sure you're getting the FireSpitter DLL from KerbalStuff.

Also - apparently you don't like some of my licenses because despite CKAN not being commercial and not actually distributing stuff, you require license information to fit a specific format. This is irritating and causing friction, please sort this. KerbalStuff lets me do 'Other', GitHub lets me do whatever I want. Don't screw up a listing because it's not on your license list (whatever that happens to be). Use human eyes for this one.

The amount of drama and entitlement I got from users advocating CKAN on that one issue alone was fairly ridiculous, and I was pretty much told 'shut up, go change your stuff, cater to CKAN or tough luck'. Hence the small dose of salt that comes with this post.

Edited by RoverDude
Link to comment
Share on other sites

I feel like I should hop on RD's salt train and add some stuff while it's going, and as always, disclaimer that I've never really liked CKAN to begin with.

CKAN, for all of its sins, could at least be tolerated if it didn't commit the two unforgivable sins that it's been committing now on a somewhat regular basis:

1) Its perfect usage success rate is terrible compared to manual installation through downloading with a browser and then extracting with winzip or something similar.

A user following directions exactly perfectly has never had an installation error with a manual install unless the files were packaged incorrectly by the modder. Never. 100% success rate for installations. On the other hand, with CKAN, I've seen users following CKAN's directions exactly perfectly end up with installs that are missing dependencies, have the wrong versions of dependencies, download not-the-latest version of the mod, etc. Then there's the fact that its no-overwrite rule can cause problems for some packages.

This has reached the point where I have to assume that any install put together through CKAN has install errors. They're simply too common for them to []not be in an install with a decent amount of mods.

This in itself is completely unacceptable. CKAN can't even do its job right. But then it has to be added to...

2) The obvious indifference of its contributors and users to the problems they might create for modders.

Every time CKAN causes an issue, modders seem to be expected to deal with it. By both its users and (as is frequently proposed every time a new thing comes up) by its contributors. Meaning that for modders to have something on CKAN they have to stem the problems created by someone else or yell loud enough to get someone else to fix the problems before they start to show up in the support threads.

An obvious solution would be to simply not have your mods on CKAN. However, taking down mods is not done unless it's licensed ARR or you can somehow convince someone that it would be a good reason to take it down. Good reasons don't seem to include repeated install screwups.

Then there's the concerning attitude that keeps popping up that "if it's not on CKAN, it may as well not exist" from both users and contributors...

So ultimately, you have a group of contributors that have no incentive to show any concern for modders whatsoever or about any problems they cause through their decisions (except for anyone that licensed ARR, so if this is a push for more restrictive licensing by punishing open licensing, it's a damn good argument). And install errors even under perfect user actions. It makes the current push for non-strict, fuzzy versioning look like it's going to be implemented in a way that simply causes more issues and we'll be the ones with the mess in the end.

I, personally, would like it if you guys just stopped. That's never going to happen, so here's some more reasonable requests: You're in the business of distribution, you handle the details of that, not us. Stop creating problems for us. Don't make or expect us go and clean up your problems. Let us pull stuff off of CKAN if you can't make it work to our standards. Make sure your users know to bother you about install issues, not us. Achieve the same standards under perfect user actions as manual installation before it's available through CKAN (100% success for every single mod, period). Show some consideration for the concerns and effort of modders that you're supposed to be "helping" by distributing their stuff.

</frustration>

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Please don't let commentors on the forums speak for the CKAN developers. Their conversations happen on Github.

...Then what is this thread for? I would expect the developers to be involved in the official thread for their own project?

So I will drop this here, and propose how this issue can be solved, before this mounting wave of backlash gets ugly.

Inclusion in CKAN should be at the discretion of the modder. Not just because someone (not the modder) throws in a pull request. Or, ask nicely. And if we say no or change our minds, respect that. Otherwise you're going to start seeing licenses that explicitly restrict distribution via CKAN. Forcing people to play your ball game is incredibly uncool.

Second. It is far easier for me to maintain my own metadata, because it lets me use my own repo as a gatekeeper. If CKAN allows me to host my own metadata in my own mod, then awesome. And with the request above (let me de-list), then we're sorted. Then I can just de-list from CKAN, and when I am ready, put my own metadata back.

Problem solved.

I'd like to see a reply from the CKAN developers on this.

- - - Updated - - -

Update.

Talked to PJF - and since it looks like I can not only host my own metadata, but also pull my listings till that's sorted, then I am a much happier camper as that solves my issues.

Link to comment
Share on other sites

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.

Except I don't do that. And then CKAN has still screwed up for my users that insist on using it, but my manual install users are left fine. I don't see why this should be a defense of CKAN, because this is the very problem: they have a greater failure rate than perfect manual installs when the modder provides perfect instructions. CKAN's responsibility should be to be as perfect as its manual competitors, and there doesn't seem to be any desire for that.

Particularly troublesome is the lack of uninstall instructions, for when a mod turns out to be incompatible or undesired.

I find this uncompelling, considering that when the install instructions are "copy folders" and the logical uninstall is "delete folders."

Please don't let commentors on the forums speak for the CKAN developers. Their conversations happen on Github.

Where do you think I've based my thoughts about CKAN contributors from? From what I've seen on Github, every problem is supposed to be fixed by modders taking on more workload and responsibility, just as RoverDude has decided to do. I don't have to run around making sure that Firefox and Chrome properly download, and that winzip properly extracts files. They work. Why is it that CKAN can't be held to the same standard? Why does every proposal and solution have us have to cleaning up CKAN's messes?

Link to comment
Share on other sites

Except I don't do that.
No. Like I said, you aren't one of the modders that created the problem CKAN solves.
And then CKAN has still screwed up for my users that insist on using it, but my manual install users are left fine. I don't see why this should be a defense of CKAN, because this is the very problem: they have a greater failure rate than perfect manual installs when the modder provides perfect instructions. CKAN's responsibility should be to be as perfect as its manual competitors, and there doesn't seem to be any desire for that.
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.
I find this uncompelling, considering that when the install instructions are "copy folders" and the logical uninstall is "delete folders."
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.
Where do you think I've based my thoughts about CKAN contributors from? From what I've seen on Github, every problem is supposed to be fixed by modders taking on more workload and responsibility, just as RoverDude has decided to do. I don't have to run around making sure that Firefox and Chrome properly download, and that winzip properly extracts files. They work. Why is it that CKAN can't be held to the same standard? Why does every proposal and solution have us have to cleaning up CKAN's messes?
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.

Link to comment
Share on other sites

The phrase "salt train" made me laugh, :D but let me throw a few drops of water on it.

I love CKAN as both a (small) modder and a player. There's a bunch of warts, but overall it's great.

I agree with RoverDude's comments - his fast-changing, complex and interlocking mods need more tight control, and it sounds like he'll get it. The vast majority of mods do not need more than a way to shove a folder into GameData.

Ferram is correct (people who install mods correctly don't have problems with mod installs), but that misses the point. The number of times people install to GameData\GameData\ModName or something equally ridiculous is way too high. There's a reason FAR has InstallChecker.cs in it - the vast, vast majority of the public, even the space LEGO video game playing public, barely know how to use a computer. Files and directories are mystic incantations. CKAN turns this mystic ritual into a point and click experience.

You can make the argument that one should have enough basic computer literacy to be allowed to install mods.. but the counterpoints are that this game is played by children as well as adults, and that I'm lazy. :D I want a point-and-click install experience. People are used to just double-clicking on Windows installers, and now just tapping in the App Store/Google Play store. A centralized, easy way to install things is something the majority of people not only want, but these days expect.

Whether CKAN is the best implementation of that desire/expectation is certainly up for debate, but the desire/expectation itself is there and isn't going to go away.

I do agree with Ferram's comments that CKAN should strive to not create more work for the author, and that the author should be the final decider of whether the CKAN install is correct or not - or whether the mod is even listed on CKAN or not. Listing a mod against the author's wishes is not cool, and indeed will only lead to anti-CKAN licenses.

Link to comment
Share on other sites

No. Like I said, you aren't one of the modders that created the problem CKAN solves.

So why do I have to put up with the problems CKAN causes? I should simply not care about making things perfect because CKAN will cause problems for me either way, right?

The critical phrase there is "when the modder provides perfect instructions". There's too many instances where that is not the case. [...] This is not about you, Ferram.

Except CKAN has, in my experience, taken the situation where the moder does provide perfect instructions and turned it into a nightmare. I've had users that have never had install errors under a manual install, and then managed to get completely borked installs from CKAN. So yes, this is about how CKAN ends up managing to create more support problems for ferram because it can't do its job right.

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.

And that's how it should be. The problem is that 1) they create errors that do not occur in manual installs and 2) we're expected to come in and fix the mess they caused when it goes to hell. I don't have to do this for Firefox and winzip, why is CKAN special?

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.

And you are exactly the problem, from my point of view. It's always about users, damn the effort and problems it causes for modders.

Ferram is correct (people who install mods correctly don't have problems with mod installs), but that misses the point.

What about the people who installed mods perfectly before they shifted to CKAN, and then when they did CKAN screwed things for them? That's my point: CKAN has a greater failure rate than manual installs under perfect user actions, and that is unacceptable. Sure, the bar for "perfect user actions" is much lower with CKAN, but if CKAN is going to screw up, it's still a screwed up install I have to deal with.

You can make the argument that one should have enough basic computer literacy to be allowed to install mods.. but the counterpoints are that this game is played by children as well as adults, and that I'm lazy. :D I want a point-and-click install experience. People are used to just double-clicking on Windows installers, and now just tapping in the App Store/Google Play store. A centralized, easy way to install things is something the majority of people not only want, but these days expect.

And this is the problem. Basic computer literacy is an amazingly low bar to reach. It's a stupidly low bar. All I ask is for people to merge a folder, and this is apparently so much to ask that I get to have CKAN come in and cause more install errors than I ever got before it. And no, I'm not exaggerating: before CKAN, install errors wouldn't leave dependencies behind, and they wouldn't cause crashes when installed with another mod, but I've gotten that now.

I do agree with Ferram's comments that CKAN should strive to not create more work for the author, and that the author should be the final decider of whether the CKAN install is correct or not - or whether the mod is even listed on CKAN or not. Listing a mod against the author's wishes is not cool, and indeed will only lead to anti-CKAN licenses.

And yet every time there's an issue, the first suggestion is that modders should take on the responsibility of dealing with the metadata, whether we want to deal with CKAN or not. And of course they're going to list mods whether authors want to or not, they have no incentive to retain good publicity among modders, because as already noted by politas, they're working for users, not modders. So who cares if modders are angry, right?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

But they don't. No one tests the metadata generated to see if it properly installs the mod before it's sent out for general use. And no one bothers to provide any out for what happens when CKAN does cause problems and won't fix it, besides suggesting that I clean up their problems for them.

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.

But mod incompatibilities are rare and can be seen coming a mile away... planet packs, MechJeb-like things, aero models, the only type of common incompatibility is when two things try to mess with the same system, and that takes about 5 seconds of thought to figure out. I don't see how CKAN is necessary for that.

That you don't find something useful or necessary does not mean that other people won't.

Oh, believe me, I'm well aware of that. We're talking about a program that replaces copying folders from a zip to a single place. I'm amazed this is even a thing, but there's apparently demand for it. Makes just as much sense to me as beer; don't understand how anyone likes that stuff, but I understand that as terrible as it is, people want it.

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.

I'm sure if it's as rampant as that, you can provide a bunch of examples of that, right? I mean, an epidemic of that that requires this kind of tool should result in a list of several dozen mods that don't fall under the, "it's obvious they're messing with the same system" rule, right?

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.

God, please no. We'd all get forced onto Curse, have strict limits on what would be allowed, get the fun of bugs in that system getting fixed horribly slowly, have difficulty even identifying the bugs and not even have the option of pushing for manual installs. That would be utterly terrible. Even CKAN is better than that.

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.

Not when CKAN causes problems for me. Not when CKAN causes problems for my users that follow its instructions perfectly and get borked installs. The same users that followed my instructions perfectly for manual installs and never got problems. No, you don't get to play the, "it's only your problem if you choose to make it your problem" card, because you guys made it my problem and won't let me opt-out and make it not my problem.

The CKAN contributors that are engaging with you are also your users, or they are working on behalf of your users.

And doing a terrible job of it, because they've successfully caused enough problems that CKAN installs aren't supported anymore. Which slows down support for everyone else. They could have left well enough alone and me and my userbase would be better off.

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.

They are asking me to fix the problems they have created for me. No. Maybe I'm in the minority, but I don't think that it's right that after someone throws a wrench at you that you should be happy to work with them or that you should fix the damage they caused. Hell, why would it benefit me to do that, to send the message, "yes, you can cause problems for me, and I'll gladly fix them for you?"

My job is to code and fix my mods. The job of distribution and installation used to be handled perfectly by the host, browsers and extractors. Then you guys came along and decided to take on that job, and somehow sold users on doing a better job of it while doing a worse job and expecting me to clean up the mess. So, again, why is CKAN special that it can't be expected to do as perfectly as a browser and extractor, hmm?

Edited by ferram4
typo in "Steam Workshop or something similiar" response
Link to comment
Share on other sites

Sorry, don't mean to interject in your guys', er, discussion... but can anyone confirm that kerbalstuff is experiencing downtime right now? It appears that my CKAN is getting 504's on any kerbalstuff downloads.

Does CKAN support multiple download locations? Like fallback repositories?

Link to comment
Share on other sites

Having the same issue hear JordanL. I'm glad you said something I was about to tear my hair out thinking I somehow broke my CKAN install (I'm a linux noob, I'm always breaking stuff).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...