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

[Autochton]

Paul: [...] Also, please put 64K on github? (It'll also make it easier to add CKAN support.)

PLEASE? *puppy eyes*

[Paul Kingtiger]

Paul: CKAN doesn't support replacing files, so that's not going to work. However, you can write your patches to AVP as *patches*, i.e. with MM. That's why rbray made the cfg file system the way he did.

Also, please put 64K on github? (It'll also make it easier to add CKAN support.)

Can MM work with non-part files? For example can you tweak RealSolarSystem.cfg with MM?

I'll look at getting it up on github, I was going to put it up on Kerbal stuff as well, now that it's in a more 'releasable' state.

Also if you can't replace files, how can I substitute a new image file such as a texture?

Edited November 17, 2014 by Paul Kingtiger

[Raptor831]

Can MM work with non-part files? For example can you tweak RealSolarSystem.cfg with MM?

I'll look at getting it up on github, I was going to put it up on Kerbal stuff as well, now that it's in a more 'releasable' state.

Also if you can't replace files, how can I substitute a new image file such as a texture?

I believe you can edit RealSolarSystem.cfg via MM. Anything inside an initial node is fair game, IIRC, and RSS has the REALSOLARSYSTEM initial node. So it should be:

@REALSOLARSYSTEM:FOR[64K]
{
// do stuff
}

At least I think. MM sometimes confuses the snot out of me.

Also, I'll submit this here as well: if 64K gets put in CKAN, would it be better for the 6.4x config and the compatibility stuff (DRE configs, RemoteTech settings/stations, SCANsat changes, hi-res textures, etc) be a separate entry? Or could we use one repo and have different releases be different entries? Does RF and MFT do that, since they're on the same repo?

Ok, lots of questions. Sorry.

[NathanKell]

Yes, MM edits confignodes. The game loads all cfg files as confignode files and puts them all in GameDatabase (well, it skips anything under a PluginData folder). In fact, if you look at Launchsites.cfg included with RSS, you'll see it does that very thing.

Good question about whether to keep together or split. pjf, thoughts?

[Paul Kingtiger]

I believe you can edit RealSolarSystem.cfg via MM. Anything inside an initial node is fair game, IIRC, and RSS has the REALSOLARSYSTEM initial node. So it should be:

@REALSOLARSYSTEM:FOR[64K]
{
// do stuff
}

At least I think. MM sometimes confuses the snot out of me.

Also, I'll submit this here as well: if 64K gets put in CKAN, would it be better for the 6.4x config and the compatibility stuff (DRE configs, RemoteTech settings/stations, SCANsat changes, hi-res textures, etc) be a separate entry? Or could we use one repo and have different releases be different entries? Does RF and MFT do that, since they're on the same repo?

Ok, lots of questions. Sorry.

I think we can use MM for most of the compatibility stuff. EVE visual packs may be harder, I'll have to play around with some examples and see what I can come up with. If we can't overwrite files it's going to take a new way of thinking, I'm not sure if it's possible or not because I've never tried. Something to keep me busy!

[Raptor831]

I did some quick tests and you can't overwrite stuff already installed by CKAN. In this case, all of the RSS configs can be switched over to MM and either replace nodes as needed or nuke and rebuild. Overwriting images would be problematic, or anything within PluginData folders (i.e. TACLS' consumption settings). You could use the "provides" member to offer choices to avoid this in the beginning since settings files (i.e RemoteTech, TACLS) aren't written until first run, but switching them could be a pain. OTOH, those aren't actually installed by CKAN...

@NathanKell One reason I'm wondering about splitting repos is because of 64Ks 8k planet textures. As a Mac user, 8k textures are buggy so I'd avoid them, so if it were to bundle everything in the same repo and only install the needed folders, I'd be downloading a chunk of 8k textures for no reason. Not the biggest issue, but it seems a waste.

[pjf]

Oh my! Lots of questions. I'll try to answer them all, but apologies if I miss one. Let me know if I do!

It seems that Kerbal Alarm Clock is installed in <ksp>/GameData/KerbalAlarmClock/ but it should be <ksp>/GameData/TriggerTech/KerbalAlarmClock/

Oh no! Can you report that on our issue tracker linked to in the top-post? I'm guessing it's just using a default install stanza (which looks for the mod name and copies the directory), but this is an easy fix with a custom install stanza.

So the error I posted about earlier? Turns out it was due to my (slightly aged) Linux distro not having an updated Mono version, which a gentleman on GitHub was swift and kind to inform me. However, all was not lost - there's a PPA for updating your stuff...

Thank you! I'll add that to our FAQ!

On to questions. I'm looking to add Universal Storage and 64k to the mod, but I have some questions regarding installation order.

By design, the CKAN does not allow the overwriting of files, nor does it allow installation order to be specified. This not only gives us a number of strong mathematical assurances (we can analyze dependencies as a set, rather than a graph), but it also means we can immediately detect conflicts, and we don't have to worry about mods installed "earlier" in the install overwriting those from "later" in the install when they're upgraded.

The ideal solution (when you can't use ModuleManager) is to this is to split configuration from content. TACLS is a great example here; TACLS give you the core, but depends upon the virtual "TACLS-Config" package. That can be provided by TACLS-Config-Stock, or TACLS-Config-RealismOverhaul, which both conflict and provide TACLS-Config, which means that you can only have one installed at a time. If you're running RealismOverhaul, then it depends upon TACLS-Config-RealismOverhaul, so you get the right one. And if you're not running RO, then you'll get the stock config, because the RO config depends upon RO.

Note that this makes it absolutely clear which package owns which files. If you were to upgrade TACLS, you'd still keep the RealismOverhaul configs for it if they were installed.

Of course, the module authors haven't split their configuration from their content at all; instead our metadata documents specify the TACLS config file that comes with TACLS for "Stock", and the one that comes with RealismOverhaul for RO. No extra files are downloaded, but the end result is we still have strong assurances as to file ownership and consistency.

A future version of the spec will probably support a "replaces" keyword, so one can say that "64K replaces Astronomers". This would effectively allow file overwriting, but in a much more intelligent way. If A replaces B, then we always take A's version of the file. Even if B is upgraded, then A's file remains. The big question here is what to do if A is removed; the goal goal of the CKAN is to provide a consistent install, and if A is removed then B is left without files that it originally had installed. I don't think we have a good solution for that yet. In Debian land, "replaces" used in this way is a packaging smell; it almost always indicates that a package hasn't undergone separation of parts, which is much cleaner solution. Our next spec revision (v1.2) is likely to have a much wider range of keywords to allow the selecting and exclusions of particular types of files, so it will be easier to say that `Foo-Core` installs everything except the textures, and `Foo-Textures-Default` installs only the textures. I know that EVE is already looking at splitting config from core, so we're on the right track there already.

Our roadmap will be including support for child documents before we support 'replaces'. This means that you can have a top-level document which describes a mod, which contain sub-documents which inherit the parent's meta-data. That means producing metadata documents for when an existing mod should be split into core, config, and texture elements are *much* easier, so separation will become much less difficult than it might first appear. It's my hope that we'll never actually have to implement 'replaces', as it does pose a threat to our consistency model, and that means a lot of increased complexity (and potentially bugs).

If 64K gets put in CKAN, would it be better for the 6.4x config and the compatibility stuff (DRE configs, RemoteTech settings/stations, SCANsat changes, hi-res textures, etc) be a separate entry? Or could we use one repo and have different releases be different entries? Does RF and MFT do that, since they're on the same repo?

I might have misinterpreted this question, so if I'm going to try and answer all interpretations. If I've missed the intended one, let me know.

If you're currently releasing everything as a single zip, then you can almost certainly continue doing that. CKAN documents are very good at selecting sub-sets of files, and it's both acceptable and encouraged to have multiple docs refer to the same underlying zip (which we'll only download once). Having a single zip makes things easy for non-CKAN users, as they just download and go. If you're looking at replacing multiple zips, then we index those fine from KerbalStuff (if they have different IDs), but our bot gets very confused if we're indexing from github; it doesn't yet understand two mods being released from the same repo.

If you have big texture packs (like RSS does), and the user can choose between them, then those are probably good things to split out, especially if they don't tend to change between releases. However we certainly don't require it; it's just a little easier on the user's bandwidth.

If changes can be made via MM, then that's always the best way to do things. It works via the CKAN or not, it never overwrites files, things will always get applied in the correct order.

Where MM doesn't work, but overwriting was previously required, we'll try to see if there's a way that we can split an install into related components, as that means another mod can say "hey, I'm providing the textures here".

~ Paul

[jkadarn]

[...]

Oh no! Can you report that on our issue tracker linked to in the top-post? I'm guessing it's just using a default install stanza (which looks for the mod name and copies the directory), but this is an easy fix with a custom install stanza.

[...]

I tried to make a custom install stanza, but I'm not sure what's the best way to do it. ^^

The path in the archive is: KerbalAlarmClock_3.0.4.0/GameData/TriggerTech/KerbalAlarmClock

Is there a way to avoid a version-dependent "install_to" directive in this case?

"install": [
    {
      "file"       : "KerbalAlarmClock_3.0.4.0/GameData/TriggerTech",
      "install_to" : "GameData"
    }
  ]

[Ippo]

Oh no! Can you report that on our issue tracker linked to in the top-post? I'm guessing it's just using a default install stanza (which looks for the mod name and copies the directory), but this is an easy fix with a custom install stanza.

Actually, it's not: we are going to need either the "find" keyword, or the upgraded install stanza with subdirectories. I'll open the issue in a moment with details

[rowns]

Can somebody explain how to do this on a mac?

[akman]

When i try to set an instal directory it tells me it couldnt find it and aborts it.

-Edit:Never mind , i just moved ckan.exe to ksp dir and fixed it

[Raptor831]

Can somebody explain how to do this on a mac?

You need to have the Mono runtime first. Can be downloaded if you don't have it. Next, open the Terminal app and navigate to the directory where you have the ckan.exe. If you don't know how to do that, look up a quick primer on Linix/Unix command line use (it's really pretty easy once you do it a few times). The docs say you can just run "ckan.exe <command>", but I have to run "mono ckan.exe <command>", so that might work too.

There's a general guide on the CKAN wiki here: https://github.com/KSP-CKAN/CKAN/wiki/User-guide

[akman]

I get this when i try to update

Unhandled Exception:

System.NotSupportedException: CodePage 737 not supported

at System.Text.Encoding.GetEncoding (Int32 codepage) [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToString (System.Byte[] data, Int32 count) [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToString (System.Byte[] data) [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipFile.ReadEntries () [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor (System.String name) [0x00000] in <filename unknown>:0

[ERROR] FATAL UNHANDLED EXCEPTION: System.NotSupportedException: CodePage 737 not supported

at System.Text.Encoding.GetEncoding (Int32 codepage) [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToString (System.Byte[] data, Int32 count) [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToString (System.Byte[] data) [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipFile.ReadEntries () [0x00000] in <filename unknown>:0

at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor (System.String name) [0x00000] in <filename unknown>:0

[pjf]

I get this when i try to update

Popping this in the FAQ right now, but if you're running Ubuntu/Mint/Debian, try:

sudo apt-get install libmono-i18n-west2.0-cil libmono-i18n-west4.0-cil

Apparently mono doesn't come with everything we'd expect. I'd love to find a way to bundle these in with the executable.

If you're not on Linux, can you open an issue on this? We'd love to find a way to make sure everyone can use the CKAN regardless of locale.

~ Paul

[pjf]

Just a quick note that v1.0.1 aka Protium is out. This is a bugfix stable release which better supports redirecting the output of `ckan available` to a file, pipe, or other non-console device.

You can always find the latest stable release linked to from the top post, or at https://github.com/KSP-CKAN/CKAN/releases/latest.

~ Paul

[David1544]

Just got this today, incredible work! I can't believe so many modders were able to hook into it so fast. And the GUI isn't so shabby either

[pjf]

Just got this today, incredible work! I can't believe so many modders were able to hook into it so fast. And the GUI isn't so shabby either

Thank you. The GUI is all nlight's amazing work, and the new GUI (which is currently in development, but you can build from git) is even nicer! (And fixes a lot of issues we were having under Linux. Nlight rocks!)

[pjf]

Also I'm excited about how easy it's going to be to spot when new releases are available and upgrade your mods. This is still very much a work in progress, but my initial results are very promising. This will be part of the v1.2.0 client. Notice the beautiful unicode indicators, and `ckan update RealChute` (output not shown) worked like a charm.

Edit: For those wondering, yes, I hope to have both `ckan list --upgrades` and `ckan upgrade --all` commands, to make things even easier.

[Deems19]

I just tried installing a fresh Realism Overhaul game (with a fresh install of KSP) using the "--with-suggests" command but I noticed that none of the procedural mods and I think a couple other suggested mods weren't included in the list of mods to be installed.

Is there a problem with the Realism Overhaul metadata? Or has it simply not been updated yet to account for recently added mods?

To make sure it wasn't just stupid user error on my part here is the command I used to install RO with suggested mods: "ckan install RSSTextures2048 RealismOverhaul --with-suggests".

Thanks in advance.

[hakan]

I am trying to set up ckan on my Linux system. There is neither Steam nor KSP on this box, as it is meant just to validate my set of ckanified mods.

So, I download the current version of ckan, create an empty directory and try to "add" it to the CKAN registry:

hakan@koala ~/src/ksp/installer $ rm -rf ksp-0.25
hakan@koala ~/src/ksp/installer $ mkdir ksp-0.25

hakan@koala ~/src/ksp/installer $ mono ./bin/ckan ksp add ksp ./ksp-0.25 --debug
Sorry, /home/hakan/src/ksp/installer/ksp-0.25 does not appear to be a KSP directory

hakan@koala ~/src/ksp/installer $ mono ./bin/ckan --version
CKAN Client 0.0.0.0
...
You are using CKAN version v1.1.0-0-gcb731cb (unstable)

I also tried creating a "GameData" inside my ksp directory and adding a readme.txt, to no avail, every time I get the "does not appear to be a KSP directory".

What is the minimum set of files and directories for CKAN to assume a valid installation?

[yopeasants]

This truly is one of the greatest things I've seen put out on this forum. Excellent job guys, you've just made my life so much easier! Thank you and keep up the great work!

[pmang6]

Ok, so when I try to help ckan find my KSP install with the ksp command (I also tried kspdir) , it won't let me. I type:

mono ckan.exe ksp ~/Desktop/KSP 0.25 MAC/KSP 0.25 MAC

Which is the directory that the game is in. But then the menu reappears without any effect. What am I doing wrong?

[Ippo]

...

Try this:

ckan ksp add "ChooseAName" "~/Desktop/KSP 0.25 MAC/KSP 0.25 MAC"
ckan ksp default "ChooseAName"

Choose the name you like for your install. This should add it to the list (ckan can manage multiple installs at once) and set it as the default.

[jandcando]

May I ask what "spec_version" does? In every example I've seen, it is set to 1.

[pmang6]

Try this:

ckan ksp add "ChooseAName" "~/Desktop/KSP 0.25 MAC/KSP 0.25 MAC"
ckan ksp default "ChooseAName"

Choose the name you like for your install. This should add it to the list (ckan can manage multiple installs at once) and set it as the default.

According to CKAN that is not a KSP directory. Am I specifying the KSP game its self is or the folder that it's located in? I've tried both with no success but I may be missing something... Sorry if I'm being a massive imbecile, I never can get the hang of anything concerning these infernal command consoles.

Actual message Its self:

[FONT=Menlo]Johns-iMac:Desktop Family$ mono ckan.exe ksp add "Main" "~/KSP 0.25 MAC/KSP"[/FONT][FONT=Menlo]Sorry, /Users/Family/Desktop/~/KSP 0.25 MAC/KSP does not appear to be a KSP directory[/FONT]

The game, along with all of its folders and such are in a folder on my desktop. By game I mean the actual application its self (Just for clarification)

Edited November 20, 2014 by pmang6