steve_v

Games don't damage hardware, or any other application for that matter. Nor do CPUs "wear out" on any relevant timescale. If software causes your hardware to overheat, the problem is inadequate cooling.

Holy untrimmed quoting...

Sure, if your code is an unmaintainable mess. A great many "non-trivial" software projects manage relatively bug-free releases, just not this one. Somehow they even manage to ship .0 releases free of obvious bugs most of the time... Perhaps it's by magic? I'm using a relatively bug-free web browser on a relatively bug-free operating system running a relatively bug-free kernel right now in fact. How strange. An end goal that KSP does not appear to be coming any closer to... 7+ years in "common" and "problematic" bugs like the awful wheel model, craft sliding around, craft spawning underground or far above the surface, kerbals sliding on ladders, flickering orbits, shifting orbits, pervasive collision detection jank, recurring fairing and cargobay bugs, parts displacing permanently on reload, garbage collection stutter, and various physics kraken to numerous to list are still not "eliminated". Add to that the multiple-facepalm-worthy game engine borkage we see every couple of versions, like continual crashing, broken HID support, broken settings system, and broken graphics... Yeah, "eliminate the most common and problematic" my ass. More like "release broken, hotfix the easy stuff, hype the next version". As for the "right now" situation, I'm pretty sure broken resource transfer fits the description of both common and problematic.

Flex at the weak docking nodes is likely the original cause of the displacement, but parts becoming permanently displaced is a bug that goes back to alpha. The problem is more obvious when robotics are involved (and used to plague IR in a big way), but any joint that moves under physics forces has a chance to be permanently screwed up on game reload. Such accumulated displacement is a prime suspect for those mysterious "my perfectly fine ship/station explodes on load all of a sudden" reports that pop up from time to time too. That report I linked is just the most recent, and the only one post bugtracker "cleanup". Amazing how all those old bugs go away when someone starts deleting things from the tracker... KJRn might be worth a look, as it attempts to strengthen connections where they should be, rather than where they are. YMMV though, IME a (complex) craft infected with this bug is krakenbait forever more.

The docking ports aren't the parts that have moved... I'm betting it's this one. Note the "acknowledged" status, which until informed to the contrary, I'm assuming means "Too hard, won't fix".

Walking EVA on Mun I see: -INFO- Tac.LifeSupportController[FFEA38D2][172.42]: Vessel situation change Repeating with every step taken. Granted the Kerbal is briefly leaving the surface, but do we really need to log this multiple times per second? Pretty sure it's at least part of what's hammering performance in this situation....

Hmm, that could be it. I have been to a couple, didn't realise it was a thing.

I have a couple of Kerbals with 3 quirks now, with default KH settings...

In no particular order: You have MiniAVC, it's broken and causes crashes. North Kerbin Weaponry is throwing exceptions, I don't see a version marked as compatible with 1.10.x anywhere. BDArmory is not compatible with 1.10.x either, though that may be limited to it's assetbundle, which is failing to load. You have a huge number of errors loading models while something is trying to apply the "Stock_FullMetal" shader, I don't recognise that one but I'd hazard a guess it's TexturesUnlimited... Which is also not marked as compatible with 1.10.x. ED, overlooked this in OP: That's a pretty big coincidence to write off as "unrelated". If you're running a discord overlay (which will be hooking the graphics stack to draw on the game's window) that's the very first thing I'd disable.

Uhh, why not less melodrama and more pulling the HDD? It'd probably be more productive... There are two kinds of computer users: those who back up their data, and those who have never had a hardware failure. Welcome to group one.

There are almost certainly only 4 participants so far (again, obvious from warped Dmagic votes), that's a mighty small sample size.

Protest the garbage that is IPS? Host the poll on a non-broken website? Abandon the poll idea altogether? This forum software is clearly broken for polls with >20 options.

Better, but still pretty broken. You're still forcing at least one pick from each group. Granted it's probably an artefact of this crap forum software, but it's still going to skew your results. It's likely already screwed up your data, note the 4 votes for Dmagic (obvious best pick of the original group 3) despite it not being mentioned in any replies...

Poll seriously flawed by requirement to select at least one from each "continued" section, giving undue weight to the last 5 options. None of those were on my list, yet I cannot vote without selecting one.

To answer my own question: No, apparently FAR does not properly support BG rotors/robotics, because Squad didn't expose the events needed. And, Aside, FAR's DPCR (Dynamic Pressure Control Reduction) flight-assist is pretty much an always-on for me, it'll (mostly) keep those sensitive controls from ripping your wings off at supersonic speeds.

I have never actually used those new BG parts in FAR (TBH I think they're a bit kludgy and OP in general and stuck with modded single-part prop engines), I'm mildly curious as to how they work out... I suspect the answer will be "horribly unbalanced and/or janky" since they're designed exclusively around stock, but I'm open to pleasant surprises.

The first things I would try are a) testing with a new user account to eliminate per-user pulseaudio configuration, and b) disabling pulseaudio altogether, In which case KSP/Unity will fall back to traditional ALSA for sound. I don't use pulseaudio myself (in fact I consider it bloatware), but I hear it's the default in Arch, so you'd want to hit up the arch wiki on how to debug and/or temporarily disable/bypass it for testing. Other than that, a copy of Player.log might be interesting. IME it rarely contains any audio related info, but it wouldn't hurt.

I find I have to try to make something unstable in stock aero, and just sticking a single tail fin on at random seems to be enough for "stability". IMO, planes in stock are so forgiving and controllable it feels like cheating. Modern ones do, but aircraft were flying level with manual trim and good design long before it was a thing. So trim in flight, again like real aircraft do. There are flight assist mods and autopilots which work well with FAR anyway, stock SAS just isn't one of them.

You'll get them, because "several hours testing" isn't anywhere near enough to be proficient in designing aircraft for FAR, and any "testing" with aircraft not designed for FAR is meaningless. It's not meant to be. It's a more accurate aero model, that's all. You're missing the big selling point anyway, which is shape-based aerodynamics and accurate drag simulation - the two historical problems with KSP that FAR was created to solve. See, one upon a time, drag in KSP had nothing at all to do with the shape of a craft, and worse still, it was based on the mass of a part rather than it's cross-section. Thus "pancake rockets" were the norm. The new KSP aero model assigned "drag cubes" to individual parts based on their cross-section, while FAR bypassed the "bunch of parts" concept altogether by calculating the shape of the overall craft. Both still make assumptions and rely on approximation, it's simply not practical to make an "absolutely accurate" aerodynamic model in the context of a game like KSP. Not true. FAR assigns magic "wing values" to wing parts just like stock does, and those attempt to take into account cross-section just like stock does. The actual implementation (and therefore results) differ though, and any mod wings will indeed have the basic "flat plane" lift all parts get unless patched for compatibility. Neither stock aero nor FAR simulate ground effect in any way. It's been suggested repeatedly, but the usual answer is that it wouldn't add enough to gameplay to justify the effort. Take off and landing speeds are higher in FAR, but nowhere near as bad as you make them out to be. This is largely because parts in KSP are unrealistically dense, so your aircraft are unrealistically heavy. Garbage in, garbage out. I regularly take off and land at anywhere from 70-120m/s in FAR, with very normal looking aircraft. My standard issue "orange tank to LKO" FAR spaceplanes land at 80-100m/s. That's not to say a 100m/s landing speed isn't problematic, the runway is short and KSP's janky landing gear are prone to random misbehaviour at anything much over 80. Drag 'chutes are the answer, just as they were on shuttle. Rubbish. I land SSTOs in FAR all the time (sometimes even on the runway ), my late-game is almost exclusively spaceplanes, and I haven't played without FAR since 2014. Aircraft that are stable according to FAR's design and simulation tools are stable in flight, and I regularly fly smooth and level with only trim. Did you run an analysis on those "severe and immersion breaking instabilities"? If you're using SAS, don't. It's tuned for stock and will almost certainly induce pitch oscillations with FAR. Real aircraft don't have SAS or reaction wheels anyway. Unfortunately the biggest difference (IMO) hasn't even been covered. Namely FAR's voxel system, which throws out the "just a bunch of parts" idea and actually analyses the shape of the craft. In FAR, cargobays and fairings aren't special magical parts with a "shielding zone". You can make a hollow structure from any old parts and have it shield stuff inside. Non-wing parts get (simple) lift simulation too, so lifting bodies work even when not made from mk2 parts and planes made from structural plates will (mostly) fly. If you clip things into the fuselage to make a smooth profile, it has the drag of a smooth profile. If you clip wings into the fuselage, the clipped sections don't provide lift. No more "hidden wings". Various weirdness like open-nodes having ridiculous drag just go away, because nodes have nothing to do with drag in FAR. Parts offset 1mm too far outside a cargobay don't suddenly get huge drag values either. Mach 1 isn't a magic "multiply drag by X" zone in FAR, if you area-rule your craft like a real supersonic design, it has the wave-drag of a real design too. You even get a bonus for realistic intake-engine geometries, as if the parts between were actually hollow. The key to supersonic in stock is "moar engines", in FAR it's "moar slippery shape". Supersonic biplanes and other nonsensical wing geometries suck in FAR almost as much as they do IRL. Stock aero only really cares about how much wing you have, FAR adds where and what shape to the equation. That which looks like a RL aircraft generally flies like a RL aircraft. That which looks "so kerbal" with wings stuck on at random will likely go into a flat spin or catastrophic stall 3' from the ground. There are however some caveats: Lift is generally lower in FAR, because it doesn't try as hard to balance against the nonsense stock density values. This increases takeoff/landing speeds and exacerbates wheel-jank. Many (most in fact) stock craft will be unstable in FAR, because stock aero is super forgiving. You will almost certainly need a bigger vertical stabiliser for a start, for some reason yaw instability isn't a thing in stock. Stalls in FAR can be and often are unrecoverable, just like IRL. If you want supermaneuverability, you need to carefully design for it. You will spend a lot longer designing and tuning your aircraft in general. Getting some aerodynamic theory under your belt is advised, because you will want to be able to read the information the design tool gives you. Water is death. Ferram tried several times to get water to behave properly with real-ish fluid simulation, and I suspect he kinda gave up in the end. Seaplanes are still possible, but they're hard. Many other mods such as autopilots, MechJeb etc. have a hard time, because they're tuned for stock aero. Also,

Only every time I remove a mod that adds partmodules. It's just a warning, and it's only complaining because some extra part data that the mod added no longer exists. The game will clear out the orphan data when you save the craft, so don't worry about it.

You suspect correctly.

Always, without exception: KAC EditorExtensions RCSBuildAid MechJeb || KER KJR Various fixes for current stock bugs, e.g. WorldStabiliser, ParkingBrake, KSPRecall, TAC Fuel Balancer. Almost always, with minor variations: FAR. Realchute TACLS + Kerbal Health || USILS CLS KIS + KAS Waypoint Manager ContractConfigurator + various contract packs StageRecovery || FMRS Most of Nertea's stuff Most of SuicidalInsanity's stuff ReStock + ReStockPlus

It could indeed, and it depends on the manufacturer of your GPU whether or not they bothered to implement the feature (or application profiles at all for that matter). I can't speak to AMD or Intel, but I can say Nvidias "control panel" is missing many features on GNU/Linux - FPS limiting included. The best option I am aware of right now for this would be MangoHud.

So I see. But you didn't list versions, so it was only by chance that I stumbled on that updated thread. Again, you didn't list versions, so there was no way for me to know that. Here we are wasting time playing 20 questions. Nevertheless, that's what is required for a bug-free modded KSP experience. Perhaps you should consider using a mod manager? If you can't keep track of which versions your mods are compatible with, how do you expect anyone else to when they don't even know what versions you are running in the first place? I just gave you two easy ways of providing that information... Open your log file and search for the word "NullReferenceException", then look at the "at <foo>" lines following it, where <foo> is the name of a mod method or DLL filename. It's usually pretty obvious what it belongs to. In your case I see exceptions from OrbitalDecay, then KerbalEngineer, then a vessel getting NaN orbit parameters, and then a bunch more exceptions from stock KSP methods. One of those first two is quite possibly causing all the others, and the presence of MiniAVC is very possibly causing all of them. If there's nothing obvious and removing the mods I mentioned don't fix it, then you'll just have to do it the old-fashioned way , as we've all had to at some point: Remove a few mods at a time until you figure out what's causing it.

Looking good so far. Eh, It happens. This is why we test things.