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

[OldLost]

Note that CKAN will update ModuleManager to 2.6.24 when you're still using KSP 1.1, even though (apparently) .24 is only for 1.1.2.

MM 2.6.24 broke MechJeb for me using 1.1. I had to go back (manually) to 2.6..23 to get MechJeb working.

Just FYI for others...

[Bleddyn]

10 minutes ago, OldLost said:

Note that CKAN will update ModuleManager to 2.6.24 when you're still using KSP 1.1, even though (apparently) .24 is only for 1.1.2.

MM 2.6.24 broke MechJeb for me using 1.1. I had to go back (manually) to 2.6..23 to get MechJeb working.

Just FYI for others...

I was just starting up CKAN while reading the latest posts, thanks for the heads up. I would have updated MM without it, 

[MisterFister]

22 hours ago, MatterBeam said:

Would you therefore suggest I create a version 1.8 marked as compatible with 1.1.1?

Absolutely, yes, no question at all, most definitely.  Though, I'd suggest marking it as compatible with both 1.1.1 and 1.1.2, if you feel that's appropriate.

13 hours ago, ctbram said:

(1) What I do not understand is the mechanism by which mod releases are updated within ckan?  Do the mod authors have to push them?  Is there a request system where users can request mods be added?  Is there some magic genie that mystically makes compatible mods get updated in the repository?

I ask because things like eve for 1.1.0 version 1-1-1 (which in it self is crazy confusing to users)  Is apparently compatible with ksp 1.1.1 because streamers and friends that simply run from their steam folder and already had the 1.1.0 version installed from ckan are running it as well as all the other mods they had previously installed from their 1.1.0.1230 install within the steam folder.

(2) But because I chose to run from a clean install they are all now incompatible for me and I have to go through and manually add them if I want to play my 1.1.1 install and have the mods that I have become accustom to using?  What I do is create individual folders when there is a steam update to ksp for instance with the 1.1.1 version 1250 release I create the folders - 1.1.1.1250 (with the clean install) then make folders I add mods to like 1.1.1.1250_StremingVersion, 1.1.1.1250_Personal, 1.1.1.1250_Experimental, etc.

(3) Then the next problem that arises is when whatever "magic genie" does update the 1.1.0 mods that are still compatible with 1.1.1 I cannot uninstall the versions I manually installed without getting the infamous - "ERROR - incompatible kracken! ckan is now bricked! Thank you for playing ....." and ckan crashes and my entire install is bricked.  Then I have to spend hours trying to unravel the dependency issues that are bricking the install or just start all over from scratch again, which becomes really annoying, really fast.

CKAN works on metadata files.  CKAN is a front-end interface, it's not a "repository" like Curse or Spacedock or Github or even Dropbox; it's an index.  Well, it's actually two indexes.  The first index is of metadata files with information on where the mod is stored for download, how to download and automatically unpack it, and a series of manually-entered info on what KSP version (or range of versions) that a mod author is willing to personally, manually, and intentionally certify that a mod version is compatible with.  With a new version of the mod is published, the metadata is appended and not replaced -- CKAN will remain capable of managing the old version of the mod if a user ever wanted it, or if the user were managing mods for an older version of KSP.  Those metadata files are manually filled out by someone who intends to submit a mod, or a mod version, or a metadata update for a mod, to the CKAN index.  (Typos in the metadata files can be persnickety.)

The second index is on your computer hard drive, wherein it tracks what folders it's made and "owns" and steers well clear of any folder that it doesn't recognize (such as "Squad," or such as any mod you manually install -- this is why mixing a lot of manual mods with a lot of CKAN mods is a recipe for pain.)  If KSP autoupdates, such as through Steam, on an otherwise existing GameData folder, then CKAN will be able to track mods installed on its internal index, but will only be looking at the outward-index for mods pegged as compatible with the "current" KSP version.  Mods pegged as being compatible with previous versions will still be suppressed for purposes of first-time installs.

Note that "my streamers and friends use a mod that lists here as being a version mismatch" is one thing.  Yes, I agree with you -- your friends do it all the time, that's true.  "...and that must mean that the version mismatch is unimportant" is an entirely different statement.  "I wish CKAN would just understand that 'the mod is working despite the version mismatch' means that the mod is still compatible."  CKAN will never understand that, even if it were true, and by the way, it's not true.  The difference between "fails with no symptoms" and "is actually compatible" is something that only the mod author specifically can ascertain, and ONLY with log files.  Period.  Everything else is guesswork.
 

13 hours ago, LividPumpkin said:

Guys how can i set CKAN to show the 1.1 mods that works with 1.1.1 ? 

Work from a backed up copy of v1.1.0 until the mod metadata is manually and intentionally updated by the author.
 

7 hours ago, KerbOrbiter said:

So, can we disable version checking, i. e. enable "you're on your own" mode?

This has been asked for a long time.  Either it won't happen, or there's an issue with making it happen.  I can say that, in my opinion, introducing this would be a bad thing.

1 hour ago, Yemo said:

You confirm the "override install" and the issues are on the user. It simply installs the last known version of the mod, ckan just provides a "download/install functionality" without patronizing the users (though giving fair warning with the "override" dialog).

I remember seeing those guidelines: https://github.com/KSP-CKAN/CKAN/blob/master/policy/de-indexing.md

But what actually happens is, that ckan itself makes all mods unavailable as soon as a KSP version update hits. That is all fine for default operations, but in the end it should be up to the users to override ckan default preferences and install the mod, tranferring responsibility to the user if s/he so wishes. Especially with the KSP version issues in mind, from 1.0.x to 1.1.x! At the moment it feels as restricting as a DRM mechanism...

Mod support is a very thankless role.  I promise you, these restrictions are there to make the mod authors' jobs just slightly less worse.

[Yemo]

1 hour ago, MisterFister said:

Mod support is a very thankless role.  I promise you, these restrictions are there to make the mod authors' jobs just slightly less worse.

I currently maintain 8 mods and the lack of manual override within ckan is a major issue.

For manual installation i can tell people just to use the 1.1.1 version for ksp 1.1.2. Since there is no manual override within ckan, this is not possible there, making my job a lot worse than it could be. So with ckan I currently have to choose between telling people to install the mod manually, thus losing the simple updateability which ckan would provide, or having to update my mods for every little ksp hotfix version. Both options are far from optimal.

Please give the users manual override instead of the current DRM light.

edit: You could mark the mods installed with "override" with a simple flag/checkbox, so the user and the one looking at the screenshot of installed mods (eg a mod author providing support) can clearly spot which mods might be the first to check for causing issues.

Edited April 30, 2016 by Yemo

[MisterFister]

1 hour ago, Yemo said:

I currently maintain 8 mods and the lack of manual override within ckan is a major issue.

For manual installation i can tell people just to use the 1.1.1 version for ksp 1.1.2. Since there is no manual override within ckan, this is not possible there, making my job a lot worse than it could be. So with ckan I currently have to choose between telling people to install the mod manually, thus losing the simple updateability which ckan would provide, or having to update my mods for every little ksp hotfix version. Both options are far from optimal.

Please give the users manual override instead of the current DRM light.

edit: You could mark the mods installed with "override" with a simple flag/checkbox, so the user and the one looking at the screenshot of installed mods (eg a mod author providing support) can clearly spot which mods might be the first to check for causing issues.

What about specifying a range of compatible versions within the metadata file, or amending the metadata?  I see plenty of mods listed as "compatible" but not for v1.1.2 specifically.

[NecroBones]

 

Quick question-- What happened to the Firespitter and InterstellarFuelSwitch "Core" listings in CKAN? I use those as dependencies for several mods, and as a user was pointing out today in my threads, they've disappeared from the list if you don't already have them installed. I don't think it's a KSP 1.1.2 thing, since IFS in particular did update for it, and they're not showing even when viewing "all". Any ideas?

 

EDIT: Actually Firespitter looks OK right now, I think it's just the InterstellarFuelSwitch entries that are missing, which is preventing people from installing CCC/FTP.

 

[MisterFister]

1 minute ago, NecroBones said:

Quick question-- What happened to the Firespitter and InterstellarFuelSwitch "Core" listings in CKAN? I use those as dependencies for several mods, and as a user was pointing out today in my threads, they've disappeared from the list if you don't already have them installed. I don't think it's a KSP 1.1.2 thing, since IFS in particular did update for it, and they're not showing even when viewing "all". Any ideas?

You beat me to it, sir!

I have video of the issue being discussed, though I emphasize that this issue only appears when the mod is nowhere else installed on your system.  if you have this mod active on your KSP install, it'll show up, but it's de-listed for new installs.

Note, video plays best if downloaded and played from desktop specifically with VLC, as opposed to other players, as opposed to playing it directly through the web portal viewer embedded into the Dropbox link.

8 minutes ago, NecroBones said:

EDIT: Actually Firespitter looks OK right now, I think it's just the InterstellarFuelSwitch entries that are missing, which is preventing people from installing CCC/FTP.

Color Coded Canisters installs just fine for me -- it pulls MM and that's it.

[WildBillKerbin]

Regarding the versioning scheme, any mod with KSP version greater than the current KSP version will be flagged as compatible.

That's why mods with KSP version 1.1.99 work with 1.1.0, 1.1.1, and 1.1.2.  Until KSP releases a mod other than 1.1.x (up to .99) mods with the 1.1.99 version tag will continue to work.  In this way, modders can write mods that should work with future minor updates, but without guarantees on any major updates.  i.e. 1.1.x but not 1.2.x

My current concern is that some modders are either too busy or not concerned with updating the metadata for their existing mods if they still work with new versions.  Many 1.0.5 and most 1.1.x mods work fine on 1.1.2, but CKAN won't allow users to install them because the metadata is outdated.  While not updating the metadata may not be a big issue for hardcore modders or mod users, for those users wanting or needing to use CKAN exclusively, this lack of attention throws a major wrench in the KSP mod works.  THIS is when allowing users to install outdated-but-working mods is most useful.  

Case in point... The amazing MK1-2 Pod IVA Replacement works flawlessly in 1.1.x, but has not been updated to reflect the compatibility.  The best solution is to encourage modders and users alike to test mods and then update their metadata as quickly as possible when existing mods still work on most recent KSP releases OR to encourage modders to include metadata allowing their mods to work on future minor updates, if no issues are expected.

[blowfish]

@WildBillKerbin A lot of modders have no interest in maintaining metadata for their mods.  Some might take a look if poked but will not proactively look at it, some don't want to hear about CKAN at all.  And I don't think it's a reasonable burden to force on modders.  A few, myself included, actively maintain metadata, but I can attest to the fact that it can be a fair amount of work.

[InsaneDruid]

On 30.4.2016 at 10:25 AM, ctbram said:

I have a couple of questions forgive me if they have been asked in another form.  I went through the last 5 pages of posts and I see something like my question but no definitive answer.

QUESTIONS:

Mods installed and available in ckan for version 1.1.0 are not showing up as compatible  in ckan for 1.1.1.  Okay I understand why so please don't bother explaining this to me.

(1) What I do not understand is the mechanism by which mod releases are updated within ckan?  Do the mod authors have to push them?  Is there a request system where users can request mods be added?  Is there some magic genie that mystically makes compatible mods get updated in the repository?

I ask because things like eve for 1.1.0 version 1-1-1 (which in it self is crazy confusing to users)  Is apparently compatible with ksp 1.1.1 because streamers and friends that simply run from their steam folder and already had the 1.1.0 version installed from ckan are running it as well as all the other mods they had previously installed from their 1.1.0.1230 install within the steam folder.

(2) But because I chose to run from a clean install they are all now incompatible for me and I have to go through and manually add them if I want to play my 1.1.1 install and have the mods that I have become accustom to using?  What I do is create individual folders when there is a steam update to ksp for instance with the 1.1.1 version 1250 release I create the folders - 1.1.1.1250 (with the clean install) then make folders I add mods to like 1.1.1.1250_StremingVersion, 1.1.1.1250_Personal, 1.1.1.1250_Experimental, etc.

(3) Then the next problem that arises is when whatever "magic genie" does update the 1.1.0 mods that are still compatible with 1.1.1 I cannot uninstall the versions I manually installed without getting the infamous - "ERROR - incompatible kracken! ckan is now bricked! Thank you for playing ....." and ckan crashes and my entire install is bricked.  Then I have to spend hours trying to unravel the dependency issues that are bricking the install or just start all over from scratch again, which becomes really annoying, really fast.

UPDATE:

OMG!  Look at the very next post to mine!  This sums up my confusion on this topic perfectly and demonstrates a good reason why this entire topic of - "How to handle CKAN compatibility issues when a new version of KSP is released" might be something worth adding to a FAQs section up in the OP or at the top of the posts with a sticky tag?

1) CKAN is based around a metadata-file called .netKan. In this file, which is created semi-automatically when you tick a checkbox while uploading a mod to spacedock, or if wanted manually there is a line that defines the location where the actual mod files are hosted (for instance: "$kref": "#/ckan/github/InsaneDruid/Proton-M" for a mod hosted on GitHub or "$kref": "#/ckan/spacedock/177" for a mod hosted on spacedock). Whenever the mod is updated in these places, the CKAN entry gets updated, too, automatically. With the logical exception for simple commits on GitHub. CKAN only seeks actual releases on CKAN. Which is cool for modders, as this allows for betatesting (manually downloading the latest version from github) with automatic releases (whenever you push an release on GitHub).

In the .netKAN file, you can also specify the compatible version of KSP, or ranges of them (1.1 will mark compatibility with 1.1.0 -> 1.1.99). This line has to be edited manually when a mod is hosted on GitHub. But if a modder hosts its own .netKan, this is easy as it gets.

The decision to flag a mod as compatible lies complete on the modder in any case.

[rasta013]

First, thanks to everyone who puts in time on CKAN.  This is an extremely thankless job and anytime I get frustrated with the quirks and bugs we run into as a user I have to remember how much time, effort and patience the people who support this continue to give to the community so Thank You very much for all you do.

That said, I have two questions re: very strange behavior that I just can't seem to figure out on my own. First, can anyone explain this to me?

CRP has no dependencies but as we all know there are dozens of mods with dependencies on it.  So, with that in mind, why is it that 0.5.1.0 shows as the latest version, I have 0.5.0.0 installed but yet no offer to update is available?

The other question can't be explained with a screen shot.  Ever since 1.1 came out I have observed a really strange piece of behavior.  So the weirdness works like this. I've installed a mod manually and CKAN recognizes this and flags it with the auto-detect.  Then I see that CKAN has updated that mod to the current version so I prepare to re-install via CKAN and remove that mod manually.  I restart CKAN...and the mod still shows as being installed and auto-detected.  I restart CKAN again, and this time it removes it and allows me to install as normal.  It's not like this is a huge inconvenience, just weird.  There is one exception to this.  KSP-AVC will not clear off the installed mods list no matter what I do.  I had to update it manually a couple weeks ago because it was causing me a major startup issue.  It of course became auto-detected but no matter what I do, I cannot get it to clear so I can re-install using CKAN.

Thanks again for all the work everyone does who works on CKAN.  No matter how frustrated anyone may get with anything to do with it there is no question this is a service that makes our lives tremendously easier as players.

[nobodyhasthis2]

17 hours ago, MisterFister said:

This has been asked for a long time.  Either it won't happen, or there's an issue with making it happen.  I can say that, in my opinion, introducing this would be a bad thing.

The override function has been created #1499. It just does not have a GUI yet. Yes all the bad stuff has be discussed in depth elsewhere but people keep on asking for a version checking to be removed. Despite the fact that mod authors could avoid the whole problem by setting max_ksp.  

16 hours ago, Yemo said:

I currently maintain 8 mods and the lack of manual override within ckan is a major issue.

For manual installation i can tell people just to use the 1.1.1 version for ksp 1.1.2. Since there is no manual override within ckan, this is not possible there, making my job a lot worse than it could be. So with ckan I currently have to choose between telling people to install the mod manually, thus losing the simple updateability which ckan would provide, or having to update my mods for every little ksp hotfix version. Both options are far from optimal.

Please give the users manual override instead of the current DRM light.

edit: You could mark the mods installed with "override" with a simple flag/checkbox, so the user and the one looking at the screenshot of installed mods (eg a mod author providing support) can clearly spot which mods might be the first to check for causing issues.

The analysis of the PR on deciding if 1.1.1 > 1.1.2 is a minor change is here #1690. If this is done all mods get automatically accepted. Doing this sort of thing was ok in the past for ksp 1.0.3. to 1.0.4. but terrible for ksp 1.0.4 to 1.0.5

With a "minor" update. Each individual's mileage might vary. 

 

Edited May 1, 2016 by nobodyhasthis2

[Torih]

Hi, would it be possible for someone to have a look at the real plume meta file. Its still showing  "ksp_version_max": "1.1",

Also Interstellar Fuel Switch has not been showing in a while, I've looked at the meta file and it appears ok to me (not that I really know what to look for).

Thanks

Edited May 1, 2016 by Torih

[NecroBones]

53 minutes ago, Torih said:

Also Interstellar Fuel Switch has not been showing in a while, I've looked at the meta file and it appears ok to me (not that I really know what to look for).

 

I've opened an issue for it on github:  https://github.com/KSP-CKAN/NetKAN/issues/3851

 

[blowfish]

Wow, from the posts in this thread you'd think that everyone forgot how to install mods manually when they started using CKAN.

[WildBillKerbin]

Just now, blowfish said:

Wow, from the posts in this thread you'd think that everyone forgot how to install mods manually when they started using CKAN.

Maybe, but the bigger issue is the way CKAN handles (or doesn't) conflicts when manually installed mods are removed.  Mixing manual installation and CKAN installation can result in some pretty disastrous errors, to the point of rendering CKAN unusable.

FWIW, I use CKAN for CKAN supported and updated mods, but JSGME for manual installs.  JSGME does a really good job of tracking changes and will even prevent the removal of one mod it it was later changed by another mod.  (As is the case of many mods that include required mods or other data shared across mods.)

For example, I have KSP-AVC 1.1.6.1 installed via JSGME because the latest CKAN version is 1.0.3.0 but AVC is a required mod for several 1.1.x compatible mods.  Not having AVC installed effectively breaks at least a couple 1.1.x mods the depend on it.  Also, StageRecovery 1.6.5 (a pre-release for 1.1.x) and the MK1-2 Pod IVA Replacement which was for 1.0.4 but still works with 1.1.x are also handled by JSGME.

In the end, users may have to pick between using CKAN or installing manually, but not both.  

[MisterFister]

3 hours ago, blowfish said:

Wow, from the posts in this thread you'd think that everyone forgot how to install mods manually when they started using CKAN.

 

2 hours ago, WildBillKerbin said:

Maybe, but the bigger issue is the way CKAN handles (or doesn't) conflicts when manually installed mods are removed.  Mixing manual installation and CKAN installation can result in some pretty disastrous errors, to the point of rendering CKAN unusable.

FWIW, I use CKAN for CKAN supported and updated mods, but JSGME for manual installs.  JSGME does a really good job of tracking changes and will even prevent the removal of one mod it it was later changed by another mod.  (As is the case of many mods that include required mods or other data shared across mods.)

For example, I have KSP-AVC 1.1.6.1 installed via JSGME because the latest CKAN version is 1.0.3.0 but AVC is a required mod for several 1.1.x compatible mods.  Not having AVC installed effectively breaks at least a couple 1.1.x mods the depend on it.  Also, StageRecovery 1.6.5 (a pre-release for 1.1.x) and the MK1-2 Pod IVA Replacement which was for 1.0.4 but still works with 1.1.x are also handled by JSGME.

In the end, users may have to pick between using CKAN or installing manually, but not both.  

I cannot agree more wholeheartedly.  Having a mostly-manual modset with CKAN running a small handful of mods is no real issue.  The opposite is true, if you have a mostly-CKAN modset with a very small number of manual mods.

Having large categories of each is just asking for trouble, especially when trying to convert a mod from manual to CKAN.  With v1.1's release of legitimate and stable Win64 support, I predict that the average modset will grow or possibly explode in size.

In v1.0.x, I was running MASSIVE installs in Linux64, which I still have backed up.  I'm talking installs running so many mods that it's physically impossible to actually count them all (counting GameData folders is misleading, since some modders consolidate multiple mods into the same parent folder underneath GameData, whereas some individual mods install multiple GameData folders.  Counting CKAN checkboxes is misleading, since some trigger dependencies, whereas some checkboxes install multiple mod families such as KerbinSide Complete.)  My best guess is that I was running somewhere between 235 and 250 mods.  Modsets like that are absolutely insane to manage manually -- it can literally take more than an hour just to go through and install them all, and that is a time estimate of what it'll take to update them assuming that a list of those needing updating is already at the ready.  Sometimes it's necessary to actually attempt to load KSP once (or more!) just to see if a mod times out due to version mismatches with a prereq mod, and with a KSC idle screen ram footprint tapping the underside of 8GB (on a 16GB system running an i7 with a GTX980) before entering the VAB or TrackingStation, individual loading attempts with no errors took more than fifteen minutes.  Longer if I'm waiting through a possible timeout, or if a recently-updated mod needed to perform some first-time-only prep work of some type.

For players with offline lives (I graduate from law school in exactly two weeks -- wow! -- followed by the bar exam) any significant or sustained loss of the utility of CKAN is literally game-breaking.  I admit that I'm on the outside of the bell curve here, but mod-heavy players will absolutely expand their average modlist, and CKAN's usefulness can only expand.

Edited May 1, 2016 by MisterFister

[nobodyhasthis2]

4 hours ago, blowfish said:

Wow, from the posts in this thread you'd think that everyone forgot how to install mods manually when they started using CKAN.

Wow, from that post in this thread you'd think that some mod authors never learned how to provide metadata when everyone started using CKAN. Or course they don't have to. We can finish the job for them with a bit of user feedback. .

Normally missing data gets fixed amazing fast. The only problem is around KSP update time things get super busy around here. Especially when a KSP hotfix is more that a hotfix to some mod authors. They need to be picky about version control. Mod authors are awesome in creating amazing things and the CKAN crew work their butts off making it all available. Then comes along the end user and says "Hey guys you missed a bit". Instead of "thank you". Then the situation can deteriorate from there,

If users are complaining to a mod author about a mod not appearing in CKAN the answer is this ...

3 hours ago, MisterFister said:

I cannot agree more wholeheartedly.  Having a mostly-manual modset with CKAN running a small handful of mods is no real issue.  The opposite is true, if you have a mostly-CKAN modset with a very small number of manual mods.

Having large categories of each is just asking for trouble, especially when trying to convert a mod from manual to CKAN.  With v1.1's release of legitimate and stable Win64 support, I predict that the average modset will grow or possibly explode in size.

[snip]

For players with offline lives (I graduate from law school in exactly two weeks -- wow! -- followed by the bar exam) the utility of CKAN is literally game-breaking.  I admit that I'm on the outside of the bell curve here, but mod-heavy players will absolutely expand their average modlist, and CKAN's usefulness can only expand.

Yes sir that is the facts. Linux64 users have seen the future of KSP modding. Although it also crops up in Windows when using multiple KSP install directories. So you might not be that far out of the statistical bell curve.

In my own case running in windows. A minimum amount of mods is around 104 after 1.0.x. The Unity 4 memory cap limits the maximum amount (How I get so many under the cap is another story).

So I ended up creating mod packs (.ckan files) aimed at setting up different flavours of Ksp. So although less mods are used the whole problem of tracking changes is just as bad. Possibly worst. On an average day I could have between 4 to 8 builds. So possibly 400 to 800 mods being chased. CKAN is the way ahead. There are things about it I hate with a passion (The documentation should be more verbose about the dangers of not obeying requests folder wipes). However the benefits to users with large installs or multiple install folders cannot be disputed.  

 

 

Edited May 1, 2016 by nobodyhasthis2

[MisterFister]

2 minutes ago, nobodyhasthis2 said:

There are things about it I hate with a passion (The documentation should be more verbose about the dangers of not obeying requests folder wipes).

The first half of your comment above, with the graphic, seems snarky to me.  YMMV.

As for this snippet here, could you go into some description of what you mean with the folder wipes thing?  I don't know how to articulate my question better, but it may or may not shed insight upon something I'm worried about on my end.  If it's out of scope, please feel free to PM me instead.

[nobodyhasthis2]

1 hour ago, MisterFister said:

The first half of your comment above, with the graphic, seems snarky to me.  YMMV.

As for this snippet here, could you go into some description of what you mean with the folder wipes thing?  I don't know how to articulate my question better, but it may or may not shed insight upon something I'm worried about on my end.  If it's out of scope, please feel free to PM me instead.

Yes the first part is a double edged sword. It just might get more self edited later on if people don't see the funny irony of version control. Especially if end users can't take the joke. Or pulled all together if too many objections raised. 

The point I was trying to make is Mod authors are awesome in creating amazing things and the CKAN crew work their butts off making it all available. Then comes along the end user and says "Hey guys you missed a bit". Instead of "thank you". Then the situation can deteriorate from there, Sometimes the best policy for the end users is to wait things out. It is difficult time for everyone right now. There is only a tiny number of people working away in their spare time to build the support network. It all takes time.

As for the remark about folder wipes. It is a really long story but crops up briefly in the thread a few pages back. In short CKAN can't be trusted to fully uninstall mods and users need to be aware of this. Mods can write their own files independently when CKAN is not running. Plus a mods folder structure is mostly agnostic. There is no default structure forced onto mod authors. There has been a few cases in the past where dodgy config files have messed things up badly. So when users get told to do a clean install by an author after a big update. They need to listen up. Unselect the mod in CKAN. Manually delete the left over config files / folders from Gamedata. Then reinstall through CKAN again.

Every suggestion to automate the process leads to a worse outcome that the original problem. Honestly we have debated this to death. It's a paradox. I am not saying it can't be fix. It just super time consuming to do once every permutation is accounted for. For something that is only an edge case that affects a small number of mods.

 

Edited May 1, 2016 by nobodyhasthis2

[MisterFister]

1 hour ago, nobodyhasthis2 said:

So when users get told to do a clean install by an author after a big update. They need to listen up. Unselect the mod in CKAN. Manually delete the left over config files / folders from Gamedata. Then reinstall through CKAN again.

Honestly, I go a step further for my own purposes and I uninstall KSP and delete that folder before proceeding.  Admittedly, my practice of saving archived copies of all "virgin" (untouched-by-mods-or-by-CKAN) KSP version numbers makes this a more palatable option for me than it may for some.  Now that I mention it, I'd guess that it also increases my incentive to run a CKAN-only modset, as well, which would explain my thus-far-inarticulable emphasis on preferring CKAN over manual.  :-\

And what you mention about ghost-folders being left behind -- this is, I think, the single best justification for allowing there to be some sort of user-visible "history" within CKAN of what mods were manipulated when, and how, and in what order.  Even just date, order, mod entry name, and one-word flags for what was done (installed, updated, "favorited" which we need, uninstalled, "suppressed" or hidden which we also need.)

[WildBillKerbin]

3 hours ago, nobodyhasthis2 said:

Then comes along the end user and says "Hey guys you missed a bit". Instead of "thank you". Then the situation can deteriorate from there,

 

I sure hope my comments were not taken as a complaint so much as an attempt at constructive criticism and commentary.

I (and hopefully most CKAN users) really appreciate all the hard work that the CKAN authors put into such a cool product.  Your contribution to the KSP community just can't be overstated and I do indeed thank you!

[MisterFister]

On ‎2016‎-‎04‎-‎29 at 1:00 AM, stupid_chris said:

You do know that 90% of mods CKAN pages aren't managed by the mod's author :| That link is simply broken due to forum migrations. Take that up to the CKAN people, not me.

 

22 hours ago, MisterFister said:

Fair enough, but with the next version release to CKAN (I'm not suggesting you make a special thing about it) would it be possible to update the metadata to reflect this forum thread?

 

1 hour ago, stupid_chris said:

I think you missed the part where I'm not the one responsible for this... For the second time, take this up to the CKAN people.

As requested by the mod author, I am reporting here that the Kerbal Stock Part Expansion mod lists a flawed forum URL in the metadata.  Is there any way I can assist in correcting this?

Edited May 2, 2016 by MisterFister

[Skeltcher]

Unterminated string. Expected delimiter: ". Path 'available_modules.KerbalTubes.module_version.['1.2.1'].identifier'. line 147403. position 7477322.

This message appears when i open CKAN, after i click "continue" to ignore the program open but no mods appearing and the same message appears again when i click "Refresh".
How do i fix it?

[Hobbes Novakoff]

Is there a way to set CKAN to ignore hotfixes when figuring out if a mod is compatable? I was trying to set up a KSP directory using CKAN, but it didn't let me install a bunch of mods (for example, scatterer) because the mods were set to be compatible with 1.1 and I had 1.1.2.