RoverDude

Yep I do a lot of spin stabilization even with stock aero early career

I hear it's going to be pretty cool...

I'd add - probably the best way to view UKS (USI Kolonization Systems) is that it's not a parts pack, it's a gameplay mod. i.e. even if all of the parts were white cylinders, the gameplay elements stand on their own. Also - don't confuse complexity with depth Most folks who get lost in UKS do so because they are trying to make a self-sufficient long term colony in a single launch or in one throw of the dice. The mod strongly encourages pre-staging of infrastructure, small steps, and a more long term gameplay approach. i.e. for your first base, you don't even need to use any of the new resourses - just drop in some hab modules and supplies, then start working slowly towards extending your stay, all the way up to making your bases relatively self sufficient (in my experience, VERY few bases actually need to use every single module UKS has - in most cases unless you want to be there for decades - it makes more sense to just send supply runs).

Just pop open the USI-LS UI from the space center - configs are only defaults. Also remember the numbers are large because they assume Gemini level tech (no recyclers!)

If you posted it before the 1.1.3 drop then yep I did a compilation right when release hit, and pulled in the PRs

Conflict with NFE. If there's still an NFE config file in the ReactorPack folder below UmbraSpaceIndustries, delete it. If the configs are coming from NFE now (which they will be going forward, @Nertea would know), then report it there so they can sort it

I make a few colonization mods

Many suggestions to help sort this have already been voiced on the CKAN threads on Github. And for some modders, saying 'Sorry, not on CKAN - read the readme and install manually' will be a better support option (whether temporarily or permanently). Fortunately, that's now supported since being listed in CKAN is not compulsory. (Some small edits for clarity)

Because when we do not provide support in the thread, we get complaints, insults, and vitrol from the users about our 'crap'. Heck, the hate mail and abuse I got from choosing not to do exhaustive documentation is just a small slice of that. So if by 'get on with enjoying your life' means having to wade through a lot of really angry people, then it kinda kills the fun. Add to that, someone has to sort out how to train said users. And even once trained (I am pretty lucky in my threads that most of the users support eachother at this point), it still clogs the thread with repeat issues, etc. (including having things on the tracker). @Hevak was 100% correct by the way, @blu3wolf . CKAN releated install issues have far exceeded the workload for traditional install issues in my threads. It's just that CKAN tends to blow up right after a major release, or when something would suddenly break. With my own metadata, that number is down, but I would still greatly prefer to deal with manual installs and teach people how to fish. Regarding @sarbian and Module Manager's takedown. Let's remember. We had a working deal. it was squashed. ModuleManager got pulled. All of a sudden, we had our deal again. Let this sink in a bit. I have maintained, and will continue to maintain, that when both parties have skin in the game, and when either party has the power of walking away, you're going to have a strong incentive to cooperate. Which is why we're here now. And this is good. Because the alternative would have been some pretty aggressive defensive coding. I for one prefer a situation where both parties choose to be involved, and both parties have a say, so that we can sort out the root issues without either party being an involuntary participant. If anything, this situation and what it took to get here has shown the importance of open dialog and voluntary participation in making these things work.

Pilot error. You did turn on RCS/SAS once you were in water correct?

Should be fine with EL last I checked? What issue are you seeing?

Agreed. Thanks. Feel free to ping me off line, I have some thoughts on how to make this happen without it breaking down what we've spent the past few days trying to sort.

Not quite. The official CKAN repo is a sticky. It's a matter of visibility and ease of access. Given that advanced users can still generate their own repos, by all means let them do it. But not, IMO, as a part of the official project, otherwise (as noted) we're going to land in the exact same spot we are now - a public repo managed by the CKAN project where modders cannot opt out, and the new answer is 'well, I'll just use the unsupported repo'. And of course, they are most definitely not going to admit to it, or plead ignorance 'But I used CKAN...?'. Are rogue repos a possibility? Sure. Will users make their own metadata and pass it around? No doubt. Should it be something sanctioned and included in an official repo maintained by the CKAN project? IMO no. It would be a shame to go through all of this hassle, all of the de-listing, etc. just to have the entire thing conveniently circumvented by an alternate (official) repo.

Looks like pjf has weighed in, and it is looking good. "In some cases it's not possible to install mods via the CKAN and maintain the goodwill of the author(s). The CKAN will not install any mod when the primary maintainer (or a significant group of maintainers when no primary is identifiable) requests the mod be removed from the CKAN. " Still some details to work out, but I'm happy with the result. I think we're in a great position to get this all sorted

Incorrect, maybe read the rest of the post. At the moment we're attempting to sort out a workable deal. And provided nobody shoves another broom into the bike wheels, it will be sorted soon enough.

We bring all of the content...

I agree with a staging and an official repo as @TeddyDD has stated. I do not agree with any official repo where 'unsupported' mods are - because all this does is push us right back into the current issues when all of the users scramble over there right after a new release drops. And we've seen how well that has worked out for us. Ultimately, cleaning CKAN and filling it with stuff that is supported, has an official maintainer, and has facilities for proper pre-testing is just going to help everyone, and also mitigate a huge amount of the animosity there. One official repo - one staging repo. Dedicated maintainers for a mod, ideally the mod author. If not, a volunteer approved by and working with the author. Let us actually use staging ourselves to test our stuff out before it gets pushed to official. This means users are going to have to wait a few days sometimes after a major update (or longer if there are dependencies, since there is going to be a long testing chain). And this is ok, if it acts as a massive filter to a lot of the issues. It's also undone by any kind of 'experimental' or 'unsupported' repo. Let's not do a repeat of what got us here. Opt-Out (for all) of course needs to always be an option. Case in point - having the power of opt-out ensures there's motivation for a conversation (again, the case in point being that it took all of this, and the loss of Module Manager to get to an actual discussion). All of this is moot until we hear @pjf weigh in. I (and I expect the rest of the modders) would like to make sure that this policy is going to actually stick, and not be rolled back. And once in place, we need to agree that this particular part of the policy needs to be irrevocable. I am not familiar with the CKAN team structure, but maybe @TeddyDD or @politas can help clarify the process, and let us know how we can best ensure the opt-out policy currently in place remains so that we can get back to focusing on more important issues, instead of waiting for the rug to be pulled out from under us. This is not productive. Especially when a lot of us are trying to sort this. You are not helping right now.

Just because I don't want an automated tool that will redistribute and incorrectly install my content (sometimes without my knowledge) does not mean I don't want said content available for users that want to use it. It is not an all or nothing, and some of us would like the courtesy of being allowed a choice. Now. Imagine the hue and cry if Curse scraped the forum for all redistributable content (and refused to allow the original content creator to remove the listing, even if it was out of date and was causing user issues).

FYI - I 100% support this pull request. https://github.com/KSP-CKAN/CKAN/commit/c6ec1e887c51fd7f88d1b5335b4ab2b5aecdabf8

Yet the discussion here is not a legal one. Legally, even an ARR license can't stop CKAN from doing what it is doing. There's not much dispute there. The oddity is that they are very selectively allowing de-listings, and even the change to restrict de-listings didn't exist when CKAN was launched, and was likely put in place to prevent certain mods from being allowed to leave. Legally, nobody is disputing their position (they could even legally be more draconian). Morally, it's both wrong, and inconsistent.

What CKAN has at the moment is a courtesy issue not a license one. Let's see if this PR gets merged. https://github.com/KSP-CKAN/CKAN/commit/c6ec1e887c51fd7f88d1b5335b4ab2b5aecdabf8

Fair enough On the one hand, I hope that now that there are conversations taking place, they continue to move in a direction that fosters equal cooperation, and equal skin in the game. Like @ferram4, I regret that it took several licensing 'tactical nukes' to make this happen, but I am hopeful we can land in a decent place. The pull request from @politas was a very good one, and sorts a key issue, which means focus can move on to the best way to support issues that do arise.

@drhay53 - the compromise (one that was proposed, and seemed on the verge of being accepted until everything went south) was based on CKAN respecting modder's wishes regarding listing. As I stated before. There are issues. Issues we can solve with a conversation. But when a request as simple as 'well, I would not like this mod on CKAN please' is stonewalled, and the only recourse is to express intent through a license file while ignoring a direct request (despite the issue not being a license one), then that's a problem. Now. Maybe the CKAN folks will come around so we can get back to sorting the reason *why* someone would want to de-index a mod (either temporarily or permanently). There have already been some good proposals - staging areas, better tools, etc. - but when one side has absolutely zero motivation to pursue change, and the other side is essentially held captive, you're not going to have a healthy conversation. For me personally, a change in CKAN policy will mean I will immediately re-list the mods I have that are ready for distribution. And in time, some may be de-indexed as they are consolidated or retired, temporarily pulled down while I move bits around, or just left online in their stable state. And if there's a major problem, I'll be confident that there will be more enthusiasm for resolving issues precisely because the policies will encourage working through issues (either party can step away) vs. ignoring or downplaying them (you will participate whether you like it or not, and you will like it).

Go for it, I'll be doing a release - especially for the modders who need access to it.

Aso RE examples, I think @ferram4 has already covered this, and @Angel-125 had his share. My own mods were a train wreck after I built USI-Core, and that was the incident that forced me to start doing my own metadata. There are issues. Resolving issues takes communication. But communication that starts off with a blatant disregard for the wishes of content creators (and this is a courtesy issue, not a legal one), is not going to end well.