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

[steve_v]

I never had a problem installing mono- did you think I had?

The '/usr/local/bin/mono: command not found' did tend to suggest that either mono was not installed, or it wasn't in /usr/local/bin. It certainly isn't in /usr/local on Debian... but I guess Ubuntu will be Ubuntu.

- - - Updated - - -

Argh, again too slow I am, nevermind.

Edited October 10, 2015 by steve_v

[politas]

Sorry- we were writing at the same time- it was a user issue (see above). But to answer:

I specified /usr/local/bin because thats what the manual said and, yes, a quick check verified that mono is installed there.

Well, that's odd. It's /usr/bin/mono on my Ubuntu 14.04 system. I am using the mono-project.org repository, though, so that might be installing it in a different location.

[politas]

The netkan I posted was an example, ripped from several sources :-)

Here is a link to AutoPruner: http://forum.kerbalspaceprogram.com/threads/101309-Script-AutoPruner-v1-1-Prune-those-parts-that-suck-up-your-RAM!-(2015-018)

Surely that is a separate mod? It would be better to handle that as a depends or recommends, and make a separate .netkan for it. You could then install a config file for pruner to handle the parts that aren't required, I suppose?

Here is the current version of the netkan, in a working state:

{
    "spec_version": "1.4",
    "identifier": "AntennaRangePatches",
    "name": "Antenna Range Patches",
    "$vref": "#/ckan/ksp-avc",


    "version":"0.1.0",


    "license": "MIT",
    "download":    "https://dl.dropboxusercontent.com/s/qb74avlcski8y1o/arp.zip?dl=0",
    "depends": [
        { "name": "AntennaRange" },
        { "name": "ModuleManager" }
    ],
    "conflicts": [
        { "name": "AntennaPatch4AntennaRange"}
    ],
    "install": [
        {
            "find"        : "AntennaRangePatches",
            "install_to"    : "GameData"
        },
        {
            "find"        : "AutoPruner",
            "install_to"    : "GameRoot"
        }
    ],
    "recommends": [
        { "name": "RemoteTech" },
        { "name": "Antennas" }
    ]
}

I'm not entirely certain, but I think the "version" line is not required if you have a properly formatted KSP-AVC .version file, given that you have used the vref. Leaving the version details to that process will mean you won't need to update the .netkan file for every mod update (though I suppose using Dropbox would force that anyway. Have you considered using a Github repo? You'd easily get a consistent url that way.)

CraftImport can download from KerbalX. KerbalX can also supply a .ckan to install any mods the craft file needs. If mods aren't available for the craft, I want to start CKAN to install them, and also exit the game when doing so.

For now, I'm just downloading the .ckan file and giving the user instructions.

That sounds very risky. For a start, how would you call ckan? The required command will vary depending on the user's operating system and particular installation. Also, any errors ckan gives would disappear due to not having any persistent interface (most of the time, anyway).

[MisterFister]

Note -- Runnig KSP 64-bit unhacked in Linux.

In the "filter" button, has it always defaulted to "compatible," or what that a setting that I'd selected without recalling?

Anyway, I run ~180 mods in CKAN plus an additional four that I install manually. One pf those four is Astronomer's Visual Pack addon for EVE, and I go manual with that one because the different choices and resolution selections seems to be beyond CKAN's ability to customize.

The other three are Kethane, CactEye 2 Orbital Telescopes (recently replaced thread due to new author), and perhaps the awesomest of the three in my opinion, ResearchBodies. In just idly going through the filter options inside CKAN (I wasn't looking for anything specific, I was just doodling and surfing) I saw references within CKAN to Kethane and CactEye. Hmm.

Inside CKAN, there was a left-column notation of "AD" instead of a checkbox to select it. Knowing that CKAN has settings designed to prevent it from attempting to manipulate manually-installed mods, I decided to uninstall those two mods by deleting their respective GameData folders. After fiddling in CKAN and even rebooting my system, I can navigate to those entries again through setting the filter option to "All" but I still cannot install these mods. Through the metadata panel to the right, I could actually manage to download the zipfile into my CKAN cache, but still, no dice to install.

Am I doing something wrong? Is this intended behavior for some kind of user-reported indexing that is not intended for full CKAN support?

Also, I've asked on the respective threads of all three of those mods if there's any thought to moving to CKAN. There has been no acknowledgement of the question. Is any info available from the CKAN goalkeepers over here on those mods or any others that might soon appear? And how reliable is the filtration option "New in repository"?

Edited October 11, 2015 by MisterFister

[politas]

Note -- Runnig KSP 64-bit unhacked in Linux.

In the "filter" button, has it always defaulted to "compatible," or what that a setting that I'd selected without recalling?

Anyway, I run ~180 mods in CKAN plus an additional four that I install manually. One pf those four is Astronomer's Visual Pack addon for EVE, and I go manual with that one because the different choices and resolution selections seems to be beyond CKAN's ability to customize.

The other three are Kethane, CactEye 2 Orbital Telescopes (recently replaced thread due to new author), and perhaps the awesomest of the three in my opinion, ResearchBodies. In just idly going through the filter options inside CKAN (I wasn't looking for anything specific, I was just doodling and surfing) I saw references within CKAN to Kethane and CactEye. Hmm.

Inside CKAN, there was a left-column notation of "AD" instead of a checkbox to select it. Knowing that CKAN has settings designed to prevent it from attempting to manipulate manually-installed mods, I decided to uninstall those two mods by deleting their respective GameData folders. After fiddling in CKAN and even rebooting my system, I can navigate to those entries again through setting the filter option to "All" but I still cannot install these mods. Through the metadata panel to the right, I could actually manage to download the zipfile into my CKAN cache, but still, no dice to install.

Am I doing something wrong? Is this intended behavior for some kind of user-reported indexing that is not intended for full CKAN support?

Also, I've asked on the respective threads of all three of those mods if there's any thought to moving to CKAN. There has been no acknowledgement of the question. Is any info available from the CKAN goalkeepers over here on those mods or any others that might soon appear? And how reliable is the filtration option "New in repository"?

I'm going to psychically guess that you're running nVidia graphics. I'm curious as to what you mean by "unhacked" though. ~180 mods sounds pretty hacked to me!

Astronomer's Visual Pack is a bit of a pain to get installed, but what option is missing?

Getting Autodetected mods back into CKAN is one of the trickiest things to do. You could try (having manually uninstalled the mods) removing the KSP instance from CKAN and re-adding, but the most useful thing would be to run mono ckan.exe repair from the command line (you'll need to have your KSP instance set as the default first). There is also a plugin that attempts to turn Autodetected mods into CKAN-managed ones, but my experience with that has been mixed.

There is a curious resistance from some mod authors to ckan. I don't understand it, but our only real option is to work around them or leave them out. CKAN policy is that we do not need a mod author's permission to include their mod (it certainly all goes easier if they're happy to work with us, though!), but some mods have licences that make CKAN's distribution methods legally questionable, so it's best to leave them out.

Edited October 11, 2015 by politas

[FreeThinker]

Question, instead of using Kerbalstuff as the main hosting source for a mod, could I instead direct to a Curse hosted download?

Edited October 11, 2015 by FreeThinker

[linuxgurugamer]

@FreeThinker:

Question, instead of using Kerbalstuff as the main hosting source for a mod, could I instead direct to a Curse hosted download?

Yes. You just have to specify Curse in the netkan.

According to the CKAN spec:

#/ckan/http/:url

Indicates data should be fetched from a HTTP server, using the :url provided. For example:

#"$kref" : "#/ckan/http/https://ksp.marce.at/Home/DownloadMod?modId=2",

Obviously replace the url with yours.

This is only available in the CKAN spec 1.6, so you would also need the following line:

"version"        : "1.6",

- - - Updated - - -

@politas

Surely that is a separate mod? It would be better to handle that as a depends or recommends, and make a separate .netkan for it. You could then install a config file for pruner to handle the parts that aren't required, I suppose?

As of now, it's not a mod, it's just an external program

I'm not entirely certain, but I think the "version" line is not required if you have a properly formatted KSP-AVC .version file, given that you have used the vref. Leaving the version details to that process will mean you won't need to update the .netkan file for every mod update (though I suppose using Dropbox would force that anyway. Have you considered using a Github repo? You'd easily get a consistent url that way.)

You are correct.

That sounds very risky. For a start, how would you call ckan? The required command will vary depending on the user's operating system and particular installation. Also, any errors ckan gives would disappear due to not having any persistent interface (most of the time, anyway).

Which is why I've dropped the idea, and am now just giving the user instructions in a dialog after the craft is imported.

However, it is possible to have a custom command for each OS, or, have the user enter a command line. Also, when calling CKAN on the command line, it does send errors to the stdout (console), which can be captured and displayed.

LGG

Edited October 11, 2015 by linuxgurugamer

[MisterFister]

I'm going to psychically guess that you're running nVidia graphics.

:-| Why, yes. I'm legit curious how you figured that. I'm not even mad.

I'm curious as to what you mean by "unhacked" though. ~180 mods sounds pretty hacked to me!

There is a working "hack" to run 64-bit KSP in Windows, and further "hacks" in circulation that actually modify mod .dll's to circumvent a mod author's intent to disable their own mod when the Win64 build of KSP is detected. Think FAR and other somesuch "core" mods. Very justifiably pissed several mod authors off. So, my knee-jerk "this is what I'm running" always specifies that I'm working within a sanctioned an unhacked Linux64 build. Yes, specifying "Linux" is technically enough, but I just don't want any room for someone to see "64" and roll their eyes and either snarkily refuse to offer support, or silently refuse in the form of ignoring my questions -- which I see happen to others all the time. Generally, I recognize the volunteer nature of mod-work and that's just my very slight and insignificant way of attempting to respect that. I recognize that it's less of an issue for a mod like CKAN, but like I said, habit.

As for so many mods: and frankly I can't decide on the exact "number" of mods, since several mods can come prepackaged in one CKAN entry, whereas something like EVE can be one mod with several entries needed to specify the parameters. Indeed, even counting GameData folders is misleading. One possible count places me above ~230. In any event, as to your implied statement that it's hacky... well, my troubleshooting involved LONG hours spent staring at the loading screen, video-capturing it to identify where stuff started crashing, reading a lot of crash logs, time spent prioritizing my way through what mods I actually wanted, and time spent segmenting my modlist to engage in elimination rounds to "find the conflict." I have a reasonably stable build right now, and I think I go from CKAN-load to career select in less than nine minutes.

Astronomer's Visual Pack is a bit of a pain to get installed, but what option is missing?

It's not a function of "missing," it's just that there are so many low-medium-high-insane resolution choices to make among individual planets, the skybox, the cloud textures, etc., that the checkbox selection system of CKAN never seemed to generate a functioning install for me. So, I worked around it. :shrug:

Getting Autodetected mods back into CKAN is one of the trickiest things to do. You could try (having manually uninstalled the mods) removing the KSP instance from CKAN and re-adding, but the most useful thing would be to run mono ckan.exe repair from the command line (you'll need to have your KSP instance set as the default first). There is also a plugin that attempts to turn Autodetected mods into CKAN-managed ones, but my experience with that has been mixed.

I considered your first suggestion, but I see in the metadata for the mods that I mention that they're tagged for ksp v0.25 or v1.0.0 (I'm running v1.0.4.) Given that my manual copy is working, that on a clean instance with ZERO mods I can't select the mods in question, and that I don't think electively messing with my heavy load of 180-230 mods is justified at this time for the likely payoff. I'll just bookmark their forum pages and keep tabs on it that way.

Thanks for the reply though! Helpful points all around.

Edited October 12, 2015 by MisterFister

[politas]

:-| Why, yes. I'm legit curious how you figured that. I'm not even mad.

I spent much of the last year struggling with beautification mods while running KSP on Linux with AMD graphics. It seems there's a curious bug somewhere in the AMD drivers that freezes your computer when certain types of PNG are loaded. Some of the cloud and other textures used by EVE and Astronomer's Visual Pack include those type of PNGs. It's a really tricky bug to track down, and there doesn't seem to be any agreement as to exactly which component of the chain of layers are causing the issue, or any real urgency for anyone working on any part of that chain in fixing this particular issue. I recently swapped to an nVidia graphics card, and so many things are working much better now!

There is a working "hack" to run 64-bit KSP in Windows, and further "hacks" in circulation that actually modify mod .dll's to circumvent a mod author's intent to disable their own mod when the Win32 build of KSP is detected. Think FAR and other somesuch "core" mods. Very justifiably pissed several mod authors off.

Ah, I see. Didn't realise that was happening.

As for so many mods: and frankly I can't decide on the exact "number" of mods, since several mods can come prepackaged in one CKAN entry, whereas something like EVE can be one mod with several entries needed to specify the parameters. Indeed, even counting GameData folders is misleading. One possible count places me above ~230. In any event, as to your implied statement that it's hacky... well, my troubleshooting involved LONG hours spent staring at the loading screen, video-capturing it to identify where stuff started crashing, reading a lot of crash logs, time spent prioritizing my way through what mods I actually wanted, and time spent segmenting my modlist to engage in elimination rounds to "find the conflict." I have a reasonably stable build right now, and I think I go from CKAN-load to career select in less than nine minutes.

We should swap information. I'm in much the same boat. Did a massive "select ALL the mods!!!!" the other day and wound up with some bizarre problems.

It's not a function of "missing," it's just that there are so many low-medium-high-insane resolution choices to make among individual planets, the skybox, the cloud textures, etc., that the checkbox selection system of CKAN never seemed to generate a functioning install for me. So, I worked around it. :shrug:

Hmm. I found if I pre-downloaded the file for one option, and also the various "Depends" mods, then it went pretty smoothly. Working out that all the various "Astronomer's Pack" entries use the same download file made it so much easier. It was a mod like Astronomer's that led me to taking up CKAN in the first place, so there's no way I'd install it other than through CKAN.

- - - Updated - - -

@politas

As of now, it's not a mod, it's just an external program

Well, it modifies game files, so it is a mod, but in the same way that CKAN is a mod. It sounds like a tricky thing to use in conjunction with CKAN, though. If it renames a file that CKAN has installed, then CKAN will lose the ability to remove that file when uninstalling the mod it came from. I suppose that its method cuts memory usage in a way that getting the same in-game result with ModuleManager doesn't?

Does it have an "undo" function? To have ckan run AutoPruner automatically after installing, you'd probably need a complementary undo function to run before ckan uninstalls.

EDIT: Just did some more reading and found the 'unprune' option. Would be interesting to see if this and CKAN could be integrated smoothly.

Edited October 11, 2015 by politas

[Ranger]

That means that either Mono is not installed, or that it is not in your search path. Bash is reporting that when it tries to run the command "mono", it can't find anything to run.

echo $PATH$

will show you your search path for commands (other than built-ins). The executable file called "mono" has to be in one of the directories listed. Mono should normally be installed into /usr/bin/ (though /usr/bin/mono will probably be a symbolic link).

Try running just this:

mono -h

You should see the same error message, which clearly indicates that the problem is with your Mono installation, not with CKAN.

Sorry for the delay, I have been AFK for a few days

I kind of figured that it was a problem with the actual Mono install and not with the mod, but I figured it was worth a shot to ask if anyone else had had the same issue after the 10.11 update.

I tried the "mono -h" and I did indeed get the same error.

[politas]

Sorry for the delay, I have been AFK for a few days

I kind of figured that it was a problem with the actual Mono install and not with the mod, but I figured it was worth a shot to ask if anyone else had had the same issue after the 10.11 update.

I tried the "mono -h" and I did indeed get the same error.

No problem with the delay; we're here talking about a game after all. I'm regularly off the forums for days at a time. Lots of other things in my life.

I'm afraid I don't know how Mono installation can be checked/re-installed on MacOS. Looks like the latest version is available as a Mac Package (.pkg) here, though.

[damerell]

@FreeThinker:

Yes. You just have to specify Curse in the netkan.

But there are two issues. The first is that CKAN cannot automatically detect new versions of Curse-hosted mods. The second is that everyone loathes Curse. :-/

[FreeThinker]

@FreeThinker:

Yes. You just have to specify Curse in the netkan.

According to the CKAN spec:

#/ckan/http/:url

Indicates data should be fetched from a HTTP server, using the :url provided. For example:

#"$kref" : "#/ckan/http/https://ksp.marce.at/Home/DownloadMod?modId=2",

Obviously replace the url with yours.

This is only available in the CKAN spec 1.6, so you would also need the following line:

"version"        : "1.6",

I understand but the url to the download on curse is not clear.

the download site is at http://www.curse.com/ksp-mods/kerbal/236825-ksp-interstellar-extended/2261911# , but what is the link to the download?

Edited October 12, 2015 by FreeThinker

[linuxgurugamer]

I understand but the url to the download on curse is not clear.

the download site is at http://www.curse.com/ksp-mods/kerbal/236825-ksp-interstellar-extended/2261911# , but what is the link to the download?

Please, for your sanity, for the ability of CKAN to automatically detect updates, and for everyone else's sanity, upload your mod to Kerbalstuff.com

Curse makes it difficult on purpose, since they want to show you advertising, etc.

That being the case, you can look at this for inspiration: http://superuser.com/questions/588684/batch-get-the-url-of-to-a-file-from-html-document

[nobodyhasthis]

Found a strange bug report in CKAN. looks like another metadata bug due to loading a mod listed as 1.0.2. Due to either no community feedback / creator metadata update / hidden compatibility issue. Everything works but this CKAN the error is disconcerting. That is the strange bit it all seems to be good and I can't see a problem in game. People also seem positive about the mod still working in 1.0.4.

Thought it worth posting a bug report despite everything working as it may be of interest to CKAN developers.

See the end of this message for details on invoking

just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************

CKAN.ModuleNotFoundKraken: Cannot install HGR, module not available

at CKAN.CkanModule.FromIDandVersion(IRegistryQuerier registry, String mod, KSPVersion ksp_version)

at CKAN.RelationshipResolver.<RelationshipResolver>c__AnonStorey0.<>m__0(String name)

at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()

at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)

at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

at CKAN.RelationshipResolver..ctor(IEnumerable`1 module_names, RelationshipResolverOptions options, IRegistryQuerier registry, KSPVersion kspversion)

at CKAN.MainModList.ComputeConflictsFromModList(IRegistryQuerier registry, IEnumerable`1 change_set, KSPVersion ksp_version)

at CKAN.Main.<UpdateChangeSetAndConflicts>c__async1.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at CKAN.Main.<ModList_CellValueChanged>c__async0.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__4(Object state)

************** Loaded Assemblies **************

mscorlib

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.34014 built by: FX45W81RTMGDR

CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll

----------------------------------------

ckan

Assembly Version: 0.0.0.0

Win32 Version: 0.0.0.0

CodeBase: file:///F:/Kerbal%20Filesw/used/ckan.exe

----------------------------------------

System.Core

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.33440 built by: FX45W81RTMREL

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

----------------------------------------

System

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.34239 built by: FX452RTMGDR

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

----------------------------------------

System.Windows.Forms

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.34250 built by: FX452RTMGDR

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

----------------------------------------

System.Drawing

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.34262 built by: FX452RTMGDR

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

----------------------------------------

System.Configuration

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.33440 built by: FX45W81RTMREL

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

----------------------------------------

System.Xml

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.34230 built by: FX452RTMGDR

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

----------------------------------------

Microsoft.GeneratedCode

Assembly Version: 1.0.0.0

Edited October 12, 2015 by nobodyhasthis

[Ranger]

I looked around a bit on the Mono mailing list/forums. Found the issue. Hope that you do not mind that I will explain the fix here for others.

Apparently when you try to run the Mono installer, it tries to install to /usr/local/bin/.

However, the "bin" directory does not exist by default in El Capitan. And the installer will not create it for some reason. So you need to manually do so before you run the installer.

It is a hidden and locked directory, so you will need admin access, but since the installer also need an admin password, that should not be an issue. However, I will give detailed instructions in case someone that does not normally do things like adjusting permissions needs to fix this issue.

1) In the Finder, Select the Go menu, then Go to Folder...

2) Type or copy in /usr/local/ and hit "Go"

3*) When it opens, right- or control-click in a clear area of the window, and select "Get Info". This is also available if you have the window selected under the File Menu.

(optional) If it is not already expanded, click on the little triangle beside "Sharing and Permissions" so that it is pointed down and that area of the window is expanded.

4) In the lower right corner of the Get Info window, click the lock icon and then enter the admin password.

5) Then to the lower left, select the "+" button. This will add who can make edits to the "local" directory

6) I would suggest just selecting "administrators" in the dialog box that opens up, as that will prevent users that do not have admin access from doing anything with a system directory. You can also just select your account, which will prevent anyone else from doing anything. Then click "OK.

7) When whoever you select shows up in the "Sharing and Permissions" area, change the "Privliege" drop-down to "Read & Write" You can now close the Get Info window.

8) Back in the "Local" window, either right/control-click again or go the the "File" Menu again and select "New Folder". Name this folder "bin"

You can now install Mono normally. It should install in this new directory, and should run normally now.

*Note that I had done the unlocking of the directory as part of my experimenting to get the installer to work. It MAY not be necessary, but I know that it will work, so that is what I am explaining. You can try skipping to step 8 at this point, but it may or may not allow you to create the directory, and if it does the installer may not be able to write to it.

[politas]

I looked around a bit on the Mono mailing list/forums. Found the issue. Hope that you do not mind that I will explain the fix here for others.

Apparently when you try to run the Mono installer, it tries to install to /usr/local/bin/.

However, the "bin" directory does not exist by default in El Capitan. And the installer will not create it for some reason. So you need to manually do so before you run the installer.

That's interesting. Does /usr/bin exist? Perhaps the Mono installation package should switch to that directory. You could file a bug report here.

5) Then to the lower left, select the "+" button. This will add who can make edits to the "local" directory

6) I would suggest just selecting "administrators" in the dialog box that opens up, as that will prevent users that do not have admin access from doing anything with a system directory. You can also just select your account, which will prevent anyone else from doing anything. Then click "OK.

7) When whoever you select shows up in the "Sharing and Permissions" area, change the "Privliege" drop-down to "Read & Write" You can now close the Get Info window.

8) Back in the "Local" window, either right/control-click again or go the the "File" Menu again and select "New Folder". Name this folder "bin"

You can now install Mono normally. It should install in this new directory, and should run normally now.

*Note that I had done the unlocking of the directory as part of my experimenting to get the installer to work. It MAY not be necessary, but I know that it will work, so that is what I am explaining. You can try skipping to step 8 at this point, but it may or may not allow you to create the directory, and if it does the installer may not be able to write to it.

I would recommend going back into the properties dialog box for /usr/local and turning those privileges back off for security purposes. Make sure the /usr/local/bin directory is owned by root and only has read+execute global privileges, too.

Can you show us what you get from an echo $PATH$ ​command, by the way? There should be a section that looks like this:

 :/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:

Posix filesystem hierarchies and the debate over where software should be installed has been going on for decades!

Edited October 14, 2015 by politas
Added Bug report link for mono-project

[Ranger]

That's interesting. Does /usr/bin exist? Perhaps the Mono installation package should switch to that directory. You could file a bug report here.

I would recommend going back into the properties dialog box for /usr/local and turning those privileges back off for security purposes. Make sure the /usr/local/bin directory is owned by root and only has read+execute global privileges, too.

Can you show us what you get from an echo $PATH$ ​command, by the way? There should be a section that looks like this:

 :/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:

Posix filesystem hierarchies and the debate over where software should be installed has been going on for decades!

Yes, /usr/bin does exist. And as for reporting, the person that posted the message that caused me to try this route said that he has done so.

Switching back the permissions, I can see that and even even agree with it. I just was not sure about mono working afterwards. But I switched the Admin group from "Read & Write" to "Read only" (In case I need to unlock it again for updates), and CKAN worked fine. I will report on any issues with updates when it comes up.

And here is the result of the echo command:

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin$

[wossname]

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

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

tl;dr...

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

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

[steve_v]

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

I.e. Norton being stupid. This is nothing new, and hardly the fault of CKAN.

I guarantee that there's plenty of other files on my machine Norton has never heard of, does that make them "BAD" too?

...that would reduce this problem.

True, but so would a non-stupid AV, since it's the AV causing the issue. Edited October 16, 2015 by steve_v

[Cetera]

I've skimmed through pieces and parts of this thread, and read through the last several pages, and I've tried searching on the thread, but I'm not finding what I'm looking for. I apologize in advance if this has been discussed already.

Background: I am running a career mode game where I installed almost everything with CKAN, for the first time. It works great! It makes managing my mods nearly effortless, and I'm so appreciative of that. It used to take me hours and hours and lots of folder management to keep everything straight.

This career I'm running is for my youtube series (see my signature). I'm running with too many mods, to be honest, and it takes the game a long time to load, and a short time to crash. I've recently decided that I want to start taking some Kronal Vessel Viewer screengrabs for blueprints and things to tie in to the episodes, so I thought I'd add KVV. However, it seems to have a fairly drastic memory leak, and makes things crash a lot faster.

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

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

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

[Prezombie]

CKAN crashes if you select Astronomer's pack - Clouds - Low, apply, then select Astronomer's pack - Clouds - High, then deselect Astronomer's pack - Clouds - Low.

See the end of this message for details on invoking

just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************

System.ArgumentException: Mod AstronomersPack-Clouds-High is not in the list

at CKAN.RelationshipResolver.ReasonStringFor(CkanModule mod)

at CKAN.RelationshipResolver.get_ConflictList()

at CKAN.MainModList.ComputeConflictsFromModList(IRegistryQuerier registry, IEnumerable`1 change_set, KSPVersion ksp_version)

at CKAN.Main.<UpdateChangeSetAndConflicts>c__async1.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at CKAN.Main.<ModList_CellValueChanged>c__async0.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__0(Object state)

************** Loaded Assemblies **************

mscorlib

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll

----------------------------------------

ckan

Assembly Version: 0.0.0.0

Win32 Version: 0.0.0.0

CodeBase: file:///C:/Program%20Files%20(x86)/Steam/SteamApps/common/Kerbal%20Space%20Program_2/ckan.exe

----------------------------------------

System.Core

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

----------------------------------------

System

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

----------------------------------------

System.Windows.Forms

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

----------------------------------------

System.Drawing

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

----------------------------------------

System.Configuration

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

----------------------------------------

System.Xml

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

----------------------------------------

Microsoft.GeneratedCode

Assembly Version: 1.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

----------------------------------------

Microsoft.CSharp

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.CSharp/v4.0_4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.dll

----------------------------------------

System.Numerics

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll

----------------------------------------

System.Dynamic

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Dynamic/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Dynamic.dll

----------------------------------------

Anonymously Hosted DynamicMethods Assembly

Assembly Version: 0.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dll

----------------------------------------

System.Transactions

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll

----------------------------------------

System.Runtime.Serialization

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Serialization/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll

----------------------------------------

System.Xml.Linq

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml.Linq/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll

----------------------------------------

System.Data

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll

----------------------------------------

System.EnterpriseServices

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll

----------------------------------------

Accessibility

Assembly Version: 4.0.0.0

Win32 Version: 4.0.30319.18331 built by: FX45GDRSTAGE

CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll

----------------------------------------

************** JIT Debugging **************

To enable just-in-time (JIT) debugging, the .config file for this

application or computer (machine.config) must have the

jitDebugging value set in the system.windows.forms section.

The application must also be compiled with debugging

enabled.

For example:

<configuration>

<system.windows.forms jitDebugging="true" />

</configuration>

When JIT debugging is enabled, any unhandled exception

will be sent to the JIT debugger registered on the computer

rather than be handled by this dialog box.

[Taki117]

If I might make a suggestion: As a user I think it would be infinitely more helpful for mod troubleshooting to add a "Date Installed" column. This would be most useful when installing new mods only to find that KSP has broken upon the next start up and you can't remember which mods you installed. I don't know how feasible this feature would be to implement, but thank you for the consideration none the less.

[maxrsp]

Hi Guys,

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

I was trying to install the mod Camera Focus Changer, which went fine on my default install, but when I switched installs it didn't even show up. After a couple minutes of head scratching I noticed the filter was showing different counts:

Javascript is disabled. View full album

Does anyone know what could be causing this? Thanks!

[HafCoJoe]

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