Scatterer and EVE dependencies restructure for modularity with Planet Packs

[Poodmund]

Scatterer and Environmental Visual Enhancements currently require a choice of configs for the stock planetary system as dependencies when the main plugin is selected for download rather than as suggested choices.

The fact that the main plugins cannot be downloaded via CKAN without config downloads being required will cause some issues when visual mod packs become available for planet packs i.e. OPM or GPP etc.

I am proposing that for Scattterer's NetKAN file the following change is made:

Existing:

"depends": [
        { "name": "Scatterer-sunflare" },
        { "name": "Scatterer-config" }
    ],

is changed to:

"suggests": [
        { "name": "Scatterer-sunflare" },
        { "name": "Scatterer-config" }
    ],

With the same going for EVE:

"depends": [
        { "name": "EnvironmentalVisualEnhancements-Config" }
    ],

to the new:

"suggests": [
        { "name": "EnvironmentalVisualEnhancements-Config" }
    ],

This will allow the user to download the plugins without being forced to download configs.

This brings about another change I think would then also be necessary if the above is considered. Rather than the virtual Scatterer-config and EnvironmentalVisualEnhancements-Config "mods" referencing the visual packs, I think that they should instead reference a sub-set of virtual listings that refer to the individual planet packs in question that then go onto to list the existing configs. For example:

Scatterer
	Suggests Scatterer-config
		Suggests Scatterer-stock
			Scatterer-config - provides Scatterer-stock
			SVE-Scatterer-Config - Scatterer-stock
		Suggests Scatterer-OPM
			PoodsOPMVO - prodvides Scatterer-OPM
		Suggests Scatterer-GPP
			GPP-scatterer-config - provides Scatterer-GPP

^ as a constructed example of the nesting/parent-child relationship.

This way is gives true modularity to the scatterer and EVE plugins to allow the user to download visual configs mods/packs for installs where they do not wish to have those visual mods/packs for the stock system.

I hope that this is making sense. I would like your feedback and discussion on this issue as I appreciate it would take quite an effort to restructure the NetKAN data but I feel it would benefit the user base.

These is another resent issue regarding the same two plugins here that may be relevant to this issue: KSP-CKAN/CKAN#2026

[politas]

The danger is that a naive user wishing to install Scatterer or Environmental Visual Enhancements will end up with no config for them. Making them non-exclusive suggestions would certainly avoid a lot of the problems people get when installing them, though.

I like the idea of planet-pack based virtual mods to use for conflicts, especially since I believe there's a mod that allows multiple planet packs to be used to make an interstellar constellation (though that project may have died since I first saw it)

[Poodmund]

I was just thinking about this issue when I tested installing Outer Planets Mod - Visual Overhaul as the only selected mod on a clean KSP install and there was no way I could do it without downloading either Default EVE configs, default scatterer configs or SVE. I just thought that this was maybe an oversight and that there may be a cleaner way of handling it, that's why I suggested that rather than 'depends' that 'suggests' be used.

Upon further thought, we are thinking about hosting Galileo's Planet Pack on CKAN in which the above behavior would be a critical issue unless GPP specific config variants were provided... but these would be listed beside the stock system configs when the user is granted the list to select from even if they weren't usin GPP.

Can you see where I'm going with this? I believe resolving this issue in a Planet Pack or System oriented way would be quite effective but would mean retroactively changing the NetKAN data for the current setup. :/

[politas]

Yes, the current setup is not going to work with a Galileo Planet Pack Visual Enhancements pack. What is the result if someone installs Scatterer and/or EVE without a config pack? Will it cause a crash, or some kind of glitches? It's hard for us at CKAN to push mod development in a way that makes for easy modularity, much as we might like to. There are too many mod devs who just don't see the value in the CKAN.

I have no problem with changing the Netkan data. To reduce problems, we can do an epoch bump on affected mods to force an upgrade.If you're willing to assist with the metadata design, I'd be very happy to work it out. It's been quite hard to sort it out without a deep understanding of the mod internals.

I think if we had each config pack provide two virtual mods, a *-config and a *-config-<PP>, and have a conflicts on the *-config-<pp>, we could keep the plugin mods depending on *-config, and the minimal amount of changes would be required. CKAN would force you to install at least one config pack, but would not prevent you installing further ones, and the planet packs could recommend their respective *-config-<PP> virtual mod. I think that would work. I don't think we have any examples of a mod recommending a virtual mod, though, so I'm not immediately sure how the program would handle that, though it should work.

[Poodmund]

That all seems pretty reasonable and logical. What would be the best way to go about mocking up some NetKAN data for review or testing, create a branch somewhere?

On the note of EVE and Scatterer being installed without configs, there is no issue and the plugins are only invoked if there are configs present.

[politas]

A branch will let us mock up netkan for testing easily enough, that's how we do all Netkan updates. Getting the resulting mocked up .ckan files into the client is a little trickier.

@techman83, can we use the staging process in this way, somehow?

[Poodmund]

Whats the starting process to get this ball rolling, should I make a branch of NetKAN and start rewriting the metadata for review?

[politas]

Yes. Make a branch, edit the netkans as your understanding of the how things should change goes, then make a PR based on that branch to the main, and we can discuss on that PR.

[HebaruSan]

EVE and Scatterer both seem to be working fine lately, possibly because, as we discovered the hard way, many authors have started configuring them with ModuleManager instead of replacing files, which is a lot more maintainable.