Clone KSP instance per solution

[ProgrammerFailure]

I'm not sure I'm describing this very well, but I'll try.

Background

CKAN now has a feature to perform a shallow clone of a KSP instance that only clones some essential files while performing a directory junction for most others. This saves a large amount of space, and importantly, makes cloning a fairly cheap operation in time/disk space

Suggestion

I suggest that KSPBuildTools have the ability to automatically make a shallow clone of this type in the root folder of a solution directory.

Rationale

I think this would be quite useful, as it would enable making a separate test instance for every solution without massively bloating disk usage. Particularly, if we had an ability to set a specific instance for cloning as default, we could repeatedly clone a stripped down test/dev instance.

Further extension would be to automatically link the "Start" button in Visual Studio to this created clone's executable.

[JonnyOThan]

An interesting idea. At first glance this should probably invoke CKAN's commandline tools instead of trying to reimplement it. At that point, what would KSPBT's responsibilities be?

• Set KSPRoot or whatever is necessary for the mod to build against the cloned instance
• Set up whatever is necessary to wire up your mod's output files to the KSP instance
• Anything else?

One thing I had been rolling around in my head is that KSPBT should be able to set up the symlinks needed for the 2nd bullet above, targeting the KSPRoot instance. So that might be a useful utility and then we could maybe set up another msbuild target or something that does all of the initial setup: restore packages, clone a new instance, install dependencies, wire up symlinks, etc.

Further extension would be to automatically link the "Start" button in Visual Studio to this created clone's executable.

This already works by starting the instance specified in KSPRoot.

[ProgrammerFailure]

At first glance this should probably invoke CKAN's commandline tools instead of trying to reimplement it.

Agree there.

• Anything else?

Compatibility with the already existing CKAN dependency fetching mechanism. So on cloning an instance, it should check to see if all requisite mods are present, if not, then fetch them.

Further extension would be to automatically link the "Start" button in Visual Studio to this created clone's executable.

This already works by starting the instance specified in KSPRoot.

I was not aware of that. Thanks!

[JonnyOThan]

Compatibility with the already existing CKAN dependency fetching mechanism. So on cloning an instance, it should check to see if all requisite mods are present, if not, then fetch them.

I believe there is already a msbuild target that does this.

[drewcassidy]

This would also fix the parallelism issue

What it could do is setup a temp directory per-run and clone gamedata into it, THEN run ckan. CKAN would then not modify the real KSP instance.

[JonnyOThan]

I’m not sure about that. KerbalVR has multiple csproj files in one solution file.

[drewcassidy]

yes, Im imagining it making a dummy gamedata per project not per solution. You could have for example two projects with incompatible sets of dependencies. then an optional setting to revert it to using the global gamedata if you want that (like if you’re using a dependency not from CKAN)