[Feature] Enhancing Install experience for complex mods/suites (RO/RP-1 use case)

[NathanKell]

Opened this in replacement of https://github.com/KSP-CKAN/NetKAN/issues/8615

Right now the install experience for RO/RP-1 is quite complex. We have a lengthy install guide on our wiki to cover how to do it. I've been spending the last month or so trying to get all the mods we depend on available for 1.10, and we're mostly there (there are basically only two remaining mods that are issues). But it's also the case that, even if everything is available on CKAN, the process of selection and install of mods is still quite complex.

The traditional CKAN flow is to select a mod or mods to install. That autoselects dependencies. Then, on apply, the user is presented with a set of recommended mods (which default to checked) and a set of suggested mods (which default to unchecked). Further, any dependencies that can be met multiple ways result in a prompt to select a mod to fulfill the dependency.

Here are the pain points in that process, for RO/RP-1 (at least those pain points I'm thinking about right now):

1. The set of recs and suggests are dependent on which mod(s) the user manually selects. I.e. the experience is different between selecting only RP-1 manually, and selecting both RO and RP-1 manually.
2. There is no in-app guidance offered on which recommendeds Really Should Be selected and which are more optional but still very much recommended. For a large list of recs (given 1 it could be very large!) this is problematic.
3. There is no in-app guidance on selecting which mod to use to fulfill a depends.
4. MechJeb requires the addition of an additional metadata repository.
5. The download size is very, very large, and if a mod that includes a bunch of assets is updated, the entire mod is redownloaded.

Now, (5) is an issue we're going to address on our side by splitting up plugin/cfg and assets. And hopefully (4) can be addressed with some level of stability in MJ where the RO-specific stuff gets merged into mainline MJ. (2) I think is a mostly unsolveable problem given the structure of CKAN--I would not suggest adding another level of rec/suggest to get around that; instead my solution will be to have a "simplified install" metapackage that shifts as much as possible into depends.

(1) is tricky. It's desired behavior in normal circumstances. I think the only reasonable answer for RO/RP-1 is that "simplified install" metapackage, and our install guide referencing only that. If users are experienced enough to install individual packages on CKAN, they're experienced enough (I hope) to make reasonable decisions.

Now, as to (3). Here, per the other issue, I think there's some nice low-hanging fruit in the CKAN client, the ability to add a comment that is displayed when a user has to select amongst different mods that fulfill a dependency.

With that change, we should be able to create an install-wizard-like experience, where you select a root metapackage, it depends on a bunch of metapackages each of which have a comment and a number of ways to fulfill them. That way the user is guided through the install process, making only informed choices about what to install. It still falls apart if the user selects additional mods at the start in addition to the "simplified install" metapackage, because then they'll get a bunch of other recs, depends, etc. And that problem I don't have a good sense on how to solve; as mentioned above I don't want to prevent "power users" from installing RO/RP-1 a la carte, and I also don't want the install-wizard metapackage to conflict the world as a way to keep first-time-installs constrained, so...gotta think about it more.

[HebaruSan]

I just did a sample install from scratch. Honestly the most confusing thing was the differences between SmokeScreen / SmokeScreen-RO and CustomBarnKit / CustomBarnKit-RO; since the RO forks have older versions, it's not clear whether I benefit more from installing "the RO fork" or from getting a newer version. Retiring the RO forks and using the normal releases of those mods would take two steps out of the install.

EDIT: Then again, I think I have a really broad compatibility configured; need to try this again without that.

EDIT 2: OK, I set my compatibility to KSP 1.10–1.12 (formerly included 1.7 for investigation of why CustomBarnKit wasn't being installed during validation of #8656), and neither of those prompts appeared. Scratch this whole comment.

[NathanKell]

Yeah I asked @sarbian to nuke the MechJeb RO identifier, would be good to nuke those too. :) (Although presumably that doesn't retroactively kill on CKAN, need to do that separately?)

[HebaruSan]

Let's document what the user sees for a typical flow. I'll set compatibility to KSP 1.10–1.12 and select RP-1 by itself as a baseline.

1. Picking RP-0/1 from the mod list: Click Apply changes →
2. Change set review: Click Apply →
3. Recommendations and suggestions: Click Continue →
4. This is where the depends/provides/toomanymodsprovide choices begin: It would be nice if these were sorted in size order (16k, 8k, 4k, 2k) rather than lexicographical (16k, 2k, 4k, 8k). So that's one possible enhancment discovered. I'll check the 2k textures and click Continue →
5. I don't remember exactly what KSPBurst was (something with the GPU?), and it's not clear why I have to install it or which of these would do the job better: I'll check the non-"lite" one and click Continue →
6. And from there we go to the install screen:

Frankly this isn't too bad at the moment. Really just two choices, one of which is pretty clear (the textures). The inclusion of KSPBurst is unfortunate; maybe we can look into why that's being pulled in and whether it's needed.

[ppboyle]

Here's a few things that might be helpful:

1. Swap need to add 'nonNonRP0' to requiring a 'NonRP0' folder to be able to see the nonRP0 parts - default experience should be to not see them. Ditto NonRO, and then most people can ignore the 'add empty folders' step.
2. We should make sure some mods like TUFX, B9 Aersoapce Proc Wings and Distant Object Enhancement work with their CKan versions - I know I manually installed them and when I checked the manual install was ahead of the Ckan version. I think these are fine though, and just need to be taken off the 'manual install' list in the wiki?
3. Is there any good reason to have to add a separate repository just to get Mechjeb Dev? Not real clear on this, why not just a separate MechJeb-RO in the main repository?
4. Don't mention Principia on the main install page + all its disclaimers. Move it to the separate 'optional' mod page - it's more optional than most mods.
5. What can we do to make as many of the visual enhancements, that I do think most players install, easiest to get?
6. Update the wiki to point at the fastest, default-est set of install options up at the top, removing all the manual install instructions for the visual mods that we can get off of c-kan. (I can do that if needed?)
7. Clean up the 'suggested' list in the ckan install, add a few newer mods that got configured. Like modular launch pads for instance.
8. Clean up the extra recommended mods section, make a 1.10 version, its a bit of a mess, as it lists a bunch of mods that are required and not really optional, probably doesn't list some that people could install, etc. Every mod that comes up as 'suggested' when you install RP-1 from ckan should be here in some fashion.

So yeah - as Hebaru points out it's mostly quite streamlined, there's just a few rough edges left to work out, and then updating the wiki.

[HebaruSan]

For what it's worth, the idea behind my suggestion in #8615 was to identify code changes in the CKAN app itself that could make this work better. Feel free to hash out wiki changes and whatnot here as well, but I will be mainly focused on finding enhancement ideas along those lines.

[StonesmileGit]

Regarding KSPBurst; that is a dependency of Real Antennas, used to increase performance. You would have to ask the creator (dkavolis) why the 'lite' version exists.

There is also one issue currently with the recommended list; We recommend both Ven's and Restock (you should get one), but since they conflict, the standard choise in CKAN is to have none of them selected. A solution could be to have something similar to the texture selection / KSPBurst screen.

[HebaruSan]

TUFX, B9 Aersoapce Proc Wings and Distant Object Enhancement work with their CKan versions - I know I manually installed them and when I checked the manual install was ahead of the Ckan version

CKAN should be up to date on all of those (unless their authors are creating pre-releases on GitHub, I suppose):

Mod	Latest version
TUFX	1.0.2.3
B9PW	0.43.0.10 (@linuxgurugamer's versioning scheme)
DistantObject	v2.0.2.0

Is there any good reason to have to add a separate repository just to get Mechjeb Dev? Not real clear on this, why not just a separate MechJeb-RO in the main repository?

The decision to have a separate dev build of MechJeb goes back at least 6 years, see KSP-CKAN/CKAN-meta#690 and KSP-CKAN/CKAN-meta#924. Decisions that old tend to be sparsely- or un-documented, but I have to assume the reasoning was that the dev build would be less stable and should therefore be opt-in only. Maybe we should ask @sarbian if that still makes sense.

What can we do to make as many of the visual enhancements, that I do think most players install, easiest to get?

Should they be recommended or suggested?

Regarding KSPBurst; that is a dependency of Real Antennas, used to increase performance. You would have to ask the creator (dkavolis) why the 'lite' version exists.

KSP-CKAN/NetKAN#8418 and KSP-CKAN/NetKAN#8419 say: "plugins_only version does not contain the compiler, use it only if KSPBurst is a hard dependency and download size is an issue" and "Does this mean that users can opt for that plugin_only zip, and everything will still work perfectly fine, just without the performance enhancements? ... Yeah".

So maybe we can clarify the abstract of KSPBurst-Lite to say that it will still work, just slower.

We recommend both Ven's and Restock (you should get one), but since they conflict, the standard choise in CKAN is to have none of them selected.

Yeah, I was surprised to see both of those unchecked; I thought we made it check the first one in the list by default for recommendations (and since you control the ordering of an any_of block, this would also let you control the default). Maybe there was some technical wrinkle that prevented that, something to look into.

A solution could be to have something similar to the texture selection / KSPBurst screen.

Something to consider, but it is still valid to install neither, and it would be weird to treat a few recommendations separately from the rest. I'm thinking that defaulting the first one to checked as I suggest above ought to help.

[HebaruSan]

One thing that bothers me is that you're putting substantial effort into maintaining recommendations and suggestions for RealismOverhaul and RealSolarSystem, which currently are just ignored if the user starts from RP-1. We should consider showing recommendations and suggestions for the entire initial change set. And possibly even for mods that are added later on via the various lists and prompts.

[NathanKell]

TUFX, B9 Aersoapce Proc Wings and Distant Object Enhancement work with their CKan versions - I know I manually installed them and when I checked the manual install was ahead of the Ckan version

CKAN should be up to date on all of those (unless their authors are creating pre-releases on GitHub, I suppose):

Mod Latest version TUFX 1.0.2.3 B9PW 0.43.0.10 (@linuxgurugamer's versioning scheme) DistantObject v2.0.2.0

TUFX and DOE are fine. I've been trying to reach @linuxgurugamer about allowing 0.43.0.10 to be installed on 1.10 (without requiring a compatibility override in CKAN) but have not heard back either way, either about this PR https://github.com/B9-Procedural-Wings/B9-PWings-Modified/pull/10 or via a discord PM). That is one of the two exceptions I mentioned above, the other being MJ.

Is there any good reason to have to add a separate repository just to get Mechjeb Dev? Not real clear on this, why not just a separate MechJeb-RO in the main repository?

The decision to have a separate dev build of MechJeb goes back at least 6 years, see KSP-CKAN/CKAN-meta#690 and KSP-CKAN/CKAN-meta#924. Decisions that old tend to be sparsely- or un-documented, but I have to assume the reasoning was that the dev build would be less stable and should therefore be opt-in only. Maybe we should ask @sarbian if that still makes sense.

I checked with sarbian and he's going to merge down the dev changes to mainline MJ in the next few days (this is the other exception I mentioned above). But long-term it would be really nice to live in a world that doesn't require manually adding a separate metadata repo, though there are also dangers in pushing dev MJ builds out at all RO players (which as the point of the dev build repo in the first place IIRC, so it didn't get served unless you asked for it).

What can we do to make as many of the visual enhancements, that I do think most players install, easiest to get?

Should they be recommended or suggested?

RSS should rec RSSVE, yes. (And thus by the non-transitive property of recs, RO/RP-1 should too :D ).

Regarding KSPBurst; that is a dependency of Real Antennas, used to increase performance. You would have to ask the creator (dkavolis) why the 'lite' version exists.

8418 and #8419 say: "plugins_only version does not contain the compiler, use it only if KSPBurst is a hard dependency and download size is an issue" and "Does this mean that users can opt for that plugin_only zip, and everything will still work perfectly fine, just without the performance enhancements? ... Yeah".

So maybe we can clarify the abstract of KSPBurst-Lite to say that it will still work, just slower.

That, and adding the comment field would be great, then RA's depends node could have a comment saying "Choose the regular version for increased performance, except in rare circumstance <i.e. low bandwidth cap>"

We recommend both Ven's and Restock (you should get one), but since they conflict, the standard choise in CKAN is to have none of them selected.

Yeah, I was surprised to see both of those unchecked; I thought we made it check the first one in the list by default for recommendations (and since you control the ordering of an any_of block, this would also let you control the default). Maybe there was some technical wrinkle that prevented that, something to look into.

A solution could be to have something similar to the texture selection / KSPBurst screen.

Something to consider, but it is still valid to install neither, and it would be weird to treat a few recommendations separately from the rest. I'm thinking that defaulting the first one to checked as I suggest above ought to help.

That would be great, yes. A similar case arises with RCSBuildAid / RCSBuildAidCont. Since they are root level howeve,r rather than in an any-of both start checked (and highlighted in red since they conflict).

[NathanKell]

One thing that bothers me is that you're putting substantial effort into maintaining recommendations and suggestions for RealismOverhaul and RealSolarSystem, which currently are just ignored if the user starts from RP-1. We should consider showing recommendations and suggestions for the entire initial change set. And possibly even for mods that are added later on via the various lists and prompts.

You do show recs for the entire manual initial changeset, not for dep'd in mods. And I think that is 100% correct. Having thought about it a bunch since my original recs question (about RSS-Textures and RSS-CanaveralHD) I've come to the conclusion that it's much riskier to have the reqs of dependencies added automatically, because e.g. RO/RP-1 could depend on a mod, but that mod's use case is mostly in a stock setup and therefore recommends a bunch of mods that don't make sense for RO/RP-1. And being in the business of copying our recs across multiple mods is easier than passing around giant lists of Conflicts.

[HebaruSan]

I've come to the conclusion that it's much riskier to have the reqs of dependencies added automatically, because e.g. RO/RP-1 could depend on a mod, but that mod's use case is mostly in a stock setup and therefore recommends a bunch of mods that don't make sense for RO/RP-1.

A bit of coding later, here's what the list actually looks like with that change made if the user picks only RP-0, so we can assess how much to worry about that:

Inspecting the middle column, almost all of the newly added relationships are from RealismOverhaul. Looks like a positive change to me.

[NathanKell]

That looks pretty weird, since there are a few mods (RSS and VNP off the top of my head) that RP-1 depends but that are listed there as uncheckable recs. Is that due to the quickhack nature of the coding, or something deeper going on? Conversely, RSS recs KSCSwitcher but it is not listed as coming from RSS.

Let me ask about the KK case explicitly then. Let's say we are in a place where RP-1 deps RSS, RSS recs RSS-CanaveralHD, and RSS-CanaveralHD recs CanaveralPads. CanaveralPads deps KK, and KK recs KSC Extended.

When you select RP-1, what subset of that appears in the rec list?

---

Another point: If this change were made, I would highly request the ability for a mod's metadata to turn that feature off, as the entire point of the simplified install (the new metapackage) is to present only well-explained choices, and a wall of mods with only their abstracts defeats the very purpose of doing that work.

[HebaruSan]

Is that due to the quickhack nature of the coding

Yup, that was a bug. Fixed and replaced the screenshot.

[siimav]

Another issue is that RemoteTech ended up in recommends which is fine for RO but completely unsupported in RP-1.

[HebaruSan]

Conversely, RSS recs KSCSwitcher but it is not listed as coming from RSS.

It's there, the column was just too narrow. Replaced screenshot with one with the column widened.

[HebaruSan]

RP-1 deps RSS, RSS recs RSS-CanaveralHD, and RSS-CanaveralHD recs CanaveralPads. CanaveralPads deps KK, and KK recs KSC Extended.

When you select RP-1, what subset of that appears in the rec list?

I think you'd see RSS-CanaveralHD as a recommendation only. Since it's only a recommendation, it's not part of the initial change set, so its recommendations wouldn't be shown (but its dependencies would be pulled in if you chose to install it).

[NathanKell]

Cool. I still think it's on net a bad idea for our particular context (although on net it may well be a good idea for non-KSP-RO use cases!), and I absolutely want the ability to turn it off (so the simplified installable can be, like, simplified, i.e. it can be bespoke), but some of the worst-cases I was worried about are gone. :)

[HebaruSan]

the ability for a mod's metadata to turn that feature off

Hmm, I think that might be one of those ideas that we think is easy to say in English but turns out to be incoherent or impossible to define when you get down to the details of implementing it. E.g., I pick two mods to install, one has the magic "don't show full change set's recommendations" flag in its metadata, the other doesn't. Do we show the full change set's recommendations, or not?

[NathanKell]

I am fully aware that what I am suggesting is boolean and here, not or; once any mod has that turned off, you have to turn the whole shebang off, as otherwise the disable-ability has no meaning and can be circumvented by selecting any other package.

[HebaruSan]

Right, which then gives your mod the ability to mess up other mods' installs, if their authors are relying on this change. Everybody needs to be able to play nice in the sandbox.

[NathanKell]

See, I read it as (and we have been presenting the examples of) enabling that feature meaning some mods can mess up other mods' installs.

[HebaruSan]

(and we have been presenting the examples of)

Was there one other than RemoteTech?

[NathanKell]

First, I forgot to mention this earlier, but before you mentioned you have a bunch of compat versions checked. That will not at all replicate a standard install, where the new user will not have any compat versions checked and thus only the mods available for 1.10.1 will be shown. I'm not sure that will change the above screenshot, but it will change your install experience.

As to your question: under the current set of recs of the RP-1 dependencies, not as far as I can tell from your list above. Under a future set, yes, there likely will be (as we switch to depending on CKAN more and manual install less, and have a fuller set of recs), and further it entirely breaks any possibility of my creating the simplified install-wizard style RP-1 installer, because that will operate off depends rather than recs,, and the recs of all depends will be selected under your proposed change, which is actively what I do not want (I want it to have no recs or suggests, merely depends/provides choices, i.e. explainable choices using the depend/comment change).

[HebaruSan]

First, I forgot to mention this earlier, but before you mentioned have a bunch of compat versions checked. That will not at all replicate a standard install, where the new user will not have any compat versions checked and thus only the mods available for 1.10.1 will be shown. I'm not sure that will change the above screenshot, but it will change your install experience.

Sure, I did that because you mentioned getting things released for 1.10, and I have 1.12 installed. But in the context of worrying about extra things being pulled in, this can only help, as it would remove mods from the list, not add them.

As to your question: under the current set of recs of the RP-1 dependencies, not as far as I can tell from your list above. Under a future set, yes, there likely will be (as we switch to depending on CKAN more and manual install less, and have a fuller set of recs), and further it entirely breaks any possibility of my creating the simplified install-wizard style RP-1 installer, because that will operate off depends rather than recs,, and the recs of all depends will be selected under your proposed change, which is actively what I do not want (I want it to have no recs or suggests, merely depends/provides choices, i.e. explainable choices using the depend/comment change).

OK, I need to think about this some more. Modders generally have good reasons for their recommendations and suggestions, and I think most probably expect that if their mod is being installed, the user will see those lists (even though there are lots of big exceptions to that today).

[NathanKell]

Ah, yeah, if you have a 1.12 local install you would indeed have gotten B9 Pwings even though that version is locked away from 1.10 at the moment.

As to the other case: yeah, I think what we are hitting up against is two things: (a) RO/RP-1 is a different beast from pretty much all other KSP mods; it's the closest thing KSP has to a total conversion, so the usual KSP modding rules of "mods play nice with each other with few exceptions, and those rare exceptions can be easily documented" is flipped on its head to "in fact, while QoL mods are often, albeit not always, safe, in the main mods work with RO/RP-1 if and only if they have been explicitly configured to do so." (b) RO/RP-1 is also way more complex, and installs can be quite finicky; it's very valuable (judging by the number of support requests we get, and the number of people begging for zipped gamedatas / modlists) to have the option for an all-in-one, canonical install path. Basing it of deps/recs/suggests doesn't really work, because then you still get questions about "which recs should I actually leave checked" and "which suggests should I add".

[HebaruSan]

RSS should rec RSSVE, yes. (And thus by the non-transitive property of recs, RO/RP-1 should too :D ).

That may be something easy we can fix in the short term, then; RSS currently only recommends RO, KSCSwitcher, and RSSDateTimeFormatter. Do you want to switch this to a metanetkan hosted on your repo for easier updates?

https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/RealSolarSystem.netkan

[NathanKell]

Yeah think that probably makes sense, I've just held off touching the RSS metadata pending getting Kerbal Konstructs on 1.10 so I can do everything all at once (I.e. rec RSSVE, RSS-CanaveralHD, and CanaveralPads).

[HebaruSan]

questions about "which recs should I actually leave checked" and "which suggests should I add".

Sigh. Maybe CKAN needs an "advanced user" flag, which just auto-clicks Continue on that screen if it's off.

[NathanKell]

I mean, that would also work. :D But you live by the CPAN / apt-get roots, you die by the CPAN / apt-get roots.

[HebaruSan]

Ironically, the command line ckan install RP-0 command does pretty much exactly that (install recommendations, ignore suggestions).

Click to expand!

``` $ _build/ckan.exe install RP-0 Module RSSTextures is provided by more than one available module. Please choose one of the following: 1) RSSTextures16K (Real Solar System Textures - 16384 x 8192) 2) RSSTextures2048 (Real Solar System Textures - 2048 x 1024) 3) RSSTextures4096 (Real Solar System Textures - 4096 x 2048) 4) RSSTextures8192 (Real Solar System Textures - 8192 x 4096) Enter a number between 1 and 4 (To cancel press "c" or "n".): 2 Module RemoteTech OR RealAntennas is provided by more than one available module. Please choose one of the following: 1) RemoteTech (RemoteTech) 2) RealAntennas (Real Antennas) Enter a number between 1 and 2 (To cancel press "c" or "n".): 2 Module KSPBurst is provided by more than one available module. Please choose one of the following: 1) KSPBurst-Lite (KSPBurst Lite) 2) KSPBurst (KSPBurst) Enter a number between 1 and 2 (To cancel press "c" or "n".): 1 About to install: * Realistic Progression One (RP-1) v1.10.5.0 (cached) * Real Solar System Textures - 2048 x 1024 v18.3 (cached) * Real Antennas v2.1 (cached) * KSPBurst Lite v1.5.5.1 (cached) * Module Manager 4.2.1 (cached) * Realism Overhaul v14.3.0.0 (cached) * Advanced Jet Engine v2.18.0 (cached) * Ferram Aerospace Research Continued 3:0.16.0.3 (cached) * ModularFlightIntegrator 1.2.10.0 (cached) * Solver Engines plugin v3.11.0 (cached) * Real Fuels rf-v13.2.0 (cached) * Community Resource Pack 1.4.2 (cached) * Kerbal Joint Reinforcement Continued v3.5.2 (cached) * RealChute Parachute Systems v1.4.8.3 (cached) * RealHeat v5.1 (cached) * Real Plume 2:v13.3.2 (cached) * SmokeScreen - Extended FX Plugin 2.8.14.0 (cached) * B9 Aerospace Procedural Wings - Fork 3:0.43.0.10 (cached) * Deadly Reentry Continued v8.1.2 (cached) * Waterfall Core 0.6.7 (cached) * Hangar Extender 3.6.0.1 (cached) * Toolbar Controller 1:0.1.9.4 (cached) * ClickThrough Blocker 1:0.1.10.17 (cached) * Zero MiniAVC 1:1.1.0.2 (cached) * Toolbar 1:1.8.0.5 (cached) * KSC Switcher v2.0.0.0 (cached) * MechJeb 2 2.12.0.0 (cached) * Procedural Fairings 1:v6.1 (cached) * Procedural Fairings - For Everything! v0.3.0 (cached) * Procedural Parts v2.1.2 (cached) * PersistentRotation Upgraded 1.9.1.6 (cached) * SpaceTux Library 0.0.6.1 (cached) * RCS Build Aid v1.0.6 (cached) * Real Solar System v18.1.5 (cached) * Kopernicus Planetary System Modifier 2:release-1.12.1-56 (cached) * RSS DateTime Formatter v1.10.0.0 (cached) * Kerbalism - RealismOverhaul Config v1.2.2 (cached) * Kerbalism 3.14 (cached) * Harmony 2 2.0.4.0 (cached) * Kerbal Changelog v1.4.2 (cached) * Textures Unlimited 1.5.10.25 (cached) * SXTContinued 2:0.3.29.6 (cached) * Firespitter Core v7.17 (cached) * Firespitter Resources config v7.17 (cached) * Retractable Lifting Surface Module 0.2.1.1 (cached) * Contract Configurator 1.30.5 (cached) * Waypoint Manager 2.8.3.1 (cached) * Custom Barn Kit 1.1.21.0 (cached) * Ven's New Parts v1.15.1 (cached) * Ven's Stock Part Revamp Core v1.15.1 (cached) * Ven's Stock Part Revamp v1.15.1 (cached) * MagiCore 1.3.2.3 (cached) * RO Engines v1.8.1 (cached) * RO Library v1.3.1 (cached) * RO Tanks v2.5 (cached) * RO Solar v1.1.1 (cached) * RO Capsules v1.5.2.0 (cached) * BahamutoD Animation Modules 1:v0.6.7.1 (cached) * B9 Part Switch v2.18.0 (cached) * Patch Manager 0.0.17.2 (cached) * KSP Wheel 1:0.16.14.33 (cached) * Kerbal Renamer v1.4.0 (cached) * AtmosphereAutopilot (Fly-By-Wire) v1.5.17 (cached) * Ship Manifest 6.0.2.0 (cached) * Test Flight v2.1.0.0 (cached) Continue? [Y/n] ```

[NathanKell]

Oh that is deeply ironic. But I'm not going to suggest people use the command line to install RP-1, alas. 😂

[jwvanderbeck]

Batch file? :p

[HebaruSan]

OK, I think I'm going to work up a pull request with:

• Check the box for the first recommendation in an any_of group
• Display a relationship's comment property if defined when prompting the user to pick a depends based on provides or any_of

I have these on a branch already, should be relatively simple to move them along. I'll leave out the full-change-set-recommendations change for now since it's, let's say, not universally popular at this point.

[HebaruSan]

RSS should rec RSSVE, yes. (And thus by the non-transitive property of recs, RO/RP-1 should too :D ).

Did this in #8689. But since it's just a recommendation, and we don't show recommendations for the full change set, users choosing RP-0/1 or RO won't benefit from this. Food for thought.

[NathanKell]

Oh, since I'm actually writing the netkans now I hit another example: RO recommends RaiderNick's part mods. But they are unsupported by Raidernick in RP-1, and RP-1 has only iffy support for them. So that's another example where we really don't want the recs of dep'd mods being carried bundled up with the actively-selected mod. (This will basically always be the case with RO and RP-1, since configuring a part in RO is easier than also placing it and pricing it and getting it all balanced for career, there will be mods that are rec'd for RO but not for RP-1--but they also shouldn't be marked as conflict by RP-1...)

[NathanKell]

Closed via #8701

[NathanKell]

Well, and via #8690 and KSP-CKAN/CKAN#3426 as well :)