Claw

Beware that if you have ships in-flight with mod parts, they will be deleted if you remove the addon and load the save. Definitely follow the recommendation to "make a backup copy" of your saves before you remove the addon. It could also be something with your setup and MechJeb. As Vanamonde suggested, a picture of your ship in flight might help.

I concur with bewing...there's no intent to force a redesign every time you start a game. Some people love spending a lot of time on design while others prefer exploring. There are a lot of folks who put out well designed vessels to fly, so no need to feel cheaty about taking them out for a ride.

This is something I hope never goes away. It's just too entertaining to build a kerbal powered glider.

Fun fact...in earlier versions of the game, the reaction wheels used to have "SAS Modules" and was internally named sasModule...which possibly lead to widespread use of terms like "sas units" and "sas parts"...or "add some SAS to your ship." I'm surprised nobody mentioned this (or maybe I missed it). For the probes, you don't have to remember the list of cores and their levels. If you go to the parts list and right-click on a part, it brings up additional info. You can right-click again on the part to make the window "stick" which allows you to scroll through the information. For probe cores in particular, there's a SAS section which shows what modes that particular part can provide. If there is no SAS section, then the probe does not grant access to SAS functions. Again, this is for probes. For manned capsules, access to SAS functions are reliant upon having a pilot in the seat. A higher level pilot grants access to more SAS options (as mentioned previously and quoted below). If you only want "Stability Assist" then use any probe core (except stayputnik, which doesn't like to stay put) or any pilot, as Snark stated.

What I said about where the torque is applied is not hearsay and not derived from experimentation. It comes from first hand knowledge about the code and how the unity engine works. Torque is applied at the reaction wheel, but (due to physics) the equal-and-opposite reaction of the vehicle occurs about the CoM when the vehicle is unconstrained (for example, in freefall). I said nothing about flex in my statement, though it's referenced in the links. Orientation will matter if the torque is not symmetric about all three axes. If it's the same, then I agree that orientation doesn't matter. Position does matter as to how the flex behaves, but is mostly masked within KSP's mechanics. So in essence, the position is much less of a factor than is the actual design of the station. Yes, we can agree on this even if you do not believe my assertions about where the torque is applied within KSP's mechanics. Also, I didn't intent that my statement of "torque is not applied at the CoM" as me claiming it as the causal factor to the OP's problem with station wobble/flex. Aside from the torque@CoM statement, I agree with your other points about how the vessel behaves and ways to help minimize/prevent the issue. Snark already explained why the "reverse reaction wheel" won't work. So here's another series of example pictures. The first picture shows a basic setup and the location of the CoM. The second image shows the result of a "turn left" input. The beam is clearly flexing, which it can't possibly do if the CoM is where it's at, and behind the launch clamps. The third image shows another setup, which clamps down the CoM even further and has some markers on one side of the beam (to show twisting in the fourth picture). And the fourth picture shows the beam being twisted. I'm not sure how this would be possible if the torque was being applied at the CoM. This is not an experiment to hypothesize where the torque is applied, it's a model to demonstrate it being applied at the end of the beam.

This is not quite accurate. Or, at least, maybe a misinterpretation of what's happening. The reaction wheels apply the torque at their location. However...torque is a funny thing in that, in the freefall of orbit, the reaction of the vessel occurs at the vessel's CoM. If anyone is interested, I have some old posts I made in threads discussing similar questions. The threads themselves are also full of good discussion. Edit: And actually, this post here addresses the statement directly.

In general, this is correct. The parts within a single vessel themselves can't collide. There are two methods at play with this one. The earlier version of wheels used a different system entirely, which essentially boils down to the existence of wheel colliders which were not ignored by the rest of the vessel. Shoving this collider into another part would cause joints to bend (because they are bendy), resulting in the ability to build things like moving cargo bays and kraken drives. This is no longer how the wheels work. The new wheels use ray casting, so it technically not a collider. The ray casting is not ignored internally to the vessel. As others have pointed out, part clipping really only becomes a major catastrophe when you cause an event which creates two vessels (such as staging or undocking). The "ignored" collisions become active between the parts of one ship vs. the other (but still ignored internally for each). So if two parts are clipped, but suddenly belong to a separate vessel after staging, they will immediately collide.

Krakensbane also had an interesting effect that when going fast enough, the exhaust smoke would actually "wrap around" such that the back end of the smoke trail would end up in front of the craft.

The Unity wheel functionality completely changed from Unity 4 to Unity 5 (as in totally changed). It also instituted several additional constraints, such as the limit to 20 wheels. The built in functionality works great if you are building a single vehicle that can be individually (internally) tweaked to work properly. If the tweaks are off, then it doesn't respond very well. Because of KSP's modular design, the required wheel tweaking doesn't really work because the circumstances for every wheel/leg is defined by the user created creation it's attached to. Some things are heavy, or light, or bouncy, or bendy, or rigid...and each setup really requires it's own tweaks which aren't easily "detectable." Some of these tweaks has been exposed for the user to adjust, but not all of them.

Having this many parts will be a drain, even without the physics. There are some extreme options that are available to try, assuming you're up for it (it might take some work, or perhaps I can whip up a quick mod to try it). I can't guarantee that it'll do what you want, but it could possibly improve the frame rate. If you post your ship, I can give the mod path a try. Otherwise, if you're up for some manual labor on your end, I can try to give you an option to try. Cheers

Your actual goal isn't all that clear to me...you don't say exactly what you're doing with the creation. Though subsequent posts indicate launch. But then you later posted... So I'm not entirely sure what you're after. If you're only using the ship as a backdrop, then starting time warp will put the craft on rails and suspend part-to-part physics calculations. Also, if you aren't maneuvering the ship, many of the physics calculations are dropped. I'm not super knowledgeable about mods available, but it would be possible to build a mod that can deactivate physics. It would essentially turn into a 1x time warp. 7700 parts is a LOT of parts, plus you're trying to run recording software. It's entirely likely that your computer is simply having a hard time getting through that much work, even if there wasn't lot of physics burden. I don't think that's going to do what you want. I could explain it here, but I made an in depth post elsewhere on the forum. The bottom line is that it controls how many graphics frames to drop in order to send more CPU power to physics. The end result for the scenarios posted here is that the visual frame rate will go down. The craft file is unique to KSP. So unless someone has built an addon for a CAD program, then it's not going to be readable. Sorry that this post doesn't contain an actual fix. If you could show or describe exactly what you're trying to film (ship sitting on launch pad, base landed on the Mun, huge space station in orbit) and what kind of maneuvers you are trying to do (launch, turn, land, etc) or not, that would be helpful in trying to find a short term solution if there's not a mod available.

Lights are lights. And if you want them to cast real time shadows, it's going to impact performance more. Also, there's global illumination to contend with. Emissives, on the other hand, are much less intensive. The trade off being that they don't actually cast light and, hence, won't cast shadows. But they are great for "seeing things in the dark" when you're trying to line stuff up or just generally find your way. There was a light strip mod (Glow Strips, I think) that added this sort of feature. I've also seen people add extra battery packs around docking ports so they have something to aim at in the dark. Neither of which is relevant to Editor dimming, but I digress. Rebaking textures itself isn't difficult, but does take time. Also, that would be an additional set of assets to load in a game that already stresses memory limits. So there are always trade offs. I can't recall for sure, but perhaps even a more simple thing to implement is that some of the lit areas are separate sub components of the interior model. If I'm remembering that correctly, then it would be a matter of also flipping those things off with the lights (this could be moddable). Though I think that might also cause the lighting structure itself to also disappear, which could be visually jarring.

Unbaked lighting has an impact on performance. If you search back through the forum archives, you'll find some old information with people having overheat and/or excessive CPU load problems in the editor. This was primarily due to lighting issues (along with a couple other things).

Without knowing much about your rig, here are a couple things to try (sounds like you are on windows): 1) Go to the .exe or your shortcut and right-click->Properties. In the Compatibility tab, select (or deselect) the "Disable display scaling on high DPI settings" option. or 2) Go to the NVIDIA control panel and find KSP's setup (make sure there's only the one). Set "Vertical Sync" to "Use the 3D application setting." You can also try turning off (or on) "Tripple buffering." You may have to restart the computer after fiddling with the NVIDIA control panel, but I'm not sure if those options will force you. Once complete, turn vsync on in KSP and make sure you restart the game. Not sure if any of that will help, but give it a try. It would also be good to know what OS you are using and such, if you're not able to figure out the issue. One more note: there have also been instances in the past where a new NVIDIA driver update hits, and we figure out later that the new update isn't compatible with KSP. In that case, some people have found success by rolling back to a previous version. Often people can get away without the newest graphics card driver version if they aren't on the cutting edge of the newest video game releases. (Often video card updates come out to support the release of a brand new video game, and new bugs are introduced for other games.)

Those screenshots look awesome! And welcome to the forums!

Bananamonde!

I agree with this being the likely big culprit, along with there being (what looks to be) not enough pitch authority. The ship probably doesn't have enough lift to brute force the nose around. Then, when the nose starts to drop, it takes full pitch to pull it back up. With the control surfaces deflected, it's likely also stealing a significant portion of the aircraft's lift and causing a lot of induced drag. It becomes a self feeding cycle once you get into the nose fight.

If you haven't already restarted KSP by this point, I would try that first. After that, I agree with 5thHorseman in that the next step is to check out the save file. You can try digging around in there yourself (the kerbal roster is at the end of the file) or upload the persistent.sfs somewhere for us to check out. The action groups aren't supposed to interfere with the scientist, but it's possible it triggered a bug.

If you can upload a log file somewhere and post a link here, that might also help in narrowing down the issue.

Another possibility: Do you now or have you ever had a joystick/game controller/game pad? Sometimes that results in: 1) If there's controller attached, you might be getting inadvertent inputs or have a bad calibration 2) If you previously had a controller attached, it can tricks Unity/KSP into adding a calibration for a controller which doesn't exist If it's #1, you can make sure there's nothing accidentally touching the controller, fix the calibration, or remove the controller. If it's #2, then you can check the KSP settings and delete the ghost calibrations, or delete the entire "settings.cfg" from the root game directory and let the game generate a new settings file on the next startup. However, that wouldn't explain the issue if it's also happening with "zero electricity." In which case, it sounds like a physics issue and would typically be related to specific circumstances (i.e. a specific craft configuration or kerbal involvement).

If you can post a save and any details on how to replicate (or a picture), that can help in finding the issue. When on ladders, kerbals sometimes add a force to the ship. So it's possible that your kerbal is bumping into a part (or invisible part) which is making the ship rotate.

Here are some semi-(but non destructive)-oldies...mostly from v1.1 (I chose this version because it was released almost exactly three years ago.)

Awesome to see this is (mostly) still going! I am sad to report that Julella and Obemy, my intrepid duo, are still stranded on Eve.

^^ That one.

We found the source of the issue, so should be all fixed up for fairings and cargo bays. Cheers, ~Claw