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

[ferram4]

Very grateful for CKAN!! Although somewhat confused at some of the hate out there for it. For instance if I venture onto the FAR thread, they talk as if anyone who doesn't install manually is some kind of lazy moron. Apparently they don't think CKAN does a very good job installing their mod.

I don't tend to venture in here, but this is relevant to me.

CKAN has caused no less than 4 different kinds of installation errors for FAR, 3 in the past two months alone.

The first was simply not including an option to wipe all the files in a directory, so CKAN users ended up with incomplete atmospheric data for planets.

The second was that it didn't install a hard dependency.

The third was that it installed the wrong version of a dependency that only had one publicly released version.

The fourth was that it screwed up getting the version order correct, because 0.15.3.1 obviously comes before 0.15.3_Froude.

From experience, no, it doesn't do a good job with FAR; I have no idea why it breaks things that manual installs don't so often. I have to wonder how many other mods get hit with this that no one hears about because they have smaller userbases.

But I hope that that answers for the "hate." It's not hate, just wariness of an app that has proven itself to be trouble.

Edited June 27, 2015 by ferram4
fix quote brackets

[Mipe]

Yes read the last page or two of discussion in this thread. CKAN is currently waiting for mod authors to update their mod signatures for 1.0.4. Until then, it's basically broken and only about half the mods will work with CKAN.

I just came here to post about this, but it looks like the cat is out of the bag already.

Well then, would it be possible to have an option to allow installing of outdated mods? You can slap a warning popup onto it or whatever.

[Dr. Jet]

Is it possible to set ksp_version to "1.0.x" or "1.0.*"? Or any other way to make CKAN know that existing mod version is compatible with SEVERAL KSP patches?

[Torih]

Further to the last post about editor extensions being upgraded to the wrong version. Does ckan read the software number as decimal? i.e the latest version 2.12 is not being installed as it should, but instead its installing 2.2 which is an older version.

[FlexGunship]

Further to the last post about editor extensions being upgraded to the wrong version. Does ckan read the software number as decimal? i.e the latest version 2.12 is not being installed as it should, but instead its installing 2.2 which is an older version.

I posted this in the Editor Extensions thread. You can verify that it's true by changing the values in the registry.json file.

This will hide a mod from showing in the application:

"ksp_version_max": "1.0.30",
"ksp_version_min": "1.0.0",

But this will show it:

"ksp_version_max": "1.0.4",
"ksp_version_min": "1.0.0",

So, ckan thinks that *.30 < *.4

Honestly, if I had to suggest anything to the amazing developers of ckan (and, seriously, ckan is AMAZING), there needs to be a hidden "pro-mode" where you can override the the version you're running and the folder. I have the same two problems repeatedly:

1) I'm not allowed to install a mode without editing the .json file despite knowing that a particular mod works with my version (or wanting to test it... yes, yes... manual install...)

2) I have always kept several installs of KSP on my desktop (RSS, last stable, stock, etc.) but ckan hates desktop folders and lists them as invalid installs.

I think I understand why those are there (to protect the little nooblets from hurting themselves and then complaining to modders or the ckan devs), but I'd like a super secret "pro-mode" that let's me override some of these things without editing the .json file.

Maybe when you enable it, the owner of every mod you install gets your username. And if you do anything other than post constructive bug reports you get an instant perma-ban from the forum and Harvester calls you a "industrial poo inhaler" on the KSP website.

Edited June 27, 2015 by FlexGunship

[volcanicshrimp]

eva parachutes and menu stabilizer aren't letting me install them using CKAN and instead come up with "could not establish trust relationship for the SSL/TLS secure channel".

[cfds]

CKAN seems to generally have problems discriminating versions 1.0.x from 1.0.y. For obvious reasons I continue with version 1.0.2 at the moment and CKAN recognizes this correctly. It nontheless wants to install ProceduralFairings 3.15 which is the 1.0.4 version. Other mods seem to have the same problem.

[Atmoz]

Sorry for my bad english... (thanks to google translate)

Could you add an option to export list (txt format) of installed mods ?

Thanks

[Torih]

Sorry for my bad english... (thanks to google translate)

Could you add an option to export list (txt format) of installed mods ?

Thanks

It you click File and export installed mods..., you can open the file it creates in notepad and it has all the mod names and versions then just save as a .txt.

[Entropius]

CKAN was autodetecting EVAManager.dll. So I decided to remove /GameData/EVAManager.dll and refresh CKAN. Unfortunately CKAN crashes on Refresh every single time. If I put EVAManager.dll back where it was, crashing stops. So basically CKAN won't let me do what I need to, to get it to manage this mod for me.

Is there something I can do to fix this short of having to remove all my mods, and reinstall them again with CKAN?

For anybody who's curious, I found a partial solution. I had to delete Tweakable Everything (which CKAN was not autodetecting), launch CKAN, Refresh, quit CKAN, delete EVAManager.dll, relaunch CKAN, refresh, then tell CKAN to install EVAManager.dll itself and Tweakable Everything.

I think the problem might boil down CKAN crashing whenever you manually delete an auto-detected mod that's a dependency of a CKAN-insalled mod. Others may want to verify this.

I'm also trying to figure out how to delete my auto-detected Module Manager so that I can have CKAN manage it, but manually deleting Module Manager and refreshing CKAN doesn't seem to be noticed by CKAN, and it seems to still think it's there. Any help on that would be appreciated.

EDIT: I'm also finding that removal of auto-detected BahamutoD Animation Modules crashes CKAN too. But I can't figure out how to work around that one.

Edited June 27, 2015 by Entropius

[Professor Dey]

Does anyone know where in the Linux buildable files the background/text colours are? Because I have a 'white text on black' theme on Cinnamon, but CKAN's mod list is still a white background, making the now white text impossible to read whdile trying to set up/search for mods. Obviously not conducive to making my time modding easier XP Anyone have any suggestions? Besides changing my theme every time I want to install a mod? Maybe a way to force mono to ignore my colour scheme?

[Barking Sands]

Would it be possible to have CKAN manage mods that aren't installed in the KSP GameData folder? I'd like to use CKAN to keep a library of my favorite mods up-to-date, and then use the file manager to manually pull mods from the mod backup library into the game's GameData folder as I decide to use them.

It would also be nice if CKAN could keep my personalized settings for each mod in a backup like the "downloads" folder, so I could update or remove mods without resetting them to the default settings.

[nobodyhasthis]

Is it possible to set ksp_version to "1.0.x" or "1.0.*"? Or any other way to make CKAN know that existing mod version is compatible with SEVERAL KSP patches?

Yes read the last page or two of discussion in this thread. CKAN is currently waiting for mod authors to update their mod signatures for 1.0.4. Until then, it's basically broken and only about half the mods will work with CKAN.

Yes. Agreed CKAN is totally broken because does it does not let you install mods that are for 1.0.2 but work under 1.0.4. Waiting for mod authors to change signatures is so stupid. It coves up the fact that CKAN has another important missing feature. Instead of having a sprint to fix the meta data. Why not just add a simple version override?

[SacreBleu]

Yes. Agreed CKAN is totally broken because does it does not let you install mods that are for 1.0.2 but work under 1.0.4. Waiting for mod authors to change signatures is so stupid. It coves up the fact that CKAN has another important missing feature. Instead of having a sprint to fix the meta data. Why not just add a simple version override?

CKAN is hardly broken. If a mod/addon/script functions in 1.0.4 the mod's author should update the metadata to represent that fact. I've seen numerous mods where the author had not updated their title to represent the fact that the mod was compatible with a new version of KSP. I've also seen some authors dump updated files 'somewhere' in their thread in spite of updating their OP. It's annoying, because I've accumulated quite a lot of mods and manually checking them for compatibility remains a tedious and time consuming process. CKAN takes that out of my hands so I can spend that time on actually enduldging myself in some Kerbal explosions.

I would agree some kind of fail-safe option could be added, but after all, how much work is updating meta-data, really? Isn't this just something that can be edited with plain text? Or is it, actually, a tedious and time consuming proces to do?

[beabop]

I just had an ugly error, where CKAN removed half of my mods:

Removing TACLS-Config-Stock...

Removing KarbonitePlus...

Removing HotRocketsCommunityConfigs...

Removing ContractConfigurator-Tourism...

Removing TACLS...

Removing Karbonite...

Removing Trajectories...

Removing CoolRockets...

Removing ConnectedLivingSpace...

Removing ContractConfigurator-RemoteTech...

Removing ContractConfigurator-KerbinSpaceStation...

Removing HotRockets...

Removing CollisionFX...

Removing ContractConfigurator-AnomalySurveyor...

Removing NMSG...

Removing KAS...

Removing ContractConfigurator-FieldResearch...

Removing CrowdSourcedScience...

Removing RoverWheelSounds...

Removing RasterPropMonitor...

Removing RasterPropMonitor-Core...

Removing UKS...

Now, I can't find half of these in the network. Most of the missing ones are under "Filter (Incompatible)". Karbonite Plus is missing entirely. I had been running 1.02 mods on 1.04 just fine before this.

I think what happened was I removed a mod that needs ModuleManager, ModuleManager got removed and then - to my great surprise - the mods that depend on ModuleManager (most of them). I think the Changeset only showed me two mods. Sorry I don't have more information, it was over so quick.

---

When CKAN blows up on you, how do you recover? The way I can think of is to install all the mods in a 1.02 KSP and copy GameData over - with the downside that I'll have to upgrade each one manually, the old-fashioned way.

I also had a time where CKAN got into a state that couldn't start, and I ended up having to delete registry.json - which meant I had to reinstall every mod to make it managed by CKAN instead of autodetected. How can you rebuild registry.json? I would have liked to be able to give CKAN permission to delete autodetected mod X and manage that mod.

[nobodyhasthis]

CKAN is hardly broken. If a mod/addon/script functions in 1.0.4 the mod's author should update the metadata to represent that fact.

So your saying CKAN is right and everybody else is wrong after a version change.

I would agree some kind of fail-safe option could be added

Glad you agree that there is a failure in CKAN when the meta-data is not correct. Sounds broken to me too. You will have to manually load all the so called incompatible mods that CKAN refuses to load now.

It's annoying, because I've accumulated quite a lot of mods and manually checking them for compatibility remains a tedious and time consuming process.

I agree with that too.

Now, I can't find half of these in the network. Most of the missing ones are under "Filter (Incompatible)". Karbonite Plus is missing entirely. I had been running 1.02 mods on 1.04 just fine before this. I think what happened was I removed a mod that needs ModuleManager, ModuleManager got removed and then - to my great surprise - the mods that depend on ModuleManager (most of them). I think the Changeset only showed me two mods. Sorry I don't have more information, it was over so quick.

---

When CKAN blows up on you, how do you recover? The way I can think of is to install all the mods in a 1.02 KSP and copy GameData over - with the downside that I'll have to upgrade each one manually, the old-fashioned way.

You don't. Apparently all the mods owners must drop everything and change the meta-data for CKAN to stop being over protective.

The let me finish on a good point. CKAN in been the greatest gift that KSP has ever gotten. Alongside KSP AVC. It does work more times that it fails.

Edited June 28, 2015 by nobodyhasthis

[Atragon]

So your saying CKAN is right and everybody else is wrong after a version change.Glad you agree that there is a failure in CKAN when the meta-data is not correct. Sounds broken to me too. You will have to manually load all the so called incompatible mods that CKAN refuses to load now.I agree with that too.

You don't. Apparently all the mods owners must drop everything and change the meta-data for CKAN to stop being over protective.

The let me finish on a good point. CKAN in been the greatest gift that KSP has ever gotten. Alongside KSP AVC. It does work more times that it fails.

Tone doesn't come through very well in forum threads, unfortunately.

Technically, I would say that CKAN is correct to flag mods without updated metadata, and isn't broken. The mod doesn't say it's compatible with version 1.0.x, therefore CKAN isn't assuming that it is.

Now, there is a period between KSP update and mod update to flag compatibility (I'm not that familiar with CKAN's backend, so I won't dive into possibilities here), so...

Adding a GUI method of overriding this to allow installation of mods that aren't listed as compatible because of out-of-date metadata would be nice. However, I would think that this would have to be reset every KSP version change to prevent a fail-deadly scenario (like rolling FAR or DRE over from .9 to 1.0 for example).

[BlackHat]

Strange error....

I was adding mods to my KSP 1.0.4 game, and I selected Community Tech Tree. (All I did was click the button TELLING CKAN that I wanted to add this mod.)

It immediately game me an error message.

It looks to my untrained eye like it has a hidden dependency on GoodSpeed mod. (But I thought CTT had no dependencies except for ModManager)

************** Exception Text **************
CKAN.ModuleNotFoundKraken: Cannot install Goodspeed, module not available
at CKAN.CkanModule.FromIDandVersion(Registry 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, Registry registry, KSPVersion kspversion)
at CKAN.MainModList.ComputeConflictsFromModList(Registry 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.34209 built by: FX452RTMGDR
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:/Games/ksp%201.0.4/ckan.exe
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
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.34238 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.34251 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.34209 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.34209 built by: FX452RTMGDR
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.34234 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
Win32 Version: 4.0.30319.34234 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.CSharp
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209
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.34209 built by: FX452RTMGDR
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.34209
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34234 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.

See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.

Edited June 29, 2015 by BlackHat

[Surefoot]

Clicking on "Mechjeb2 Modules for FAR" brings CKAN down with that exception:

CKAN.ModuleNotFoundKraken: Cannot install MechJeb2, module not available

à CKAN.CkanModule.FromIDandVersion(Registry registry, String mod, KSPVersion ksp_version)

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

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

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

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

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

à CKAN.MainModList.ComputeConflictsFromModList(Registry registry, IEnumerable`1 change_set, KSPVersion ksp_version)

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

--- Fin de la trace de la pile à partir de l'emplacement précédent au niveau duquel l'exception a été levée ---

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

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

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

--- Fin de la trace de la pile à partir de l'emplacement précédent au niveau duquel l'exception a été levée ---

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

************** Assemblys chargés **************

mscorlib

Version de l'assembly.: 4.0.0.0

Version Win32.: 4.0.30319.34209 built by: FX452RTMGDR

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

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

ckan

Version de l'assembly.: 0.0.0.0

Version Win32.: 0.0.0.0

CodeBase.: file:///I:/Kerbal/ckan.exe

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

System.Core

Version de l'assembly.: 4.0.0.0

Version Win32.: 4.0.30319.34209 built by: FX452RTMGDR

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

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

System

Version de l'assembly.: 4.0.0.0

Version Win32.: 4.0.30319.34238 built by: FX452RTMGDR

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

[rottielover]

Where is it that we go to request mods be indexed?

HGR has some good stuff:

Corvus pod and don't forget the optional extra's pack: http://forum.kerbalspaceprogram.com/threads/121062-1-0-2-Corvus-Size-1-two-Kerbal-command-pod%28Version-1-1-1%29

The currently indexed HGR mod is listed as "HGR Props", I think that is confusing (here is link to thread: http://forum.kerbalspaceprogram.com/threads/60974 ) I think this needs to be renamed to either HGR Parts or just HGR or similar, props makes it sound like it's just IVA props.

[damerell]

Where is it that we go to request mods be indexed?

Apologies if you know this, but it is worth checking a) if the mod has ever been indexed in the past and if the current version is known to work in the current KSP. If both these things are true, it's a lot easier.

- - - Updated - - -

From experience, no, it doesn't do a good job with FAR; I have no idea why it breaks things that manual installs don't so often. I have to wonder how many other mods get hit with this that no one hears about because they have smaller userbases.

You have just rejected, in very strong terms, an offer by someone to sort out the CKAN metadata for FAR - someone who is doing this for many mods and seems to have their head screwed on.

Perhaps that makes it harder to get things right?

[Murdabenne]

Where is it that we go to request mods be indexed?

HGR has some good stuff:

Corvus pod and don't forget the optional extra's pack: http://forum.kerbalspaceprogram.com/threads/121062-1-0-2-Corvus-Size-1-two-Kerbal-command-pod%28Version-1-1-1%29

The currently indexed HGR mod is listed as "HGR Props", I think that is confusing (here is link to thread: http://forum.kerbalspaceprogram.com/threads/60974 ) I think this needs to be renamed to either HGR Parts or just HGR or similar, props makes it sound like it's just IVA props.

I like that mod too - the Corvus stuff is really well thought out and looks great.

You'll find that Corvus and HGR Props are both updated for 1.0.4, per my last check of the CKAN client (I just installed them as a matter of fact). Installing Corvus will grab HGR Props along the way as a dependency.

Edited June 30, 2015 by Murdabenne
reduced post to topic of Corvus hgr

[Murdabenne]

My analysis:

Its taking all addons and addon managers and version trackers a while to deal with all the fallout from having apps that are still good despite a version change to KSP. Its not just CKAN, but CKAN, KSP-AVC and KerbalStuff are all having to come up with ways to allow for an app that's made for 1.0 (or 1.0.2) and not updated since then still being considered compatible with 1.0.2, 1.0.3 and 1.0.4. but also still filtering out ones that are not.

The old assumptions of new releases breaking addons is no longer valid now that we players are seeing patch/hotifx releases like 1.0.4.

So those authors are having to come up with ways to allow for an addon that's made for 1.0 (or 1.0.2) and not updated since then still being compatible with 1.0.2, 1.0.3 and 1.0.4. For example, something like Hyperedit isnt really touched at all by any of those updates, so why should the author of that addon be forced to recompile/rebuild just to mark it as compatible? Answer: s/he should not! The whole thing of these tools is to help users manage their addons, and do so in a way that prevents errors like an outdated or conflicting app, however they also add benefit to addon authors in that they can relieve some of the work that the rapid version changes throw at the authors. Typically, authors would rather be improving their addon instead of dealing with versioning issues and bugs caused by users installing when/where they shouldn't.

CKAN has taken the approach to this problem of adding KSP min and max versions to their metadata, which is what they are doing at the moment, updating the metadata of hundreds of indexed addons. This allows an addon to be marked as installable and compatible for multiple versions in a range, which is very convenient in the event of a hotfix. For authors (or even someone they designate), after a hotfix or minor patch that doesnt affect ther addon, instead of rebuilding the whole thing and re-releasing it, all they (or a friend) needs to do is simply change the ksp_version_max in the netkan or ckan metadata, and you're done. CKAN can update the rest for its users.

Hopefully addon developers will see and understand this isnt an attempt to take their apps away, but to help distribute them to an even wider userbase, and reduce the workload of doing updates whenever Squad drops a hotfix. Is this fixed yet? Does this still work with 1.0.x? Where is the update? Is this the stable version? Does this depend on adodn X, and is it and this updated? CKAN and a quick metadata update can prevent a lot of those. This is what my posts to most addon's forum threads have been about - Im offering to help update CKAN's metadata, so the addon authors dont have to fiddle with it.

- - - Updated - - -

Some End-users want more choices, so I have proposed (for discussion) having different modes of operation to allow the users the choice of how tight they want the checking:

• strict -- must be released for the exact version, must be marked as such by the author. Its how things work now, pretty much the safest way, and this would be the default mode of function.
  

• gras "generally recognized as safe" meaning although its compiled for 1.0, its OK to use on 1.0.2, 1.0.3, per the author (usually via a forum question or email) -- it looks like most falls into this category, (gras is also french for "fat" - as in a fat selection, lots of stuff). This saves addon authors time and effort when their users use CKAN to get updates.
  
  

• forced which means the user overrides the version safety for this app (and its dependencies). Do this when your favorite addon isnt current but you want to install it anyway. This is akin to a manual install. The only thing you gain from CKAN is that it will check dependencies, and let you know when an update is available.
  

• YOYO - You're On Your Own - doing this basically means you are unsupported and should not bother the authors of the addon or the authors of CKAN with errors you have created. Its like using Win64 mode - go for it, but dont go looking for support. The only thing CKAN does here is simply tell you what addons you have installed and give you pretty checkboxes to check and do an install,. or uncheck to uninstall.
  

This would make more people satisfied, allowing power users more leeway, but keeping most users in the safe zone.

(moved to its own post as a separate topic - a proposal for CKAN)

Edited June 30, 2015 by Murdabenne
moved discussion of CKAN reasoning to its own post

[damerell]

I think forced == YOYO - as we know from past github issues, one reason the CKAN devs have (rightly, in my view) been reluctant to add a non-expert way to force installation is the inevitable tide of spurious bug reports.

I'd go so far as to suggest any forced/YOYO installation should leave a very prominent marker in output.log.

[Murdabenne]

Strange error....

I was adding mods to my KSP 1.0.4 game, and I selected Community Tech Tree. (All I did was click the button TELLING CKAN that I wanted to add this mod.)

It immediately game me an error message.

It looks to my untrained eye like it has a hidden dependency on GoodSpeed mod. (But I thought CTT had no dependencies except for ModManager)

************** Exception Text **************
CKAN.ModuleNotFoundKraken: Cannot install Goodspeed, module not available
at CKAN.CkanModule.FromIDandVersion(Registry 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, Registry registry, KSPVersion kspversion)
at CKAN.MainModList.ComputeConflictsFromModList(Registry 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.34209 built by: FX452RTMGDR
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:/Games/ksp%201.0.4/ckan.exe
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
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.34238 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.34251 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.34209 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.34209 built by: FX452RTMGDR
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.34234 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
Win32 Version: 4.0.30319.34234 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.CSharp
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209
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.34209 built by: FX452RTMGDR
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.34209
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34234 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.34209 built by: FX452RTMGDR
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.

See the end of this  message for details on invoking just-in-time (JIT) debugging instead of  this dialog box.

I just tried installing CTT on my 1.0.4 install, and it didn't error, but I do have a ton of addons installed, do you still get this error after exiting, refreshing and retrying? I also tried GPOSpeedPump (which is GoodSpeed continues, installs as GoodSpeed directory) since its an addon I always have loaded as soon as its available, and its working too. Strange they should show an error - usually I am an error magnet for addons, if they break I break em.

- - - Updated - - -

For YOYO, I'd think not just a marker, but change the menu so that's the only mode you can use from then on, with appropriate warnings, popups, ominous sounds, and pictures of Walter White to indicate that you are now breaking (bad) the app.

Edited June 30, 2015 by Murdabenne