KSP's RAM issue Is Getting out of hand {But it cant be fixed Right Now}

[Tris_The]

DISCLAIMER I am not a Regular Forum user this is one of the few posts I've ever made.

DISCLAIMER I am not a Programmer or Coder I'm knowledgeable enough to understand code functions but I do not write them.

 

--->Steam Post<---

 

Please Notice:

This is a culmination of testing I have done for problems I've seen unanswered at an attempt to allow new comers to understand a portion of what limitations they will have to account for while playing the game there are a lot of quick justifications made without the cold complicated truth of the matter that I feel ColdJ and Lisias down below came in clutch answering. These issues do not make the game unplayable it just makes it confusing to understand why, for some (myself included), without a "first page" understanding of the issue especially with the dozens of posts with hundreds of comments of fragmented information.

 The Game in its current state is having certain problems that are bound to occur if you are interested in it and want more out of it.

hopefully the comments to this post help clarify both the argument and the lack of a resolution for the issue . 

 

Whats The Problem

So I've been doing some mod testing to create a modpack that runs stably and I have run into the issue I keep seeing casually ignored that stops this game from being modernized.

 The RAM
Yes its talked about plenty but don't see anyone talking about the real problem and with the release and failure of KSP 2 something should be done to bring back KSP 1 so its not just its base gimmicks.

 

What I've Noticed

The main thing I noticed, KSP is loading all stock assets, old assets, DLC assets essentially the entire game plus all the mods you install. Then it is loaded into Cache on RAM instead of pulling from a caching file on storage so at all times the entire game is loaded on ram, not the engine, not the current assets, everything minus like maybe a Gig, and thats not including the doubling bug. Currently I have an install over 16 Gb and it is pulling 8Gb RAM at the Main Menu, 14Gb at KSC, VAB, and Luanchpad. Of course as I'm writing this its being on its best behavior but it will reach 20 Gb when it boots and at times almost 30 GB while playing and my computer doesn't freeze out but SignalRGB breaks, Youtube Breaks and whatever else depends on the same rendering instruction sets as KSP.

 

What Does That Even Mean

First it means don't B!#@h about there being to many mods that isn't the problem never has been the game runs perfectly fine with several hundred mods. The problem is KSP is doing something most other games avoid which is loading the entire game repository into ram.... its why your latest COD game can be over 200Gb and not use well (ill do a quick guesstimate in comparison the the game content to cache ratio of KSP) 168Gb or so in RAM. So while people are trying to back up the statements of you have to many mods or its simulating an entire solar system understand that's not how it works. KSP is storing ALL of the game files in RAM to be swapped in and out of the game instance and simulation runs on CPU "~most likely" and the data is stored in a sub 100Mb file. KSP needing any more resources outside of the capacity of the game itself is unfounded.
 

Whats Going On Then In plain text

KSP is loading all assets on runtime into RAM disallowing future expansion for modernization. On top off that a reoccurring bug, acknowledged by the community and only truely addressed "recently" in a single thread, causes the game assets the load twice or even three times into RAM on warm up which can lead to PC wide stack overflow Crashes with 1.12+ Versions of the game.

Thread mentioned: https://steamcommunity.com/app/220200/discussions/0/3392923906939515058

 

What Should We Try

What would work the best is if managed to convince what remains of KSP 1 Development to Modders find a way to implement a advanced bootstrapper that integrates with LODs and Occlusion Culling checks so when game assets are loaded at launch it would simply be for a asset check then it will call assets during gameplay rather than packing the RAM up before hand. Essentially the game needs a system to call on assets when they are needed instead of the old fashion method of load everything and don't worry. Maybe this is something modders can work on simply we need something to at least patch the bug currently happening cause at least my computer (not a potato) cant handle the game taking wayyy wayyy more resources than it needs for any reasonable purpose I've been getting flashing screens, laggy windows issues and more. Mostly, just Brainstorm Right now.

 

Ok That's All

I've Spent my time organizing and setting up my game plenty of reinstalls over the years and I'm hoping to be able to play at some point without the game breaking my computer. I've gotten it stable so far but at this point its seeming like a game you need a special dedicated computer to run. Anyways that's my Bit, for those who need it Specs are Below (not that it really matters in this context)

 

~SPECS~

OS - Windows 11
CPU - Ryzen 7 5800x @ ~4.62 - 4.75 Ghz
RAM - 32GB @ 3.2Ghz
GPU - MSI Nvidia RTX3060Ti 8Gb GRAM (Full while running)
 

Programs tested with running

- Chrome (Unstable - especially YT)
- Discord (Stable - Can even Stream)
- SignalRGB (Unstable - Theme Engine crashes clogs rendering instruction sets even bugs out CKAN
- OBS (Stable maybe - didn't test much)
- Ableton (Stable - I use this for Mic and audio input)
- Focusrite Scarlett drivers (Unstable - un-syncs device audio clock I get BSODs in ARMA3 because of this guy)
- Task Manager - (started to skip update repaints)


P.S. As of Writing this the ram usage has dropped to 11.5Gb giving me reason to believe the game has the implications to achieve what I am proposing but is using the utility's to a very poor margin. And I should also Address, Caching files don't get cleared quickly. enough

Edited 4 hours ago by Tris_The
Final format

[Anth]

Main issue is that there is a memory leak that was introduced with 1.2, I think relating to the Unity garbage collection. When the game changes between scenes it appears to load the universe every time and it causes the memory to go up and up and also the load times get longer and longer.

In addition the bigger the save file the faster the memory leak increases.

If this issue was eliminated then most of the memory issues would be gone.

[Tris_The]

which would most likely be eliminated through a bootstrapper that actively calls on objects limits the game cache where by frequent garbage collection would not happen except for unloading preferably relegated to another sub-program or the bootstrapper itself. I guess I should recognize that we don't have the source code for the game but regardless its been 10 years and nobody has anything. maybe unity garbage collection shouldn't be used maybe someone should make a patch or a extra loaded in process that piggybacks the Gar Collection on a 3rd party.

BTW I'm not a programmer I can understand how to determine verbose functions but don't ask me to write any code, Im more of a project manager.

[Tris_The]

11 hours ago, Anth said:

Main issue is that there is a memory leak that was introduced with 1.2, I think relating to the Unity garbage collection. When the game changes between scenes it appears to load the universe every time and it causes the memory to go up and up and also the load times get longer and longer.

In addition the bigger the save file the faster the memory leak increases.

If this issue was eliminated then most of the memory issues would be gone.

Forgot to quote you on my last post but

Is it only changes between scenes because a lot of the time when I get the memory leaks it is in loading but there are other times to when I'm mid flight it seems like it does the same loading prosses im assuming over a corrupted and/or missing file and it starts adding more data into RAM than consists in the whole playable portion and engine of the game combined twice... All I can say is this cant be good for my computer it, isn't even crashing right. 

[HebaruSan]

18 hours ago, Tris_The said:

what remains of KSP 1 Development

Good luck with that. The remaining team members are:

 

 

 

 

[Mr. Kerbin]

@Tris_The,  @HebaruSan means that there are no more developers. No one works on KSP1 or 2- they have all been fired.

[Tris_The]

2 hours ago, Mr. Kerbin said:

@Tris_The,  @HebaruSan means that there are no more developers. No one works on KSP1 or 2- they have all been fired.

 

2 hours ago, HebaruSan said:

Good luck with that. The remaining team members are:

 

 

 

 

useless semantics anyone, ok and understood, sorry to get agitated what about not detracting from this by pointing out the obvious what about modding. Why is everyone so gun ho on acting like this issue doesn't mean anything lets brainstorm maybe I've been through hundreds of forum posts about the RAM issue and not a single one provides any intelligent thinking and comments just elaborate recreations of the phrase just get a better computer or use less mods, but you download one mod its got dependencies those dependencies have features that drastically improve the game but its only dependent on the RAM nothing else not storage space, not simulation, just RAM.

 

I apologize for the Rant was getting liquided over reacting but modding I forgot to put a proper acknowledgment for modding in my statement about "what to do".

Edited yesterday at 03:39 AM by Tris_The
apology for rant

[Ultimate Steve]

Is this one of the memory leaks that KSP Community Fixes fixes, or is it deeper than that?

[Anth]

9 hours ago, Tris_The said:

Forgot to quote you on my last post but

Is it only changes between scenes because a lot of the time when I get the memory leaks it is in loading but there are other times to when I'm mid flight it seems like it does the same loading prosses im assuming over a corrupted and/or missing file and it starts adding more data into RAM than consists in the whole playable portion and engine of the game combined twice... All I can say is this cant be good for my computer it, isn't even crashing right. 

The memory leak I am talking about in my experience overshadows any other memory leaks. The developers of KSP1 at one point had fixed some other memory issues but they weren't even noticeable because of this one.

If its happening over corrupted/missing files that would show up in the log file?

1 hour ago, Ultimate Steve said:

Is this one of the memory leaks that KSP Community Fixes fixes, or is it deeper than that?

No idea.

Also the developers said it wasn't able to be fixed, so I am not sure what mods could do to counter it.

Though, what they might have been meant by it not being fixable, might have been that it would have taken too much time and money to fix it.

[Zombie_Striker]

21 hours ago, Anth said:

Main issue is that there is a memory leak that was introduced with 1.2, I think relating to the Unity garbage collection. When the game changes between scenes it appears to load the universe every time and it causes the memory to go up and up and also the load times get longer and longer.

In addition the bigger the save file the faster the memory leak increases.

If this issue was eliminated then most of the memory issues would be gone.

So thats why loading the VAB/Tracking station takes soo long.

I'm unsure if this is possible, but are modders able to create custom scenes from within the KSC? So, for example, recreating  the VAB without having to go  into the VAB scene fort parts? If so, you could use harmony to disable the base-game ship builder, implement your own, and that would reduce the amount of times the world needs to be reloaded. Same for tracking station: Implement your own tracking station ui from the KSC, and thats one less scene to reload.

[HebaruSan]

10 hours ago, Tris_The said:

useless semantics anyone

Sorry, I would have tried to be funnier and more sarcastic, but I didn't think it would survive moderation.

10 hours ago, Tris_The said:

I've been through hundreds of forum posts about the RAM issue and not a single one provides any intelligent thinking and comments

And now we have hundreds-plus-one!

[ColdJ]

10 hours ago, Tris_The said:

Why is everyone so gun ho on acting like this issue doesn't mean anything

Combat fatigue.

There is a high chance that someone will reply with a post to tell me I am wrong, but this is my understanding of the situation.

In the rush to keep updating KSP with new features they did not stop and correct mistakes in the base code when it would have been easier to do so. So each update was built on flawed code and added more flaws which were built on etc.

Mods cannot truly fix the underlying flaws and it would take going back to the early versions of KSP and fixing the code then adding the the next update, finding it's flaws, fixing them, then implementing the next etc. Repeat until you get to the last iteration.

Technically this was the original mission of the start of KSP2, with graphical improvements then built on top, then now with a stable base, new features developed. Sadly due to changes of mind and choices made, this went out the window.

So only people legally allowed to work on the copyright protected code could actually fix it. Which is not going to happen currently due to all those who could have, being let go.

Members have been asking that it be released publically so that passionate independent programmers could legally get in and fix it, but currently that has not happened, so nobody can get in and fix it without opening themselves up to litigation.

Most people who are interested in this topic and are long time members, who have been following through all the events for a decade, are understandably weary and so when someone brand new comes in and posts as if all this hasn't been rehashed over and over for years. They may accidentally reply in a sarcastic manner.

It is not you personally they are out to upset. They are just tired of the whole situation.

[Fizzlebop Smith]

Additionally, there have been other efforts made to correct various memory problems.

KSP Community Fixes (Mod)

Heap Padder (Mod)

KSP Memory Allocation Fix (Utility)

I too only have the barest understanding of code, but thought there would be some mention of effort already made. It just seems that someone would do a quick "KSP1 Mem Allocation Fixes"

Interwebz search before posting such a length call for discourse. Referencing those past discussion would lend more insight on how to focus / compose such a post.

As it is.. it cones off as a "Hey everyone. I noticed something that has been overlooked for 15+ years. Where do I send the bug report or how bout one of you ace modder get on this?"

[Scarecrow71]

51 minutes ago, ColdJ said:

Mods cannot truly fix the underlying flaws and it would take going back to the early versions of KSP and fixing the code

@Tris_The

What ColdJ said above.  The only way to fix the memory leak issue is to get under the hood and rewrite the sections of code that deal with this.  Modders can come close, like they did with the Community Fixes.  But without access to the actual source?  Not going to happen.  Doesn't mean it's not an issue, but rather it's unfixable unless Take Two wants to make the code public and open source.

[Lisias]

On 9/29/2024 at 3:22 AM, Tris_The said:

   The main thing I noticed, KSP is loading all stock assets, old assets, DLC assets essentially the entire game plus all the mods you install. Then it is loaded into Cache on RAM instead of pulling from a caching file on storage so at all times the entire game is loaded on ram, not the engine, not the current assets, everything minus like maybe a Gig, and thats not including the doubling bug. Currently I have an install over 16 Gb and it is pulling 8Gb RAM at the Main Menu, 14Gb at KSC, VAB, and Luanchpad. Of course as I'm writing this its being on its best behavior but it will reach 20 Gb when it boots and at times almost 30 GB while playing and my computer doesn't freeze out but SignalRGB breaks, Youtube Breaks and whatever else depends on the same rendering instruction sets as KSP.

This is not necessarily bad - but can get uncomfortable pretty quick as you install more and more texture intensive add'ons.

Essentially, KSP was meant since the beginning to be as "middle game load free" as possible. The original designer didn't wanted loading pauses while transitioning between reference frames in Space, or while flyng around Kerbin.

Since at that time the game was fitting easily on a 2G RAM machine (this thing was originally meant to run on 32 bits CPUs!!!), this really wasn't a problem for the vanilla game.

But then 64 bits versions came, memory intensive add'ons became popular, and now we have this new situation that weren't intended to happen on the game's original architecture.

I think the situation is still salvageable with some clever coding tricks, but access to the original Source Code is essential to do a good job without playing havoc on the installed, legacy, code base in use.

 

On 9/29/2024 at 3:22 AM, Tris_The said:

What Does That Even Mean    First it means don't B!#@h about there being to many mods that isn't the problem never has been the game runs perfectly fine with several hundred mods. The problem is KSP is doing something most other games avoid which is loading the entire game repository into ram.... its why your latest COD game can be over 200Gb and not use well (ill do a quick guesstimate in comparison the the game content to cache ratio of KSP) 168Gb or so in RAM. So while people are trying to back up the statements of you have to many mods or its simulating an entire solar system understand that's not how it works. KSP is storing ALL of the game files in RAM to be swapped in and out of the game instance and simulation runs on CPU "~most likely" and the data is stored in a sub 100Mb file. KSP needing any more resources outside of the capacity of the game itself is unfounded.

You are comparing oranges with apples here. COD is not a open world.

A better comparision would be MS Flight Simulator 2020. But even this one is not exactly accurate, because you don't keep dozens of crafts "flying" around the Kerbol System and can to switch to any of them at any time.

You see, you can have a craft orbiting Kerbin, another one in transit to Dune and a Station orbiting Jool. And you may need to switch to any of them at any instant for a planned burn or something, and the original game designer wanted that such switching would be absolutely transparent and loadless. What he did, indeed, accomplished with success using the vanilla game.

Yes, I agree that nowadays a clever memory management is desperately in need but, and again, this is not a problem for the base game. I would agree with you if you were complaining about KSP2, but KSP¹, definitively, can't be blamed for what we have now. WE DUG THIS HOLE OURSELVES.

 

On 9/29/2024 at 3:22 AM, Tris_The said:

   KSP is loading all assets on runtime into RAM disallowing future expansion for modernization. On top off that a reoccurring bug, acknowledged by the community and only truely addressed "recently" in a single thread, causes the game assets the load twice or even three times into RAM on warm up which can lead to PC wide stack overflow Crashes with 1.12+ Versions of the game.

I think you are wrong here. What's hurting right now are memory leaks and terribly annoying bugs on the code base.

Like this exactly bug that you mentioned - see, this is a bug. Not a glitch from an architectural decision.

One of the terrible bugs in need to be tackled down is about how the game's concurrency utterly breaks when you are using asymmetrical CPUs (that ones with P-Core and E-Core thingies).

Synchronization on KSP (as a matter of fact, in Unity) are.... brittle. Everything assumes that all CPUs are running in the same speed, so there's no difference in how much time a process will be tackled down if it's assigned to a different CPU in the middle of the process.

With asymmetrical CPUs, this assumption utterly breaks - and anything relying on things happening deterministically across the whole CPU utterly breaks.

Try to set up the KSP's process "Affinity" to use only P-Cores and I think this particular problem will be mitigated for you.

This is not a new problem, by the way, some other strange thingies can be explained but this problem.

 

On 9/29/2024 at 3:22 AM, Tris_The said:

   What would work the best is if managed to convince what remains of KSP 1 Development to Modders find a way to implement a advanced bootstrapper that integrates with LODs and Occlusion Culling checks so when game assets are loaded at launch it would simply be for a asset check then it will call assets during gameplay rather than packing the RAM up before hand. Essentially the game needs a system to call on assets when they are needed instead of the old fashion method of load everything and don't worry. Maybe this is something modders can work on simply we need something to at least patch the bug currently happening cause at least my computer (not a potato) cant handle the game taking wayyy wayyy more resources than it needs for any reasonable purpose I've been getting flashing screens, laggy windows issues and more.

They already tried that. It helped on loading times, but didn't fixed (obviously) the flaws I mentioned above (as they are essentially Unity being Unity, and not KSP¹'s fault on the most part).

What I think you are missing is that a way worse problem is... well... memory leaks. Due how Unity do things, the Garbage Collector is always in deficit and is never really allowed to do a proper deep garbage collecting, so the tendency over time is to have lots and lots of memory being left on the bin can to never be collected and reused.

What you are proposing will increase the pressure on the GC, probably making things worse instead of better.

You will find the gory details here:

But, TL;DR, setting the environment variable MONO_THREADS_PER_CPU to 1 before launching KSP MAY mitigate a bit the problem (besides not really solving it). Interesting enough, doing it increase the FPS a very tinny bit, and decreased my CPU's temperature while running KSP (keep in mind, however, that I play on a potato - your mileage will vary).

I also managed to decrease the system temperature and increase the battery life on the Steam Deck by using this trick, and not only on KSP, but on any Unity game I'm playing lately.

I think you should try this trick - but, keep in mind, it may bite you - it depends on what you have installed on your rig. Try this trick on a disposable KSP first, before using it on your "production" KSP installments.

[modus]

I am a total layman so I dont know if this is related, but do any of you guys tried this

 

I haven't because I don't really understand it, but some users seem to be happy with what this does?

[Lisias]

4 hours ago, modus said:

I am a total layman so I dont know if this is related, but do any of you guys tried this

I haven't because I don't really understand it, but some users seem to be happy with what this does?

It may help if you are multitasking while playing, but it doesn't really fix any memory leak.

This is how things work: KSP allocates memory preemptively, because it thinks (not wrongly) that you will need any memory you free when changing scenes. For example, when changing from Flight into KSC, everything "alive" goes on rails and so all the living parts, physics engine data et all are deallocated.

But KSP knows that you will go back to flight sooner or later, and so it keeps all the memory for itself instead of returning it to the System.

This tool kicks KSP regularly to force it to return freed memory to the system regularly. This makes changing scenes a bit slower, because asking the System for memory is a bit slower than just keeping it, but it allows other processes to have some memory left while you play KSP. It have the drawback of heavily fragment the System Heap, so it's common that once you exit KSP and go to the browser (another memory guzzler), the system freezes for some minutes as soon the browser needs some extra memory as the Kernel is defragmenting the huge mess that became the System Heap.

Keep in mind, however, that these kicks only forces KSP to free memory that it managed to collect from the garbage collector. Memory Leaks that are not freed by the GC are, obviously, not returned.

On the other hand... Reading that thread suggested me that GC is induced to do a deep Garbage Collecting before returning memory to the System, so it may be another viable mitigation for the problem I mentioned on my last post.

I would suggest trying both mitigations at the same time to see if you get any further improvement.

[Tris_The]

15 hours ago, ColdJ said:

Combat fatigue.

There is a high chance that someone will reply with a post to tell me I am wrong, but this is my understanding of the situation.

In the rush to keep updating KSP with new features they did not stop and correct mistakes in the base code when it would have been easier to do so. So each update was built on flawed code and added more flaws which were built on etc.

Mods cannot truly fix the underlying flaws and it would take going back to the early versions of KSP and fixing the code then adding the the next update, finding it's flaws, fixing them, then implementing the next etc. Repeat until you get to the last iteration.

Technically this was the original mission of the start of KSP2, with graphical improvements then built on top, then now with a stable base, new features developed. Sadly due to changes of mind and choices made, this went out the window.

So only people legally allowed to work on the copyright protected code could actually fix it. Which is not going to happen currently due to all those who could have, being let go.

Members have been asking that it be released publically so that passionate independent programmers could legally get in and fix it, but currently that has not happened, so nobody can get in and fix it without opening themselves up to litigation.

Most people who are interested in this topic and are long time members, who have been following through all the events for a decade, are understandably weary and so when someone brand new comes in and posts as if all this hasn't been rehashed over and over for years. They may accidentally reply in a sarcastic manner.

It is not you personally they are out to upset. They are just tired of the whole situation.

 

13 hours ago, Lisias said:

This is not necessarily bad - but can get uncomfortable pretty quick as you install more and more texture intensive add'ons.

Essentially, KSP was meant since the beginning to be as "middle game load free" as possible. The original designer didn't wanted loading pauses while transitioning between reference frames in Space, or while flyng around Kerbin.

Since at that time the game was fitting easily on a 2G RAM machine (this thing was originally meant to run on 32 bits CPUs!!!), this really wasn't a problem for the vanilla game.

But then 64 bits versions came, memory intensive add'ons became popular, and now we have this new situation that weren't intended to happen on the game's original architecture.

I think the situation is still salvageable with some clever coding tricks, but access to the original Source Code is essential to do a good job without playing havoc on the installed, legacy, code base in use.

 

You are comparing oranges with apples here. COD is not a open world.

A better comparision would be MS Flight Simulator 2020. But even this one is not exactly accurate, because you don't keep dozens of crafts "flying" around the Kerbol System and can to switch to any of them at any time.

You see, you can have a craft orbiting Kerbin, another one in transit to Dune and a Station orbiting Jool. And you may need to switch to any of them at any instant for a planned burn or something, and the original game designer wanted that such switching would be absolutely transparent and loadless. What he did, indeed, accomplished with success using the vanilla game.

Yes, I agree that nowadays a clever memory management is desperately in need but, and again, this is not a problem for the base game. I would agree with you if you were complaining about KSP2, but KSP¹, definitively, can't be blamed for what we have now. WE DUG THIS HOLE OURSELVES.

 

I think you are wrong here. What's hurting right now are memory leaks and terribly annoying bugs on the code base.

Like this exactly bug that you mentioned - see, this is a bug. Not a glitch from an architectural decision.

One of the terrible bugs in need to be tackled down is about how the game's concurrency utterly breaks when you are using asymmetrical CPUs (that ones with P-Core and E-Core thingies).

Synchronization on KSP (as a matter of fact, in Unity) are.... brittle. Everything assumes that all CPUs are running in the same speed, so there's no difference in how much time a process will be tackled down if it's assigned to a different CPU in the middle of the process.

With asymmetrical CPUs, this assumption utterly breaks - and anything relying on things happening deterministically across the whole CPU utterly breaks.

Try to set up the KSP's process "Affinity" to use only P-Cores and I think this particular problem will be mitigated for you.

This is not a new problem, by the way, some other strange thingies can be explained but this problem.

 

They already tried that. It helped on loading times, but didn't fixed (obviously) the flaws I mentioned above (as they are essentially Unity being Unity, and not KSP¹'s fault on the most part).

What I think you are missing is that a way worse problem is... well... memory leaks. Due how Unity do things, the Garbage Collector is always in deficit and is never really allowed to do a proper deep garbage collecting, so the tendency over time is to have lots and lots of memory being left on the bin can to never be collected and reused.

What you are proposing will increase the pressure on the GC, probably making things worse instead of better.

You will find the gory details here:

But, TL;DR, setting the environment variable MONO_THREADS_PER_CPU to 1 before launching KSP MAY mitigate a bit the problem (besides not really solving it). Interesting enough, doing it increase the FPS a very tinny bit, and decreased my CPU's temperature while running KSP (keep in mind, however, that I play on a potato - your mileage will vary).

I also managed to decrease the system temperature and increase the battery life on the Steam Deck by using this trick, and not only on KSP, but on any Unity game I'm playing lately.

I think you should try this trick - but, keep in mind, it may bite you - it depends on what you have installed on your rig. Try this trick on a disposable KSP first, before using it on your "production" KSP installments.

OK ok yea, I was making some broad comparisons and generalizations in the points of getting someone to ACTUALLY explain why we cant do anything and now thank you Lisias for taking your time to break down the details seeing alot of this makes things more understandable. I've been trying to find one reason for these issues out side of laziness imposed as sarcastic backlash for over 5 to 6 or so years (plus not to mention the same with everything else in life for longer). So thank you for making it so anyone who needs this information, say people thinking of spending money on the game giving more money to take two, from digging through trash for an ounce of information. I've  personally been thinking about buying the expansion packs but now knowing the affiliation F this I'm out I ain't buying that.

People need to know this info especially so they can at least understand that this isn't fixable without boycotting TT I hope moderators pin this because if people are still posting to this sub-forum with it being called suggestions and development Clearly some false ideas are still being propagated like there are dozens of requests for additions to the game and no recognizable reason why not to ask so any pushback from users just seems like an endorsement for laziness rather a serious "fixable" problem with root code being systematically blocked by serious issues in business politics. I have no quarrels with anyone just weird to see secrecy in specific politics being the reason for of all things a video game having problems which I get it happens all the time just what the heck I'm gunna advocate a little for everyone and just say its wrong.       

12 hours ago, modus said:

I am a total layman so I dont know if this is related, but do any of you guys tried this

 

I haven't because I don't really understand it, but some users seem to be happy with what this does?

 

8 hours ago, Lisias said:

It may help if you are multitasking while playing, but it doesn't really fix any memory leak.

This is how things work: KSP allocates memory preemptively, because it thinks (not wrongly) that you will need any memory you free when changing scenes. For example, when changing from Flight into KSC, everything "alive" goes on rails and so all the living parts, physics engine data et all are deallocated.

But KSP knows that you will go back to flight sooner or later, and so it keeps all the memory for itself instead of returning it to the System.

This tool kicks KSP regularly to force it to return freed memory to the system regularly. This makes changing scenes a bit slower, because asking the System for memory is a bit slower than just keeping it, but it allows other processes to have some memory left while you play KSP. It have the drawback of heavily fragment the System Heap, so it's common that once you exit KSP and go to the browser (another memory guzzler), the system freezes for some minutes as soon the browser needs some extra memory as the Kernel is defragmenting the huge mess that became the System Heap.

Keep in mind, however, that these kicks only forces KSP to free memory that it managed to collect from the garbage collector. Memory Leaks that are not freed by the GC are, obviously, not returned.

On the other hand... Reading that thread suggested me that GC is induced to do a deep Garbage Collecting before returning memory to the System, so it may be another viable mitigation for the problem I mentioned on my last post.

I would suggest trying both mitigations at the same time to see if you get any further improvement.

And hey guess what that's a possible fix for the Instabilities I was testing for yes longer load times but its better than RAM death, Sadly its only on 1.7.2. Sadly Development was one time and is now dead it supposedly works but the app is ear(bad words).

Edited 4 hours ago by Tris_The
typo