TC One

I guess I have a bug to report. Not sure though if it's a Dang It! bug or some sort of incompatibility with my other installed mods... So, the problem is that part failure is not persistent. If something fails and you unload and reload the scene the part is likely to be perfectly fine. It doesn't happen to all parts though. A bit of examples: 1. One of 6 antennas on my unmanned probe failed. It got red highlight and stuff, however it wasn't too critical, so I just ignored it. After certain time when I needed that probe again and switched to it from KSC said antenna was broken phisically, no red highlight, just part of the antenna missing (vanilla Communotron 16, when you break it you lose all telescopic parts and all that left will be the base). So... while not exactly the expected behavior it's at least persistent, good. 2. One of my solar panels servos malfunctioned during the unmanned mission. And again, it wasn't critical, so I continued the mission and after switching back to KSC to let the satellite do it's job for some time (SCANSat mapping) I switched back to it to transmit science and... both solar panels were perfectly fine. Worth mentioning that it was vanilla solar panel, nothing fancy. 3. And again - unmanned mission, battery malfunction this time, but unlike previous examples this one was critical. It happened to my rover that actually had exactly 1 battery and more so, it had like 50% of the contract complete, so I actually prepared an expedition to get an engineer there and fix the damn thing. As you may have guessed by the fact that I'm righting this bug report, when engineer arrived to fix the battery... it was 100% okay. "Inspection" stated that it's "As good as new". Part in question: Vanilla RoverMate body. (engineer died during re-entry after that mission, which doubles the grief ) It appears that the mod only keep failures persistent if the part itself have a "broken" state. Like that antenna, I mentioned above. However, I can be very wrong, anyway I hope it can be fixed (relatively) easy. And thanks a lot, btw, for bringing old good mods back to life, you're doing the great job! UPD: Just an idea regarding the thing discussed above. While "on rails" malfunctions will cost some coding to you and some performance to users, I'm unsure if mod checks mission duration when deciding on failures. In my experience, craft that spent 2 years in orbit awaiting for crew to arrive was good as new and performed it's mission perfectly fine. If I time accelerate for 2 years with the craft in focus I'm sure I'll get some failures, or at least parts won't be "good as new" anymore. So... maybe instead of background failures it would be a good idea adjusting parts condition based on mission time at the moment you focusing your space craft? Doesn't sound as something hard to implement. UPD 2: I just copied over the latest version which is 0.7.7 rewriting my old 0.7.7 (pointless, I know) and... my rover's battery is in fact damaged. So it appears that mod does save the failures. Now I can't explain why engineer had nothing to repair, because I did inspect the battery and it 100% was "good as new".

RPM was recently updated, now VV spamming the log with this (and not working): [EXC 04:36:58.940] NullReferenceException: Object reference not set to an instance of an object VesselView.VesselViewPlugin.OnGUI ()

Thanks! Without forcing Dx11 it loads and works.

I was actually looking into the wrong log file, that's why I never sent it. Here is the link to the output_log from x64 data. It actually have some error info, related to Shaders: https://drive.google.com/open?id=0B80KH2tPkE0YWU1RNTBlS0tNeEk Sorry for not informative post, I was sure that actual logfile only contains some random part error. I run Windows 7 x64 with GeForce GTX 770 and 8Gb RAM

Is there any known incompatible mods? All I got after installing this mod on 1.1 KSP is CTD before I even see the loading screen. KSP log states that certain part cannot be loaded (it's reflection module), if I remove that particalr part, CTD still happens and there will be another part from another mod and so on. Removing shader.dll fixes the CTD, but obviously removes all the Environmental Enhancements aswell P.S. I used this mod at 1.0 (or even 1.0.5) and it was all good, now I use all the same mods (some of them still pending update to 1.1, so in fact mod list is even shorter). Mods appeared in the log after CTD was Karbonite and then Kerbal Alarm Clock.

Nope, never tried that, however this can be convenient, but what if I need different settings on the same part in different circumstances? Say, you are landing at Ike, assembling the rover with preset wheels, then disassembling it and heading to Duna with much higher gravity, you might want to change your wheels setup in that case. Anyway - that was just an idea, this mod is great with or without this implemented.

Hello and thank you for your great mods. They are my most favorite (both KAS and now KIS). While playing around with KIS I've noticed just one thing that I really miss in this mod (except the node attachment, which was already announced): Consider a possibility to provide engineers (lvl 4-5) an ability to tweak all SPH/VAB tweakable parameters with the right tool. Some of the modded parts really needs it to be used after in-space assembly. I'm speaking mostly about modded wheels now, they require suspension settings after installation, and since it's only available at the craft editor - installing those wheels on site is perfectly fine, but the settings are locked on defaults. Ofcourse wheels are not the only part that might require additional settings, I just don't want to list all the things that could, and I suppose, I don't even know most of the mods (modded parts) which are useless, unless you set them up properly in the VAB/SPH.

One of the many things I really like in KSP - you'll never stop learning. Thanks everyone for tips!

I'm not sure if I should put it in a separate Tutorial topic, I'd probably start it here as a comment: I've found a way to 2.1x - 3x multiply my FPS in OpenGL mode on my nVidia GTX 770 card. First of all: - I have 2.76Gb Game Data folder. - Game runs at 2.5Gb memory usage at menu upon loading winth ACM and OpenGL forced and Half-Res textures. (around 2.8-2.9 at DX) - Game clock is always yellow for me in OpenGL. Even with 10 parts craft my game speed were reduced like 1.1-1.3 times to normal. - Average FPS (according to Fraps) was around 15 when I see no significant lag, and comes to 7-10 with 80+ parts Multi_Docking_Nodes crafts. - Tested in DX mode and got like ~30 average FPS with 45+ parts rover and ~27 with the same rover + it's lander for a total about 80+ parts. About ~20 FPS with complex multi dock 150+ parts space ship (not notable lag with just my perception). - Now after implementing this solution I run 30+ FPS with the same Rover+Lander 20+ with the craft mentioned above + some minor service crafts around it like unmanned 30+ parts probe coming in dock etc. So, you have nVidia card and your game runs super slow? Try this one: 1. Open your nVidia control panel (right click on the nVidia icon at the system tray -> Open nVidia control panel) 2. Open "Manage 3D settings" dialog (refer to screenshot attached) 3. Find or add KSP.exe to the listed apps 4. Turn Threated Optimization ON. 5. Tune other settings as you thing your rig should manage to bare. 6. Save and run the game. 7. Post if it helps you or not.

@ Alchemist Thanks for the tip about target's periapsis. It's so obvious, when someone else say that out loud @ Warzouz Regarding MJ and KAC - they are pretty good, really. But looks like sometimes MJ tends to recommend the most recent transfers instead of the maximum efficiency, however you can always wait a bit and find a new variants from it's porkchop selection.

I've spent a lot of time constructing and testing a bunch of vessels to my upcoming Moho mission, since Kerbal Alarm Clock notified me that the launch window will open in a couple of weeks. When every single craft was tested and I was extremely satisfied with the result, I finally plot a course to Moho, ~2100m/s dV from 241km circular Kerbin orbit (which is a bit higher then Wiki told me, but who am I to argue with MechJeb ). The problem is that I was pretty sure that 6500 dV is more then enough for a Tow to deliver a mission to whatever place in Kerbol system (maybe except Eeloo, I've never been there). Imagine my disappointment when I've realized that with ~4500m/s dV left upon arrival to Moho SOI i can barely inject into orbit, not even thinking about continuing my mission. My super fancy spaceship was stranded in Moho hight orbit waiting for a refuel. So, what I want to know - was that my mistake or 6500 dV for a Tow is not enough to get from Kerbin orbit to Moho low orbit and then get back? Was my transfer maneuver that bad (tried both MechJeb plotted and manual), or 4200-4700m/s braking is just Okay for Moho orbit injection? (I'm a little surprised that most of tutorials and stuff like that doesn't even mention Moho as a place to go, or just saying that 'It's just another Mun')

While this report is pretty big it's just a part of the actual mission report. The another big part is imgur albums, linked in each mission stage. Some of the pictures are commented with mission details, others are just beautiful. Take your time to look at them, hope you'll like it. Here is my Duna science mission report. The mission itself took about 1-1.5 days playing (not sure how many hours) from vessels design to the Kerbin landing with all the science collected. It was almost successful, but I has stated it as a partial success because of two big fails: Poor main ship design (no Jr. docking ports and no mobile lab) which forced me to only transmit Ike's science data without 100% recovery, and the terrible rover design (along with planning gap) which after all leads to little cheating. Well, without a cheat the mission was a complete disaster which leads to death of two Kerbonauts. The details are below. Mission contains multiple launches mostly because I wanted to pilot each vessel without heavy lags and that means that each vessel parts count is below 100. The other reason for multiple launch is because the design of a big exploration ship will take ages (for me) and in case of failure it can lead to the whole mission failure, while one-of-a-fleet vessel fail is just a pity and nothing more. Mods: I have a lot of mods installed, I've tried to use only well balanced engines on this mission, so If my craft has non stock engine it is stock-a-like as much as posible. No 'over 9000 isp' engines was used during this mission. The most important mods which affected the nature of the mission are: Deadly Reentry, Remote tech and TAC life support. Having them installed affecting the vessels design a lot. I've also have FAR installed, which makes getting to LKO a little easier (in dV terms). Also I'd like to mention Hangar mod, which helps to improve performance and sometimes aesthetics (not in my case ). No craft files will be included in this post, because of modded parts. If you like one of the designs and occasionally have same mods as I do - ask for a .craft and I will gladly post it here Mission plan and goals: 0. Map the Duna and Ike's surface, determine future landing sites. [Partial success] 1. Design a small fleet of scientific vessels. [Partial success] 2. Launch them all into LKO unmanned before the Kerbin->Duna window. [Success] 3. Man the main ship just before the launch window. [Success] 4. Travel to Duna's SOI and achieve 300-500km Duna orbit. [Success] 5. Land and deploy the Duna rover unmanned. [Success] 6. Make sure that landing site is suitable for the manned landing. [Success] 7. Land two Explorers on the surface of Duna. [Success] 8. Visit at least 4 of 5 Duna's biomes with a scientist aboard the Duna rover. Collect all science and place a flag. [Success] 9. Deploy the unmanned probe to the Duna surface to transmit the valuable date from the last biome. [N/A] 10. Deploy the Ike exploration probes for visiting and studding every Ike's biomes. [Success] 11. Recover unmanned probes data and store it at the Carrier to deliver back to Kerbin. [Failure] 12. Return the manned lander to the orbit of Duna and randevu with the tow. [Success] 13. Return the main ship and a drones carrier back to kerbin with all scientific data stored. [Partial success] Vessel list: 0. Galileo 2.0 - Unmanned mapping satellite, launched a long before the actual mission. 1. 'Pioner' - More like a tow then a interplanetary ship. 3 kerbals crew, a lot of food, water and oxygen stored. 2. Duna lander - The lander for manned mission. Is capable to return to Duna orbit from the surface and even has a little more fuel to randevu with the tow. 3. 'Spore carrier' - Unmanned carrier with 4 probes on board. Probes are mostly intended to use on Ike's surface, but one of them is designed to be used at Duna. 4. Duna landing probe - Unmanned probe inside carrier's hangar. Designed to have the parachute, Ion engine for deorbiting and 4 pieces of scientific sensors for surface (and on flight analysis). 5. Ike landing probe - Unmanned probe inside carrier's hangar. Designed to have much more (2x) dV then the Duna probe to be able to land on Ike multiple times. Has additional fuel tanks and only 3 sensors, since Barometer is useless on the Ike. 6. Rover lander - A big hangar with two purposes. Fist of all it's a lander for Rover delivery and the second -it has two Remote tech antennas one of them is capable to communicate with the Kerbin and another is omni directional for providing data link to unmanned rover. 7. Duna rover - Pretty small rover with scientific sensors and one seat for a driver. Capable of unmanned travel while in range with the Hangar. Mission Stage 1: Galileo 2.0 mapping mission Imgur album of the mission. Not too much, but some good views inside This flight begun long before the actual mission report (and the whole mission plan) came to me, I do not have many scree shots regarding Galileo 2.0 mission. The mission took more then 200 days after arrival to Duna SOI and my Duna map was still partial. Not sure what went wrong, I've chosen the wrong orbit, I suppose. Anyway the Ike was mapped till 100% and Duna like in 50%, but enough to choose a landing zone (as per mission plan). The First maneuver after entering Duna SOI was to catch up with Ike - seemed as a big mistake, since I've used most of my fuel reserves to catch up with this little rock. After Ike mapping with all dV left I've got back to Duna SOI at ~500km polar orbit and begun to scan. As soon as the map showed me that most of the Duna Biomes are located next to each other near the south pole - I've decided to send a mission to collect all the data from the surface at once. Stage result: Partial success. Enough to continue the mission. Stage 2: Getting the manned mission ready and launching to Duna Imgur album of the mission. The album is well commented but I will describe some mission stages here anyway. Pioneer was launched first, unmanned, long before the transfer window opens. Then the lander followed Pioneer to the LKO. After all maneuvers was completed and two vessels met each other at the orbit I've realized that I too too much fuel to the orbit. In fact this problem will follow me during the whole mission now. Almost every vessel had so huge fuel reserve that If I equipped them with KAS ports or just some ordinary docking ports I would be able to refuel main ship and visit Eve before coming back to Kerbin. Docking was not a big deal, to be honest I did the docking so good, that I was even unable to make some nice pictures of it. The lander was shifting in all three dimensions towards the Pioneer docking port and BOOM, docked. Never managed to did that before, and will never repeat it again, I suppose. After the ship assembly I just waited for the window to open and launched two other ships into Kerbin orbit. Since all of them are relatively light launches had nothing to picture, that's why we skip it and continue on Pioneer mission. In four hours before the burn I've accidentally remembered that Pioneer will actually need some crew to operate. The crew transfer mission begun in a rush, but speaking ahead: It was absolute success! Jeb will carry 3 explorers to the orbit on a SSTO space plane. , since most of people (and me too) do like SSTO space planes I have the launch and the whole crew transfer well pictured at the album. .Having the crew inside the Pioneer, Jeb was going back to Kerbin. This space plane was designed for this crew transfer in a big rush and was barely tested, It took some time (and some save/loads) to realize that it require some fuel balancing before reentry, but as soon as I transfered all Oxidizer to the front-most tank the plane became stable again and Jeb landed it easily. Stage result: Success. Mission continues. Stage 3: Leaving Kerbin orbit Imgur album of the mission. This mission stage went smooth and has almost nothing valuable to report. As always - all pictures are at the album. And I must admit (again) that I took too much fuel, the rover Hangar executed half of ejection burn with it's launch stage while it has travel stage with dV suitable for the mission. I will have to eject it half-full later on at Duna orbit. What a waste! Stage result: Success. Mission continues. Stage 4: Duna arrival Imgur album of the mission. Just as the 3rd stage this one went smooth and has nothing special to report. Each craft successfully arrived to Duna SOI at a planned time and Periapsis. The rover lander was the last one to get to Duna, like 4-5 days after the drone carrier. That was a little off plan, since the rover is the first thing to land on duna. Anyway shifting the planned dates in a long term mission is not a big deal, Pioneer crew was patiently waiting for the rover at the Duna orbit. Stage result: Success. Mission continues. Stage 5: Rover landing Imgur album of the mission. This one is one of my favorite. Since I use the Remote tech and unable to control the descending unmanned craft inside the atmosphere (due to antenna dish just fall apart under dynamic pressure) I had to use some 'smart parts' (mod name) bits to trigger specific actions according to altitude. First of all I had to actually fold the dish before the reentry (is it RE-entry when you enter another planet atmosphere?), then at a certain altitude solid boosters fired to slow down the hangar , so it can safely deploy it's chute. Next was actually deploying chutes and landing gears, and at last the 4th stage at about 10 meters above the surface unfolded the dish aging returning controls to me. It was like watching a movie about the rover landing, when you can see the picture but can't actually do anything about it. Since the rover is valuable, but not vital part of the mission I've decided to let is fall down and watch what will happen without loading the QS, if it crash into surface. But the whole landing was surprisingly as planned and I hit the flat ground next to south pole of Duna at the highlands.After the dish was enabled I've opened the hangar and rolled a rover out. Stage result: Success. Mission continues. Stages 6 and 7: Manned landing and rover arrival to lander Imgur album of the mission. Manned landing went as smooth as possible. I've missed a rover landing zone just a few (4) km, and landed on a relatively flat ground. Watch the stage album for screenshots. After the rover roll out I've realized a couple of things: 1. The landing zone is flat enough to land without any precautions. 2. Rover behaves weird at the surface. As the first one is self explanatory the second needs some clarification. I am using the modded rover wheels which not only has the custom 3D model, but has some additional settings, like spring strength and dampener settings. The dampener was exactly the thing I f**ed up with! While driving the rover at the flat surface it behaves well and even has a good speed. While you are jumping out of some hills the rover is super stable since it has additional SAS module. But when it comes to hill climb the disasters begun! The suspension reacts on increased G force when rover comes from the flat ground to a lift. Rover goes down to ground as is Elephant in the driver seat, and this leads to second design problem, rover has two RTGs installed at the bottom! Guess what? Right - when going uphill faster then 10-12m/s it's just enough for the RTGs to hit the ground and blow. I was even considering to cheat-send a fixed rover instead of this one, but decided to move on with what I have. Traveling 4km to the lander was not a big pain, so I thought that a poor rover is not that bad after all. A big mistake! Stage result: Success. Mission continues. Stage 8: Landing probe on Ike Imgur album of the mission. Before going on a rover trip I decided to perform some extra landings. And started the preparations for Ike exploration. Album has more the enough pictures if you are interested. I'd just say that the lander was not a brand new vessel (in fact it was the one and only well tested ship I had, since the same lander was used in my Mun and Minmus explorations prior to Duna mission) - so it behaved as it intended to. Crash landing it at the 3rd Biome was not a problem since I had just enough electric charge left to transmit all the data collected. And after that I've realized the second issue with this mission. I have no way to collect the science data from the probes! I forgot to place a mobile lab to my drone carrier, and there was no way to store all the data collected by unmanned probes. But anyway I have 2 spare probes left and will transmit all science from Ike, which leads us to partial success of the stage, and the unmanned mission as a whole. Stage result: Partial success. Mission continues. Stage 9: Exploring Duna Imgur album of the mission. Here comes the worst page in my story. I must say that stage album contains 100 pictures, most of them are commented and worse checking. Here I will describe the mission in words, not pictures. First of all as per my plan I was going to visit 4 of 5 biomes of Duna. I've landed at the Highlands, so they are already visited. I've just placed a flag next to the lander and brought all the science collected from the rover to lander. But the next thing I've noticed - I can't fing the 5th biome on map! I had to search forum to find out that 'Craters' biome is adjacent to poles, and luckily after the close observation I've realized a good thing: I will visit all 5 biomes on a rover! First two journeys from the lander to Craters and to Poles didn't took much time. It was unpleasant to go there, then get back and then again go to the south, but I had only one driver seat and there was no way to carry two flags at a time. Having 3 flags placed (Highlands, Craters and Poles) I was aiming to Lowlands and Midlands, both of them was relatively close to the north. Just 37km... close. Whit such a poor rover I was not going to repeat the poles journey - I mean traveling 37km, planting a flang and then coming back to lander just to take another flag and head all the way back - that's too much! If only my rover was stable enough I would do that with Rover Autopilot, while watching movie, but my poor little piece of sh*t was unable to move on it's own longer then 3-5 minutes without colliding to the ground even in half speed. That's why I've used some field customizing with the help of KAS plugin I've remove a ladder from the lander and attached it to the rover. Now I have two kerbals available, that means two flags and no need to double trip! Problems begun almost when I travelled the first 100 meters... The first of them was the ladder: A hanging engineer was shifting down the ladder as rover moves, and I had to adjust his position constantly not to let him fall. He did fell several times while rover was traveling all the distance, mostly when I was AFK. The second problem was combination of my mistakes and lack of Duna knowledge. As I have already mentioned - rover had two RTGs on the bottom, so they tends to collide at the surface. When it happened again I opened the mission log, found that only one RTG collided with surface and continued the mission (saved the game) that was a big mistake! I don't know when and why - but I've lost the first RTG long ago! That means that as of now - rover became solar powered with just a few low grade solar panels, but it's not a big issue on it's own. I've mentioned my lack of Duna knowledge? I didn't know how fast the sunset changes to night! I was 30+ km away from the lander when sun disappeared and both of my Kerbals was left to die (TAC life support requires Kerbals to have electric charge in their suits to live), that's where I have cheated and used the HyperEdit to recharge rover several times, just not to terminate the mission. Without cheating manned mission can be counted a catastrophe, witch lead to the death of 2 crew members. I have decided to count the cheating a miracle and continued the mission. I've recharged rover's batteries like 3-5 times before I made it back to the lander. All 5 biomes visited, and the manned mission is almost over. Time to go to orbit. Stage result: Success. Mission continues. Alternate stage result: Catastrophic failure. Unmanned mission continues / Orbital module pilot is the only Kerbonaut to survive. Stage 10: Manned mission packing Imgur album of the mission. Nothing unusual to report. Lander was well designed and easily achieved the duna orbit. To to the landing site elevation (~3km) I even had enough fuel to match planes with the Pioneer and randevu with it on my own. Docking was performed from IVA, and well pictured in the album. Almost forgot to mention: I have evacuated all valuable scientific sensors from the rover, to conduct some researches at the orbit aswell. Stage result: Success. Unmanned mission continues / Manned mission is ready to leave. Stage 11: Second unmanned mission on Ike Imgur album of the mission. The second Ike mission ended up just like the first one, but I've managed to visit every last biome before the crash landing. I had a little issue with the Western mountains since they was always either in shadow, or on the dark side of Ike (relative to Duna) so I was unable to contact carrier and therefor unable to control the probe. It took a long time to Ike to align well, but I eventually made it to the last biome with some crash, and with enough electric charge to transmit all the science. Stage result: Partial success. Unmanned mission terminated / Manned mission is ready to leave. Stage 12: Unplanned anomaly exploration Imgur album of the mission. This part was unplanned, but why not to visit the 'anomaly' if I have a spare probe left? Pretty short mission stage is pictured well in the album. Stage result: Out of scope Stage 13: Kerbin return Imgur album of the mission. After a long awaited Duna->Kerbin window the manned module along with expensive lander is returning home. Bringing back 8591 science in it's storage! All the stage is well documented in the album and awaits you at imgur. Stage result: Success. Mission accomplished. Mission review. So, it's time to write down some results and a lesson I've learned the hard way. First of all: Before sending a complex mission to another planet: Have a checklist! Without it - you will be unable to complete all goals as I did with mobile lab missing. The second: My next manned mission will have some kind of crew rescue system. I really didn't like to cheat, I'd prefer to evacuate Kerbonauts next time if the sh*t with rover happen again. The third: Always have a backup. I brought several probes to the Duna system. That allowed me to have some fun with crash landing and NOT loading the QS after it. While the one and only rover made me frustrated and want to kill myself. If you managed to read the whole thing, and like it - please comment. I want to know if my report was entertaining, since I've enjoyed writing it as much as I enjoyed the mission itself. Thanks for reading - fly safe!

Thanks to all for the answers. I will try to maintain some build/play balance - that minimize my crashes For the record: OpenGL saves almost 1Gb of loaded RAM on my setup.

@Taki117 I've already did that. I suppose my setup wouldn't even load without OpenGL forced @eurybaric Thanks for the link, at least I do know that the leak is not my very own issue.

Hi all! Does anyone know how to flush the memory used by the process 'on the fly'? Here is my situation: - A lot of mods. - All memory conserving methods I managed to find on forums are used (Active Texture Management, force OpenGL, Half-Res textures setting) - I have about 2.2 to 2.5 Gb memory used by KSP when the title screen appears after game is loaded (depending on mods used, I am trying to trim my install, but don't want to get rid of all favorite parts) - Like 2.5 to 2.7 Gb used when I've the savegame loaded While actually playing KSP with the memory usage as listed above I do not face any crashes and/or severe lags. By playing I mean - piloting my ships/planes/rovers. I happen to travel almost 100km across Mun surface on rover with a couple of quick loadings (due to rover crash), and didn't exceed the available memory. I've also flew an atmospheric plane for more than 1000km (yes, not meters) at the Kerbin to complete the Temperature scan contract and had no issues with memory, I suppose that loading a new terrain while traveling that far is not a big deal for KSP. But I do have a serious problem at VAB and SPH. While building a new vessel (especially a SpacePlane) I do a lot of tests to ensure that the new toy will fly (or roll, or whatever) as good as I want it to, after each testing launch memory usage is increasing, even if I'm building a rover and the testing area is actually limited to SPH runway. Let's say I enter SPH with 2.7Gb loaded, I'm starting the test run and memory usage comes to 2.8-2.9, then I revert and change a couple of parts, the process memory is still 2.8-2.9, running a next test will consume another 50-150mb, and so on, until I get 3.6-3.7 and a crush after all. I admit that my real problem is excessive mod usage and my issues can't be addressed to Squad. But maybe someone do know how to deal with the situation above? What actions in game can force the KSP to unload some unused stuff from active memory? Unloading the game back to title screen is not helping (100-200mb unloaded maximum). Any ideas or suggestions? UPDATE: Important thing to note that the memory doesn't leak while I do nothing on any screen. So, the problem is not an ordinary memory leak as we all might faced in some other games.