Migrate mods to different KSP installation

[Hexicube]

This is a potentially complicated feature request, but I feel it will be invaluable for the ease of use it can provide. In the simplest form, it would function like this:

• User adds the location of a second KSP installation normally, which should be mod free
• User goes back to their modded installation and presses a "Migrate" button
• User specifies the newly added second KSP installation as the target
• A warning will show if any mod is detected that is not in the modded installation, asking for it's removal or allowing the user to press on
• CKAN will check every single mod for compatibility with the target version
• If all mods share a "major KSP version" (see below for method of calculating) but have a differing "minor KSP version", allow a forced migration
• If mods do not share a "major KSP version", prevent the migration completely (or give a more prominent warning)
• Allow choosing what mods to migrate in the event that KSP versions do not match, so the user can resolve issues
• Ask the user if they don't want any mods moved over
• Start migrating mods to the new install area
• Switch over to the new install area

An important thing to note from step 4 is that it will only complain if mods exist that are not in the pack being migrated. This means you can migrate again later on, to add in any missing mods that weren't up to date the first time.

I have two possible methods for splitting the version into a major and minor segment, which can be used together:

• The first 2 numbers are major (overrides the one below if the number count is below 3)
• The last number is minor (if comparing two, the shorter one determines the last number and the longer one has multiple numbers)

This would effectively remove a lot of effort for the user when the KSP version changes. Instead of manually selecting every mod they had and having to remember what mods they still need when some fail, they can simply press a button and select the new KSP install and the work is done for them. They can still tweak it after the migration, and can go ahead with missing mods if they desire, but they save time looking through lists and adding mods one by one and have all the information broke down for them.

This isn't required immediately, but would be very useful to have for when 1.1 comes out and mods start moving over.

[Dazpoet]

What would be the major benefits of this method rather than the current one where you export the metapackage file, switch over to the new installation and install from said file there and grab all relevant mods? Not saying both cannot co-exist but trying to understand the pros and cons of each method clearer :)

[Hexicube]

Primarily ease of use, and not needing to save the metapackage anywhere. I was also under the impression the metapackage would enforce the same KSP version.

The only con I can see is the work being put in to make it work. It probably ends up working like metapackage importing, but is simpler to use.

[politas]

There's also an issue with metapackage migration if some mods are unavailable for the KSP version you're migrating to, which means the entire metapackage fails. Could we make a metapackage creation option that uses "Recommends" rather than "Depends"?

[tehbeard]

@Dazpoet I came here looking to make a ticket after trying the metapackage export / import trick.

Even if the mod has a version for the KSP you are installing into, it does not seem to install unless the version matches that in the index.

For instance, I just tried and got this message:

Module KIS required, but not listed in index, or not available for your version of KSP

Error!

Now, there is KIS 1.2.3 Listed in CKAN, but the metapackage file has 1.2.2 listed. Changing the metapackage to that version fixes it, and tells me the next package I need to fix the reference of.

An option during import (or perhaps a new menu item) that just looks at package identifiers and not versions would solve the problem for the most part.

[mheguy]

@tehbeard that already exists. When exporting your metadata list you can change "save as type" to "CKAN favourite list". The latter is exactly what you're looking for, no hard version dependencies.

And yes, it's nearly impossible to know that without being an "insider". I've been thinking about how we can make metapackages better overall for users.