Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple KSP installs. #29

Closed
pjf opened this issue Oct 4, 2014 · 3 comments
Closed

Support multiple KSP installs. #29

pjf opened this issue Oct 4, 2014 · 3 comments
Assignees
Labels
Enhancement New features or functionality

Comments

@pjf
Copy link
Member

pjf commented Oct 4, 2014

(Text mostly taken from @Wizarth in #23)

It's a common use case for modders to have multiple installations/copies of KSP.
I suggest a per-user index of installs. This is enough data to point one instance of
CKAN to different installs of KSP, each with it's own per-install data store.

We can safely assume any install folder will be writable by CKAN (or else how would we
install mods).

ckan list-installs
ckan add-install name path/to/install
ckan modify-install name changed/path/to/install
ckan remove-install name

This then allows users to specify which install they want to operate against. If one is not
specified, assume special case default.

ckan --ksp=0.24_IQ list

As per #28, if no installs defined, CKAN should attempt to automatically detect default. (E.G. Steam).
If not possible to detect, user should be prompted to define default install.

Install data should be stored in the Windows/Mono registry, since we can't access (or even create) the CKAN registry until we know which install we're dealing with.

Currently being worked upon by @Wizarth, unless he claims otherwise. ;)

@pjf pjf added the Enhancement New features or functionality label Oct 4, 2014
@pjf pjf added this to the Advanced Features. milestone Oct 4, 2014
@pjf pjf added the ★☆☆ label Oct 21, 2014
@AlexanderDzhoganov AlexanderDzhoganov added In progress We're still working on this and removed ★☆☆ labels Oct 21, 2014
@AlexanderDzhoganov
Copy link
Member

This has been implemented for both cmdline and GUI in #125, closing issue.

@AlexanderDzhoganov AlexanderDzhoganov removed the In progress We're still working on this label Oct 22, 2014
@pjf
Copy link
Member Author

pjf commented Oct 22, 2014

For what it's worth, the coolest way to close issues is to simply have "closes #29" in a git commit. When that merges to master, it will close the issue automatically. It's super cool, because it means that when a branch it merged it closes all the issues it solves, and when a branch is pending merge you can still see where the commits that that are needed for issue resolution. It's one of my favourite workflows ever. :)

@AlexanderDzhoganov
Copy link
Member

Makes sense, I will do this from now on :)

RichardLake pushed a commit to RichardLake/CKAN that referenced this issue May 30, 2015
RichardLake pushed a commit to RichardLake/CKAN that referenced this issue May 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New features or functionality
Projects
None yet
Development

No branches or pull requests

2 participants