[Feature] Allow blacklisting of particular files under installed mods.

[etmoonshade]

Problem

When installing mods, I sometimes have things I don't want to be installed with them. Whether it's a particular patch for compatibility that's more like combatability, or a mod that bundles other mods that I may not want, there doesn't seem to be a way in CKAN to say I don't want something.

Suggestions

I'd like to see an option somewhere (whether it's in a separate menu, a config file, a right-click menu, or integrated into the bottom-right area with the various tabs, possibly even enabled by an "Advanced Mode" switch) to blacklist a file or folder from being installed when I install a mod.

Sure, I could write a powershell script to remove the ones I find offensive, but that requires running it manually every time I update or pointing Steam to a PS script that starts KSP after it cleans up or something like that. Similarly, I could just remove the files by hand every time I update a mod. It just seems to go against how CKAN is automated for everything else.

Example: KSPI-E bundles InterstellarFuelSwitch, and has MM entries to patch a lot of things when Near Future Electrical is installed. I have custom fuel tanks that I use for KSPI-E fuels and I dislike what the NFE patches do.

Similarly, a bunch of mods bundle ModuleManager, but I just install it separately. Multiple MM .dlls can break stuff from what I've read, so maybe I want to explicitly prevent any other mods from installing the .dll.

I should be able to specify something like the following:

Blacklist
{
  WarpPlugin
  {
    \InterstellarFuelSwitch
    WarpPlugin\Patches\USI_NF_Mode.cfg
  }
  !ModuleManager
  {
    *ModuleManager*.dll
  }
}

This would, in theory:

• Prevent the InterstellarFuelSwitch folder from being installed ONLY from the WarpPlugin mod (I imagine this would be some internal identifier or a GUID instead of "WarpPlugin" - that's just the mod folder's name.)
• Prevent ModuleManager.dll from being installed UNLESS it's being installed explicitly as the ModuleManager mod. The first would match ANY folder under a mod - this would be wise if a mod author stuffed MM in some random subdirectory for some reason (something that actually happened in a previous version of a mod I was looking at...) -- This is probably a pretty specific use case, the first functionality would be far more useful if you had to pick one.

Obviously I'm writing the above in a .cfg format with MM flavoring, but I don't particularly care how it's done - just that it's possible. :)

I considered submitting this as a request to MM and mentioned it on the thread asking if the capability was there, but I feel like there's just too much possibility for bad behavior from mods that think they have a hard incompatibility with something and screwing up a game. It's a kettle of fish that probably shouldn't be opened.

(KSPI-E no longer bundles IFS, but the general idea stands - it used to install GameData\InterstellarFuelSwitch. Lots of mods bundle stuff that might be essential for gameplay the way the author intended, but not necessarily required for basic functionality.)

[DasSkelett]

or a mod that bundles other mods that I may not want, there doesn't seem to be a way in CKAN to say I don't want something. Similarly, a bunch of mods bundle ModuleManager, but I just install it separately. Multiple MM .dlls can break stuff from what I've read, so maybe I want to explicitly prevent any other mods from installing the .dll.

Does this actually happen? CKAN already filters bundled dependencies (or better: we only tell it to install the folder(s) belonging to this mod in the metadata). If you see CKAN installing ModuleManager or other bundled mods together with another mod, this would be incorrect metadata, and please let us know of it (over at NetKAN preferably).

How useful would it be for the other case, to block specific patches you want to supply yourself? Would it actually save some time? You'd have to think of, write, and likely debug this sort of blocklist config for every single file/folder/mod you don't want to have installed. Would this be faster than just clicking on File > Open KSP directory, navigating to the file in GameData and remove it? You likely don't install the same mod daily, do you? More like once every few months or something, if at all. While I like automation, I feel like there the automation would take longer to set up than the task you are trying to automate will ever take, and not even be more convenient.

Like you already said, we'd have to make sure that this feature is somewhat "inaccessible" and hidden, to avoid people not knowing what they do to mess with their installation in CKAN itself. I don't like the idea of "installed with ckan mod not work what do?" comments on forum threads bothering the mod authors, forgetting to mention that they manipulated the installation process to leave out some crucial files.

[etmoonshade]

Does this actually happen? CKAN already filters bundled dependencies (or better: we only tell it to install the folder(s) belonging to this mod in the metadata). If you see CKAN installing ModuleManager or other bundled mods together with another mod, this would be incorrect metadata, and please let us know of it (over at NetKAN preferably).

The MM thing was an example of something that I thought illustrated the general point. I don't think I've actually seen it happen live, and it's kind of neat that CKAN handles that automagically.

To provide some real examples, at the risk of calling mods out:

The CKAN install for Galileo's Planet Pack bundles a couple of mods that are stored under the GPP folder structure; off the cuff, there's something that renames Kerbals, something that changes the textures for them (and the navball,) and something that replaces all the loading screens (including ones from other mods) with stuff for GPP. It looks like TweakChutes is under there too.

Grannus Expansion Pack provides a second install of TweakChutes (again, a mod I don't want.)

Actually, a lot of the planet packs are ones that do stuff I don't want, but they're not the only offenders. Looking through my list, I count five other mods that I've had to blow away parts of (including full .cfg files.) I'm sure I'm missing one or two. Not a huge number, but certainly not insignificant IMO.

I also realize that a lot (all?) of those mods I explicitly mentioned are by Sigma88, and from reading through the other issues (to see if this was suggested before,) I know that's kind of a weird problem in and of itself.

It seems to me that the same code could be used to handle files and folders though (I roughly know how I'd do it in PS, at least,) so at least it shouldn't add extra burden to the code work needed.

How useful would it be for the other case, to block specific patches you want to supply yourself? Would it actually save some time? You'd have to think of, write, and likely debug this sort of blocklist config for every single file/folder/mod you don't want to have installed.

True, but I'd really only have to do it once. And assuming it was a simple interface (key|value like the settings screen for metadata?), I could probably knock out my blacklist in 15 minutes or less once I had the info to generate it.

I'll note that there is technically a third option that I didn't mention, because it'd be a nightmare to maintain - you could make MM patches to revert changes made by other mods. It's doable, but at that point I'd rather hand-delete - I'd end up spending hours every time a mod changes, diffing the configs to make sure my changes are still valid.

Would this be faster than just clicking on File > Open KSP directory, navigating to the file in GameData and remove it? You likely don't install the same mod daily, do you? More like once every few months or something, if at all. While I like automation, I feel like there the automation would take longer to set up than the task you are trying to automate will ever take, and not even be more convenient.

The second one is literally my desktop background at work - I'm well familiar with it, and I was actually thinking last night what column it falls into. I want to say that "sunk cost" is probably 15-30 minutes per mod, but you incur that cost every time a mod updates. If you figure on 10 mods that need modifying in a way that you can't use a MM patch for, and those mods update 3 times per year (that probably averages out, but I have mods with far higher update frequencies,) it puts us at roughly 7.5-15hr/year* after the initial install.

That's surprisingly higher than I thought at first, and puts the 5-year ROI at somewhere around 3 days of work. This does get multiplied across a lot of people who may want to use the functionality, and it's hard to tell how much time it would save for them unless they start commenting here. Whether it's worth the trouble is really up to whoever is twiddling the bits to get it done though.

That 15-30 minute figure includes a couple of things that aren't immediately obvious, like how long it takes me to load my heavily-modded KSP (often multiple times because I forgot something) and looking through each patch to find the one that does what I don't like. And of course, realizing that a particular mod does something dodgy in the first place, although you can probably bake at least part of that time into general usage.

And then there's the fact that time spent on figuring out mod issues is time not spent playing KSP. You can't put a time figure on that. ;)

It's actually more of a problem now that I'm using CKAN - in the past I've basically played through KSP unpatched after the initial install (since it takes a day or two to go through the manual download process for everything,) so I really only had to do it once in a while. Now, with CKAN, I see every single update that's released (off the cuff, I'd say I've had 10 updates out of the 146 mods I have installed currently, in the 2 days I've had CKAN running. Yes, I only just started using CKAN... and here I am already making work for y'all ;p)

Like you already said, we'd have to make sure that this feature is somewhat "inaccessible" and hidden, to avoid people not knowing what they do to mess with their installation in CKAN itself. I don't like the idea of "installed with ckan mod not work what do?" comments on forum threads bothering the mod authors, forgetting to mention that they manipulated the installation process to leave out some crucial files.

This is definitely what I expected the main objection to be, and why I suggested a bunch of options for how to allow this functionality. When I ended up discussing this on the forums, I believe I said "if it's too easy to get to, it'll be just another thing blamed on CKAN." I don't do dev, but I do do systems, so I'm obviously sympathetic to the "everything gets blamed on me" thing.

• 10 mods x 15 minutes x 3 updates = 450 minutes.

[HebaruSan]

This reminds me a bit of #2490, which proposed to prevent MiniAVC from being installed with some kind of global filter (or the later comments said that).

You likely don't install the same mod daily, do you?

Upgrades, I guess? Delete a file in the current release, upgrade the mod, it's probably back. A persistent filter would be more... what do ops people say about containers, "repeatable"?

[etmoonshade]

This reminds me a bit of #2490, which proposed to prevent MiniAVC from being installed with some kind of global filter (or the later comments said that).

I could see that being a use case too, and it's probably a better example since it's easily removable and (as far as I know) has to be in the individual mod folder.

You likely don't install the same mod daily, do you?

Upgrades, I guess? Delete a file in the current release, upgrade the mod, it's probably back. A persistent filter would be more... what do ops people say about containers, "repeatable"?

Pretty much this, and put a lot more succinctly than I did. :grin:

[HebaruSan]

Should this be instance-specific? I.e., if I want to exclude a file in a particular instance, am I likely to want to exclude it from all of my instances?

[etmoonshade]

Should this be instance-specific? I.e., if I want to exclude a file in a particular instance, am I likely to want to exclude it from all of my instances?

I think it should be - or based on the issue you linked, perhaps an option for instance-specific vs. universal.

With the MiniAVC example, yeah - I probably don't want to deal with it at all. In my use cases though, I may not want/need to block certain files/mods from being installed on all installs.

Example: Nertea's Cryogenic Engines requires Cryogenic Tanks. I have KSPI-E and a custom Procedural Parts mod. I may want to suppress the parts/configs/etc. of Cryogenic Tanks from being used*, because I have something that covers it already. But I may be playing another install that doesn't include my custom procedural parts and/or KSPI-E for some reason - in that case, I need those tanks.

* Note, this is a workaround for an entirely separate problem I've run into on occasion - not being able to break "hard" dependencies like this. As long as I only have to do it once per install though, this is an acceptable workaround in my opinion.

[HebaruSan]

KSPI-E no longer bundles IFS, but the general idea stands - it used to install GameData\InterstellarFuelSwitch

I just checked this, and the only folders CKAN has ever installed from this mod are WarpPlugin and InterstellarHybridRocketry (since removed). I assume there was bundling at one point, but CKAN would have been ignoring that.

• https://github.com/KSP-CKAN/CKAN-meta/tree/master/KSPInterstellarExtended