CKAN pros/cons

[RoverDude]

37 minutes ago, phoenix_ca said:

That's an annoyance I have sympathy for. Though I disagree that being entirely opt-in is a preferable solution. At least not for CKAN. As I said, people are just going to scare-up their own CKAN files (I certainly would), and that'll end-up with more headaches on both sides. (Edit: And more animosity when users circumvent mod authors.)

As far as I'm aware, this is it. It's not enough to deal with dependencies, conflicts, recommendations, etc. (All of which are really, really handy as a user.)

Edit: Which actually has me a little confused. @RoverDude, didn't you say earlier that AVC "handles" dependency versions? Or did you just mean it'll probably check the plugin that someone else's depends on and prompt the user to update it if it's out-of-date? Because if so it's not quite the same thing.

First.  I disagree that entirely opt-in is not a preferable solution.  It is the ONLY community friendly solution.  The root here is modders not having control of the distribution of their content, and 'random people on the internet' wasting our time and causing support concerns.  If someone is enthusiastic enough to do their own NETKAN files for their own install, then they likely know how to properly troubleshoot their install.  But having it be the default (and encouraged) behavior, to the point where the CKAN team is stating that they will absolutely add stuff even if the mod owner explicitly did not check that option on SpaceDock is very bad, is not neighborly, and is why they are sucking up a ton of backlash.  Please do not be part of the problem.

This will very likely land in 'mod wars' land where CKAN is aggressively worked against (and trust me, it's almost trivial to break CKAN... it was my fallback for the Malemute if said metadata was not removed).

For your other question.

KSP-AVC notifies me when dependencies have changed.  It's easy as pie.

Drop a mod in GameData (with all of it's stuff).  

Drop several more.

Run KSP-AVC - I will very quickly see if a dependency got stomped to an older version.  And I get instantaneous version updates (i.e. no waiting for a reindex).  I can also cherry pick and read up on any change logs before deciding to do an update (tho the modder has to, like all things, opt into the change log mechanic)

Ironically, CKAN was pushing bad data for the install of KSP-AVC after the 1.1.3 drop

 

[phoenix_ca]

30 minutes ago, RoverDude said:

This will very likely land in 'mod wars' land where CKAN is aggressively worked against (and trust me, it's almost trivial to break CKAN... it was my fallback for the Malemute if said metadata was not removed).

Doing that will guarantee genuine (and justified) user backlash. Users who just want to mod their games easily and have no idea that this issue is such a hot-button topic here that mentioning it is practically guaranteed to start a flame war are just going to see it a petulant mod authors throwing a fit. It wouldn't solve anything, just breed more animosity between everyone, which is obviously something the KSP needs absolutely no more of, frankly.

32 minutes ago, RoverDude said:

For your other question.

KSP-AVC notifies me when dependencies have changed.  It's easy as pie.

Drop a mod in GameData (with all of it's stuff).  

Drop several more.

Again, at hundreds of mods, this becomes untenable. Manual installation and patching becomes extremely time-consuming. Frankly, I don't have the time, which is why I use and will continue to use CKAN until there's a better solution.

 

33 minutes ago, RoverDude said:

Run KSP-AVC - I will very quickly see if a dependency got stomped to an older version.

Define "very quickly". It takes several minutes for KSP-AVC to complete its checks for me (about 6-7, and my KSP startup time is 10 mins in total). Going through that however many times a day, manually patching things and hoping that I don't slip-up somewhere (which can and has happened to me in the past, sometimes creating bugs that result in corrupt saves)? No.

 

35 minutes ago, RoverDude said:

The root here is modders not having control of the distribution of their content, and 'random people on the internet' wasting our time and causing support concerns.

Then your problem isn't with the distribution platform specifically, it's with the users. I fail to see how this is any different then the problems faced by mod authors in other communities, especially Nexus and for Bethesda's games. They all have to deal with users running into problems, sometimes caused by the software they use to manage their mods, the thing is that there's a culture where people adding mods obviously "get" that doing something wrong with NMM or Mod Organizer can cause issues. Maybe CKAN is a victim of it's own efficiency and KSP's somewhat more sane addon management (and that the game, being a sandbox, doesn't result in nearly as many conflicts), because both combined makes adding mods so trivially easy.

 

You have to keep in mind that if CKAN dies, someone will create a new distribution platform in relatively short order. Hell, I'd do it myself, and probably do it even worse since I'm far from experienced in dealing with such design problems. And then we'll all be exactly where we started, except two steps backward.

[ferram4]

14 hours ago, cantab said:

Do you see another way forward? As I see it, things are going to get better for everyone involved if a better mod manager than CKAN is made.

 

 

And the problem is that unless it kills CKAN completely, it will be useless.  CKAN has too much marketshare and mindshare in the mod manager department to have any hope of being unseated at this point.  And besides, from my experiences before mod managers were a thing, it's a hell of a lot better for modders when there aren't mod managers, and the users seem to have fewer install issues too.

The only way forward at this point is either to get CKAN to change itself to be less terrible, or to simply kill it and go back to the way things were.  The latter is almost certainly never going to happen, so that means the only option is to get CKAN to change.  But CKAN contributors try as hard as they can to keep CKAN's policies from changing if they benefit modders, and so we are stuck with the issues.

 

46 minutes ago, phoenix_ca said:

Doing that will guarantee genuine (and justified) user backlash. Users who just want to mod their games easily and have no idea that this issue is such a hot-button topic here that mentioning it is practically guaranteed to start a flame war are just going to see it a petulant mod authors throwing a fit. It wouldn't solve anything, just breed more animosity between everyone, which is obviously something the KSP needs absolutely no more of, frankly.

 

Unfortunately, CKAN has ensured that modders butt heads with CKAN users and everyone butts heads with CKAN contributors.  So many conflicts between users and modders right now are just related to CKAN and never existed before CKAN.  The best way to end the animosity is to get CKAN to stop causing issues for modders.  Give some consideration to the problems affecting modders for once and stop worshiping users like they're the shining center of the universe.

[panarchist]

On 6/17/2016 at 10:59 AM, goldenpsp said:

I'm sure there is a technical term for when someone takes one argument and then attempts to extend it to everything, but I cannot think of it now.  

It's called "false equivalence".  I think the basic argument is somewhat valid (that the attitude can be "elitist"), but to amplify on what you said, goldenpsp, it's definitely *not* the same - knowing the guts of a Windows program means knowing what version of DirectX and .Net it uses, knowing what 45 registry keys it modifies, and knowing the structure of where everything goes. KSP, as you said, is far less complex.

I can appreciate what CKAN does, and is, but honestly the instuctions for installing a mod in KSP can fit on a napkin.

1. Is there a GameData folder in the file structure of the mod?
2. If yes, copy everything under it into your GameData folder of your KSP install
3. If no, then take the root folder, or whichever folder has a "Parts" or "Plugin Data" directory and copy *that* into your GameData folder
4. Copy your saves directory to a safe location
5. Run KSP

Granted, there are a few extra steps if it's Steam, or if you need to install / troubleshoot 70 mods, but if you aren't using CKAN and you *have* 70 mods, then you already know somewhat what you are doing.

 

[phoenix_ca]

1 hour ago, ferram4 said:

But CKAN contributors try as hard as they can to keep CKAN's policies from changing if they benefit modders, and so we are stuck with the issues.

Well as a CKAN contributor, albeit a very recent one, I take umbrage with that.

I and other users here have already posited the question to you guys, the modders, "What would help to make it better?" (Other than the snide "just install your mods manually and use AVC". We've been over that; if someone wants to use hundreds of mods, that's just untenable.)

 

So I put it to you guys again, what features would make CKAN better for you guys? An optional extension of AVC's version files for dependency versioning maybe? Fixes to any specific problems with CKAN's behaviour?

What if it's something as simple as a kindly message inside CKAN somewhere reasonable reminding people to make sure they don't confuse mod problems with CKAN problems? Or point them to the simple troubleshooting method of "try a manual install instead just in case"? I'm just throwing ideas out here.

You're the ones in a position to tell what would be helpful. It goes back to what @cantab said:

16 hours ago, cantab said:

That means that either the mod developers get on board, or the mod manager developers just put things in anyway, and CKAN shows how the latter approach goes.

 

You're also the ones in the best position to actually get the goodwill of users on your side to affect the changes you want. I hope you guys can see that. (You'll kill that goodwill if you go waging a flame war and breaking CKAN intentionally though.)

Edited June 23, 2016 by phoenix_ca

[panarchist]

On 6/18/2016 at 7:19 PM, cantab said:

Modpacks are not a thing with KSP.

Well, except for "Renaissance", which bundles several mods.  It's not the "Wolfpack" mod for Silent Hunter 3 or "Long War" for XCOM, but it's a start.  There's already kind of a convergence around specific mods like the USI mods or Pathfinder, or Kerbal Interstellar, or TAC-LS, and then there's the start of "all-in-one" mods like Kerbalism, which incorporate aspects of what used to be several mods.  I think that it's pretty apparent that the mod community is implementing several "solutions" which address the issue, but none are any kind of clear leader or preferred approach.  I think that actually makes the community stronger.

[RoverDude]

@phoenix_ca - we keep saying it.  Opt in only.  Do not list stuff without modder's approval.  Heck, one of your very first contributions to CKAN personally caused me grief, and wasted my time.  Don't do that.  Seriously.  I totally get this is not the answer you (or the CKAN folks) want, but it's the answer that solves the issue.

@ferram4 is right.  As a modder, CKAN (because of their continued disregard for the content providers they depend on) has caused significantly more issues than it has solved.  And sorry, but the next time something of mine gets listed that I do not wish to be listed, I will be taking some seriously aggressive action to make sure that does not occur again for any of my mods.  

[passinglurker]

here is a thought on a way to make CKAN change. 

If CKAN's policies continue to spark flame and strife on the forums because they are not a purely opt-in with no option to opt back out at any time then the thing to do for the sake of civility on the forums is simply change the forum rules to bar the discussion of all mod managers that are not purely opt in.

And tada! CKAN's defence that open licences let them do what they do is suddenly moot as they must either change to remain on the forums or move the discussion and distribution of thier service from the forum which would be a detrimental blow to thier visibility and therefore thier popularity.

[SingABrightSong]

59 minutes ago, panarchist said:

Well, except for "Renaissance", which bundles several mods.  It's not the "Wolfpack" mod for Silent Hunter 3 or "Long War" for XCOM, but it's a start.  There's already kind of a convergence around specific mods like the USI mods or Pathfinder, or Kerbal Interstellar, or TAC-LS, and then there's the start of "all-in-one" mods like Kerbalism, which incorporate aspects of what used to be several mods.  I think that it's pretty apparent that the mod community is implementing several "solutions" which address the issue, but none are any kind of clear leader or preferred approach.  I think that actually makes the community stronger.

You bring up an interesting point, there. I have 86 "installed" packages in CKAN, but most of those packages are either required extra data for other mods, or I have all of certain author's mods installed. Mods that are designed to be used together, as the USI mods are, would if packaged together relieve much of the pressure on large installations(USI in particular bundles its own shared libraries with every release, which means that installing all of them consists of overwriting these dependencies every time an archive is extracted to GameData). Maintaining these bundled releases would place an extra burden on the mod authors, however, which is of course undesirable.

[RoverDude]

And USI for one is more like a spice rack - take the bits you want, and mix them up.  And KSP-AVC makes sure you don't grab a bad dependency by accident.  Even for very large installs, I find it highly effective.

[SingABrightSong]

2 minutes ago, RoverDude said:

And USI for one is more like a spice rack - take the bits you want, and mix them up.  And KSP-AVC makes sure you don't grab a bad dependency by accident.  Even for very large installs, I find it highly effective.

'Twas merely an example, not any sort of demand.

 

And for what it's worth, CKAN appears to have delisted the majority of your mods.

[RoverDude]

Not de-listed, broken metadata issue.  But at least it's something I can sort on my end (and folks can install manually in the interim).

[phoenix_ca]

24 minutes ago, SingABrightSong said:

And for what it's worth, CKAN appears to have delisted the majority of your mods.

O.o No it hasn't. They're all still there.

37 minutes ago, RoverDude said:

I totally get this is not the answer you (or the CKAN folks) want, but it's the answer that solves the issue.

It's not about what I or anyone else "wants to hear", it's about what is a reasonable solution. A purely opt-in system is just going end-up with moving the problem back a step. Instead of a centralized repo of CKAN metadata files, there will be a mess of CKAN files distributed between users and there simply won't be a single authoritative copy unless the mod author makes one. That'll go for any mod author who doesn't opt-in. And then you're going to end-up with mod authors being angry at users for helping distribute their mods to other CKAN users, and users being angry at mod authors for being angry at them because they'll see it as just trying to help-out other users. People like me who have such large installs will probably end-up making their own repos just so they have a place to keep the atrocious amount of CKAN files they end-up with. (With the assistance of a short Python script to recreate those files on a schedule.) And then to top it all off have an angry mod author throw a spanner in the works every time one tries to update. (I know I said angry a lot but boy, are the profanity filters on the forums sensitive or what?)

All I see down that path is ruin, with absolutely no one being happy. It's a matter of which is the lesser evil. But if both sides of this are beyond reason and coming to the table in good faith to create a solution that's amicable for both parties (and I'm starting to suspect this is the case), then I don't see how any progress can be made.

Edited June 23, 2016 by phoenix_ca

[ferram4]

31 minutes ago, phoenix_ca said:

It's not about what I or anyone else "wants to hear", it's about what is a reasonable solution. A purely opt-in system is just going end-up with moving the problem back a step. -snip-

Well... all of that sounds like part of the problem is that CKAN can point to repos other than the official one.  So make it opt-in, and force CKAN to point toward the official repo only; problem solved.

31 minutes ago, phoenix_ca said:

All I see down that path is ruin, with absolutely no one being happy. It's a matter of which is the lesser evil. But if both sides of this are beyond reason and coming to the table in good faith to create a solution that's amicable for both parties (and I'm starting to suspect this is the case), then I guess we're done, and you should bring-out the CKAN-breaking stuff. *shrug*

Then give some ground.  I'd personally prefer that CKAN were dead just because it's cutting the knot, but I know that won't happen, so as long as it is restricted in such a way that it can't cause issues for me, I'll be happy:

1. Make it opt-in.
2. Have automated auditing of metadata between expansion by the NetKAN bot and being pushed to the metadata repo in order to ensure that the install it creates is functionally identical to that of a manual extraction install.
3. A serious culture adjustment for the contributors: more focus needs to be given to modder concerns, and when there's an issue, telling modders any variant of "well, why don't you submit the fix for us?" or insinuating that they're part of the problem because they are voicing complaints / submitting issues as opposed to fixing it themselves shouldn't be acceptable.
4. Ensure users know that (the vast, vast majority of) modders have no control or influence on the metadata.  CKAN users need to know that CKAN is responsible for that, not us unless we've explicitly taken on the responsibility.  How I'm not sure of, and progress has been made in the docs on this recently, but it needs to be better than it is right now.
5. An always-installed plugin that lists in the log what mods have been installed through CKAN, what ones have been auto-detected, which versions, and what .ckan files they came from for the purpose of troubleshooting when these things happen and users provide us with logs.

That is my personal wishlist of things that CKAN should have.  #1 and #2 are really the most important, as 1 is the source of many issues and 2 would allow so many issues to be caught before they are pushed out.  I've suggested 2 numerous times, but it always gets ignored even though that would have fixed the big screwup it caused FAR.

Edited June 23, 2016 by ferram4

[passinglurker]

23 minutes ago, phoenix_ca said:

All I see down that path is ruin, with absolutely no one being happy. It's a matter of which is the lesser evil. But if both sides of this are beyond reason and coming to the table in good faith to create a solution that's amicable for both parties (and I'm starting to suspect this is the case), then I don't see how any progress can be made.

all I see down a path that isn't for the support of the mod author over the user is basically what we see with the fallout community right now. Your scenario is hypothetical whereas this scenario is reality for other communities. You need to give mod authors control and you need to enforce thier wishes if some one disagrees with the mod author then licence permitting they can fork the mod under a different name to avoid confusion.

the alternative is one where mod authors code against CKAN, push for forum policy against CKAN, and ultimately go on strike in protest of CKAN much like we again see happening right now in the fallout modding community because bethesda set of up system that was more oriented to the support the users over the mod authors.

[phoenix_ca]

53 minutes ago, ferram4 said:

Then give some ground.

Sorry for the bold text but I think it's important to make this clear:

 

Keep in mind I'm not a CKAN team member, just someone who added and updated some metadata files.

I just want to get a handle on what might be an amicable solution for everyone here so no-one gets burned (or continues to get burned...or we all get burned equally...whatever you probably get the gist of it). I'm mostly doing this because I really want to see a good outcome from this where everyone gets to have their cake. Or eat it. Can't do both. I'm getting distracted again.

53 minutes ago, ferram4 said:

 

1. Make it opt-in.
2. Have automated auditing of metadata between expansion by the NetKAN bot and being pushed to the metadata repo in order to ensure that the install it creates is functionally identical to that of a manual extraction install.
3. A serious culture adjustment for the contributors: more focus needs to be given to modder concerns, and when there's an issue, telling modders any variant of "well, why don't you submit the fix for us?" or insinuating that they're part of the problem because they are voicing complaints / submitting issues as opposed to fixing it themselves shouldn't be acceptable.
4. Ensure users know that (the vast, vast majority of) modders have no control or influence on the metadata.  CKAN users need to know that CKAN is responsible for that, not us unless we've explicitly taken on the responsibility.  How I'm not sure of, and progress has been made in the docs on this recently, but it needs to be better than it is right now.
5. An always-installed plugin that lists in the log what mods have been installed through CKAN, what ones have been auto-detected, which versions, and what .ckan files they came from for the purpose of troubleshooting when these things happen and users provide us with logs.

Most of that I would get behind. Especially the troubleshooting one; I can appreciate how that'd be extremely helpful in diagnosing issues when users bug mod authors for support. But I'm not the one who has to implement them.

Strict opt-in only is where I differ. What if there was some way to differentiate which mods the author opted-into listing on CKAN and which ones didn't? That could be as simple as a single extra boolean in the schema that defaults to false (indicating a "no, and don't bother the mod author about this because it's squarely in CKAN territory if excrements explodes"). Maybe say it's verified by the mod author, or managed by the author, or something. Or different levels like Managed (e.g. what @RoverDude does), Opted-In (the author does want it listed on CKAN but doesn't provide the metadata files themselves), or Open/Contributed/Whatever for ones where the author hasn't provided any input. I am generally of the opinion that the last case probably shouldn't be the norm, but maybe if each different case was explicit instead of implied as it is now, that'd help? It might be a solution for both 1 and 4. (And it leaves open the possibility of authors passing-off the actual making of the files to someone else if they can't be bothered, which is fine.)

If that data was there the application could then provide the user with clear indication of who to blame first when things go wrong with their installation. (Or at least reduce how much they pester authors about problems.) Because the thing is, authors still opt-in to mods going on CKAN via SpaceDock fairly often, and it might be useful to distinguish between the two first cases I brought up.

Edit: Another random idea. If how the metadata was added (by the author, by someone else but with the author opting-in, or without direct input from the author)  was included in the metadata, it'd be possible to do things like alert mod authors whenever metadata was uploaded in the latter two cases. Heck, you could probably make a case it that the bot should do this whenever it sees a new or changed .netkan. Not sure how to go about passing the right contact info to it though. Just a thought.

I hope some of the CKAN team see this and chime in.

 

52 minutes ago, passinglurker said:

the alternative is one where mod authors code against CKAN, push for forum policy against CKAN, and ultimately go on strike in protest of CKAN much like we again see happening right now in the fallout modding community because bethesda set of up system that was more oriented to the support the users over the mod authors.

If you're talking about Bethesda.net, that has a whole pile of problems with it that aren't really relatable to this particular debacle. Or I'm missing the point.

Edited June 23, 2016 by phoenix_ca

[lodger]

On 17.6.2016 at 8:35 AM, goldenpsp said:

don't think any tool is a substitute for understanding the process, that is often what happens.  People will use CKAN and as a result never learn how to actually install a mod manually.  

So, copying one folder into the other is too much for the average user to cope with? I don't think so.

[passinglurker]

32 minutes ago, phoenix_ca said:

If you're talking about Bethesda.net, that has a whole pile of problems with it that aren't really relatable to this particular debacle. Or I'm missing the point.

Fundamentally the controversy is the same. ours is just smaller and more tame.

First bethesda implemented a system that not all thier mod authors are keen to support for various reasons or were not in a position to quickly support before users lost patience and took matters into thier own hands much like we have seen with the how CKAN is "adopted" in this community

Mod authors in fallout are initially badgered to give xboxone support which isn't to far off from the calls of ckan support in the modmangers early days just we as a community were admittedly relatively more civil about the matter.

Then when the mod author declines console support or takes his sweet time getting the job of console support done right some impatient script kitty comes along and does the job for them... very poorly... and as a result of the unsolicited actions of a third party the mod author has a new flow of external hate and support requests much like what we see with farram and people implementing FAR in CKAN in his place or with rover dude complaining about with people constantly screwing up his meta data which he on supports for his sanity sake. Though thanks to the openness of this community we've managed to avoid the worst of the theft issues fallout is suffering from but that difference doesn't change how things are similar.

Mod authors then complain to bethesda to fix the issues with thier system to prevent the thefts and stop the sullying of thier hard works good name at the hands of poor third party implementation, but unfortunately bethesda's response so far hasn't been anywhere near satisfactory much like how people's complaints about CKAN's policies seem to fall on deaf ears.

And now we have reached the present with this conversation pushing for a change of policy, but the events of the bethesdanet controversy can still show us what is to come if things keep going as they are and what is to come simply put is "Push Back" many fallout modders in response to the bethsdanet debacle have started coding thier mods to be incompatible with the xbox one, and others have pulled thier mods from all sources entirely as an act of protest until bethesda makes the changes needed to protect the mod authors and thier work. This is the direction we too are headed roverdude has already threatened to code and package his mods against CKAN and who's to say modders strikes couldn't imaginably soon follow after all 1.1.3 is right around the corner mods will need to be updated it would be the perfect opportunity to push for change. About the only thing that has stopped this in the past is the authors not wanting the good users to suffer, but for how many more updates do you think thats gonna last?.

Edited June 23, 2016 by passinglurker

[politas]

On 18/06/2016 at 4:19 AM, Diazo said:

The other strike against CKAN is that there is no dependency control with other mods. While it does a good job of checking which version of a mod work on a specific KSP version, there is no way for a mod author to say "I need this version of this other mod for my mod to work". CKAN just always installs the latest version of a mod. I'm pretty sure this is why FAR and CKAN have had so many issues playing nice with one another (or at least one of the reasons).

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.

[phoenix_ca]

32 minutes ago, passinglurker said:

but unfortunately bethesda's response so far hasn't been anywhere near satisfactory much like how people's complaints about CKAN's policies seem to fall on deaf ears.

That's the only real corollary I see here. A huge part of the problems with the Fallout modding community right now stem from limitations of consoles, and there are a lot of those limitations to go around. The fundamental problem ends-up being the same, in that you end-up with users who are belligerent in part because they don't understand the problem. (Bethesda can't be blamed directly for a lot of the problems either. Consoles are more restrictive in what they let in than the Apple App Store. There's reams of legal agreements and understandings and licenses controlling every single microcosm of a console; I'm amazed modding happened at all.)

 

The important thing to keep in mind is the comparison breaks-down because we aren't talking about large, seemingly monolithic corporations here. Everyone involved individually is able to be contacted individually and there aren't any legal teams in the way. It should at least be possible to hammer-out some ideas that will be an easement to the problems discussed.

Edited June 23, 2016 by phoenix_ca

[passinglurker]

11 minutes ago, phoenix_ca said:

That's the only real corollary I see here. A huge part of the problems with the Fallout modding community right now stem from limitations of consoles, and there are a lot of those limitations to go around. The fundamental problem ends-up being the same, in that you end-up with users who are belligerent in part because they don't understand the problem. (Bethesda can't be blamed directly for a lot of the problems either. Consoles are more restrictive in what they let in than the Apple App Store. There's reams of legal agreements and understandings and licenses controlling every single microcosm of a console; I'm amazed modding happened at all.)

 

The important thing to keep in mind is the comparison breaks-down because we aren't talking about large, seemingly monolithic corporations here. Everyone involved individually is able to be contacted individually and there aren't any legal teams in the way. It should at least be possible to hammer-out some ideas that will be an easement to the problems discussed.

No there is no break down here you are focusing on unimportant details to willfully obstruct the core of the matter.

CKAN is the ksp communities equivalent to fallout's console modding they are both new additions to their communities that take the modders time to support and as a result some don't support.

CKAN's unsolicited third party contributors are the ksp community's equivalent to fallouts mod thieves. They may not have stolen anything like their counterparts but they still cause the mod authors grief with implementations that do more harm than good.

The requests that CKAN change to an opt-in system to solve this is our equivalent to the calls for Bethesda to police the mod theft to solve its problems.

Things are happening on different scales but ultimately they are the same the mod authors are in both cases not being given the support and respect they deserve which is breeding frustration.

If the trend of similarities between ksp and fallout are anything to go by then an aggressive push back from the mod authors is the next logical step.

[phoenix_ca]

38 minutes ago, passinglurker said:

No there is no break down here you are focusing on unimportant details to willfully obstruct the core of the matter.

Please, let's try to be civil. I'm not trying to "wilfully obstruct" anything. I'm just not seeing how this is a direct parallel. A lot of the hardware and legal issues in mod support on consoles are de facto not solvable. There's only so much you can do when the hardware is grossly inferior to mid-range PCs of today on top of the legal constraints put on everyone because of the nature of licensing on consoles. When there's no script extension, no possibility of ever having that script extension without Bethesda's intervention (which could very well be much worse than a non-trivial effort on their part), and a paltry 2Gb of space for all of their mods to fit in, and you have a recipe for disappointment for all concerned.

But those huge issues aren't present here. What we seem to have here are a set of mostly policy issues, not technical ones. The technical stuff is solvable, which means we just need to get everyone on the same page, so-to-speak.

38 minutes ago, passinglurker said:

CKAN's unsolicited third party contributors are the ksp community's equivalent to fallouts mod thieves.

No, they aren't. This isn't a KSP version of The Pirate Bay we're talking about here. No one is taking mods from their download pages and redistributing them while claiming they are their own, which is what thievery implies. The .netkan metadata files essentially serve as pointers to tell the CKAN application where the downloads are, how the mod is identified internally, and which other mods conflict or the mod is dependent on. Granted, they can be broken and cause issues, but it doesn't constitute copyright infringement.

If I were to take all of RoverDude's mods and re-upload them somewhere, that would be extremely rude and definitely be redistribution and ultimately theft, sure. But what if I just wrote a small script that took a link to his mods' releases on GitHub and then downloaded the latest version and copied its contents into my KSP GameData folder? Is posting the link and the script now stealing? I would contend that it isn't, far from it, and that in principle this is much better analogue for what CKAN is doing. What it obviously needs is some polish and creation of some features that would help mod authors not get overwhelmed with users knocking-down their doors when the blame for a particular problem doesn't lie with them.

 

Also, random idea as I think of them: The CKAN spec could probably use uninstall directives too, to ensure that mods get cleaned-up correctly. ModuleManager for example creates extra data files that CKAN doesn't wipe after uninstalling it. That's something that could be done concurrently with ferram's second point and kill two birds with one stone. (It'd require the checker to have a working KSP install and automatically run it so that plugins actually execute, but it would then be possible to flag mods that need extra clean-up.)

Edited June 23, 2016 by phoenix_ca

[Kobymaru]

2 hours ago, ferram4 said:

Well... all of that sounds like part of the problem is that CKAN can point to repos other than the official one.  So make it opt-in, and force CKAN to point toward the official repo only; problem solved..

How do you plan on enforcing that? Fork CKAN repo, revert the commits in question, click build and upload the client as CKAN_l33t_h4xx0rd.exe .

I get that you guys are upset with CKAN as an entity, and maybe with the contributors. But at this point it has become much more than that: it's the Idea of having a central repository for mods.

If you force the CKAN maintainers to do it opt-in only, there are plenty of people in this community willing and able to either fork CKAN or create an equivalent system. Heck, some already claimed they would rebuild it if CKAN got killed. It'll start out as "alternative mod listings" for their own convenience, but they'll get traction with people who DO want to have all the mods in one client.

So I ask you: how do you want to fight an idea that is sitting in the heads of hundreds of users, who have seen the benefits of this system?

Edited June 23, 2016 by Kobymaru

[phoenix_ca]

4 minutes ago, Kobymaru said:

How do you plan on enforcing that? Fork CKAN repo, revert the commits in question, click build and upload the client as CKAN_l33t_h4xx0rd.exe .

I can't speak for ferram but I think he was getting at that the preferred situation would be that the mod author would, like RoverDude, have their metadata files on their own repo where they are in control of them. The repo that CKAN pulls its metadata from would then just have that stubby .netkan that tells it to get the actual file from somewhere else (the .netkan on the author's repo). Obviously that doesn't cover the case of mod authors who want their mod listed but don't want to bother with the metadata spec or other cases, which I was trying to get at in my previous posts.

[cantab]

7 hours ago, ferram4 said:

And the problem is that unless it kills CKAN completely, it will be useless.

I think you're letting the perfect be the enemy of the good here. But in the long run, a good mod manager ought to displace a bad one.

Even if it's still CKAN, an "official" repository that has proper support and is well tested has a good chance of largely displacing an unofficial repo that's full of bugged metadata.

7 hours ago, panarchist said:

I can appreciate what CKAN does, and is, but honestly the instuctions for installing a mod in KSP can fit on a napkin.

1. Is there a GameData folder in the file structure of the mod?
2. If yes, copy everything under it into your GameData folder of your KSP install
3. If no, then take the root folder, or whichever folder has a "Parts" or "Plugin Data" directory and copy *that* into your GameData folder
4. Copy your saves directory to a safe location
5. Run KSP

Except when doing that doesn't work and instead means that Mod X clobbers the stuff Mod Y needs.

4 hours ago, passinglurker said:

If CKAN's policies continue to spark flame and strife on the forums because they are not a purely opt-in with no option to opt back out at any time then the thing to do for the sake of civility on the forums is simply change the forum rules to bar the discussion of all mod managers that are not purely opt in.

I can't see that kind of policy as a good idea, and if it ever happens I'd be deeply concerned. Something everybody involved should think about: do you want Curse to move in? Because the longer CKAN and other community-developed mod managers are a basketcase, the more likely that is to happen.

1 hour ago, phoenix_ca said:

No, they aren't. This isn't a KSP version of The Pirate Bay we're talking about here. No one is taking mods from their download pages and redistributing them while claiming they are their own, which is what thievery implies.

This brings up what *may* be an option for strongly anti-CKAN mod developers. Host your mods on your own website, and write the terms and conditions of that website to ban their download by CKAN. (If CKAN provides a meaningful user agent enforcing this is simple, otherwise it might be a bit problematic but you can still complain to Squad maybe). Now if the mod is under a permissive or copyleft license you can't stop someone else re-uploading it to another site to serve as a CKAN repo, but it's an extra step for anyone who wants to go past you - hopefully someone who wants to make their own CKAN-compatible mod repository will try and do a decent job.