KSP version mission patches

[wowbagger's liquid lunch]

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.

Edited February 22, 2020 by wowbagger's liquid lunch
add pictures; correct information

[jost]

2 hours ago, wowbagger's liquid lunch said:

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!

I can't help with your question but at the risk of liquiding you off: Why do you doing this project at all? It's possible to manage multiple installs with ckan as well .
And I imagine that it will be quite messy to maintain two package databases. CKAN already has a history of causing problems thus some modders don't support installation via CKAN. 

I expect that just another tool like it won't make things better in that regard.

That being said, if you want to continue I would suggest to just create a new frontend (aka a nice and polished MacOSX friendly interface), but use CKAN for the actual work by calling it from your GUI. Since ckan has a command line mode this should be pretty easy to implement. Just call "ckan list" to get a list of mods, let the user select one from your GUI and then do a "ckan install mod". 

Then you would have the best of both worlds. 
 Just my two cents and I hope you don't think to hard of me. Just some constructive criticism.

 

Good luck with your project and happy hacking!

Edited January 14, 2020 by jost
Typos

[wowbagger's liquid lunch]

1 hour ago, jost said:

I can't help with your question but at the risk of liquiding you of: Why do you doing this project at all? It's possible to manage multiple installs with ckan as well .
And I imagine that it will be quite messy to maintain two package databases. CKAN already has a history of causing problems thus some modders don't support installation via CKAN. 

I expect that just another tool like it won't make things better in that regard.

That being said, if you want to continue I would suggest to just create a new frontend (aka a nice and polished MacOSX friendly interface), but use CKAN for the actual work by calling it from your GUI. Since ckan has a command line mode this should be pretty easy to implement. Just call "ckan list" to get a list of mods, let the user select one from your GUI and then do a "ckan install mod". 

Then you would have the best of both worlds. 
 Just my two cents and I hope you don't think to hard of me. Just some constructive criticism.

 

Good luck with your project and happy hacking!

 

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.

[HebaruSan]

Ambitious project! Any relation to this?

• https://github.com/winsmith/launch-pad

EDIT: I suppose I should note that the CKAN team desperately needs and would welcome Mac developers to create a better official client. We had hoped the below effort would pan out, but there weren't any updates from the OP after the first day:

• https://github.com/KSP-CKAN/CKAN/issues/2848

Edited January 14, 2020 by HebaruSan

[wowbagger's liquid lunch]

11 minutes ago, HebaruSan said:

Ambitious project! Any relation to this?

• https://github.com/winsmith/launch-pad

EDIT: I suppose I should note that the CKAN team desperately needs and would welcome Mac developers to create a better official client. We had hoped the below effort would pan out, but there weren't any updates from the OP after the first day:

• https://github.com/KSP-CKAN/CKAN/issues/2848

 

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.

[jost]

1 hour ago, wowbagger's liquid lunch said:

 

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.

As @HebaruSan said: "Ambitious project! " But if it's not working at the moment I can understand it. However I don't agree with "it treats Mac and Linux as a second class citizens, with minimal documentation and support. " 

I can't say anything about the Mac port but I'm running Linux and it runs pretty smooth. What's the problem with 32bit? In my understanding a mono app should run anywhere with a recent mono version. 

Concerning the metadada: It's a good idea to use the existing format, so basically reimplementing CKAN just in a native port for Mac OS X. First you don't need to reinvent the wheel, second it minimize compatibility issues. However I think this conflicts with the idea of a "more flexible/extended interpretation". If your implementation behaves differently at a critical point this will mean, that the same *ckan file can't be used for both implementations. I doubt that most modders will care about this so in the end they will just support one port (the one with more users). To avoid missunderstandings: This is not a critic of your implementation or the modders. Everybody of you is doing it for free, so it's understandable to use the time in a efficient and (ideally I mean it's a hobby) fun way. Especially "infinite recursion" sounds like a smoking gun for me: 

• Infinite recursion can be a problem by itself (e.g. Mod a points to Mod b which points to Mod c which points to Mod a->The actual dependency is not fetched
• If a modder expect the behaviour of your variant but CKAN behaves differently this can lead to confusion at the end user.
   

Both together can lead to support nightmares for the modder, the CKAN guys and yourself.

Or did I understand what you are trying to achieve with this feature? What's your rationale behind it?

Edit: Aha I see the CarbonPort of mono is just supported for 32 bit, meh: https://www.mono-project.com/docs/about-mono/supported-platforms/macos/ 

They mention a GTK# port however. Although that's not very Maclike has anybody tested to build and run CKAN with it? 

Regards, Jost.

 

Edited January 14, 2020 by jost

[HebaruSan]

7 minutes ago, jost said:

However I don't agree with "it treats Mac and Linux as a second class citizens, with minimal documentation and support. " 

Linux is a first-class citizen of CKAN; all official builds and tests are performed on a flavor of Ubuntu, and all of the devs are either primary or exclusive users of Linux. Some of us dual boot into Windows to iron out quirks resulting from differences between .NET and Mono.

7 minutes ago, jost said:

What's the problem with 32bit? In my understanding a mono app should run anywhere with a recent mono version. 

For whatever historical reasons, Mono's implementation of WinForms only works in 32-bit mode on Mac. Recent versions of Mac OS dropped support for 32-bit mode. CKAN's GUI uses WinForms, so it won't run on recent Mac OS.

• https://github.com/mono/mono/issues/6701
• https://github.com/KSP-CKAN/CKAN/issues/2272

If you try to run the CKAN.app on such an OS, it will fall back to a text UI:

• https://github.com/KSP-CKAN/CKAN/pull/2911

If the Mono team creates a 64-bit implementation of WinForms, this will take care of itself, but there doesn't appear to be strong demand for that.

7 minutes ago, jost said:

Especially "infinite recursion" sounds like a smoking gun for me: 

• Infinite recursion can be a problem by itself (e.g. Mod a points to Mod b which points to Mod c which points to Mod a->The actual dependency is not fetched

More to the point, nesting any_of directives doesn't let you accomplish anything that one flat list wouldn't. In the end, you still need just one of the "leaf nodes" to be satisfied. So this would be unlikely to occur in CKAN's metadata.

[wowbagger's liquid lunch]

3 hours ago, jost said:

However I don't agree with "it treats Mac and Linux as a second class citizens, with minimal documentation and support. " 

 

3 hours ago, HebaruSan said:

Linux is a first-class citizen of CKAN; all official builds and tests are performed on a flavor of Ubuntu, and all of the devs are either primary or exclusive users of Linux. Some of us dual boot into Windows to iron out quirks resulting from differences between .NET and Mono.

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. 

3 hours ago, jost said:

Concerning the metadada: It's a good idea to use the existing format, so basically reimplementing CKAN just in a native port for Mac OS X. First you don't need to reinvent the wheel, second it minimize compatibility issues. However I think this conflicts with the idea of a "more flexible/extended interpretation". If your implementation behaves differently at a critical point this will mean, that the same *ckan file can't be used for both implementations. I doubt that most modders will care about this so in the end they will just support one port (the one with more users).

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.

3 hours ago, jost said:

Especially "infinite recursion" sounds like a smoking gun for me: 

• Infinite recursion can be a problem by itself (e.g. Mod a points to Mod b which points to Mod c which points to Mod a->The actual dependency is not fetched
• If a modder expect the behaviour of your variant but CKAN behaves differently this can lead to confusion at the end user.

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.

3 hours ago, jost said:

What's your rationale behind it?

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.

3 hours ago, HebaruSan said:

More to the point, nesting any_of directives doesn't let you accomplish anything that one flat list wouldn't. In the end, you still need just one of the "leaf nodes" to be satisfied. So this would be unlikely to occur in CKAN's metadata.

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.

Edited January 15, 2020 by wowbagger's liquid lunch