CKAN pros/cons

[swjr-swis]

14 minutes ago, RoverDude said:

"It's worth remembering also that not selecting the CKAN option on Spacedock does not mean that the mod won't be listed on CKAN. If a CKAN user asks for a given mod to be listed, we will generally do so, barring some legal block. Since you have licensed Larinax under CC-BY-SA-NC, you've given us irrevocable permission to distribute it."

This is not neighborly.  It encourages restrictive licenses, and ultimately pushes more modders into actively opposing CKAN.

That I agree on, regardless of any other arguments.

14 minutes ago, RoverDude said:

Replace with 'Delete old version first then copy' and you've hit the 99.9% use case.

I wouldn't say quite that much, there's definitely a number of mods out there with config files or other output that you need/want to keep in the mod directory, which if doing a very simplistic 'delete and replace' will be lost.

Truth is that it's not so simply cut, mods do come with various installation instructions/requirements, sometimes chancing for specific updates, and mod authors have good reason to want that freedom. But at the same time, the fact that this diversity does exist and happen, is also why some form of automated install would very much up the user-friendliness, even for those of us with PhDs and intimate knowledge of processor registers and six programming languages.

Edited June 21, 2016 by swjr-swis
quote was too short

[Stone Blue]

15 minutes ago, swjr-swis said:

Like I said: not so simple after all. Now you have to search and check every mod release thread for specific instructions regarding each update, that may (or may not!) be stated in the OP.

For one mod, 5 mods, 10 mods.. perhaps doable. For 50 mods? 100? 200? Updating each at their own random moments and may or may not have exceptions in the 'very simple' install procedure to take into account.

Why would you have to search EVERY mod release thread?... And besides, dont people even LOOK at a mod release thread OP, BEFORE choosing to install a mod, to even SEE what the mod is, and looks like... ???

I disagree... While there ARE mods that lack pertinent info in the OP, I think its a small majority, or its an old mod that circumstances (KSP/other mod updates) have broken or changed the requirements, and the OP is not active any more...
In these cases, its a simple matter of PMing the dev to add such info to the OP... OR even scanning the last page or two of the thread for the most current info...And possibly posting a reply, asking for help or clarification...

I'm sorry, i just think there is a generation coming up that just wants things handed to them, simply, that work, and dont want to exert the effort to do for themselves, especially when it's someone ELSE who has to hand feed them... AND I AM NOT SINGLING OUT ANY ONE PERSON< OR GROUP BY STATING THIS... If this offends YOU (in the general sense of the word, NOT swjr-swis specifically), then maybe you should ask yourself WHY you are taking offense to it... Does it hit to close to home?

If this post is also deemed worthy of escalating things, I will also remove this one... I also ask that anyone who wants to quote this, please just delete the quote and replace with "<snipped>"

Edited June 21, 2016 by Stone Blue

[swjr-swis]

5 minutes ago, Stone Blue said:

Why would you have to search EVERY mod release thread?... And besides, dont people even LOOK at a mod release thread OP, BEFORE choosing to install a mod, to even SEE what the mod is, and looks like... ???

The install moment is only one time when this may play a role and the simplest case; the update moments are what more frequently mess things up.

 

6 minutes ago, Stone Blue said:

I disagree... While there ARE mods that lack pertinent info in the OP, I think its a small majority, or its an old mod that circumstances (KSP/other mod updates) have broken or changed the requirements, and the OP is not active any more...
In these cases, its a simple matter of PMing the dev to add such info to the OP... OR even scanning the last page or two of the thread for the most current info...And possibly posting a reply, asking for help or clarification...

When I mod an install, it's easily hundreds at a time (209 on my current mod install for 1.1.2). Consider having to do this for an average of 5-6 mod updates every single day, even without a KSP update being the cause. Keeping your install up to date becomes very tedious, I can tell you, even with the convenience of most of the mods being 'done' by CKAN, let alone having to scour the 'last page or two' of relkease threads on the off chance, which lately turns out not to be so off, that the update requires a little different or extra to be done.

Just for giggles, check a moment how many mods are currently in 'maintenance mode' only by people that are not the original dev, and where updates are only being notified somewhere in the thread and not in the OP. It's almost starting to become a norm of sorts, unfortunately (yet very grateful that volunteers pop up willing to maintain and recompile mods).

 

12 minutes ago, Stone Blue said:

If this offends YOU (in the general sense of the word, NOT swjr-swis specifically)

Not offended, you're stating your case and so am I. Even if it's not really my case per sé, as I'm perfectly capable of even recompiling mods for myself when/if I need to... there is still a case in my view for making the process less time-consuming for those of us that like very modded installs.

[RoverDude]

Except for the fact that when CKAN falls over... it falls over horribly.

My worst install support cases have been and continue to be CKAN users.  And if anything, support for installs has increased with the advent of CKAN because while it is a nice idea in theory (minus all of the nasty opt-in bits), it lacks in execution.

Watch the forums after any release for a live example of this.

 

For the OP.

Learn to install mods.  It's trivially easy.  Do not use CKAN.

[cantab]

23 minutes ago, swjr-swis said:

For one mod, 5 mods, 10 mods.. perhaps doable. For 50 mods? 100? 200? Updating each at their own random moments and may or may not have exceptions in the 'very simple' install procedure to take into account.

This problem has led to me in the past simply not updating mods. I've got them installed and then kept on those same versions for as long as I keep playing that KSP version.

And now I've decided to take a leaf out of Microsoft's book. Unless I encounter critical bugs, I'm going to check, update, and test mods once a month. If I finish my mod checking on the 15th June and Mod X releases its awesome new update on 17th June, well I'm not playing that update until July.

The "and test" bit above is by the way a major reason updating mods isn't trivial for me, and still wouldn't be even if I did use CKAN. I don't just slap the updated version on because I've been burnt by that before, so now I check that my game is running properly with the updated set of mods. Obviously I can't check every fine detail, but I can and do catch gross issues. Stuff like celestial bodies going missing or being clearly bugged, unwanted severe changes to aerodynamics, and even framerate dropping to a quarter of what it was before.

[Tex_NL]

34 minutes ago, Stone Blue said:

Why would you have to search EVERY mod release thread?... And besides, dont people even LOOK at a mod release thread OP, BEFORE choosing to install a mod, to even SEE what the mod is, and looks like... ???

I disagree... While there ARE mods that lack pertinent info in the OP, I think its a small majority, or its an old mod that circumstances (KSP/other mod updates) have broken or changed the requirements, and the OP is not active any more...
In these cases, its a simple matter of PMing the dev to add such info to the OP... OR even scanning the last page or two of the thread for the most current info...And possibly posting a reply, asking for help or clarification...

I'm sorry, i just think there is a generation coming up that just wants things handed to them, simply, that work, and dont want to exert the effort to do for themselves, especially when it's someone ELSE who has to hand feed them... AND I AM NOT SINGLING OUT ANY ONE PERSON< OR GROUP BY STATING THIS... If this offends YOU (in the general sense of the word, NOT swjr-swis specifically), then maybe you should ask yourself WHY you are taking offense to it... Does it hit to close to home?

If this post is also deemed worthy of escalating things, I will also remove this one... I also ask that anyone who wants to quote this, please just delete the quote and replace with "<snipped>"

A deliberate quote and NOT a snip!
You are absolutely correct by stating too many people want life to be spoon-fed to them. If people are offended by the truth that's their problem, not yours. You should NEVER apologise for telling the truth.

[swjr-swis]

2 minutes ago, cantab said:

This problem has led to me in the past simply not updating mods. I've got them installed and then kept on those same versions for as long as I keep playing that KSP version.

Agreed, I've got to that point several times too. My older still live installs of 1.0.4 and 1.0.5 are in effect frozen - no updates at all happen there, those careers saves will either end or get archived exactly as they are now. My 1.1.2 modded install is not running a career, as I'm in wait mode for a few of the promised KSP fixes, but in the meantime it's a mod test bed, to develop a few mod-lists to use with the next stable release. The constant updating is rather inevitable for this.

'Freezing' an install however forms another point of controversy between users and authors: an oft-heard question back when first reporting any issue is "are you running the latest (dev*) version?". Users are expected to keep their mods up to date.

(* another one of those trends lately, of releasing fixes in interim/dev/forked versions not published in the OP)

Believe it or not, I'm not trying to heckle mod authors here. A lot of the arguments I see mentioned are perfectly reasonable, and would be workable when only dealing with one or a small number of mods/authors. But it rather unravels for the user when the number increases. And wasn't one of the hypes everyone was vocal about with 1.1.x 64-bit support the ability to use 'moar mods'...?

[Stone Blue]

42 minutes ago, swjr-swis said:

The install moment is only one time when this may play a role and the simplest case; the update moments are what more frequently mess things up.

 

When I mod an install, it's easily hundreds at a time (209 on my current mod install for 1.1.2). Consider having to do this for an average of 5-6 mod updates every single day, even without a KSP update being the cause. Keeping your install up to date becomes very tedious, I can tell you, even with the convenience of most of the mods being 'done' by CKAN, let alone having to scour the 'last page or two' of relkease threads on the off chance, which lately turns out not to be so off, that the update requires a little different or extra to be done.

Well, i DO understand this... I usually run around 120-130 mods myself... I would run more, but I'm on a 4yr old laptop...

But then, really, unless something is actually game breaking, or buggy for a function you actually USE in-game, I dont see the necessity of having to stay on top of updates that religiously... Of hving to have the latest update, simply BECAUSE it IS the latest update..???

47 minutes ago, swjr-swis said:

Just for giggles, check a moment how many mods are currently in 'maintenance mode' only by people that are not the original dev, and where updates are only being notified somewhere in the thread and not in the OP. It's almost starting to become a norm of sorts, unfortunately (yet very grateful that volunteers pop up willing to maintain and recompile mods).

This i can agree with, it DOES make it a bit more troublesome and time-consuming...

Best thing to do is to once in awhile go to the Addon Releases forum, and scan the latest threads for mods with recent postings.. ESPECIALLY with those comments last posted by the OP...
THIS is the reason I REALLY wish EVERY mod dev would include, and update the date of the latest release in the thread title...

 

50 minutes ago, swjr-swis said:

Not offended, you're stating your case and so am I. Even if it's not really my case per sé, as I'm perfectly capable of even recompiling mods for myself when/if I need to... there is still a case in my view for making the process less time-consuming for those of us that like very modded installs.

Thats where I DO see the benefit of something like CKAN: a way to take away some of the tediousness, and simplify things, for those who know what they are doing... However, i see many (read LOTS) of people openly asking for support, when they are clearly kind of clueless, and using CKAN more as a crutch, willing to invest some time into at least learning BASICS of mod install, before wnating to install several hundred mods at once... THOSE, ARE the people that "I", and most mod devs, seem to be concerned about... NOT the ones who properly know how to at least state, or do basic troubleshooting, for mod support... Over on Reddit, I see too many times, someone ask for support, or about installing a mod, who hasnt even heard of CKAN, get one-line replies of "Oh, just install CKAN, it will do EVERYTHING for you, and you wont have to bother putting in any effort at all"...

Thank You!... I agree... YOU have every right to state your case, and I think we've been doing a good job of at least agreeing to disagree.
And again, I am NOT trying to single YOU out, or lessen your argument... I might be trying to CHANGE your opinion thru discussion, but you and everyone who feels strongly as you do has the absolute right to their opinion, and to state it openly, and I will defend that right...

[RoverDude]

And hooray.  Just found another case where 'random people from the interenet' added my stuff to CKAN.  Stuff that I can pretty much guarantee will break due to bad CKAN metadata in my next patch.  Found it at random.

No communication, just support issue spawning.

This folks is why CKAN is bad.

[swjr-swis]

1 hour ago, RoverDude said:

Stuff that I can pretty much guarantee will break due to bad CKAN metadata in my next patch.

Why are you putting bad CKAN metadata in your next patch...?

[RoverDude]

I'll assume that was sarcasm

Random guy on internet submitted CKAN data with metadata that is going to be totally invalidated next release... and it will break.  Hence why I maintain my own.  Now I get a ton of support issues because of a non-working mod.  Because the CKAN guys have no concept of how to actually work with the community who's content they are dependent on.

[Bombaatu]

Thank you all; the question has been answered.

[maxrsp]

Bombattu is gonna kill me for adding to this after it appears he tried to bring this discussion to a nice close

Since I'm not a mod author like many of the folks responding to this thread, I tend to take the user perspective which is to make the process as user-friendly as possible because I'm interested in a huge community that will keep the game alive and strong for years to come.  Like many others, I have no problem with installing mods manually and troubleshooting as required but that's neither here nor there, I still want it to be one-click if possible.

That said, I have great respect for the time and effort modders dedicate to make our game better, so I also accept the counter arguments and I certainly don't want these guys burdened with "extra" support requirements.

So both sides are right... what a brilliant observation!  So now what?  Let me ask this:

Why don't we ask a few of the established mod authors to develop a standard spec/process for mod installations that could be automated.  That way, mod authors would get control back of how their mods are installed and save a ton of time and frustration supporting uncontrolled installs.  While at the same time providing users the elusive one-click solution.

We have had many games with a far more complex mod install process be completely automated, I'm not sure why KSP is so different.  An obvious example of this is the Nexus Mod Manager which can install mods for many many different games.  I've used it extensively for Fallout 3 (and NV), Skyrim, Fallout 4, and Witcher 3 with great success.  I'm not advocating for NMM specifically (its not perfect), nor am I looking to start another Nexus-based discussion here, only pointing it out as an example of what can be done to standardize and simplify for everyone.

At the end of the day if only one of these perspectives prevails (modders or users) then we all lose because we'll never achieve the maximum potential for modding with KSP.

My 2 cents

Edited June 21, 2016 by maxrsp

[Stone Blue]

3 hours ago, maxrsp said:

That said, I have great respect for the time and effort modders dedicate to make our game better, so I also accept the counter arguments and I certainly don't want these guys burdened with "extra" support requirements.

<snipped>

So both sides are right... what a brilliant observation!  So now what?  Let me ask this:

<snipped>

At the end of the day if only one of these perspectives prevails (modders or users) then we all lose because we'll never achieve the maximum potential for modding with KSP.

Well stated

[phoenix_ca]

7 hours ago, maxrsp said:

Why don't we ask a few of the established mod authors to develop a standard spec/process for mod installations that could be automated.  That way, mod authors would get control back of how their mods are installed and save a ton of time and frustration supporting uncontrolled installs.  While at the same time providing users the elusive one-click solution.

 

I have no idea. Modders here are in the best position to do exactly that. This topic is like playing with a live grenade (which I'm sorry to say, is extremely reminiscent for me of the reasons I left the KSP community years ago...coming back to this mess reminds me why I left in the first place  ). With all due respect to RoverDude, KSP-AVC is not a solution for heavily-modded installs. Full stop. It's great to have as a backup to know when CKAN is going wrong (as it recently did with Historian Expanded; AVC's warnings let me know there was something off). However, it doesn't support dependencies, and it doesn't detect conflicts. What's worse, running AVC requires you run the game itself, which is a slow-as-molasses operation compared to CKAN checking for updates.

The reason I use CKAN is because it's the only viable solution for running 200+ mods at once. At that scale, human error becomes a very major concern, and can make debugging the install because you fumbled and installed some older dependency file over a newer one because hey, mod authors aren't perfect and/or aren't around and sometimes do that, a major pain-in-the-ass. I use it for the same reasons I use Mod Organizer for Skyrim. It's the best solution available, not necessarily the best solution.

So I'll keep using it and keep contributing metadata files and/or updates when appropriate, for the sake of keeping it running. This is going to sound rude but: If there's a problem, how about we all shut up and fix it instead of bickering?

[ferram4]

10 hours ago, maxrsp said:

Why don't we ask a few of the established mod authors to develop a standard spec/process for mod installations that could be automated.  That way, mod authors would get control back of how their mods are installed and save a ton of time and frustration supporting uncontrolled installs.  While at the same time providing users the elusive one-click solution.

Your suggestion to fix CKAN... is to have a bunch of us get together, create our own version of CKAN from scratch with direct control instead?  Why the hell would be bother with all that work?  It wouldn't be even remotely worth it unless it definitively, completely, totally destroyed CKAN and left no trace of it anywhere KSP touches, but that's not going to happen, so all the problems with it discussed here will still exist.  And there is always the risk that it morphs into the kind of thing CKAN is currently if it focuses more on users than on modders.  This is not a solution in the slightest, it just sounds good because it's trying to hit some strange "middle ground."

2 hours ago, phoenix_ca said:

So I'll keep using it and keep contributing metadata files and/or updates when appropriate, for the sake of keeping it running. This is going to sound rude but: If there's a problem, how about we all shut up and fix it instead of bickering?

Oh, I forgot to add this complaint to the long list of ones related to CKAN: the fact that any time a CKAN issues occurs and causes workload for me, CKAN contributors and users respond to complaints about it by demanding that I put in work for them.  This happens every single time.  And none of them accept blame (or even blame any policies or anything in CKAN) for the issue; at best, it's blameless.  At worst, it's the modder's fault for not directly supporting CKAN metadata.

[cantab]

47 minutes ago, ferram4 said:

Your suggestion to fix CKAN... is to have a bunch of us get together, create our own version of CKAN from scratch with direct control instead?  Why the hell would be bother with all that work?  It wouldn't be even remotely worth it unless it definitively, completely, totally destroyed CKAN and left no trace of it anywhere KSP touches, but that's not going to happen, so all the problems with it discussed here will still exist.  And there is always the risk that it morphs into the kind of thing CKAN is currently if it focuses more on users than on modders.  This is not a solution in the slightest, it just sounds good because it's trying to hit some strange "middle ground."

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. From the point of view of end-users, "better" is going to include having lots of mods. 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. I would venture that "better" for the mod developers is going to include not creating bugs and issues from screwed-up installs, and that too is most achievable with the input and involvement of those developers.

[dewin]

I like CKAN in principle, though I feel it does have a lot of flaws in implementation.  The original intent was to be like various Linux package managers (namely apt), but it falls short in many ways.  I've often wondered if a cross platform port of apt/dpkg would be a better tool for the job.

A few major things that I think would help CKAN for everyone are:

- The ability for it to have changelog/important information as part of the install/upgrade process.  This can allow its use for cases like "90% of this mod is just copying files from X to Y, but you absolutely must do these other steps or nothing will work."

- A prominently displayed bit on who the "official" maintainer is for metadata.  Installation issues should be reported to that maintainer, which might be the mod author but not necessarily.

- A way for users to submit unofficial updates, but warn about them.  ("This version of SuperPluginMod is not officially supported by its author.  Install anyways?")

- Explicit support for beta/alpha/dev mods, with user selectable release preferences for each mod or their entire install as a whole.

- More mod authors or communities to maintain their own CKAN repositories.  This allows users to still gain all of CKAN's benefits while still allowing mod authors to maintain control.  I know that @sarbian does this with MJ dev builds, and there are a few others.

 

If the overwhelming issue with CKAN is its management, there's always the option of forking the existing repository and adopting a more strict policy about updates to the fork's metadata. 

[phoenix_ca]

On 2016-06-21 at 10:58 AM, RoverDude said:

And hooray.  Just found another case where 'random people from the interenet' added my stuff to CKAN.  Stuff that I can pretty much guarantee will break due to bad CKAN metadata in my next patch.  Found it at random.

 

If you would care to be specific, I'd make a PR to fix it right now (assuming I could without a priori knowledge of whatever the next update will be). But I just went through all of the mods on CKAN that have you as the author, and aside from Asteroid Day and Firespitter Core, all of them just point to your repo. O.o

 

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

There is another option. Close the NetKAN repo, make it a walled garden more fortress-y than Apple's App Store, and only let mod authors touch their metadata files.

I think it's obvious how that'll end-up though. We'll end-up with users passing around their own hacked-together CKAN files that they'll use for installs when mod authors inevitably forget or don't update the metadata files (or simply have no interest in doing so and thus don't create them at all, like @JPLRepo; and to be clear, JPLRepo's stance is an entirely understandable one that I fully support). We'll be in an even worse situation than we are now, because instead of there being one place to point to and say "AHA! That's the problem!" we'll have dozens of unique files buried in threads or completely out-of-sight in PMs between users.

Driving users "underground" like that by putting the full onus on mod developers to support CKAN or any manager like it will serve no one.

[RoverDude]

29 minutes ago, phoenix_ca said:

 

If you would care to be specific, I'd make a PR to fix it right now (assuming I could without a priori knowledge of whatever the next update will be). But I just went through all of the mods on CKAN that have you as the author, and aside from Asteroid Day and Firespitter Core, all of them just point to your repo. O.o

 

There is another option. Close the NetKAN repo, make it a walled garden more fortress-y than Apple's App Store, and only let mod authors touch their metadata files.

I think it's obvious how that'll end-up though. We'll end-up with users passing around their own hacked-together CKAN files that they'll use for installs when mod authors inevitably forget or don't update the metadata files (or simply have no interest in doing so and thus don't create them at all, like @JPLRepo; and to be clear, JPLRepo's stance is an entirely understandable one that I fully support). We'll be in an even worse situation than we are now, because instead of there being one place to point to and say "AHA! That's the problem!" we'll have dozens of unique files buried in threads or completely out-of-sight in PMs between users.

Driving users "underground" like that by putting the full onus on mod developers to support CKAN or any manager like it will serve no one.

It was the Malemute - and they already pulled it.  Which is for the best right now.  And restricting NetKAN to purely opt-in only would not be a bad move IMO, though I would not hold my breath on that one.  I still maintain that manual installs coupled with KSP-AVC remains the better solution for reasons noted previously, and in light of how incredibly easy it is to install KSP mods.  Conflicts are very rare, and in the few cases where you stomp over dependencies with older versions, KSP-AVC sorts that out.  It also lacks the lag time issue of CKAN (I am already getting CKAN support requests due to this, despite 'playing nice' and having current metadata).

 

I would add.  Yesterday, in the middle of releasing all of my stuff, I had to stop, go poking around for metadata, figure out why the Malemute was even appearing in CKAN, try to scare up a CKAN person, and in the end, stop what I was doing to log an issue.  All for something I didn't initiate and wanted no part of.  In other words, my valuable time was wasted (again) by 'random person on the internet'.

[Bombaatu]

One of the reasons I like CKAN as a user is that I can see newly-added mods that I might have otherwise missed. Threads move so rapidly on the forums that it is easy to miss something. However, I fully understand the mod-makers' frustration with it; the tool is incomplete in that it does not do dependency version checking, and allows anyone to edit the metadata files which results in a support nightmare. I see a solution along these lines:

1. A stand-alone product, in that you do not have to run KSP to get a report of updates
2. Well-documented metadata requirements (I have not viewed CKAN's so this is not a condemnation)
3. Opt-in only - of course, this would require the mod makers' support
4. Only the mod-maker OR THEIR DESIGNATED AGENT(S) can edit the meta-data. This could help with the point above, allowing the mod maker's work to be on the new platform but freeing them of much of the onus of maintaining metadata. This would also eliminate the 'random-person-on-internet' issue.
5. The metadata should track dependency versioning. In the case of a version conflict, notify the user

[soundnfury]

I'm both a mod author and a CKAN user, and from both sides I've found the CKAN process to be well-designed.  Obviously some other people in this thread have had rather different experiences, but that brings me on to the second point...

I've only seen one substantive complaint about CKAN, which is "CKAN users pester me about CKAN even if I don't touch it".  Frankly, I don't see how that's CKAN's fault - rather it's caused by some members of the community being excessively entitled, and we've seen that in plenty of other contexts that have nothing to do with CKAN.  (The phrase "64 bit" comes to mind, I can't think why.)  Getting rid of CKAN, or changing its submission rules to forbid third-party metadata submissions, wouldn't change that in the slightest.

12 minutes ago, Bombaatu said:

the tool is incomplete in that it does not do dependency version checking

I have seen this claimed a number of times in this thread, but my understanding is that it's not true.  Certainly the metadata can specify versions with dependencies - see https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#relationships - and I'm fairly sure the client respects them.

[Bombaatu]

11 minutes ago, soundnfury said:

20 minutes ago, Bombaatu said:

the tool is incomplete in that it does not do dependency version checking

I have seen this claimed a number of times in this thread, but my understanding is that it's not true.  Certainly the metadata can specify versions with dependencies - see https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#relationships - and I'm fairly sure the client respects them.

Ah. My bad from making the assumption - that was the gist I was getting and have just recently ran into this very thing with version 0.7.4 of MOLE. Turns out CKAN did not update a dependency as it was supposed to.

[SingABrightSong]

I use CKAN, but I suspect I'm a minority of its use case in that I don't generally expect support things I've paid for, let alone for things released for free. Too much experience with Bethesda games, I suspect.

Installing a mod manually is quite easy for KSP, of course, and CKAN is unnecessary for installations(And, with the AVC, unnecessary for updating them), but I find it useful to check out newly released mods. How much metadata is included in an AVC file, though? I don't recall whether it includes a hyperlink to the download page.

 

 

[phoenix_ca]

4 hours ago, RoverDude said:

It was the Malemute - and they already pulled it.  Which is for the best right now.

Yeah. I looked back at the history and that was actually my bad. It was my first contribution and I didn't know you were managing your own mods. It got merged; later I realized you manage your own files by looking at all the other USI ones and once I knew what was going on I edited the wiki to point-out to anyone else new wanting to contribute that some authors manage their own stuff and it's better to leave them to it (there was no such information when I looked at that guide and thus, that didn't occur to me; at the time I didn't know CKAN even had that ability, to pull from some other metadata file somewhere and the one in the repo being effectively just a pointer to it).

Anyway, that was mostly a documentation issue and has since been fixed. Hopefully no one else new who wants to add your mods to CKAN will do what I did because they'll read the guide and be clued-in. Or at least I can promise to bring-it-up as long as I'm keeping my eyes on that repo.

(I had the best intentions! The Malemute Rover is a great mod.  )

 

4 hours ago, RoverDude said:

I would add.  Yesterday, in the middle of releasing all of my stuff, I had to stop, go poking around for metadata, figure out why the Malemute was even appearing in CKAN, try to scare up a CKAN person, and in the end, stop what I was doing to log an issue.  All for something I didn't initiate and wanted no part of.  In other words, my valuable time was wasted (again) by 'random person on the internet'.

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

 

3 hours ago, Bombaatu said:

My bad from making the assumption - that was the gist I was getting and have just recently ran into this very thing with version 0.7.4 of MOLE. Turns out CKAN did not update a dependency as it was supposed to.

The crux of that issue is that CKAN depends on the original metadata being correct, and while large portions of that is automated (including versioning by reading the AVC .version file if it's there), as far as I'm aware things that specific are limited to users having to manually add them to the .netkan file for the mod. That leaves some room for human error, which can definitely be frustrating for both users and mod authors alike.

The obvious solution, I think, would be to get AVC to support dependency versioning as well (not just the mod version + KSP version). If it's there, CKAN could read it and use it. It would add some robustness without the mod author needing to understand the vagueries of the CKAN metadata spec (of which there are many ).

As for the spec itself, that's something of a documentation issue. I've tried to add important bits when I can (like editing the "getting started" part for new users who want to add a metadata file so that it mentions specifically to look-out for authors like RoverDude who prefer to manage their own metadata files that I mentioned earlier), but a lot of the extra bits like overrides and stuff really needs better documentation and examples. (Not being well-versed in C# and Perl myself doesn't help.)

 

4 hours ago, soundnfury said:

I've only seen one substantive complaint about CKAN, which is "CKAN users pester me about CKAN even if I don't touch it".

That certainly seems to be the biggest complaint, unless I'm missing something.

 

4 hours ago, soundnfury said:

I have seen this claimed a number of times in this thread, but my understanding is that it's not true.  Certainly the metadata can specify versions with dependencies - see https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#relationships - and I'm fairly sure the client respects them.

While true, this does also require periodic human intervention to make sure those versions are up-to-date, which is a problem.

 

2 hours ago, SingABrightSong said:

How much metadata is included in an AVC file, though?

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.

Edited June 22, 2016 by phoenix_ca