sal_vager

I found this, it may help you

The runways start position is a long way from the shore, so no, I won't be doing that.

I can't tell Mavi, can you try a fresh save and vessel please.

Oh by the way, anyone still trying to make OpenGL work could try these new commands. If you're having trouble with the standard -force-opengl, forcing a different version may help.

Just need a longer ramp

I launched a catamaran from the pad, it's too far from the runway.

This kind of thread really should be in Support, moving!

You know, the ckan devs could fix their software so it uses the path set by the user as the working directory before starting KSP... I mean, that would be the sensible thing to do, seeing as it's their software calling the KSP.exe from outside the games folder... Nah, obviously it's all Squads fault.

What poll?

We probably won't see a dock any time soon, which is a shame as it'd make it easier to recreate SpaceX style barge low velocity impacts landings. Until then I'll keep doing this.

Mavi, where have you installed ckan? If the ckan.exe is not in the KSP folder, and you set the path to KSP.exe within ckan, ckan will try to start KSP from whatever folder the ckan.exe is in. If this is your desktop, KSP won't find the settings.cfg, PartDatabase.cfg or Physics.cfg, and it will be forced to use the built-in defaults. As Streetwind says, these are incorrect and will cause the symptom you describe, and now you have deleted the Physics.cfg you will need to get that file either from the KSP.zip or from my Linux thread. To fix your issue, you will need to put the ckan.exe inside the KSP folder, replace Physics.cfg, and run ckan from there. If you really need ckan on your desktop you can make a shortcut to it in Windows.

Separate quality settings for non-part textures would be nice yes. Try it, it would be interesting to know how it turns out. Yep, that's why I looked for .dds files in the KSP root directory, since 1.0.x all the stock textures are .dds now, but the ones in the asset folders aren't so easily deleted. Edit: .assets archive files I should say.

In the part.cfg, change "retractable = false" to "retractable = true"

Heh, I knew I should have not done this from memory, you can get this far... But that's it. Poor Bob can't see!

Yep, every .dds texture outside the asset files were nuked, not just those in Parts, and everything but the Mk1-2 IVA in the later test. Also, folder size has virtually no correlation to the size loaded into memory But the problem with fully removing IVA's is that if you do that you can't load any pod or cockpit that uses them.

Hi cowswag Help us help you by checking out the thread here, this issue doesn't sound familiar so we'll need more info.

Sometimes players ask about running KSP on old PC's with limited resources, and the usual recommendation is to use active texture management on aggressive to compensate for Squads choice to preload all part textures. But lately I see people posting that even ATM isn't helping, since 1.0.x all the Squad textures have been converted to the more memory efficient .dds format, but rather than mess around with ATM I thought I'd see what would happen if they were removed completely. Bare in mind this just covers initial memory use with a stock install, any issues with PQS terrain caching, requestresource, the GUI or any addons aren't covered here. All tests were with 32bit KSP on Linux, as 64bit programs naturally use more memory, and all memory is shown in megabytes, and this is RAM, not the size on the hard drive. So first I needed a baseline, I unzipped a new copy of 1.0.4, opened htop, started a new game with all settings on their defaults, put a KerbalX on the pad and flew to orbit... Scene Memory Start 1011 KSC 1145 VAB 1179 Pad 1146 Flight 1147 Orbit N/A That's a big difference from one setting change and memory used is lower than I expected it would be, so maybe the lower texture setting works better with the default SM3 shaders than it does with the SM2 and fallback shaders, also after asking around in IRC I found that all the textures in the asset files are already .dds, so I guess there's just a lot of them, they certainly have to cover a much larger area. So what can we take away from all this? Squads part preloading doesn't look like a problem, and ATM or even texture deletion isn't going to help much with memory use, but you could run out of memory if you use a lot of unoptimized parts. So insist on .dds whenever possible, and convert textures yourself if you have to, there's a converter here by Lilleman, as well as free tools like Imagemagick. But for a quick fix for high memory usage, turn down your texture quality.

That should have worked, there is no DRM even on the Steam version, so check your KSP.log and output_log.txt for the issue.

Try checking the box to stay logged on, I have to do that as well. Can't help with the emails though, sorry.

While it is true there was a memory leak with the 3rd party code used to warn the player of overheating parts in flight, that has already been resolved. As was already said, the garbage collector will still run even if there is little or nothing to collect, currently it is doing a fine job collecting the few megabytes left over by the older Unity UI object draw calls, which you can see yourself in the debug screen, performance tab. These draw calls will also be resolved in Unity5 with the unified UI, but the GC will still run because it's automatic, and while KSP does use a lot of RAM this is not the same thing as a leak, so "cleaner code" won't make a difference. Also, these GC runs are on the order of milliseconds and are hardly game breaking, they are more a slight annoyance than anything else. You seem to be basing your opinions on old information and incorrect assumptions here, it might help if you learned a bit more about memory leaks, garbage collection and why computers use them to manage memory.

Hi ogre14t, please upload the logs from an unmodded KSP, thank you.

By the Kraken this is old, 20th February 2014 vintage, and the name is officially "Funds" Closing this one. And all the K names suck, Munies is much better :Þ

That was fixed already.

This may help with the Nvidia drivers

Also the garbage collection is automatic and can't be disabled, and each time the GC runs it checks for all reachable objects and deallocates the areas of memory in the programs heap that didn't have a reachable object in it, this obviously takes time and if most objects are still in use then the memory released is small. More info here.