steve_v

How much RAM you have is far less relevant than how much RAM is free. If there's something else running that uses much memory, that would explain it. I have on many occasions found zombie KSP processes running long after closing the game, this may be a Unity on GNU/Linux thing, or it may not. Check your task manager for anything eating lots of memory. Not from where I'm sitting, but then I run GNU/Linux so I'm using the OpenGL renderer. It doesn't use anywhere near 4GB VRAM at any rate. At this point I'd try a clean reinstall of the game without any -force-whatever command line options, just in case something screwey (like duplicated textures) is going on with your install. I don't know a lot about DirectX, but I don't think it should be using that much VRAM... Or that much system RAM either for that matter, not if you have no part or graphical mods installed.

I use 0.6-0.8 for kerbin-only stuff (which I like to throw around a bit), and 0.2-0.3 for spaceplanes where dry mass is a big deal. As for stability, the latest FARc seems fine in 1.9.1, I have no major issues with it. Yeah, true. This is KSP though, so assuming depleted-uranium parts, no ground-effect, and an intent to go to space.

No, but it did rattle loose a recollection of something I heard about recently. Are you using TweakScale? MakingHistory parts? Does this sound at all like what you're seeing? From what I gather it's not actually a bug in TweakScale, just something in KSP 1.9.x that TweakScale uncovered... Not sure what exactly is required to trigger it, but if it sounds familiar you might ask Lisias for details...

Could not allocate memory: System out of memory! Trying to allocate: 673616B with 32 alignment. MemoryLabel: VertexData Allocation happened at: Line:171 in C:\buildslave\unity\build\Runtime/Graphics/Mesh/VertexData.cpp Memory overview [ ALLOC_DEFAULT ] used: 788950121B | peak: 0B | reserved: 905653305B [ ALLOC_TEMP_JOB_1_FRAME ] used: 0B | peak: 0B | reserved: 1048576B [ ALLOC_TEMP_JOB_2_FRAMES ] used: 0B | peak: 0B | reserved: 1048576B [ ALLOC_TEMP_JOB_4_FRAMES ] used: 0B | peak: 0B | reserved: 33554432B [ ALLOC_TEMP_JOB_ASYNC ] used: 0B | peak: 0B | reserved: 1048576B [ ALLOC_GFX ] used: 712650660B | peak: 0B | reserved: 772866508B [ ALLOC_CACHEOBJECTS ] used: 770661720B | peak: 0B | reserved: 1061496968B [ ALLOC_TYPETREE ] used: 2271736B | peak: 0B | reserved: 5242880B [ ALLOC_TEMP_THREAD ] used: 32768B | peak: 0B | reserved: 5144576B (Filename: C:\buildslave\unity\build\Runtime/Allocator/MemoryManager.cpp Line: 1175) Crash!!! Could not allocate memory: System out of memory! Cause of problem looks pretty obvious to me.

Images are properly useless for debugging 99.9% of the time. What would be useful is the game log covering the time this occurred, as well as all the other stuff mentioned over here. You didn't provide any useful information, so there's no way to tell what caused it, let alone fix it. If you want the developers to see it, you'll need to reproduce it in an unmodded game and file a report on the bugtracker. Ain't nobody here but us chickens. Did you search the bugtracker? Break a solar panel? What? Meh, destroy the ship from the tracking station, then edit your save to revive the crew back at the astronaut complex (state = dead -> state = available). Much easier than starting a new game.

Dynamic Pressure Control Reduction. One of the flight assist toggles in the FAR window. Specifically put there to help in keeping your wings attached. That or turn more gently. Analogue control helps here, either by using a joystick or the time-honoured PWM fingers method (tapping controls rather than holding keys). DPCR helps a lot. Most things that help IRL will work in FAR too. Look at real aircraft, copy, adapt. Use one chute, centrally attached and on the lower half of the craft to force the nose down. Lock steering and stay off the brakes. Pray to the gods of Unity physics. The usual stuff. You and everyone else, ever since the new and "improved" wheel physics landed. We've been collectively whining at Squad about it for years. KSPWheel (+ the stock patches from KerbalFoundries) makes all this rubbish behaviour go away (in stock as well), but it has a performance tax in it's current incarnation. If you can live with that' it's a fix. If you can't handle performance with KSPWheel, you might calm the wheels demonic pogo-sticks down a little by twiddling the advanced tweakables (spring, damper). I've had limited success with this, but it's too much of a black-art to go into detail here even if I could articulate it, which I probably can not. TL;DR: KSPs wheels suck. Others have claimed it's just because we're doing it wrong, but I'll be blowed if I know how to explain that. You'll have to ask them.

?

Experience. KSP has suffered significantly over the years from Unity's limitations (particularly the garbage collector), and while there isn't really anything inherently wrong with the engine, it does have something of an image problem... There are a huge number of really really bad games made with unity, it's low-cost and ease of use lends it to minimum-effort products and the asset store is a goldmine for cheap asset-flips and even wholesale selling store assets as a complete game. Add to this that it's only games using the free version which get a big "made with unity" on the startup screens, and you see where it gets it's bad rep.

I'll add that this is often a good idea anyway. KSPs wheel physics get mighty janky (particularly under braking) at >80m/s, and for anything resembling an SSTO spaceplane you'll probably be landing faster than that if you want it to have a respectable payload fraction. Use drag chutes, ideally RealChute drag chutes.

Use the strength/mass sliders to make the wings stronger. Fly more carefully. Use DPCR. Install KJR if you haven't already. Beyond that, it's a tradeoff just like IRL - things that fly well at low speed don't fly so well at supersonic speeds and vice-versa. Flaps, slats, and variable wing geometry can help with this to a point. I've made many an aircraft that can land at <80m/s and still do mach 4+ at altitude, but you do need to watch how you handle the controls if you want the wings to stay attached. Real-life aircraft can't pull 15G in a turn without coming apart, and the same is true in FAR. Good question, I've always just relied on common-sense, test-flights, and experience. For the rest, see 1. Stop using SAS. Trim for level flight with trim. Reduce control authority at high velocity. Mechjeb can be used at a pinch, but you will have to muck with the attitude control window and even then it's usually far too aggressive for anything but attitude hold. Kramax Autopilot is considerably better as it's controllers can be tuned to work properly with just about anything. For most aircraft in FAR, you'd start by doubling the scalar on the pitch control and work from there. 'tis what I use, and with much success. It can even land for you.

I got tired of the constant whining about "unsafe site" a while back and dumped a letsencrypt cert + acme.sh on my server box. Doesn't make anyone any safer mind, but it shuts them up and it's pretty much zero maintenance. Ed. Oh doG, tell me it ain't so... Microsoft-IIS/10.0 *shudder* No nifty auto-renewing shell script for you then... Likewise. Since it was Nutscrape Navigator. *shudder*

Indeed.

You'll have to ask @alberro+ that one I'm afraid, I don't touch the stuff myself. It sounds like chrome's download protection whatchamacallit to me, I did hear something about a "strict" setting that prompts for any archive or executable not on some kind of google whitelist... But then I don't use that particular piece of spyware either, so ¯\_(ツ)_/¯

It sure does, both links work fine. There's nothing wrong with @R-T-Bs files, that warning is from your system. It's likely some "malware protection" (scarequotes intended) in your browser. Nothing anyone can do about it but you.

That doesn't help anyone to figure out your problem, least of all me. What might help is actually listing those those things you have tried and providing some system information and log files. At least we might be able to eliminate something from the near-endless list of possible causes. Before anyone else decides to pile on in with "me too" or "this is annoying", please read the pinned posts in this forum, particularly this one: Then look through at least the first few active or recently answered topics and see if you're hitting something like the recent timezone screwup. If none of that helps, tell us what you tried so we can eliminate it instead of going around in circles. And post logs. Always post logs. Without logs nobody knows if we're even talking about the same problem.

Looks a whole lot like GPU or GPU driver problems to me. Giving "error 0x887a0005" to google may be productive, as may updating (or downgrading) your nvidia drivers. Which also suggests that something has changed WRT your system rather than the game. There have been no updates to KSP in the last week, but there was an nvidia driver update on Monday.

Because it'd be ludicrously dangerous, that's why. Any one of those on it's own is frighteningly volatile and difficult to handle, let alone all three at once. Hydrogen is at least manageable, but Fluorine? Seriously? A substance that will burn ice and corrode glass? Imagine the paperwork.

Go play in the ocean, you'll see. Assuming it's working of course...

TBH I don't care overmuch about graphical fidelity anyway, especially not in a game like KSP. I'd much prefer time and effort went into engaging gameplay over fancy shadows. DX11 is fine. Hell, OpenGL is fine. I still play Doom II and Descent, the graphics don't bother me, because the games are fun. My only concern WRT graphics APIs in KSP is their contribution to that nasty CPU bottleneck. Interesting, though not particularly surprising. The name is still stupid. Non-vendor-locked is nice, absolutely-os-locked is not. My point exactly, though I'll admit I don't follow such things closely enough to pin a number on it. You might, and you probably do... But for the record I've met more than one "tech journalist" who didn't really know much of anything beyond the marketing hype he'd sucked up. Not saying it was you, not at all.. but I kinda have to put it out there.

Fair enough. I'd be annoyed if this was a bespoke engine early in development and they went with DXwhatever over Vulkan, but if Unity's Vulkan support requires a bunch of extra work to actually use you're probably right. It's likely too late in development for KSP2 to get vulkan or "DX12 ultimate" (pretty lame name btw nvidia), if it happens at all now it'll be long after release.

Not just useful on MacOS either, most of what you can do in a MacOS terminal will also work more or less the same in GNU/Linux, BSD, Solaris, and a bunch of other unix-like and/or POSIX compliant operating systems. It's good stuff to know. Glad to be of service.

Try it and find out. If it doesn't, recompile it and try it again.

Now there's a deliciously twisted show if ever there was one.

I don't know much about MacOS, but that there is a screaming filesystem permissions problem. My approach would be the generic *nix one, i.e. fixing permissions on the KSP root directory from a terminal. Recursive chmod & chown, that old jazz. There's probably a clicky GUI way of doing this too, but I don't know what it is. Google will undoubtedly tell you. I also hear Catalina comes with some new permissions-related aggravation, something regarding a "security and privacy" settings page in the system preferences gizmo that allows you to grant file permissions to applications. That's probably a good place to look for a start if you're not comfortable with the terminal.

Nothing, besides delivery method and some mostly pointless overlays and such. Is almost certainly an underlying system problem, not the game itself. What's your system RAM and pagefile size? If your pagefile is set to dynamic (as by default), how much free disk space do you have on the system partition? VRAM size? GPU type? Any system info at all? BG doesn't add anything exotic, but it does push memory use (both system and VRAM) up a fair bit. A period of freezing followed by a system crash sounds like it could be exhausting physical RAM, paging hard, then hitting some limit on pagefile size. But that's just a guess, which is all you'll get without some kind of log or core dump.