ferram4

There is a simple method of preventing false alarms, but my understanding is that the average user doesn't want any odd mod calling home all the time. Not to mention that the current forum rules basically turn it into a nightmare for the user (tons upon tons of "yes, I agree to send data over an internet connection" buttons), so even though the idea was entertained way back when CC was conceived, it's basically off the table now. There's also the problem that what a user considers a "false alarm" is often not a false alarm. Many times, things quietly break and users don't notice. Then they show up asking for support, and all it takes is for them to update. This has happened so many times that it's not even funny, and the number of times that it has made our lives more difficult is staggering. This is a very common occurrence with abandoned mods, and is one of the many reasons for it in the first place. I should also note that if a CC version is set with a higher version number, that is the particular bit of code that runs, with the exception of the unique compatibility info for each mod. Incidentally, this is how this mod breaks CC; it's simply tricks the existing CC code into seeing an empty class as a version of CC with version = Int.MaxValue. The main purpose was to unify the reports into a single popup and allow later versions of CC to override earlier versions for improving behavior and fixing bugs; it's kind of disappointing that something intended for user convenience was used to undermine the entire thing.

Can you post a copy of the Player.log? I'll have to see what "Invalid object handle" points to, perhaps that can help.

@Khatharr: Three big problems with your code: 1) There is no way to not silence the message on repeats. While I understand that this is the behavior you want, it isn't useful to users that want or expect to be reminded. 2) Without providing a license for the code, it is licensed ARR, and we can't use it. Why haven't you licensed it? 3) It is not a functional Compatibility Checker version; as I mentioned, the proper thing for you to do is to release the full version as a fork of CC. Why have you not done this? At this point, you've basically declared that we use your code (and suffer forum rule violations and take down our mods because of violating the license) or we deal with this interference plugin.

And the feature will be overridden by the KSP version incrementing, correct? For major, minor, patch, and build versions? Because otherwise, your feature will have the same problems that you have created with this particular mod. I'll admit I'm not happy about even this suggestion. The number of times I've gotten reports from people that consider ignoring the Compatibility Checker to be okay is still very high, and every update it becomes worse because of people that claim that the mods are working perfectly fine, even when they aren't. This is not a good feature. It's just better than breaking the whole damn system. Good job. Even better, you broke everything by exploiting the system that was purposefully intended to not .... off users with a ton of popups each time they opened the game. Shows what we get for trying to warn you without it being a popup parade. I'm not sure who you're going to send it to though. There is no "CC team." You'll be releasing it as a new version of CC and hoping that it is taken up by the modding community, just as was intended by the license.

How so? You want a feature, it's licensed so that you can fork the code to implement that feature, so why aren't you implementing it? Why do you want to make our support workload heavier?

CompatibilityChecker is licensed BSD-2. You could have just created a CC version 5 that did what you wanted instead of doing this. Then that would have overridden all the older versions of CC, just like this does, and you would have gotten exactly what you wanted. Why didn't you do that instead?

Docking port joints are the same as any other joint. Nothing special there, and they are also affected. Unfortunately, the size and mass of docking ports relative to what's connected to them still means that the connections are somewhat flexible.

Update the cockpit mod, it should have a fix.

@Khatharr: I suggest that you try recompiling mods using the code you've provided; I think you'll discover it breaks quite a few of them. Aside from that, remember that you can always just recompile mods that include Compatibility Checker, but in the process not a single mod author who implements it will want to support you. I cannot think of a mod that implements Compatibility Checker that is not updated regularly, so your problem is one of your own making. I sincerely hope you don't run into any old bugs or issues caused by the wrong KSP version, since those ones tend to be quite nasty if they aren't the kind that throw compiler errors. And I'm not being sarcastic, a lot of those are a pain, and if you're getting CC warnings and you're trying to ignore them, you'll run into one of those probably soon.

A message telling you that something is incompatible is coercive... That's a new one to me. If users don't get the warning, they assume everything is hunky-dory. The reason this exists is because so many users are, apparently, incapable of remembering to update their mods. You and I both know that people tell warnings to go away without thinking about them. Then, they come and blame us for giving them a way around it. Want to dismiss the warning? Go address the problems it's warning about. I didn't know that you were forced to install a mod (which is the only way to have a CC stuff), that it loads up KSP at inopportune times when you're trying to sleep, and that you had no other recourse. Would you mind telling us who forcibly installed that mod that takes over your computer so badly that it warrants a comparison to being woken up a 3AM ceaselessly? I didn't realize it was so bad, I thought we were talking about a message that popped up about a mod that you installed of your own volition was out of date when you went to play on your free time, not something that horrifying.

You did not update FAR then. The most recent FAR includes configs to make the updated SP+ parts work. Update FAR, it should have been yelling at you for not updating anyway.

The entire point is to tell people that they're running out-of-date versions of mods that were not built for the KSP version they're running. Letting them shut off the reminder doesn't get them to update, and that's the entire point. Part of the reason that there isn't an alternative disable method is to put users in the position of either A) updating the mod like they should have in the first place or assume responsibility for themselves and compile it for their own use. I don't see the problem, everything appears to be working as intended.

KJR doesn't do enough to produce that amount of lag alone. The only explanation is that the off/on rails switch is very heavy due to the mods you are running / the size of your craft. I suspect that if you remove KJR, you will see the same behavior.

ALL engines will make more thrust in vacuum than at SL, regradless of whether they are underexpanded at SL or overexpanded at altitude. Even the SL optimized ones. Even the ones optimized for 20 atms pressure. The only difference is that SL optimized engines will not be as efficient in vacuum as the vacuum-optimized ones (obviously), but the vacuum-optimized ones will become amazingly inefficient at SL. As an example, the Poodle is making about 3 times the thrust it should be at SL if it were actually vacuum optimized; that's a little closer to a mid-to-upper range engine, I think.

Yes, an engine in vacuum will have higher thrust, that's what I said. Your chart says otherwise, and shows engines that produce less thrust in vacuum than at SL. The expansion of the plume after the nozzle doesn't matter, it's the pressure difference at the nozzle exit that accounts for the thrust and Isp offset from the design point.

@LMA: Source code link in the OP. It's pretty obvious, right underneath the download link. Make sure you're using the latest version of pWings, some changes were needed to it to make it function properly with the latest version of FAR. @acc: I cannot reproduce the issue using procedural fairings; they shield things just fine. Make sure you're using the most up-to-date version of both mods, and ensure that there are no conflicts caused by other mods. @Gfurst: I know all about those, they're fixed in the dev build. Alright, the v0.14.3.2 patch is out, which fixes a bunch of wing interaction issues, which should be the majority of the problems people have been having.

All rocket engines (that do not use any reaction mass from the atmosphere) have their peak Isp and thrust in vacuum, period. Even the ones that are optimized for non-vacuum, but still not SL pressures; they all have better Isp and thrust once there is no atmospheric back-pressure to fight against. There is no situation where a standard rocket engine produces more thrust at SL than in vacuum, regardless of what pressure they are designed for. Honestly, the "less thrust in vacuum" idea is less realistic and worse than the constant thrust issue. At least with that issue, the engines sort-of follow realistic principles. With this, anything not designated as vacuum-optimized will be completely wrong.

@LMA: Then try the dev build from the github repo. In any case, those tiny vertical tails so close to the CoM won't provide much yaw stability at all. @El wonso: I haven't seen this problem for symmetrical designs. It is possible that KSP's wonky attachment resulted in you building a vehicle that was slightly asymmetric. Always assume the vehicle is asymmetric first, it is often the truth.

@DaMichel: I saw it, I just haven't merged yet. @LMA: You've never been able to get away with tiny tails. Now is no different. @FirstSecondThird: Then it's reading off of AoA. The second AoA or sideslip gets above ~20 degrees, it lights up with that. The GUI will only light up with that if the AoA or sideslip is that high. It doesn't matter if they work well, it just matters that they are at high AoA or sideslip.

zuuhis, try this then: load up FAR, clear the runway and launch pad, and launch a vehicle that does not have a command pod or probe core. Basically, nothing for it to command with. See what happens then.

Fairing and cargo bay shielding works perfectly fine on my end. If there is an edge case where things don't work, you'll need to provide a full copy of the log and reproduction steps.

There are some wing interaction issues that will still need working out. Some of my optimizations caused unintended behavior, and that's what a lot of people are seeing with uneven lift. Dev build should fix it, but the main thing I'm waiting on is someone on Linux who was getting the insta-vehicle destroy to test it and see if it works.

@ravenousjoe: No, because even calculating it is more complicated than was needed. You don't need the arrow at all, just the location of the center of pressure. @xXIndestructibleEVAXx: Initial TWR between 1.2-1.7. Start turn at 100 m/s. Keep close to prograde until atmosphere is mostly gone. Then continue to orbit like any other time. Just make sure your rocket isn't a great big asparagus pancake or has no thrust vectoring control and you should be fine.

NEAR and FAR are virtually identical in the code that applies forces, and if the error is in there it should occur for both. You can also try using the dev build in the github repo to see if that fixes it, and I do need people who actually suffer from the problem to test it, since I haven't been able to cause it at all.

@mcirish3: Same as compiling any other plugin; there are tutorials down in the addon development section. @ravenousjoe: That is intended. The vector doesn't actually mean anything and shouldn't be there to start with. It's just a point in space, that's all that matters.