ferram4

@ctbram: Dunno, looks like you either screwed up the installation or something is interfering with it. Don't know what though, I've never seen that happen from any of the mods you listed. @blowfish: Confirmed, it's fixed by opening and closing the bays (even just partially). Not sure what causes it though yet, I'll need to investigate. @Mekan1k: Ummm.... yes. In fact, everyone can. That would be because it is part of the stock game.

@slumpie: Try this: remove FAR, then set the drag on all the other parts on that plane to 0 in the config files (this will approximate the extreme of FAR's lower drag). Then, try flying it and tell me that it's a FAR issue. Infiniglide requires thrust. FAR always applies some drag force, with the lowest possible drag coefficient on a part being 0.003 (0.006 for a wing). Infiniglide can only occur if the drag coefficient < 0, and it is never less than zero.

@sand500: Nope, not possible from the way FAR works. @slumpie: That is because they are not the stock wings anymore and are not supported by FAR; those parts are suffering from the infiniglider bug, because they are using stock winglet code. Any infinigliding is stock, as it requires drag to be <= 0; FAR does not allow this under any circumstances.

@Wanderfound: They act like non-circular bodies. They don't act like fins or wings at all. @Forty21112: The 0.24.2-compatible versions of FAR do not function with the new wing parts at all. You would be best served by updating to the latest version of FAR instead of trying to find something "better" among the older, buggier, less-compatible versions. @Klingon Admiral: Considering that control surfaces only do what you (or SAS or some other control system / autopilot) tells them to do, I'm not sure what problems you're having. I will need logs and reproduction steps for both problems, including exactly what I should find. This means numbers and proof for orbital shenanigans, especially since FAR doesn't even get to the force calculation code if the air density == 0. @FreeThinker: Nope, and no plans to add them. No idea how to do it easily without causing lots of issues and without adding one more thing that will break when 0.26 comes out.

@mech_engr: For all of those surfaces in a single part? FAR doesn't support that. You'd also get much more accurate behavior by having each surface be distinct from the wing itself. @RadarManFromTheMoon: Not gonna happen. @5thHorseman: That shouldn't be happening, the button is only ever removed when leaving the flight scene. Post logs and full reproduction steps.

That is because KSO is not set up to be NEAR / FAR-compatible. This is a problem on their end, nothing I can do about it.

@nli2work: Try the readme file.

@theend3r: You don't. You either fly a better trajectory, protect the part with fairings, or turn off aerodynamic failures entirely. You don't get to play god. @Northstar1989: You mean the issues that the patches were released to fix?

@skeevy: Most of the GUI stuff doesn't require much processor power at all, so if you're not using that, you won't notice. If you like the difference in aerodynamics when you change Mach number, you're probably going to miss them if you switch from FAR to NEAR. Also, a lot of the wing shape effects are removed as well, which means a lot of your designs will fly a lot differently. It'll be less computationally intensive, sure, but it'll mostly be because the physics are differnet. @zuuhis79: Np. I guess I'll just chalk this up to outdated Linux libs and call it a day.

Those aren't the users that bury good bug reports (or at least ones trying to help) when KSP updates. Once CC can't be relied on to tell people that their mods are probably incompatible, with that KSP version we're back to dealing with that. And now CC can't be relied on to deal with that contingent. Well, if it's an image problem, then there's nothing to be done, and ultimately it needs to be abandoned. The community is too large for its attitudes to be affected once they're set, and at that point there is no reason to waste time fighting something that can't be fought. I'd actually argue this isn't the case. Most reply to any explanation with, "but it works fine!" Of course it doesn't actually work fine, there are errors being thrown everywhere, but the user wants it to work fine. And so magically, it does, lest the errors are blatant enough that no one can tell themselves that it is working fine. As I mentioned, most don't listen to it. Second, a group that doesn't like a message dialog and wants it to simply go away because "it works fine!" isn't going to bother to read an explanation. Can't update a mod from inside the game, updating requires going online, which (if bundled in a mod, rather than as a separate thing, as CC is) is going to cause people to overreact. Temporarily getting rid of the message will just be viewed as a "fix me" button, and we'll be back to where we were before CC was created. It's not supposed to be a mod updater. It's just supposed to tell you that you're running on the wrong KSP version. Anything more is outside of CC's scope, IMO. I see two other alternatives: 1) a user takes over the mod, and it is no longer dead. All the problems are solved in the process. 2) The mod dies, rather than staying in a state of un-death. In the state of ISA Mapsat, once it finally just died, we got SCANsat to replace it, and everything was back to normal. Problems should be addressed, not ignored. Already happened. Once people start ignoring the warning and advocate ignoring the warning because "it's fine!" there isn't much other option. We do. Most don't provide it. Or get pissed and post goatse instead. Also possible, but I'm not sure how much effort that's worth going to.

There are people who aren't on a 64-bit OS at this point? Really? All the problems appear to be pointer errors with addressing memory above the 32-bit limit, which implies a 64-bit pointer being coerced to 32-bit somewhere. Supposedly hardware affects this, but I'm not sure how hardware could cover up the errors that would result from truncating a 64-bit pointer.

I see nothing breaking in the log. I also know from experience that KER parts do not cause the behavior described. In particular, 0 mass, 0 stock drag parts aren't treated any differently by NEAR, so there shouldn't be any problems. The only issue is that the KER part clipped into the bottom of the pod might confuse it into thinking that the heat shield is covered, and so that there is no drag there. In practice, this should lead to the KER part being destroyed during reentry.

There are times when you don't give people what they ask for because it will cause large problems, and win64 KSP builds were one of those situations. I'll also note that Squad learned this lesson already. Experimentals used to be public, but the complaints and inaccurate bug reports resulted in them being made private. When the experimentals were closed they were more stable than the win64 build is currently, which makes this incredibly strange. With that in mind, let me amend my statement slightly: It's beyond me why they released it in the first place, when they've already dealt with the same exact situation by keeping the builds private.

And an output_log.txt? Something is clearly breaking, but I have no idea what without a log.

@Raven: Point 2 was the original proposal of this thread; messages alone were used because we wanted to make things easier for users and be understanding of users that were willing to run the game even with the incompatibilities. That didn't work though, and a very large number of mods already do that. And requesting logs from people is standard, but that doesn't solve people running around talking about how X mod causes Y problem, when the only reason there's a problem is because there is a compatibility error. If they're running something that permanently suppresses the messages, then we're back to the point where the best case is that they complain that X mod doesn't work, instead. The ultimate problem though is that no amount of unifying code can be written for this anymore now that the sabotager plugin is out. It overrides any unified code in CC. All of it. @m4v: Yet it cannot be relied on to do its job anymore, nor can we know if it has been distributed beyond the main source. We also don't know to what extent it will grow beyond this point; it might be promoted by someone somewhere and become an actual problem with significant numbers; in that case, it would be better to have already addressed that possibility rather than scramble to do it then.

The win64 build was horribly unstable for 0.24. It has only become worse for 0.25, and it's beyond me why they released it in the first place. It crashes randomly, with no useful information being put in any of the logs. Memory usage above 4 Gb makes crashing almost inevitable, though it also occurs below that, at memory usage levels where win32 builds are perfectly stable. As a result of this instability, many mods simply refuse to run on win64 builds of KSP to ensure that all issues are attributed to win64 itself, not to any of those mods.

There really isn't a point anymore. CompatibilityChecker is dead, killed because it had a method of unifying the message displaying code for user convenience. At this point, it is unreliable for its original purpose, and so long as the sabotage mod exists, it will continue to be. We have no way to know how many people will use it, but it will certainly be enough for the next KSP update to be a problem; remember, 0.26/0.90 is going to break anything that functions in the editor hard, and CC would have been valuable there, but now it is not. Finally, there is the problem of what would be happening: we would be rewarding someone for sabotaging a mod. Worse, we would be rewarding that someone and hoping that they might decide to stop breaking that mod out of goodwill, though the sabotage in the first place shows a distinct lack of it. We do not want to teach people that if they want to get something that they should sabotage a mod because it will result in compliance with their demands, however reasonable they might be.

@biohazard: I cannot reproduce the issue. I'm not sure what's wrong. @Pondafarr & Xenro66: I've attempted to reproduce from a stock NEAR install, and cannot reproduce it. All SP+ control surfaces function properly; I suspect that you haven't installed NEAR correctly, do not have a copy of ModuleManager installed, or are using something that interferes with NEAR.

Yes, actually. Do it. You can be responsible for all the support of each and every mod. Once you're redistributing a mod, it's your problem, not the mod creator's, and you shouldn't go out of your way to make it the mod creator's. Take on the responsibilities of redistribution and support, just like any other modder. But you don't know how the mod works? Too bad, your problem now. You found a bug that you want to report? Too bad, your problem now. You want to help users, but you don't know what to say? Too bad, your problem now. You don't have the time to provide full support and development to all the mods you're redistributing? Too bad, your problem now. Go ahead, redistribute mods. And when users come to the threads of any of the mod authors and expect support, you should expect them to be rejected, because any mod author can't be expected to know what you've changed, how your pack is set up, or anything like that. It's your problem now. I'm sure this will make users quite happy.

Forking it was always an option; if you had bothered to look at the license you would have realized that, and since you had to look at the source to sabotage CC with this, you were clearly aware of the license; you just didn't care. And as I said, I don't quite see the value in the feature, besides in (at this point) making you stop sabotaging CC. But at that point, I'd be proving to people that sabotaging mods in order to get what they want works, which leads down a much nastier path than we have now. At this point, I think the discussions are moot anyway. I'm probably going to remove CC entirely, since I can't rely on it functioning anymore. It's really good to know that the feature that was intended to not spam people with multiple messages at launch was used to kill CC. I'll just have to come up with another solution. If you had forked CC, as you were allowed to do from the start by the license, there would be no problem. If you had done it for yourself, there would be no problem. But instead, you decided to make the warning system unreliable and risk lots of extra support requests. We know that 0.26 / 0.90 is going to break mods hard because of the editor changes, and that is the situation where CC is valuable. We're headed towards a KSP update where all of those support reducing methods are needed, and you released something that makes the most valuable one unreliable. We are not pissed that you took control. We're pissed that you made more work for us.

@Volt: I can look into that, but it might not be something I can fix on my end. If they're teleporting you from the KSC to those launch sites during the Start() methods, then there will be serious problems, and there's not much I can do about that. They'll be effectively putting half the aircraft in one location and half in another for all the wing interaction effects.

Well then, since it's not a feature that I would like to see, I won't code up a CC version involving it. I've only ever used CC versions developed by others, I don't see why I should start for a feature that I don't see merit in. You could have avoided this by just releasing it as a full CC version, and then maybe I would have considered it; given the way CC works (as you are so clearly aware, since you're exploiting it for this), all you would have had to do is get one other mod using CC to update to your version, and the one that I included would have been irrelevant. So you're just trying to make our lives harder. Thanks. It deliberately disables what is the primary feature of Compatibility Checker. The only thing it doesn't do is interfere with the compatibility checks themselves. Yet, I suppose. A popup that can be addressed while loading the game up is interference... It's intended to convince people to update. I know damn well I can't force people to update, there's no way around that. Reminding them that their mod isn't intended to work on this KSP version, that I can do. Said like someone without experience supporting a mod. The number of times that people wonder what mod includes X feature, or why after removing Y mod Z was gone, etc. is more than enough proof that people forget what they've downloaded and installed. As with all the others who think they know better than the modders that are already here: try your hand at it for a bit, then come to a conclusion. Yes, I am sure that after you've acted with intent to make our support lives harder that you will simply stop if we cave. So basically, "do my bidding, or I will punish you for the sin of providing us with free stuff and trying to make it easier on yourselves by addressing common user problems." You and I both know that you'll never be satisfied, and that it's just a ruse. If it weren't, you would have gone through with making the CC fork. Instead, you decided to try and kill CC entirely. CC always provides only 1 popup. Ever. It's part of the system that Khatharr is exploiting to make this function. So at best, you're getting 10 popups to close. ...but if KSP is crashing often enough that you're having to restart it 10 times in a day, you've got worse problems than CC.

Control surfaces are not useless when stalled. They are just less effective. There's also the fact that at those Mach numbers, "stalled" isn't really a concept that makes much sense. It will fly fine.

CoL behind CoM, just like any stable vehicle. It simply has the pitch authority to remain in that configuration. It's not special. It's just designed a certain way.

There's plenty you can do; the source code is available, and you can go and recompile the mod. The only reason mods remain abandoned is because good users do nothing.