Akaji

I'm also seeing the quad core explode if I go to 3x or 4x physics warp. My quad core was sandwiched between a 1.25m fuel tank (the longest stock one) and the basic stock command pod. It had a magnetometer, science bay, mysterious goo, and orbital telescope. I haven't tested with hex or octo yet. I haven't tried with just Univ. Storage and no other mods.

Looking through your code, I'm wondering if there is a leak related to the projection map. I'm having difficulty identifying where the projected biome map is getting cached. It looks to me like any time GameEvents.onDominantBodyChange or GameEvents.onVesselChanged triggers and the new body is not the current body, the projected biome map is regenerated. Since 'current' is set to null prior to beginning generation, if onDominantBodyChange is sent with from==to (e.g. Kerbin to Kerbin) then the map would get regenerated. It also looks like the map generation will get restarted any time that onVesselChange triggers, even within the same SOI, for the same reason. If GameEvents.onDominantBodyChange is triggered when going from the space center to the launchpad, and the space center is considered to have a null dominant body, it looks like the projected biome map will get regenerated. It's possible I was mistaken about where the memory leak happens - it could happen when going to the launch pad, but I only was able to notice it when returning to the space center. It's worth noting that the launch scene uses less memory than the space center scene, so that could be obfuscating where the leak is really happening. (Sorry if I'm reading the code wrong - I haven't developed in C# before, and my Java experience doesn't translate 1:1) On a related note, does UnityEngine's Texture2D implementation handle resource disposal automagically with GC? If not, then the projectedMap needs to be disposed/destroyed prior to being set to null so that the underlying resource doesn't stick around indefinitely. Even if GC should handle the resource, a leak could occur if something prevents the Texture2D object from being collected. I didn't see anything in your code that explicitly allowed the object to be held on indefinitely, but it could be happening somewhere else (maybe Unity itself? I've heard that its resource garbage collection is iffy). It's also possible that there's some wonkiness with the C# iterator function causing it to hold on to the resource when it gets interrupted. It might be worth trying manually collecting (dispose/destroy) the projection map prior to unsetting it just to see if that fixes the leak.

There seems to be a memory leak with this plugin. When returning to the space center from flight, memory usage jumps by 20+ MB more than it does in stock (stock also sees the memory usage jump when returning to the space center, but it isn't as severe and the jump reduces in size each time you return). I have a large number of mods installed, so this is causing me to bump up against the ~3.5GB memory barrier for 32-bit KSP and crashing. I'm running KSP 32-bit v1.0.4 with ScienceAlert v1.8.7 on Win7 64-bit. I'm using the --force-opengl command-line argument to make KSP take less memory on startup. To reproduce: With just KSP and Science Alert installed, start a new campaign. Build a ship that's just a command pod. Go to the launch scene for the ship, but immediately recover the ship. Repeat while watching memory usage in the task manager.