ferram4

@Ixenzo: No, that's called, "stock launch clamps jump for no apparent reason." It happens in the stock game, it's more noticeable in RSS. I'm constantly told that it's a KJR bug despite the fact that the joint holding the clamp in place isn't affected by KJR at all, making it some kind of a stock bug that I likely cannot fix. Sorry. @Tiberius K: No idea, craft file? And there's a new KJR that will help with stations wagging themselves apart a bit.

@Vegetal: If I find anything else to try and fix, I'll look into it. It doesn't make any sense that these things happen. Anyway, FAR v0.15.7.1 "Kutta" is out with slight fixes to voxel asymmetry, bundling MFI 1.1.6 to fix the Kopernicus issue and a change to the license. All art assets and shaders are now licensed ARR, everything else is GPL V3, as it was before.

@Vegetal: I did some testing and did fix some asymmetry bugs, but those didn't fix the extent of your craft's unevenness. Turns out that the vertical tail really is just angled a fraction of a degree off center, with the leading edge a tiny bit further to the left than the trailing edge is. Swap this for your FAR dll, grab the rotation gizmo in the editor, hit F to switch it to absolute mode, turn on angle snap, select the vertical tail and click on any of the rotation rings to get it to snap and then try it and see if it works. Once that's done I'll push a new FAR version bundling the new MFI and those fixes.

Thanks to discussions with @politas, @pjf, @TeddyDD and the rest of the CKAN crew my biggest objection to CKAN is now resolved, and so CKAN installs of FAR are now supported again. [insert rejoicing] As of this writing (June 27, 2016) the debugging and diagnostic tools that I hope CKAN to have soon have not been created yet, so I will not be able to easily tell if it is a CKAN metadata issue solely from logs. If after providing debug logs and repro steps I still can't create your issue, please try a manual install if you haven't already to see if it was a CKAN metadata issue. If that fixes it, the issue is possibly CKAN-related in some way, and the CKAN guys would like to hear about it in their thread or their github so they can investigate. @Vegetal: Sorry about the delay, I'll get to looking at that soon. Things have been happening, as you might have guessed from above.

It came off as an insult given that I've always been extremely forward about my reasons for releasing and it was phrased as if I haven't been. It comes up every time someone asks about why modders release things. Acting as if I'm not completely honest about it is just... what? Anyway, good on you trying to take a stand. I don't have high hopes though.

CKAN users are, in my experience, not a group that provides valuable bug reports compared to manual users. I say this as someone who had a lot of manual users before CKAN existed who were a lot more useful. CKAN users introduction has not improved the SNR because I had a better SNR before CKAN existed. Despite CKAN supporters insistence to the contrary, CKAN is a net increase in support workload for me that I don't benefit from. I really don't know why you guys keep insisting that it's a good thing for me when I had the only install errors that happened prior to CKAN existing sorted and CKAN has only added new and exciting ways for it to fail. So much for that. And ultimately, this distracts from the problem which is: even if CKAN was a great and wonderful improvement to my support workload (hah) I have no recourse in dealing with them on the support issues they do cause because they lack incentive to address the issues. Because they would like to try and turn a courtesy issue into a legality issue only.

And like @RoverDude, if CKAN policy changes, CKAN installs will be supported again for FAR and my other mods, and I'll work with them, because I am assured to know that they have reason to be responsive without requiring the threat of license changes and full-on de-listing to even get a conversation started as we have right now.

In other words, CKAN should not introduce bugs beyond the ones that exist in the package itself. It should not be a less effective means of installing mods than following manual instructions. Unreasonable? From the perspective of a CKAN author or a user, absolutely. From the perspective of someone who has had to deal with these issues with no recourse, the only responses being, "you know, there wouldn't be problems if you fixed the metadata for us" or "you can just change your license" and hope that there are no hostile forks and the support requests don't come to me, this isn't so unreasonable. The only way for support to be as low as before CKAN was introduced is for it to be perfect, especially considering it has the large deficit to make up every time it does fail and the install issues are compounded well beyond what a single user could ever hope to do. Were there more courtesy involved in handling CKAN issues, it wouldn't be necessary for my attitude to be that CKAN basically not exist from my perspective. Consider how many of these issues would be fixed by a staging repo. Or auditing metadata every time a NetKAN is inflated. Or having human eyes check problems that show up. None of these are done currently, and it's been nearly a year since CKAN first showed that it has serious metadata issues. Maybe when this is all over there can be a far more amicable agreement, like we almost had yesterday. Pretty sure I tried that once and it didn't get users to add issues to the github. Turns out that users take the path of least resistance. Probably got removed when I made the link to the CKAN support thread and was cleaning things up in the OP. I still get pretty much the same number of actual github issues as opposed to forum post issues as before so nothing has changed. Funny that. And none of the demands have been about getting rid of CKAN. CKAN is quite fine existing so long as it causes minimal issues and provides some courtesy wrt modders when it does cause issues.

@genbrien: Found that and got it sorted; some code I thought was firing wasn't. Until the next release, do the workaround you identified. @Vegetal: Hrm... I don't think that small asym error would cause a massive issue. It might create some slightly-off-center forces, but I doubt it would be really noticeable unless something else was off. I'll investigate; mind sending me the craft file so I can be absolutely sure of what's going on?

And I'll note that in the latest CKAN issue there were people arguing that they had no obligation to de-list ARR either. Which is concerning if CKAN ever decides they should go for that option. Yes, a good mod manager would prevent my minor error there. However, at the same time that error is not fixed unless MFI 1.1.5 is distributed. FAR bundles MFI 1.1.4. CKAN (as of this moment) doesn't distribute anything newer than MFI 1.1.3. This is the exact thing we're complaining about in terms of support issues.

And here's a nice long #ckan log to be complete. Statement doesn't seem to have too much context, tbh, simply being at the end. It is nice to read explicit statement of what I suspected for a long time though: the sticking point is FAR. The entire reason is to keep RO being installable through CKAN regardless of the support issues it causes. Edit: Actually, I think it's kinda funny that you think calling me selfish is an insult @politas. I've always been rather transparent about the fact that I only release my mods for the sake of feedback and bug reports to make it better; I'd have thought that the selfishness would be quite clear.

I did not create the logo, an artist created it for me a long, long time ago. The descriptions are pretty short all things considered, not at all what I would expect from someone trying to get users. I have not created any videos about my mods. I merely link some useful ones that other people have made. The wiki is a very, very poor attempt to get users to shut up about questions over features that I implemented for me. It's a support-reducing measure. The donate button is only there because enough people asked that I bothered. These actions are consistent with wanting a small, manageable userbase for feedback and bug reports so I can better improve my experience. The type of userbase that CKAN tries to bury with it's lowest-common-denominator flood. I see no reason why I would want CKAN to create that mess for me, and one of the many complaints wrt CKAN is that its supporters and anyone trying to mediate always tries to sell CKAN bringing in more users as a good thing for modders to the same modders that don't want those users.

He may not be, but I am. And I agree pretty much completely with exactly what he said.

@Ilya: I have tested all stock panels on the pad and each of them produces a electricity. I need full reproduction steps and a copy of the log.

That would be ideal, and FAR already has a github and uses its bugtracker. The problem is that getting users to use that is like herding cats, and I barely get enough useful bug reports as it is.

They say this every time. They also ignore the policy issues that cause this every time. Remember, a year's worth of inaction. Because that method doesn't work simply due to the volume of complaints. If you had seen the FAR thread during the huge disaster CKAN created for v0.15 you would have seen crucial, valuable bug reports simply buried under floods of CKAN-related complaints. The signal-to-noise ratio becomes terrible, hinders support for the users that aren't relying on broken CKAN, and risks issues just not being solved because they're buried entirely. And that's before we get to the people who lie about installing manually, just as they lied about using win32 rather than win64. Why? Because it is a way to improve the signal-to-noise ratio. The goal is to make my projects perfect; a streamlined and clear support system is needed for that; CKAN interferes with that by adding unnecessary noise. Only if it's that absolutely terrible. Hell, if CKAN had started with that method, considering that it had support from a few modders starting out it would have been far better than just starting as a barren wasteland. And if your argument really comes down to, "I need to do these things that will cause strife for other people in order for my project to work" then maybe you shouldn't create that project. That's simple; none of these places ever have install instructions, and manual installs are so mindlessly easy that it's hard to screw up. Of the only type of install error that's commonly possible with manual installs, my plugins load sufficiently that I can use the game to provide correction instructions to the user during loading so they can stop loading the game and fix it. Only CKAN screws things up beyond the point that any code I put in a mod can recover. And also see above; to improve the signal-to-noise ratio. Because users can't spend the time reading the FAQ in the forum post but can spend their time making a post asking about it and burying useful bug reports under dozens (at least) of complaints. As noted above, if you have seen or had to deal with the signal-to-noise ratio, you will understand. The sheer scale of issues is one of the big ways that CKAN screws up in its worst moments. And yet, I have tried to avoid doing that with CKAN. As I tried to avoid doing that with win64 for an entire KSP update before it became too much and the crashes got worse. And as I did with CompatibilityChecker only providing warnings rather than locking down the mods. Each time I have been exceedingly patient, and in the case of CKAN far, far more patient than I was with the other ones. I dislike nuclear options, but sadly every time one of these things comes up it ends up being necessary. Because they bury valuable support, and then they get defended by all the users that claim to appreciate us while demanding we put in more work, have a poorer signal-to-noise ratio and end up with buggier mods as a result. We are trying to manage our time and make things easier for us to support and fix our mods. Stop making things harder.

And now, FAR v0.15.7 "Küchemann" is out, with 1.1.3 compatibility and a few bugfixes and voxel optimizations. Also a fix for a possible race condition that might have been hitting some people.

When it changes from mere words to policy changes and procedure changes to address the issues. Not the object-level "X mod was installed wrong" issue, but the issues that allow inaccurate metadata to be added and for any kinds of install errors to occur. This has not been done. And if users came to me and pointed to my source code and told me how that caused a bug, I'd be able to fix it quickly too. I don't demand that though, because it's completely unreasonable; I work with the bug reports I get. I merely forward the complaints that I get from users that things don't install correctly, in a system that I don't want anything to do with and don't understand, and then I'm berated for not offering up the fix myself. If I tried to pull this on my users they would flip out (and justifiably so). Right now? Dunno, issues seem to come and go. Even when it is, what safeguards does CKAN have in place to prevent issues from occurring? Oh, and since I missed this the first time: Alright, so here's what you do. This is actually probably the ideal kind of first plugin to write because it's so simple: Even with my problems with CKAN, I really don't want that method. Besides to issues with throwing rules around like that (honestly, I really don't like externally imposed rules in general), there isn't a very good way to implement that. If the rule is made too narrow, it will be easily circumvented by CKAN (say, by manually changing the repo to a different one). If it's made too broad, then CKAN has no option out (say, if the rule bans the option for it to change to a repo that indexes things regardless of modder discrestion). It also opens up the issue of drama based on forking mods with open licenses regardless of a modder's personal wishes wrt that particular fork. That should always be allowed, even if the unnecessary / hostile forker should be condemned and their actions frowned upon. It also opens people trying to maintain a open source mod whose author has gone AWOL to unnecessary and unjust flak. And to end it all, it would be hypocritical. The main issue is that modders are getting forced into dealing with CKAN with virtually no non-nuclear-option recourse, resulting in severe animosity. Forcing CKAN into bending the knee would result in the same animosity on the side of CKAN contributors and users.

@Kobymaru: And yet, is any of it untrue? If CKAN contributors decide not to do anything about issues reported, what recourse does a mod author really have? What direct, measurable consequences will there be for CKAN under those circumstances? The only options right now are to abandon the mod or go to war and try to sabotage CKAN. We want an opt-in only method for CKAN so that we don't have to go that far. As for being evil, I don't believe that. I just believe that they don't particularly care. Considering that the issue that turned me completely against CKAN happened over a year ago now, it's pretty obvious they don't put priority towards fixing their issues. Uh... the fact that they can thumb their noses at modders without consequence? The same thing I have been complaining about here? When you modify those tools to get around steps that modders take to reduce their support workload and then share that with other people so as to sabotage those attempts, you are not a responsible adult; you are a jackass making modding harder for us. And yet, what other options do I have? I keep asking for less drastic measures, and CKAN contributors and supporters keep telling me that isn't acceptable. I don't take their existence as an insult; I do take the insinuation that the "good word on my mod" or that reaching any kind of wider audience should be a mitigating factor as one though. I don't care about having more users, I care about having a manageable and useful support and feedback system. CKAN does not provide that. That would be far easier to defend if CKAN did not introduce install errors galore. The demands are not based in legality, but in a demand for some courtesy for once and an acknowledgement that you do create issues and that you would rather have greater goodwill with modders than to risk creating additional issues. In the same way that modders can deliberately ignore unintended and fixable conflicts between mods, but we don't and try to fix them because we would rather things work well and that everyone get along rather than simply pointing to a license and thumbing our noses at each other over it. And you know what? If CKAN were opt-in and weren't so prone to creating install errors, I wouldn't want it removed. So there's a very easy way to make that request go away that's in your benefit. Besides that, you might be bound by the project policies, but that doesn't mean to throw up your hands and not bother changing them. Removing that one policy would fix so many animosity issues in one fell swoop. And yet, the issues this is intended to fix happened a year ago. A year ago. And no progress was done on it. I suggested something like this to you specifically in the CKAN thread approximately 8 months ago. And there has been no progress. For all you claim to be working on things, nothing has been done in a long, long time. And yet they will not be stickied at the top of the Addon Release forum, they will not have had institutional support from a few modders, they will have to fight their way to getting visibility and a userbase. And if the user responses to the CompatibilityChecker breaker and win64-forks for FAR were any indication, many users really don't agree with introducing extra workload for modders even after they've explicitly asked for it to change.

While those are all nice ideas, they all fall into the same category as the rest of 2-5, which is that they don't solve the problem; they merely mitigate any issues that can come up. Only an opt-in system actually provides a way for modders to absolutely, positively be certain that they cannot be harmed by CKAN. It's also a somewhat necessary gesture of goodwill, since implementing that would include CKAN and its contributors acknowledging through action that they can cause severe issues for modders, that they're willing to take steps to address those issues, and if necessary, suffer a massive hit by de-listing the mod if they don't do so to the modder's satisfaction. As opposed to now, where there isn't any incentive for CKAN and its contributors to fix issues that they cause for modders, because they can basically just laugh and disregard complaints. This is part of where the real animosity comes from, because not only does CKAN cause problems, they have set up a system to shield themselves from the consequences of those problems. Making the system opt-in removes that shielding and puts CKAN in the position of having skin in the metadata-and-install issues game. I plan on enforcing it the same exact way that TinkerTime and KSPModAdmin are suppressed by CKAN: they won't be the official source everyone talks about, they won't have the massive blessing that is being stickied by the forum moderators to get them their attention, and modders won't want anything to do with them because they're jackasses. It is possible to write a simple plugin to dump what's in the CKAN folder and know what people have installed, you get some good data about the metadata, if they're using a hacked CKAN build, at best, block them and blacklist them from support; at worst, set up code in the mods to break them if installed through that particular CKAN hack. In all honesty? Pretty much what I do now; scale back on support of my mods, development of new mods, and engagement with the community. You people have made modding a lot less enjoyable for me, and the benefit of releasing (useful bug reports and feedback) basically got crapped all over by CKAN. The latest project I have in development is going to have to be ARR to protect me from people like you. And all any of you had to do to not cause it was be happy you got something that never existed before, but that wasn't enough, was it? No, I was getting at that CKAN should not be able to point to repos other than the official one, to get around the issues caused by simply running an unofficial repo. The end result is that it is pushed back to an unofficial CKAN build, released on an unofficial thread, minimizing its impact. I think you overestimate the amount of people that will switch. CKAN is perfectly poised to become the mod manager equivalent of the zombie that was ISA MapSat, never dying no matter how bad it got. And that was people being stubborn without ISA being promoted constantly in the forum sticky. I have no love for Curse... but why would that be a problem? Their mod stuff doesn't function for non-Curse sites, so why would any of us care? They have a nice and happy opt-in method baked in that I really don't have a problem with.

Well... all of that sounds like part of the problem is that CKAN can point to repos other than the official one. So make it opt-in, and force CKAN to point toward the official repo only; problem solved. Then give some ground. I'd personally prefer that CKAN were dead just because it's cutting the knot, but I know that won't happen, so as long as it is restricted in such a way that it can't cause issues for me, I'll be happy: Make it opt-in. Have automated auditing of metadata between expansion by the NetKAN bot and being pushed to the metadata repo in order to ensure that the install it creates is functionally identical to that of a manual extraction install. A serious culture adjustment for the contributors: more focus needs to be given to modder concerns, and when there's an issue, telling modders any variant of "well, why don't you submit the fix for us?" or insinuating that they're part of the problem because they are voicing complaints / submitting issues as opposed to fixing it themselves shouldn't be acceptable. Ensure users know that (the vast, vast majority of) modders have no control or influence on the metadata. CKAN users need to know that CKAN is responsible for that, not us unless we've explicitly taken on the responsibility. How I'm not sure of, and progress has been made in the docs on this recently, but it needs to be better than it is right now. An always-installed plugin that lists in the log what mods have been installed through CKAN, what ones have been auto-detected, which versions, and what .ckan files they came from for the purpose of troubleshooting when these things happen and users provide us with logs. That is my personal wishlist of things that CKAN should have. #1 and #2 are really the most important, as 1 is the source of many issues and 2 would allow so many issues to be caught before they are pushed out. I've suggested 2 numerous times, but it always gets ignored even though that would have fixed the big screwup it caused FAR.

And the problem is that unless it kills CKAN completely, it will be useless. CKAN has too much marketshare and mindshare in the mod manager department to have any hope of being unseated at this point. And besides, from my experiences before mod managers were a thing, it's a hell of a lot better for modders when there aren't mod managers, and the users seem to have fewer install issues too. The only way forward at this point is either to get CKAN to change itself to be less terrible, or to simply kill it and go back to the way things were. The latter is almost certainly never going to happen, so that means the only option is to get CKAN to change. But CKAN contributors try as hard as they can to keep CKAN's policies from changing if they benefit modders, and so we are stuck with the issues. Unfortunately, CKAN has ensured that modders butt heads with CKAN users and everyone butts heads with CKAN contributors. So many conflicts between users and modders right now are just related to CKAN and never existed before CKAN. The best way to end the animosity is to get CKAN to stop causing issues for modders. Give some consideration to the problems affecting modders for once and stop worshiping users like they're the shining center of the universe.

Your suggestion to fix CKAN... is to have a bunch of us get together, create our own version of CKAN from scratch with direct control instead? Why the hell would be bother with all that work? It wouldn't be even remotely worth it unless it definitively, completely, totally destroyed CKAN and left no trace of it anywhere KSP touches, but that's not going to happen, so all the problems with it discussed here will still exist. And there is always the risk that it morphs into the kind of thing CKAN is currently if it focuses more on users than on modders. This is not a solution in the slightest, it just sounds good because it's trying to hit some strange "middle ground." Oh, I forgot to add this complaint to the long list of ones related to CKAN: the fact that any time a CKAN issues occurs and causes workload for me, CKAN contributors and users respond to complaints about it by demanding that I put in work for them. This happens every single time. And none of them accept blame (or even blame any policies or anything in CKAN) for the issue; at best, it's blameless. At worst, it's the modder's fault for not directly supporting CKAN metadata.

@the_machemer: If the rudder is producing a leftward force on the plane, then the rudder is not on straight. Angle snap does not always put parts directly straight, especially when they're placed on parts that don't have simple, cylindrical colliders. This is a long-standing issue in the stock game that will also show itself under stock aerodynamics and it is not something I can fix, nor is trying to fix part attachment issues in the editor in scope for FAR. @Kurtvw: That is not an issue. That is exactly how the Flight Assistants have always behaved; they remain on when you leave them on, because you told them to be turned on. This behavior has existed since the original FAR v0.1 and will not be removed because the game deciding "no, you didn't really want this control system active, I know better than you you poor, dumb player" is the worst kind of behavior to add.

Here's the solution for the Tweakscale interaction issue: wait until 1.1.3. I'm not going to push a FAR update with that fix when 1.1.3 seems to be so close.