wowbagger's liquid lunch

Hello my fellow Mün-enthusiasts. I would like to announce a project I have been working on for a while now: neuCKAN, an open-source KSP mod manager not entirely unlike CKAN. I wrote it from scratch in Swift, and aim for it to fill the void of CKAN GUI on macOS. It was briefly mentioned in this KSP Discussion thread a few months ago, and now I'm finally properly introducing it. This is how neuCKAN looks so far (version 0.0.1). Although it doesn't look like much, it took me 6 months to get to this stage. As shown in the screenshot above, the software is very much incomplete. It's still very early on in alpha development. Functionally, it's able to install mods that are not hosted on spacedock (there is a weird bug with spacedock's links). As little as it currently does compared to CKAN, I have a very ambitious plan for its future. If anyone is interested in learning more about it, please check out the repository on GitHub for better details. To all the developers, graphic designers, and all the talented people here in the KSP community, I welcome and need every bit of help I can get to push this project forward. Let's collaborate and make it happen! Here is the same announcement on r/KerbalSpaceProgram.

Yep I was wrong. I should've thought twice before rushing in my words. What I meant was how, although .NET was meant for cross-platform development, the development for Mac (perhaps not for Linux in this case) was more like an added-on benefit, just tagging along, but it not sharing an equal focus. That's just how I felt while using CKAN on Mac, at least. I expanded 3 parts in interpreting the metadata: license, version comparison, and "any_of". My implementation should be able to understand all licenses listed on SPCX License LIst, and pulls detailed information from it. I compare mods' versions the same way as CKAN does, alternating strings and numbers, but also take into account for non-Latin characters and semantic versioning-like versions. The "any_of" recursion will go only as deep as it is in the metadata. By "infinite", I meant it's capable of handling as many levels as there is, like unlimited depth, but not self-referencing or digits-of-π kind of infinity. My intention was to allow metadata files to expect a behaviour as if they were parsed by CKAN, and at the same time allow for some room of growth. However, I must admit that until I saw your reply, I overlooked how CKAN might deal with metadata outside of its specification, and how my implementation might clash against it with unexpected behaviours. Thanks for the words of caution. The whole infinite "any_of" recursion started loosely because of the incompatibility between JSON's weakly typed and Swift's strongly typed data structures. It was quite fun to solve it by stretching their compatibility to as wide as possible, and indeed I did it mostly for fun. Although, it did take me about 2 weeks to solve this problem. I posted this stack overflow question a few days before I found a solution. Yes, this is definitely true. Since all the relationship fields in the metadata are just logic expressions, however complex they might be, they can all be reduced to a single layer of ands and ors. I must admit, I did the recursion mostly for fun, and also for modders who might want to use multiple levels of "any_of" out of either convenience or laziness. EDIT: Some grammatical issues. I typed at first in a hurry.

Thanks! I hope it's not too ambitious tho, just so I can finish it before it's too late. I studied Launch Pad's code and took a lot of inspiration from it. Both Launch Pad and my project use different backends from CKAN's. But there are a lot of differences as well. Most superficially, we have very different approaches to parsing CKAN's metadata. Launch Pad mostly followed the JSON files structure, including the key's names, whereas my project uses a completely new structure for representing each mod release, and maps my structures and the JSONs' for decoding. This allows the "objects" in my code to be more tidy, and it allows my project to follow Apple's API design guidelines. As for issue #2848 on github, I'm doing something very different. I avoided using electron for a similar reason to avoiding .NET. I want to be able to access native system calls natively, and not rely on a wrapper's implementation for anything. I'm totally open to joining my project into the main CKAN, if their devs approve of it. I'll release my source code under WTFPL as soon as it's in beta, so the CKAN team can freely copy every bit of it into CKAN as well.

Thanks for the input. I really appreciate it. The main reason is that CKAN's GUI doesn't work for the current macOS version anymore. Last time I checked, it was practically unfixable because of the 32-bitness. Even when it worked in previous Mac versions, it was glitchy, and its behaviour was inconsistent with Mac app's UI/UX. In general, it treats Mac and Linux as a second class citizens, with minimal documentation and support. In a way I am making a frontend, and a bit more, mostly an entire backend too. I am using CKAN's metadata but with a more flexible/extended interpretation (e.g. my implementation supports infinite recursion in the "any_of" field). I am not using CKAN's command line tool tho, because I don't want to use .NET wrapping native system calls when I can access them directly. Not using CKAN's command line tool also gets rid of the mono dependencies. In addition, I want my mod manager to be in complete control of everything it does, and not throw it at the mercy of CKAN working properly. My mod manager is written in Swift, which is possible for cross-platform support as well, but that could be years into the future before it happens. I think I'll be able to release the beta within a month, and I'll publish a much more detailed description of my rationale behind developing it and its features.

Hi everyone! I'm developing a CKAN replacement for macOS. One of the features for this new mod manager is the ability to handle multiple KSP installs concurrently. I really like the mission patches' design for each KSP release, and want to incorporate them into the UI for navigating through different KSP versions. Here is a mockup of a sidebar showing how I intend to use the patches: However, I'm not able to find any of those mission patches online. The one I used in the picture above is cut out of the KSP 1.8 release poster using Photoshop. Does anyone know where I can find official mission patch designs for each KSP release with a transparent background? I emailed press@kerbalspaceprogram.com, but was told to ask the community for help instead. Thanks in advance for your help! UPDATE Ara from Private Division has provided me all the releases' logo images a bit more than a week ago. (Sorry! Just remembered to update this post.) However, Private Division doesn't have any releases' stylised logos prior to Take Two's acquisition of KSP. If anyone knows where I can find logos with transparent background in these following images, it would be extremely helpful! As a side note, I plan to release the first alpha version along with all the source code within a week. It will be very very alpha and unfinished, but will give everyone an idea of the finished version's UI/UX.