Padishar

That article describes the generational collector in recent versions of Mono, not the collector in the old version of Mono that Unity uses...

It appears to me that the mod in question was doing something incorrectly with shaders and materials causing a memory leak which he then fixed (and, by the look of it, not by a particularly sensible method). Why is he creating and destroying a shader and material instance on every frame? Yes, but it isn't really about freeing up memory, it is more about splitting up the work required into smaller packages so the pauses they cause are less noticeable. There is no "first (quick)" garbage collect in the version of Mono used by Unity (as far as I am aware). In fact, the only one of your points that really makes sense is the first one...

Why delete and ignore if they load and appear to work fine? If all they are missing is the name and other details in the load dialog then he could probably keep playing them for years...

There is the official Squad bugtracker at http://bugs.kerbalspaceprogram.com/ You should be able to search and read bug reports without an account but you would need to create one to be able to post or vote on anything. If you do create an account then the best idea is to use the same name as your forum account as this makes it easier for people to work out who you are...

We would need to see an output_log.txt/player.log file and details of what other mods you have installed to suggest anything useful. It sounds like it wasn't correctly installed or there is a clash with another mod during the AppLauncher handling. The log should tell us...

Not really. As I have posted in various other related threads, Squad are aware of the problem and of some of the specific problem areas and are intending to fix them. The best way to increase the priority of that work would be to add information (and/or votes if that is working) to one or more of the existing bugs in the bug tracker, complete with good information that demonstrates why it is such a bad problem.

Most of the problem is caused by Squad's code and by mods allocating and discarding too much memory. KSP does push Unity considerably beyond what it's really designed for but there really is no excuse for any game to be constantly allocating and discarding megabytes of memory every second. This would cause issues whatever game engine (with whatever underlying memory allocation model) was used. As I said in the other post, people hoping that Unity will update Mono to use a better GC algorithm would be disappointed by the effect (or lack of) it would have on KSP...

Can you try loading the Platonic Stations save in my MemGraph thread and flying the KerbalX and then just holding down left cursor to rotate the view continuously? If you really can't see any stutter in that then I will be very surprised...

Unfortunately, the EditorLogic, GizmoXXX and GizmoXXXHandle classes are intricately interlinked, lots of the code concerned is private, and there is no remotely easy way to do what you want. I also want something similar as I would like to make Part Angle Display enable the rotation keys in rotate mode. There were some potential changes on the table for 1.1 that would have made this easy so I never fully investigated whether it was actually possible to do it now via reflection or some other underhanded method. However, those changes to KSP had to be postponed due to more serious issues that needed to be worked on.

People have been looking for a solution for years, the problem is that the only practical solution is to reduce the rate of memory allocation by both core KSP code and mods. Also, I don't see any mention by @sarbian that this was any sort of "fix". He clearly stated it was an experiment and also clearly stated it could make things better or worse. I have also tried various things along these lines (including patching mscorlib.dll to be able to profile exactly how long a manual run of the GC takes) but they do not help. The frequency of the pauses is directly related to the rate of garbage creation, the collector runs automatically when the Mono heap doesn't have enough space when some C# code tries to allocate some memory. The length of the pauses depends on a number of factors but the amount of garbage to be cleaned up is quite a minor one. The total number of allocated blocks of memory is the main factor as the collection basically works as follows: Step 1, loop through every block of memory allocated on the heap and mark it as unreachable. Step 2, loop through every global and stack reference variable and mark the memory block as reachable. If the block contains any references to other blocks (that are still marked as unreachable) then mark those as reachable and continue recursively. Step 3, loop through every block and collect any that are still marked as unreachable. The collection usually involves moving the memory blocks down to fill up the collected spaces as this greatly increases the allocation efficiency. It should be obvious that, even if there are no unreachable blocks at all (no garbage to be collected), running the collection will still take a considerable time as the entire heap is still scanned through twice plus the entire recursive "reachable" scan still has to run. The only bit you save on is the shuffling around of the still-allocated blocks and fixing up of the references. So, the only sensible ways to reduce the severity of this issue are: Reduce the overall number of "live" memory blocks. Various parts of KSP (and mods) use significantly more memory (or more complex data structures) to represent things than is required. E.g. the PartResource class is a simple class used to represent a resource in a part but it is derived from MonoBehaviour which is a complex Unity class that has many other reference members. No base class would make this much simpler and would reduce the number of memory blocks used by loaded vessels considerably (and making it a struct instead along with some tweaks to the Part class would make it even better still). This would reduce the length of each pause but would have no direct effect on the frequency. Reduce the amount of garbage being created, especially on a regular basis (e.g. in Update/FixedUpdate). As stated before, the collection runs when the free space in the heap runs out. If the game is allocating 10 MB/s then the free space in the heap will run out much sooner than if it were only allocating 10 KB/s and hence the collections would be happening much more often. Reducing the amount of garbage created has the potential to reduce the collection frequency to such an extent that the collections could be triggered at times when the user is unlikely to notice the pause, e.g. switching to/from map view, pausing the game, etc. or to attribute it to something, e.g. run it after every save and load. Unity do recommend manually running the garbage collection at a high rate as a way of preventing this issue but, only in games where the total heap size is small (I seem to recall it mentions < 50 or 100 MB). KSP uses several times this just getting to the main menu and the GC runs simply take too long to be deliberately triggering them during scenes. Even Unity upgrading the version of Mono used to a version that has a much more efficient garbage collector would not eliminate the problem though it should reduce the length of the pauses. I have numerous saves where the memory allocation rate is constantly over 50 MB/s which results in the GC running every 2-3 seconds. Even the latest version of Mono (or the very latest version of .NET) would have problems collecting the garbage from that without causing any delays longer than a frame or two. Edit: one other thing, to eliminate the somewhat garbage happy GUILayout code in this mod I recommend you make sure the window is closed before evaluating the stutter.

Well, presumably the two saves are corrupted in one way or another. Does it actually let you load them and, if so, does it actually work? Can you zip up your whole saves folder and upload it somewhere? It may be possible for someone to salvage them...

Oh for pity's sake, take your tin-foil hat off, there's no conspiracy involved... Quite a few of the messages I've seen about this issue were definitely more pitchforky than disappointed... Edit: damn, I was trying really hard to avoid posting in any thread related to this issue...

That doesn't necessarily mean they are generating drag (I'm not saying they are or aren't and won't without seeing decent evidence on a completely clean stock install). Heat can be conducted to parts inside cargo bays but has problems radiating away and are protected from the extra atmospheric cooling by convection...

Hehe, at 800 m/s the vessel travels 16 meters in every physics timestep (20 ms) so if it's shorter than that it could go straight through...

What is the root part of the vessel? The deltaV calculations only work correctly if the root part remains with the vessel until all the significant stages have been simulated. From your screenshots it appears that the root part is probably the probe core. In the second shot, the deltaV is shown is S3 (correct) and S1 (not correct, this means it has decoupled the full ore tank before calculating the last stage). In the first shot, the last stage is shown as S2 which is before the empty ore tank is decoupled. Clicking the "All Stages" button may make it more obvious what is happening, especially if you pay attention to the masses reported for each stage. To get correct readouts simply use the reroot tool (4) to make the ore tank (the payload) the root part. You may also then need to grab the decoupler and detach the rest of the rocket from the payload and then reattach it. It should then start calculating consistently. Edit: Pad, the anti-ninja, strikes again...

This sounds like an issue specific to that contract pack though there is nothing obvious in the logs so you will probably be better off posting in the mod's own thread (assuming it has one) or the contract configurator's thread.

The "crash" in ntdll.dll isn't a case of the OS doing anything bad. What is happening is that ntdll.dll is raising a structured exception because it has been called incorrectly by the program and the default (and, arguably, the most sensible) way of handling such an exception is to terminate the process. It is trivially easy to write a program in C/C++ (or any other compiled language that lets you call OS functions directly) that will fail with exactly that stack trace. The underlying cause is probably the same as the "double free or corruption" error seen from glibc, namely that an invalid pointer is passed to a function that releases memory. Whether the pointer has been previously freed, its value has been corrupted or the data it points to has been corrupted remains to be seen but any of these could easily cause both of these sorts of problems. Also, on the subject of how the game uses memory, it isn't as simple as Unity asking the OS for memory and giving it to Mono and then KSP code uses that. Unity almost certainly uses a different API to allocate the memory it gives to Mono than what it uses to allocate memory for other things it needs to do. Most normal memory allocation in C/C++ is done using either malloc/free in the case of C and new/delete in the case of C++. These APIs are actually implemented by the C runtime (e.g. glibc) or the C++ runtime and they call the functions in ntdll.dll (or the Linux/OSX equivalents). In the case of the memory given to Mono, I suspect that Unity calls directly to the OS APIs rather than going though the C/C++ library. My take on this whole "random crash" issue is that there is almost certainly an underlying bug in Unity, most likely caused by a multi-threading issue, because these crashes always seem to occur at times when Unity is likely to be doing more work in background threads. Multi-threading is hard and Unity does quite a lot of it. If data is shared between threads but is not correctly protected from simultaneous access then it is quite easy to end up with this sort of "random" crash. Sometimes, it requires one thread to be at a particular instruction in the code when another thread accesses the data for there to be a problem. It can even require one thread to be suspended at a particular instruction to allow some other thread to run, e.g. if you have a pointer that is shared between two threads where each thread is careful to null check before using the pointer then you might imagine it would be safe for one thread to release the pointer and then set it to null but, if the other thread has just executed its null check and then gets pre-empted before using the pointer then the first thread could release the pointer and set it to null but the other thread would go ahead and use the pointer when it gets resumed. If nothing else happened in the first thread then this might not cause any obvious problem, e.g. the second thread could just be using the memory as a buffer to store data in and would just be writing the data into memory that has been freed but, if the first thread (or any other thread) happens to do any memory allocation before the second thread is resumed then the memory could be reused for another purpose and then have its contents corrupted by the second thread. The second thread could even do a memory allocation and get given the same pointer for the new allocation as it has for its buffer.

Is there any chance you can do this bit when the problem happens?

You are trying to use the version of KER intended for KSP 1.1 with KSP 1.0.5. You will need the older version, 1.0.19.4 from here: https://github.com/CYBUTEK/KerbalEngineer/releases/tag/1.0.19.4

Well, it sounds feasible. Module manager keeps a cached version of the Physics.cfg file with any mod patches applied. Step 2 probably results in this cached version being a complete working version and MM probably doesn't update it because it doesn't detect any changes to the stock file because you set it to read only. So, every time you start KSP it creates bad default settings and then MM overwrites the newly created default settings with the correct cached version...

You will need to give more information, what version of KSP, what version of KER, what other mods you have installed, what OS you are on. Also, the most useful info in any KSP troubleshooting is to look in the log file. This is either called output_log.txt on Windows and lives in either the KSP_Data or KSP_x64_Data folder depending on whether you are running the 32bit or 64bit version. On linux and OSX the file is called player.log and lives in an odd place. See the "How to get support" sticky thread in the modded support forum for details if you're not on Windows. Please upload this file to a file sharing site such as dropbox and post a link here.

Yes, it appears that all asteroids are spawning as 150 tons. Perhaps you can add some more info to this bug report: http://bugs.kerbalspaceprogram.com/issues/9392 Edit: Though it does make contracts for larger asteroids quite a lot easier... a 150 ton class E takes a lot less pushing than a 3000 ton one...

Strange, that's the same conclusion I come to whenever I go there... The thread here has been reopened though please take the time to read through at least a few of the most recent pages of posts so you don't go pointlessly reporting stuff that has already been reported...

Unfortunately, he couldn't say that because the dev team are on a break (well, he could have lied, I suppose, but that probably wouldn't have been such a good move)...

There is a thread discussing how to fix this over in the plugin development sub-forum: So, it's being worked on and the person concerned is doing the sensible thing and asking for help...