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

[pjf]

Woah! What's been happening with the CKAN? I hear you index a whole bunch of mods now!

That's right, Other Paul, we do! Plus there's a cool video showing how the metadata has grown.

Neat! Where can I find out more?

You should read the...

CKAN Weekly - 28 May 2015

[kcs123]

I'm not a fan of this. It's terribly limiting, and mods *should* be able to create files if they want to.

I'm not a fan of this either. Lots of mods will find themselves co-existing in the same folder, and this is just asking for collateral damage.

Luckily, there are some ways I am fond of for managing this. They're also very much aligned with us being able to make strong promises when converting autodetected mods to CKAN-managed mods, and they also let us make strong promises when it comes to preserving or removing files on upgrades or uninstalls.

TL;DR: We're working on it.

~ pjf

Thanks for looking into this problem in more convinient way. On top of tracking metadata logs, what should be alowed to delete and what not, you could keep track data what kind of mods is using particular submod to keep main mod runing properly. I mean, metadata is OK for current version of mod, but in next version of some mod, files that should be alowed to delete/overwrite could change it's behaviour.

But if you have another table in repository that keeps track of data for other related mod needed for main mod to work properly, it will be possible to know if it is safe to delete non empty folder from some mod or not.

For example, you install FAR and deadly re-entry mod. Both mods require modular flight integrator to work. For some reason you uninstall FAR.

Modular flight integrator need to stay because it is still needed for deadly re-entry. So, on uninstall procedure, CKAN need to check that new table and see if there is still active mods installed in game to see if it is safe to uninstall it or not. If there is still there listed mod that require modular flight integrator, CKAN should warn that is not safe to uninstall it.

When you uninstall both, FAR and deadly re-entry, CKAN can know that modular flight integrator is no longer required and ask user to uninstall this one as well.

This feature could be helpfull also when user try to uninstall modular flight integrator only, without knowlage that this one is essential for FAR and deadly re-entry. CKAN can warn user about it and disallow uninstall if needed.

That new "table" does not have to be too complicated. Whenever CKAN install something it should write name of mod in XML file used for tracking this. Whenever some other mod is installed that depends on this mod, it can add it's name under subnode of XML node where required mod created his "root" install node.

So whenever, install/uninstall occur, CKAN can check this and if there is no other mod that require some mod to work, than it is safe to delete entire folder regardless what kind of data is in it.

I also wrote couple of pages back some other stuff, that you might missed.

Idea how to help with more complicated mod install.

Currently, CKAN GUI when you install some mod looks consists of this (more/less)

1. Main zip package for your mod
   
2. List of mandatory packages (or other mod) that were needed for your main mod to work properly - All of them necessary
   
3. List of optional (recommanded) packages, things that could improve your mod, but it is not mandatrory for main mod to work properly
   

What i have proposed, to got additional layer of GUI when you install things:

1. Main zip package for your mod
   
2. List of mandatory packages (or other mod) that were needed for your main mod to work properly - All of them necessary
   
3. List of mutualy exclusive packages - at least one of them is mandatory for your mod, but if you choose one, other packages on that list must be excluded(unchecked) from install
   
4. List of optional packages, things that could improve your mod, but it is not mandatrory for your main mod to work properly
   

No.3. could be additional usefull feature. Sorry, don't yet have plans to make github account and open issue/request there.

Just wrote some ideas as they pop up, before I forget about them. If it can help, use it, if not, diregard it.

[Dazpoet]

Answer the parts I think I have a clue about, leaving the rest for people more knowledgable than me.

This feature could be helpfull also when user try to uninstall modular flight integrator only, without knowlage that this one is essential for FAR and deadly re-entry. CKAN can warn user about it and disallow uninstall if needed.

What if that file is a config file for the mod with your personal settings in it? I'm on slippery ice here but I _think_ this would mean that our upgrade process (as it works right now) would remove autocreated config files with personal settings if they lived in the same folder during upgrades. Just making a note of it here so pjf or some other dev can comment on if this is the case or not.

This feature could be helpfull also when user try to uninstall modular flight integrator only, without knowlage that this one is essential for FAR and deadly re-entry. CKAN can warn user about it and disallow uninstall if needed.

Right now the clients will give you a list of all mods that will be uninstalled every time you ask it to remove mod X. Say that you attempt to uninstall Modular Flight Integrator, the client will then ask if you want to remove it, FAR and DRE since they depend on it. You want this to be a more explicit system somehow?

I also wrote couple of pages back some other stuff, that you might missed.

Idea how to help with more complicated mod install.

Currently, CKAN GUI when you install some mod looks consists of this (more/less)

1. Main zip package for your mod
   
2. List of mandatory packages (or other mod) that were needed for your main mod to work properly - All of them necessary
   
3. List of optional (recommanded) packages, things that could improve your mod, but it is not mandatrory for main mod to work properly
   

What i have proposed, to got additional layer of GUI when you install things:

1. Main zip package for your mod
   
2. List of mandatory packages (or other mod) that were needed for your main mod to work properly - All of them necessary
   
3. List of mutualy exclusive packages - at least one of them is mandatory for your mod, but if you choose one, other packages on that list must be excluded(unchecked) from install
   
4. List of optional packages, things that could improve your mod, but it is not mandatrory for your main mod to work properly
   

No.3. could be additional usefull feature. Sorry, don't yet have plans to make github account and open issue/request there.

Just wrote some ideas as they pop up, before I forget about them. If it can help, use it, if not, diregard it.

No.3 is already in effect if I understand you correctly. E.g when installing TAC-LS you will be asked if you want the RO or Stock config, choosing one nullifies your ability to install the other one. Similarly if a mod in 0.90 depended on AerodynamicModel the users got to choose between FAR and NEAR, upon choosing one the other one became impossible to install. This system is used pretty heavily to get some of the visual mods to work with eachother.

I very much recommend getting a github account since it makes issues and ideas much easier to track for us.

[kcs123]

What if that file is a config file for the mod with your personal settings in it? I'm on slippery ice here but I _think_ this would mean that our upgrade process (as it works right now) would remove autocreated config files with personal settings if they lived in the same folder during upgrades. Just making a note of it here so pjf or some other dev can comment on if this is the case or not.

Well, if you are uninstalled mod, and have no other mod that require it, why you should need to keep personal config file at all when you are no longer want to use it ?

Upgrading mod over uninstaling compleatly should be recognizable by CKAN, what you have choose to do, uninstall or upgrade.

In case of upgrades CKAN can recognize trough metadata what kind of thing is possible to delete/overwrite and what not.

There is two possibilities with personal config files. In one case user have proper config files that contains bunch of customization, like keybindings, window positioning etc.

You want to keep that file after upgrade, so you don't have to bother with personal customization again after upgrade, understandable.

However, there could be another situation where user have screwed up config file and mod no longer work properly. He is advised to re-install, but even after that, mod does not work properly because faulty personal config file is still in mod folder. It is nightmare for moders to figure out what went wrong and give proper advice to user, without knowlage that he didn't actualy uninstaled mod properly.

Later one happened recently when someone opened FAR debug menu and deleted/changed some essential stuff in there and complained that FAR is faulty, no worthy etc. while it is enierly user fault.

He has tried re-install trough CKAN without checking out to delete main mod folder between installs.

How to satisfy, both, users and modders ? To have easy handling of various mods for user without making modders mad because they have to handle false bug reports more than actual problems.

Right now the clients will give you a list of all mods that will be uninstalled every time you ask it to remove mod X. Say that you attempt to uninstall Modular Flight Integrator, the client will then ask if you want to remove it, FAR and DRE since they depend on it. You want this to be a more explicit system somehow?

Right now, when you install mod X, it depends on mod Y. Another mod depends on mod Y too.

When you want to uninstall mod Y alone, currently(just checked) CKAN alows you to uninstall it, breaking others mod in that way.

Also if you want to uninstall mod X, CKAN will uninstall it without leaving other requirements installed. That is Ok if some other mod need it, but when there is no other mod depending on it,

user should be able to choose to uninstall it as well.

Mostly users will not going to pay attention if something is no longer required or not, leaving potental memory usage in game while you actualy wanted to remove it, making some space in RAM, for example.

No.3 is already in effect if I understand you correctly. E.g when installing TAC-LS you will be asked if you want the RO or Stock config, choosing one nullifies your ability to install the other one. Similarly if a mod in 0.90 depended on AerodynamicModel the users got to choose between FAR and NEAR, upon choosing one the other one became impossible to install. This system is used pretty heavily to get some of the visual mods to work with eachother.

I very much recommend getting a github account since it makes issues and ideas much easier to track for us.

Didn't come across with such installs, so I didn't know that such thing already exist in CKAN. Sorry for bothering you with that, disregad it.

I have some plans to use github in future, but until I sort out things waht I need to have and what not on my end, I only can propose ideas and issues here. Hopefully I will sort things out on my end soon.

Thanks for taking time to answer.

[Dazpoet]

Right now, when you install mod X, it depends on mod Y. Another mod depends on mod Y too.

When you want to uninstall mod Y alone, currently(just checked) CKAN alows you to uninstall it, breaking others mod in that way.

Also if you want to uninstall mod X, CKAN will uninstall it without leaving other requirements installed. That is Ok if some other mod need it, but when there is no other mod depending on it,

user should be able to choose to uninstall it as well.

Mostly users will not going to pay attention if something is no longer required or not, leaving potental memory usage in game while you actualy wanted to remove it, making some space in RAM, for example.

These sound like rather horrendous bugs in our relationship resolver. Please give examples and reproduction steps because this is one of the most critical issues I can imagine!

EDIT: Also supply OS, CKAN version and KSP version please.

Edited May 27, 2015 by Dazpoet

[plague006]

Right now, when you install mod X, it depends on mod Y. Another mod depends on mod Y too.

When you want to uninstall mod Y alone, currently(just checked) CKAN alows you to uninstall it, breaking others mod in that way.

Just to be clear, this (gif) is how uninstalling mod Y *should* be working. In the gif I show the relationship between the mods, and I only select 1 mod to be uninstalled but CKAN should force all dependent mods to be uninstalled along with it.

[mgsdk]

Right now, when you install mod X, it depends on mod Y. Another mod depends on mod Y too.

When you want to uninstall mod Y alone, currently(just checked) CKAN alows you to uninstall it, breaking others mod in that way.

Please supply a copy of registry.json when this happens, it will help with debugging. You can find it in the CKAN folder, which is a sub-folder of the KSP install you are working on.

Also if you want to uninstall mod X, CKAN will uninstall it without leaving other requirements installed. That is Ok if some other mod need it, but when there is no other mod depending on it,

user should be able to choose to uninstall it as well.

Mostly users will not going to pay attention if something is no longer required or not, leaving potental memory usage in game while you actualy wanted to remove it, making some space in RAM, for example.

A good suggestion. I don't know if we keep track of user-installed and dependency-installed mods at the moment, so it may not work retroactively.

[kcs123]

These sound like rather horrendous bugs in our relationship resolver. Please give examples and reproduction steps because this is one of the most critical issues I can imagine!

I just tried example we discussed earlier. I have installed FAR. It requires Modular Flight Integrator, so it is installed as well. After that I have installed Deadly Reentry that also require Modular Flight Integrator.

1) Tried to uninstall Modular Flight Integrator, while leaving FAR and Deadly Reentry - CKAN alows it. Installed again only Modular Flight Integrator for second scenario.

2) Uninstalled FAR and Deadly Reentry. Neither have asked to uninstall Modular Flight Integrator. After deinstalling both, Modular Flight Integrator is still left in GameData folder.

Fortunately, Modular Flight Integrator does not cause too much extra memory usage, but some other mods that have parts/textures can take considerable amount of RAM.

Another example is Antenna range that requires Toadacious tools, when you uninstall Antenna range, Toadacious tools are still left. Another example is USI/MKS/OKS mod that recommand bunch of other mods to be installed as well. If you want to uninstall one, otheres are left untouched and user might not remember to uninstall each one of additional dependencies.

KAS/KIS is also good example. Someone install KAS, KIS is one of dependencies and deceide to uninstall KAS due to bugs/issues encountered for example and want to remove it until bugs are ironed out.

You have uninstalled KAS, but KIS is still left.

There is plenty of other examples as well, those are just ones I recall from top of my head.

Usually it is not much of issue until user is encountered some bug. When that happens, user is usually advised to uninstall something, most of time some mod that he recall what was last thing installed, but might be also something else. He does this trough CKAN, thinking that he have uninstalled mod properly while there could also be leftovers either from main mod or from some of dependencies.

He try to troublshoot issue within game and it happens again, thinking that installed mod is not of issue, while it still cause it because he didn't properly uninstalled it.

- - - Updated - - -

Just to be clear, this (gif) is how uninstalling mod Y *should* be working. In the gif I show the relationship between the mods, and I only select 1 mod to be uninstalled but CKAN should force all dependent mods to be uninstalled along with it.

Yes, something like that, but it will need to do extra checking, so it does not uninstall modul manager, for example that is required for all other mods to work properly.

[Dazpoet]

I just tried example we discussed earlier. I have installed FAR. It requires Modular Flight Integrator, so it is installed as well. After that I have installed Deadly Reentry that also require Modular Flight Integrator.

1) Tried to uninstall Modular Flight Integrator, while leaving FAR and Deadly Reentry - CKAN alows it. Installed again only Modular Flight Integrator for second scenario.

Tried this using both GUI and CLI in windows and linux and am unable to reproduce this behaviour. Please do as mgsdk asks:

Please supply a copy of registry.json when this happens, it will help with debugging. You can find it in the CKAN folder, which is a sub-folder of the KSP install you are working on.

If we can get the registry.json both before and after you uninstall ModularFlightIntegrator that'll make it possible for us to track this down.

Also what is your version of CKAN, what OS are you running and what KSP version are doing this with?

[kcs123]

CKAN v1.6.17

KSP 1.0.2 Windows

Although, I didn't make a clean CKAN install, I upgraded it trough previously installed version.

Also, I was having FAR and modular flight integrator manualy installed. New version of CKAN allowed to uninstall it. I installed again and tried mentioned scenario.

I is quite late right now to provide you with json files, I will send you tomorow as soon as possible, for both, before I uninstall Flight modular integrator and after.

[kcs123]

Please supply a copy of registry.json when this happens, it will help with debugging. You can find it in the CKAN folder, which is a sub-folder of the KSP install you are working on.

A good suggestion. I don't know if we keep track of user-installed and dependency-installed mods at the moment, so it may not work retroactively.

It is possible to work retroactively too. If something like that is going to be introduced in one of future version of CKAN, it will be easy to provide legacy support.

When CKAN with that new feature is introduced, proposed table that will keep tracking mod relationship will be empty.

CKAN have his own database with all dependencies, also it also have all data what is already installed in GameData folder.

It is possible to fill necessary data going trough all already installed mods, just filling table data, without actual re-install of each mod.

What kind of mod depends on another is already known trough CKAN database repository.

Here is requested registry.json. There is several situations I attempted like yesterday. I managed to reproduce situation where DeadlyReEntry is uninstalled and MFI too, but FAR that depends on MFI have remained in gamedata folder. I tried to produce same bug with other mods too, bu it seems that they work properly as intended.

Also Tried on separate KSP instance, for test purposes only, it seems that there is no problem there either.

I will try to keep eye on stuff like that, so if it happens again, I will save needed json files and let you know about it.

[jmbailey2000]

Yes, it is radical, but I agree to that. If something is not CKAN compatible, user should install it by himself, outside of CKAN.

But, again, option to be able to wipe out whole folder when you ininstall mod, could also help. I understand concerns that something that user have add in that folder could be lost, but in most cases, there is no such super high important data in mods folder anyway. Mostly it will be just additional config files or in some cases backup of texture files, if you have used DDS converter for mods that still use png or something else.

In my case, wiping out whole mod folder could prevent that strange bug I have suffered. There is not lot of users that could investigate true reasons behind it and will just spamm forum in various threads complaining that something is not working. In conclusion, not deleting entire folder from some mod thinking something of ultra high of importance data is in that folder is actualy backfired to CKAN users creating more bugs where they should not exist.

Well, my intention is to be more informative about whole "uninstall" discussion and pro/cons behind it. If other users who have read this will pay attention more in future when using CKAN, half of job is already done.

Personally, we shouldn't ignore text boxes that provide details of something. In this case, an issue with a folder. I have ignored the message before and paid the price. No body to blame, but me. Now, I have issue with wiping out the folder via CKAN. Maybe I put files in there for a specific purpose. Maybe the mod did and has settings in the file I need. Let me go in and look and handle it. I don't want CKAN making that decision and changing CKAN to give me all the ability to research what I want to do is not feasible. Plus, personally, make people learn!!! Forums are for asking questions and people are willing to answer them. I know I am (not that I have many answers). But, let's quit forcing developers to make their programs more complex and convoluted because people don't want to "learn" how something works. Because KSP has issues, because mods have issues, I have asked questions, talked with people and Googled (lord have I Googled) and learned a lot about part CFG files. So much so that I've been able to make minor repairs to craft files so I can migrate them from .90 to 1.0 until some parts/mods are fully updated. If the mods tried to do this for me, odds are things wouldn't have been perfect, and I wouldn't have learned some very interesting things about how KSP and mods work!! It is actually quite enjoyable!

Just my $0.0193944763394949

[divad1978]

Been trying to use CKAN with no luck on Fedora Linux. My issues existed prior to the current CKAN build but after the post on Reddit about a new release I was hoping to see them go away.

I've followed these instructions:

https://github.com/KSP-CKAN/CKAN/wiki/Installing-CKAN-on-Fedora

Plus the instructions under Note from the release page:

https://github.com/KSP-CKAN/CKAN/releases

Three issues:

1) Checking a box for a mod won't always respond and I have to click 3-6 times a lot

2) If I go through and check more than a few mods and click Changeset most of the mods selected won't show up to install.

3) When scrolling down a few mods if I then check a mod it will check more than one mod It's strange because I'll hover over the box I want to check after scrolling, click the box, then it seems like CKAN scrolls a few more lines making my cursor appear over

another mod and the box for that one is checked as well as the mod I intended to check.

Images for issue two:

None of the below mods selected end up showing up in Changeset. In fact I probably have 35+ mods selected. I've noted this problem exist with much less though.

Not sure if at all related but I do see this message on the terminal screen.

Thanks. Really would love to get this tool working on my end as it's frustrating trying to manage 40+ mods.

- - - Updated - - -

I thought I'd test checking one Mod at a time and confirming ChangeSet and had the following experience.

Checked [X] Science : it showed up

Checked Action Groups Extended : it showed up

Checked Actions Everywhere : it did not show up

Unchecked Action Groups Extended : it went away

Unchecked Actions Everywhere and then checked it again : it showed up this time

Checked Alternate Resource Panel : it did not show up

Checked Ambient Light Adjustment : it did not show up

Unchecked [X] Science : it did not go away

Unchecked and Rechecked Alternate Resource Panel : still doesn't show up

I then clicked Clear on the Changeset tab and [X] Science still doesn't go away. I proceeded to click it a multitude of times out of frustration and then CKAN just actually aborts and closes with a stack

dump to my terminal session.

Thanks

Just messing with it some more and I've noticed after a few seconds checking mods just becomes very slow and I have to wait instead of just clicking the mods I want real fast. If I click a mod and just wait 10 seconds the check mark will suddenly appear. I was able to go through and select about 15 different ones albeit very slowly and they all showed up in Changeset. Unfortunately when I went to click Install

it seemed to be working for awhile downloading and then all of a sudden popped up an error: Failed to download "https://github.com/SirDiazo/AgExt/releases/download/1.32b/ActionGroupsExtended132b.zip" - error: 77

Anyways I'm done messing with it for now and just want to play some KSP. Any advise or requests for debug info please let me know.

Thanks

Edited May 29, 2015 by divad1978

[fredo]

Is there any way to uninstall all the mods at once?

[Drake1500]

Is there any way to uninstall all the mods at once?

You could change the filter to just the mods you've installed (Click the magnifying glass at the top), and then uncheck all your mods. Not quite a one-click solution, but it does make it much easier.

[Dazpoet]

Is there any way to uninstall all the mods at once?

In the terminal you can do 'ckan remove --re .' which will prompt you for an uninstall of all mods. Not implemented in the GUI yet though.

[pjf]

v1.6.18 aka Oberon released!

Changes since last version:

• [bugfix/GUI] Switching instances is likely to leave the GUI in an inconsistent state (mgsdk)
  
• [bugfix/GUI] The textbox showing new CKAN release notes has better scrolling (RichardLake)
  
• [bugfix/GUI] The GUI will no longer crash when selecting a mod with multiple choice dependencies (eg: TACLS) (pjf)
  
• [Moar Boosters] Numerous internal speed improvements (RichardLake)
  

Note

• A known bug exists where the client no longer presents the user with options when a user requests a mod with multi-choice dependencies (such as TACLS or Real Solar System) via the GUI. You can still pick the config or texture pack manually. We're working on this (#976), the multi-choice support was never supposed to have disappeared.
  
• The command-line still works fine for installing mods with multiple choices.
  

[BlackHat]

Is there a way to cause CKAN to initiate a "Refresh" on launch?

99 times out of a 100 when I start CKAN the first thing I do is "Refresh" to check for new mods or updates. [Thanks for fixing the "new in repository"] (The 1% is if I am launching CKAN to remove a mod)

It would be nice if there was a setting in the Options to do a refresh on launch.

[Dazpoet]

Been trying to use CKAN with no luck on Fedora Linux. My issues existed prior to the current CKAN build but after the post on Reddit about a new release I was hoping to see them go away.

I've followed these instructions:

https://github.com/KSP-CKAN/CKAN/wiki/Installing-CKAN-on-Fedora

Plus the instructions under Note from the release page:

https://github.com/KSP-CKAN/CKAN/releases

Three issues:

1) Checking a box for a mod won't always respond and I have to click 3-6 times a lot

2) If I go through and check more than a few mods and click Changeset most of the mods selected won't show up to install.

3) When scrolling down a few mods if I then check a mod it will check more than one mod It's strange because I'll hover over the box I want to check after scrolling, click the box, then it seems like CKAN scrolls a few more lines making my cursor appear over

another mod and the box for that one is checked as well as the mod I intended to check.

Images for issue two:

None of the below mods selected end up showing up in Changeset. In fact I probably have 35+ mods selected. I've noted this problem exist with much less though.

http://i.imgur.com/8NpO8K2.png

http://i.imgur.com/OyX7GPf.png

Not sure if at all related but I do see this message on the terminal screen.

http://i.imgur.com/TuoEMZq.png

Thanks. Really would love to get this tool working on my end as it's frustrating trying to manage 40+ mods.

- - - Updated - - -

I thought I'd test checking one Mod at a time and confirming ChangeSet and had the following experience.

Checked [X] Science : it showed up

Checked Action Groups Extended : it showed up

Checked Actions Everywhere : it did not show up

Unchecked Action Groups Extended : it went away

Unchecked Actions Everywhere and then checked it again : it showed up this time

Checked Alternate Resource Panel : it did not show up

Checked Ambient Light Adjustment : it did not show up

Unchecked [X] Science : it did not go away

Unchecked and Rechecked Alternate Resource Panel : still doesn't show up

I then clicked Clear on the Changeset tab and [X] Science still doesn't go away. I proceeded to click it a multitude of times out of frustration and then CKAN just actually aborts and closes with a stack

dump to my terminal session.

Thanks

Just messing with it some more and I've noticed after a few seconds checking mods just becomes very slow and I have to wait instead of just clicking the mods I want real fast. If I click a mod and just wait 10 seconds the check mark will suddenly appear. I was able to go through and select about 15 different ones albeit very slowly and they all showed up in Changeset. Unfortunately when I went to click Install

it seemed to be working for awhile downloading and then all of a sudden popped up an error: Failed to download "https://github.com/SirDiazo/AgExt/releases/download/1.32b/ActionGroupsExtended132b.zip" - error: 77

Anyways I'm done messing with it for now and just want to play some KSP. Any advise or requests for debug info please let me know.

Thanks

The warning about URL handlers is nothing to care about, it is for a not yet fully implemented functionallity.

I've never seen an issue quite like this one I think so we'll have to start out with the basics.

What is the output of 'mono --version' in a terminal?

Does commandline work? Aka can you issue a command like 'ckan install ContractConfigurator' and it does what one would expect it too?

In the gui can you use the up and down arrows in the modlist and click space to select/deselect mods and if so does it work better than using the mouse?

I recommend you open a github issue about this and add the information request above aswell as your initial problems to it.

- - - Updated - - -

Is there a way to cause CKAN to initiate a "Refresh" on launch?

99 times out of a 100 when I start CKAN the first thing I do is "Refresh" to check for new mods or updates. [Thanks for fixing the "new in repository"] (The 1% is if I am launching CKAN to remove a mod)

It would be nice if there was a setting in the Options to do a refresh on launch.

Please add to https://github.com/KSP-CKAN/CKAN-GUI/issues/87 so we can see what people want

[jrandom]

Uh oh... fired up CKAN after the update and I only get mods starting from "Stork Delivery System" (alphabetically) on the list. Filter says "Compatible (28)". Where'd everything else go?

[Squeaky]

Uh oh... fired up CKAN after the update and I only get mods starting from "Stork Delivery System" (alphabetically) on the list. Filter says "Compatible (28)". Where'd everything else go?

Same with me, only showing a total of 47 mods (That's including incompatible). Was working like an hour ago?

[Dazpoet]

PSA:

Our indexing bot just turned murderous and exploded a major part of the metadata repository. We're working on a solution and no changes are lost at this time since github allows us to revert all the damage!

[jrandom]

Figures a Kerbal program would be attacked by killer robots.

[abowl]

Im guessing there as in issue with repositories atm. im only getting very few mods right now

[Squeaky]

Figures a Kerbal program would be attacked by killer robots.

Infernal Robotics mod no doubt