pjf

And our bugfix release (v0.15.1 - Hydrazine Princess) is now out! Not only is the can't-download bug fixed, but all operations are now transactional. If you try to upgrade a mod and it fails (and mod upgrades are still pretty buggy, so they probably will), or you try to install six related mods and one of them barfs, then everything is put back exactly as it was before. I can't explain just how excited I am about this, but I am *incredibly* impressed with C# transactions right now.

It's not just you! It seems to be everyone, including me. Luckily I've got a good idea as to which part of the system is responsible, so stand by.

@nli2work: Oops, our validation bot doesn't like RetroFuture. In particular, it's very particular about the license, and because KerbalStuff allows free range strings it's not always able to figure out which license is on which mod. I don't suppose you can change your KerbalStuff license to "CC-BY-NC-SA-4.0"? There's no need for a new release, I can just run the indexer again when done. Many thanks! ~ Paul (Also, for those interested, we're popping out new test releases every day or two now.)

Just a bit of a preview, for a *typical* mod (which is one that's on KerbalStuff, and has zipfile which contains a directory with the same name as the module), you can soon get away with: { "spec_version" : 1, "identifier" : "DogeCoinFlag", "$kref" : "#/ckan/kerbalstuff" } That's the *entire* file, and it doesn't even need to be embedded in your zipfile at all, we can just have it in our BootKAN/NetKAN system which does a lot of the automated production of metadata. That file above will get all the metadata from the KS, and then traverse the download zipfile for a directory called `DogeCoinFlag` (so it will do the right thing work with: `GameData/DogeCoinFlag`, `DogeCoinFlag-1.02/GameData/DogeCoinFlag`, and just `DogeCoinFlag`). I'm thinking of changing $kref to allow identifiers like "#/ckan/kerbalstuff/269", which means we no longer need an external index of where to locate said data. More tomorrow when I have time to write! ~ Paul

@nli2work: I've got your mod working great with the following: { "spec_version" : 1, "identifier" : "RetroFuture", "$kref" : "#/ckan/kerbalstuff", "depends" : [ { "name" : "Firespitter" }, { "name" : "ModuleManager", "min_version" : "2.5.1" } ], "recommends" : [ { "name" : "FerramAerospaceResearch" }, { "name" : "RasterPropMonitor" }, { "name" : "BDArmory"}, { "name" : "ProceduralDynamics"}, { "name" : "SmokeScreen"} ], "install" : [ { "file" : "RetroFuture", "install_to" : "GameData" }, ] } However support for Firespitter is currently an open issue. If you need all of Firespitter, then the code above is correct. If you just need the Firespitter dll, then it's likely that will be called `FirespitterCore`. Because the dll isn't released like a normal mod, it's proving a bit hard to provide packaging for it. This is a good thing for us to be discovering now. Also, do feel free to chime in on any of the issues on github, especially those marked as policy. We're trying to figure out the best way to do a lot of things, and while most policy decisions are relatively easy, there are some which I know we need to get right now because they'll be hard to change in the future. ~ Paul

@Justin: I'd *love* something more friendly than our current validator. It's written primarily to target our continuous integration system (travis-ci), and so it's not exactly user-friendly; we don't have to worry too much about exit statuses as *any* error indicates that we need human attention. One of the gotchas for validators is we need to use v4 of the JSON Schema spec, and the java validator is the best one I've found out there. (The dependency is in the git repo, so we recommend just cloning that). Going forward, we're hoping people can write significantly reduced descriptor files, which get most of their info from KerbalStuff or GitHub. These use a special reference that's described in the latest version of the spec.We're also hoping to make it easier for mods which use a standard directory structure to not require install instructions, which will make things easier still! I'm in the process of writing up better (and *much* simpler) contributor guidelines now, but I've got my hands full with a burst pipe as well, so that may be delayed a little. @nli2work: That looks *awesome*. Technically you can leave out the homepage (and resources entirely) if you want to use the homepage you have listed on KerbalStuff. I'm going to test your descriptor now to see how it goes. Are you on github at all? (It'll make it easier for me to CC you in on the testing there.) ~ Paul

Hey Trueborn! I *love* your work, and would *love* to have CustomBiomes packaged for the Comprehensive Kerbal Archive Network (CKAN). I don't suppose you'd also consider putting your releases up on KerbalStuff by any chance? We have a bot that works well with the KerbalStuff API, which means that CKAN users will be able to install or upgrade new mods from KerbalStuff almost as soon as they go on-line. Many, many thanks! ~ Paul

Thanks Paul! I *love* your work, so I'm glad you're excited. Right now you *can* install mods based upon the presence of other mods: { "file" : "GameData/YourMod/Optional", "install_to" : "GameData", "requires" : "SomeOtherMod" } However this is discouraged, and we may even officially deprecate it. The reason is that the user may install SomeOtherMod in the future, in which case they *won't* get the extra components from yours. Likewise, if the user uninstalls SomeOtherMod in the future, our dependency system doesn't detect that parts of your mod should be uninstalled with it. Where possible, the preferred way to make a component that conditionally activates on another is using ModuleManager, with the `[:NEEDS]` token. This simplifies the install, and handles the situation there the additional mod is installed (or potentially removed) in the future. For more complex operations, relationships combined with provides can be very expressive. For example, if you have a mod that requires life support, has custom components for each life support mod, and a base of common components which are used by everything, one could use this sort of arrangement: * MyMod depends upon MyModLifeSupport * MyModTACLS provides MyModLifeSupport, depends upon MyMod and TACLS, conflicts with MyModLifeSupport * MyModECLSS provides MyModLifeSupport, depends upon MyMod and ECLSS, conflicts with MyModLifeSupport * MyModSnacks provides MyModLifeSupport, depend supon MyMod and Snacks, conflicts with MyModLifeSupport This guarantees that anyone installing MyMod must also select a life support system to go with it (and the latest dev build of the GUI does this), but you can't have *two* modules providing MyModLifeSupport installed at the same time. We have a special rule that mods can't conflict with themselves. (If you're familiar with Debian packaging, this is pretty much identical.) Likewise, while the spec currently defines an `optional` keyword for install stanzas, its use is also discouraged (and may be deprecated), as we can't query the user about optional components for unattended installs. The recommended way of doing this is to have another package which depends upon, and is either recommended (installed by default) or suggested (not installed by default) by the parent package. Those package may reference the same underlying zipfile, so there's no need for additional downloads or author packaging, but the result is that users can install and uninstall optional components via the client, and other mods can also depend upon or recommend optional components of other mods. ~ Paul

Just a quick note to say: * Your mod will start to appear in the CKAN even without you having uploaded it to KS. We've got a special deal where we can download files from the future. * I've just about got github support working. * You can download a test client and play if you like, just make sure you report any issues you might encounter. (`ckan version` and `ckan gui --debug` are useful commands here)

Ippo: Hooray! I look forward to it! jordanjay29: Aye, good idea. Although we're not really stirring up the publicity engine fully until we've got a solid, user-targeted release. That's coming along pretty quickly, though; I'm already managing all my mods via the CKAN. Justin: We've got a 4.0 target because the code makes extensive use of dynamic objects (which are *really* useful when working with JSON), and also because I'm still relatively new to C#, and all the features I kept reaching for were only introduced in 4.0. I fear if I was targeting 3.5 from the get-go then we wouldn't yet have a usable client. If it ends up that a 4.0 target is a big hurdle after our first release then we can look at shifting back to 3.5, but I suspect that most people will find installing the .NET/Mono 4.0 framework a relatively easy step. ~ Paul

We've released! Head on over to the official release thread, as this thread is now closed. The Comprehensive Kerbal Archive Network As some of you know, we've had a team of people working on the Comprehensive Kerbal Archive Network, or CKAN. The CKAN aims to provide a way to install and manage mods and their dependencies in a reliable, reproducible fashion. It does this through the use of strong metadata (with both human readable and machine readable specs), with many lessons and conventions drawn from both the Debian Policy Manual, and the CPAN Meta Spec, both of which are successful projects with similar operation, and which deal with tens of thousands of software packages and their dependencies. If you've come from a Debian or Ubuntu background, then the CKAN is "apt-get for KSP mods", but with a GUI as well as a command-line tool. If you've ever facepalmed because users couldn't follow install instructions, installed incompatible mods, installed outdated mods, didn't install the dependencies, or installed things to the wrong place, then the CKAN aims to make your life easier. The CKAN is still being developed, and is pretty close to a v1.0 release. There's a working client under active development, and we're in the process of gearing up for an official release now. We absolutely welcome testers and contributions, but there is absolutely no guarantee that things won't break. The client works on all operating systems (targeting Mono 4.0), can detect steam installs and KSP version, and is able to calculate which mods can be installed on your system, and actually install (and upgrade, and remove) them for you. However the CKAN can only install mods if it has the metadata it needs, and that's where you come in. CKAN Metadata - We need your help We need the help of mod-authors to make their mods CKAN indexable. If you're already releasing KerbalStuff, then this is as simple as writing a CKAN file once, and including it in the zip file you distribute. CKAN files are just JSON, and if you're releasing on KerbalStuff then it can be a very small JSON file, as the KerbalStuff APIs can provide us with the rest of the information we need, which means you can include it once and never have to update it again. This is what a simple CKAN fragment looks like: { "spec_version" : 1, "identifier" : "DogeCoinFlag", "$kref" : "#/ckan/kerbalstuff/269" } The "$kref" token is a special token indicating that the CKAN toolchain is expected to fill in remaining felds (version, license, author, homepage, etc) from externally supplied data (in this case, from KerbalStuff). By default, if no install instructions are provided, the CKAN installer will look for the top-most directory in the zip file that matches the mod identifier, and install that to GameData. This works with the majority of common mods. However CKAN files can contain a lot of data, for example, they can depend upon, recommend, or suggest other mods, install tutorials or ships, or list additional resources: { "spec_version" : 1, "identifier" : "ExampleMod", "$kref" : "#/ckan/kerbalstuff/1337", "depends" : [ { "name" : "RealSolarSystem" }, { "name" : "ModuleManager", "min_version" : "2.5.0" }, { "name" : "FerramAerospaceResearch" } ], "recommends" : [ { "name" : "RealismOverhaul" }, { "name" : "Toolbar" } ], "resources" : { "github" : { "url" : "https://github.com/ExampleUser/ExampleMod" } }, "install" : [ { "file" : "ExampleMod", "install_to" : "GameData" }, { "file" : "ExampleTutorial", "install_to" : "Tutorial" } ] } When we declare the CKAN client ready for release, we'd like to support as many mods as possible, which means collecting mod metadata now. We're very dedicated to working with mod authors to make that happen. Getting the client Go to our releases page! Releases run on Windows, Linux and Mac, and have no dependencies other than .NET/Mono 4.0. Adding your mod to the CKAN Use this awesome guide on our wiki! You can update it if you have hints or tips! Get involved! If you'd like to see CKAN development as it happens, have a chat, or even see what you can do to help, you can join us in #ckan on irc.esper.net. The CKAN github repo is our focal point for tracking issues, contributions, making releases, and getting things done. We welcome contributions and discussions that are in-line with our code of conduct, and we always have plenty of things we're working on. If you'd like to join us, we'd love to see you! Many thanks! ~ pjf

On that note, if you end up listing the CKAN identifier in your directory, that would be amazing for us, and means folks who find a mod they like can just `ckan install ThisAwesomeMod` to get it along with its dependencies.

Hi there! I'm from the Comprehensive Kerbal Archive Network (CKAN)! We're still in development, but that's moving along quickly, and with our current roadmap we'll have KerbalStuff integration happening in the next couple of days, and be ready for user testing within the week. Our goal is to make KSP mods easy to install and manage, and are doing this through strong metadata, and a lot of learning from Debian and Perl who have systems which deal with tens of thousands of interrelated software packages. If you can use the CKAN metadata index to help your project, then please do so. The spec is available in both human readable and machine readable forms, and all our code and contributions are MIT/CC-BY/LGPL, so you should be able to use them however you like. A lot of activity for the CKAN happens on github, but also #ckan on irc.esper.net. We'd be delighted to see you there! Keep being awesome! ~ Paul

Hey HoneyFox, Just popping over here with my question from github. I'm wondering if it's possible for us to simplify the distro of EngineIgnitor, and particularly the embedded zip files (Ignitor Configs and Pressurized FTs). In particular, I'm hoping to just sanity check that if we were to add the appropriate ModuleManager directives (:NEEDS, :CONFLICTS, etc). If so, that means that installation would become much easier, and (most importantly for me) I can add it to the CKAN. I'm happy for myself or one of my minions to do the conversion and send you a pull request; mainly I want to check that I'm not about to embark on something that's already been tried before and failed. Many thanks! ~ Paul

This is a great question, and something I had hoped to assist with, but I seem to have got distracted by another project. Last I checked, ATC doesn't allow the addition of nodes, which means squishing the RPL tree into approximately half the nodes that it has now. I do *very* much want to do see a RealismOverhaul friendly tech-tree, although with less mod requirements, although I can't realistically expect to start working on such until late October. If someone else happens to start doing this in earnest, then I fully expect to help out around the edges

I love you right now. Thank you!

RO is almost entirely (in fact, I think entirely entirely) ModuleManager and standard .cfg files. It really shouldn't care where it's located, and so I'd be very surprised if being installed on X: is the problem (or if it is, it's nothing to do with RO). In your logfile I can see a Null Reference Exception in ModuleEnginesFX that may or may not be causing you issues. There's a second NRE in there that *may* related to MessageSystem, but that's not as clear, and I have no idea if MessageSystem is part of core, a mod, or something else entirely. ~ pjf

Hooray! Welcome back! I would love this! Making RPL a community project doesn't mean losing control; I find it much more of a happy state where everyone else fixes your bugs for you, and other people can try weird stuff that might not work, and then you can pick and choose the bits which do. On that note, have you considered moving the RPL tree out of TreeLoader and instead have it packaged with the main RPL distribution? The reason I ask is that TreeLoader runs *after* MM, which makes it impossible to for an end-user to edit the tech tree without directly modifying the tree.cfg in the save. I'd really love to fix up some spelling mistakes, sort some unsorted parts, add my fixes for additional modules, and generally help with tree clean-up, and that's *much* easier to do if everything is managed by MM. I am happy to do the TreeLoader to MM conversion and testing. Oh no! I'm so sorry to hear of your HDD failure, but I'm delighted to see the code on github. You can expect some pull requests from me soon. Keep being awesome, and thank you again! ~ pjf

I've been collecting various patches for fixing up the tech tree, adjusting science, incorporating procedural parts, and the like. I've asked MN if he'd be happy with me doing an unofficial release, but we've both been super busy recently and some follow-up is required. In the mean-time my relevant files can be found here. As for fixing up CustomExperiment and DataGenerationModule, I know the source can be found in this thread. Unfortunately I don't yet have the dev environment or background for C# development, but I hope the changes needed for 0.24.2 compatibility will be minor. ~ pjf

Just reporting a bug with the MOL Science lab, and a fix to go with it. In the `Gemini_MOL_Sci.cfg` there's a `ModuleScienceLab` module. It contains a line `containerModuleIndex = 0`, which KSP uses to figure out where to find a science container. However the zeroth module in the lab isn't a science container, it's a LifeSupportModule. The result is a null-pointer-exception whenever someone right-clicks on the science lab, which requires a scene change to fix. Luckily, the bugfix is easy; simple move the ModuleScienceContainer to be the first module on the part, and then everything works as intended! (I noticed there were two ModuleScienceContainers in the part file, and so I removed the second one in my install. I haven't tested what happens if *both* are left in, nor am I sure that having two was intended.) Many thanks again for a totally kickass mod! ~ pjf

This sounds awesome! You rock! Nope! I just love US and the octo-cores having access space through the middle of them, so want to put all my Life Support gear on them. I can always write a few .cfgs to make new parts from the existing models (and if you're cool for me to distribute those .cfg files, all the better!) Many thanks, and really *do* keep up the great work! You're amazing! ~ pjf

Oh, sorry! I have Nathan's PP patch here! It only covers tanks, but that's better than how things were before!

My pleasure! We seem to having some debate over the intended design of the fuel cell, especially with the oxygen tank being bigger than the hydrogen tank. If you have the chance, I'd love for you to pop over to the github issue and provide any input you might be comfortable with.

Reporting a slight nit-pick on the fuel cell. Unless we're doing things totally wrong in RealismOverhaul land, fuel cells use *more* LH2 than LO2. Hence I'd suggest swapping the oxygen/hydrogen labels on the fuel cell as it currently stands, so the LH2 tank is larger.

I'm so very much looking forward to the next version. If I can put in some requests for new wedges (especially for the changes with TACLS 0.9, and RealismOverhaul): - Carbon Extractor (Bosch reaction; CO2 + 2 H2 -> H2O + C) or Borsch + Integrated Electrolysis (CO2 -> C + O2). - Compressor (Allows OX -> LOX, H2 -> LH2, etc) Together, these would allow for the full range of life support functions to be supported by Universal Storage wedges. Many thanks!! ~ pjf