-
-
Notifications
You must be signed in to change notification settings - Fork 348
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
Multi-instance support #125
Multi-instance support #125
Conversation
@AlexanderDzhoganov : Travis says no. I don't suppose you can add a commit which fixes that test case, could you? |
@@ -137,20 +185,12 @@ private static string FindGameDir() | |||
return exe_dir; | |||
} | |||
|
|||
// Check the registry, maybe it's there. | |||
string registry_dir = FindGamedirRegistry(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing something here, but we really do want to check the registry first. If the user's configured their default KSP install (ckan config gamedir ...
), we don't want to go using a different one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tested with the cmdline client. It now always finds my steam install, rather than my testing install which is in the registry. And even if I use ckan config gamedir
, it still can't find it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, looks like I broke the command-line client after all. Let me fix this before merging.
Looks like adding a new KSP directory (which has never had a CKAN client see it) causes problems: |
@@ -224,9 +218,9 @@ public void InstallList(List<string> modules, RelationshipResolverOptions option | |||
} | |||
} | |||
|
|||
if (!notCached.Any()) | |||
if (!notCached.Any() && !cached.Any()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait... If not not cached any, and not cached any... Well, not not cached is cached, and not cached is the opposite of that, and they're anded together, so...
This line really needs a comment. I can't tell what it's supposed to be doing or testing for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It tests if both notCached and cached are empty
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So... if we have no modules cached, and no modules not cached, that means... we're installing no modules and hence we do a roll-back? Under what circumstances would we encounter that? When ModList
is empty, which I don't think can happen unless modules
is empty...
So wouldn't be be better of testing one of those variables earlier on, and signalling appropriately if they're empty?
It's late and I'm low on sleep, so I may be missing something here, but that's a typical state for developers, so if it's confusing me now it'll almost certainly confuse someone else (possibly future me) later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, it'd be better to test at the start of the function.
… AutoStartInstance to registry
Let me know if you'd like me to re-review this. I may not get a chance to do so tonight (my apologies), but I hope to do so soon! <3 |
(Today has been a flurry of build crews and plumbers fixing a burst pipe, and has been hectic!) |
I need a few more hours to modify the command line client and we can merge this :) |
else | ||
{ | ||
// auto-start instance specified | ||
if (KSP.AutoStartInstance != null && KSP.AutoStartInstance != "" && KSP.Instances.ContainsKey(KSP.AutoStartInstance)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I didn't realise there was an autostart instance. Perfect!
- Does this check the current working directory for KSP first? We need that for portable installs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It uses the old "find default install" method, so it should work.
Review finished, going through checklist items now. :) |
I responded to some of your comments :) |
Hooray! I super-duper want to get this merged tonight, but I'm occupied right now. Do feel free to make new work on top of this, but if you can make sure it's on a branch that would be grand. :) You rock, and thanks again! <3 |
Ok, here's how I fucked up: What I thought I was doing was making a branch off my master and then merging it back (into my master). What actually happened was that it merged into KSP-CKAN master o.O . I managed to revert it back but this pull request got closed for some reason. |
@AlexanderDzhoganov - Everything is fixable. I've got myself into some weird weird situations with git :) |
@AlexanderDzhoganov : Aah! The PR closed because github saw its commits merge into KSP-CKAN/master. I'll go look at how everything is now, but I don't imagine it'll be more than a few minutes work to put back. :) |
And fixed! It's super easy when you know how! (See #140 on step-by-steps, in case you ever need them!) |
- Split management of multiple instances into KSPManager - No need to manually save or load from registry. - Added GetPreferredInstance() as the best way to find the user's preferred instance, if a single preferred instance exists. - Added PortableDir() to install portable installs. - Decoupled transactional file transactions from KSP class. - KSPPathConstants in their own file - KSPPathUtils in its own file. - Some tests, but not enough, darn it! For KSP-CKAN#125
- Split management of multiple instances into KSPManager - No need to manually save or load from registry. - Added GetPreferredInstance() as the best way to find the user's preferred instance, if a single preferred instance exists. - Added PortableDir() to install portable installs. - Decoupled transactional file transactions from KSP class. - KSPPathConstants in their own file - KSPPathUtils in its own file. - Some tests, but not enough, darn it! For KSP-CKAN#125
- Split management of multiple instances into KSPManager - No need to manually save or load from registry. - Added GetPreferredInstance() as the best way to find the user's preferred instance, if a single preferred instance exists. - Added PortableDir() to install portable installs. - Decoupled transactional file transactions from KSP class. - KSPPathConstants in their own file - KSPPathUtils in its own file. - Some tests, but not enough, darn it! For KSP-CKAN#125
- Split management of multiple instances into KSPManager - No need to manually save or load from registry. - Added GetPreferredInstance() as the best way to find the user's preferred instance, if a single preferred instance exists. - Added PortableDir() to install portable installs. - Decoupled transactional file transactions from KSP class. - KSPPathConstants in their own file - KSPPathUtils in its own file. - Some tests, but not enough, darn it! For KSP-CKAN#125
Only works in the GUI for now, doesn't break the command-line client but the new options are not implemented.
Related to #29