Conditional recommends / suggests

[Ippo343]

I have been thinking about the possibility of having conditional relationships, specifically a conditional recommends or suggests.

Example usage: Entropy is an extension for Dang It that also has a secondary module called EntropyRealChute. The latter obviously depends on RealChute: so the main module Entropy cannot recommend EntropyRealChute, or RealChute becomes selected by default even for users that did not mean to install that.

It would be cool, in this case, to be able to recommend EntropyRealChute only if RealChute is already installed or about to be installed: this way, it's automatically selected for the users to whom it applies and remains hidden for those that don't need it.

Ideally, it would look something like this:

"recommends" [
    {
        "name": "EntropyRealChute",
        "if_installed": "RealChute"
    }
]

[cake-pie]

Being able to specify "if Mod A & Mod B then (recommend/suggest) Mod C" would be tremendously useful, especially if we can define "mod" loosely to include extensions, compatibility patches, etc.

Would like to note that the logic should not be confined to only "when installing Mod A, (recommend/suggest) C if B is also installed". Suppose the example given above is reversed, so Entropy (A) is already installed, then the user adds RealChute (B) -- it is also appropriate to recommend EntropyRealChute (C) at that juncture.

Want to support this feature with several additional use cases:

---

1. Indicator Lights & Indicator Lights Community Extensions

Indicator Lights uses patches to add its lights to existing parts, comes with configs for stock parts.
IndicatorLights Community Extensions contains patches for parts of other mods, contributed by the community,

e.g. End user has (or about to install) Indicator Lights (A) and MKS (B). Strong recommendation for grabbing IndicatorLights_MKS.cfg (C) from ILCE.

---

2. Connected Living Space configs

• CLS (Mod A) allows specifying behavior of each part via config
• Some part mods (Mods B) bundle their own CLS configs (C) for their own parts
• CLS bundles configs (C) for some part mods (B), but coverage is not exhaustive
  • installing CLS currently includes baggage of extra configs for mods you don't have

2a

With metadata set up properly, CKAN can selectively install from among the configs (C) that are bundled with CLS (A) only when the end user also has the corresponding mods (B) installed.

2b

Where neither CLS (A) nor the part mod (B) provides CLS configs, a third party could create the necessary config (C) and make it available separately.

---

3. Connected Living Space compatibility for parts with dynamic crew capacity

Connected living space needs some special handling in plugin code for parts which can have their crew capacity changed on-the-fly (deployed/inflated/reconfigured/etc).

Stock (Making History inflatable airlock) is supported since KSP 1.4.1, but other mods that use bespoke plugin partmodules for their own parts -- including since before KSP 1.4 -- are not (yet). I am looking to tackle this in the near future.

A: CLS
B: Other mods (e.g. SSPXR, MKS, Pathfinder)
C: small plugins that either ( register themselves with CLS / CLS auto-detects ). Each provides support for respective mod Bs, only installed as needed

This approach would be architecturally speaking the cleanest as it would avoid needing complex reflection-based code in CLS itself to detect whether each mod B is installed on a mod-by-mod basis.

---

4. Upcoming mod adding info panel for EVA kerbals

Forum thread w/ prototype

A: EVA info panel mod
B: other mod (e.g. Kerbal Health provides some health info)
C: extension that pulls Mod B info and packages it into a UI snippet format specified by Mod A.

Result: Mod A autodetects extensions C and includes the snippets of Mod B data in the info panel.

---

5. Mod localization metadata support

Logic can be reused to implement #2113 with slightly different metadata syntax.

It pretty much works if we loosely treat the end user's language selection as "Mod A", the mod being installed as "Mod B", and required localization dictionary file as "Mod C", e.g.:

e.g.
A: installed KSP localization is set to Japanese
B: AirlockPlus selected to be installed (AirlockPlus.X.X.X.zip)
C: in addition to main installation, also grab localization_ja.cfg from (AirlockPlus.localization.X.X.X.zip)

[cake-pie]

More use case

Medical Expansion for WBI [ Forum | GitHub ] is a 3rd party expansion/patches that adds KerbalHealth functionality for Pathfinder parts.

(Due to KSP-CKAN/NetKAN#4296 Pathfinder is not indexed by CKAN, but supposing it were...)

This 3rd party patch would obviously set depends on both KerbalHealth and Pathfinder but this does not highlight itself to end user as "I provide compatibility between these other two mods that do not ship with compatibility with one another by default -- you should consider getting me too".

If we stick to the current syntax (or an extension of it, e.g. the suggestion in OP) then it is required that another mod be the one to make the recommendation / suggestion. But in theory, neither KerbalHealth nor Pathfinder author/maintainer are obliged to endorse this 3rd party patch by setting the relationship their respective netkan.

So we may need some means for a 3rd party mod to at least weak suggest (if not strong recommend) itself on the basis of mods that the player already has installed. Might have to be defined narrowly and somewhat policed to prevent abuse. Perhaps provides-compat-for or something like that.

[HebaruSan]

If the syntax was slightly different, with a general if property with its own object argument:

"recommends": [
    {
        "name": "EntropyRealChute",
        "if": { "installed": [ "RealChute" ] }
    }
]

This would make it easy to add terms, such as negation, to upgrade/downgrade a relationship between recommends and suggests:

"suggests": [
    {
        "name": "EntropyRealChute",
        "if": { "not_installed": [ "RealChute" ] }
    }
]

EDIT: And the identifier arguments probably need to be lists...