Padishar

It doesn't look like the applying of the padding was directly responsible as the log shows it applied successfully and then quite a few other things happened before Unity/Mono reported an "out of memory" on a subsequent allocation that then led to the crash. Do you have your Windows pagefile disabled or fixed to a small size? The 64 bit version really shouldn't be getting out of memory errors unless you run out of free memory and Windows is unable to allocate space in the pagefile... You have at least one mod that hasn't yet been updated to KSP 1.2 (it's still trying to use KSPUtil.dll). IRSurfaceSampler and IRActiveStruts both appear to do this so I would be suspicious of all of the Infernal Robotics stuff (is this an unofficial build for 1.2?). There are quite a few exceptions from IndicatorLights so that should also be investigated. Almost a third of your log is full of exception spam from docking ports and, while I think these are probably related to the Infernal Robotics issues, they could be causing underlying issues (e.g. memory leaks or otherwise upsetting Unity in some way).

Hehe, loads of new toys for you to play with...

There is a bug in Unity 5.4.0 that causes the log to be written into your user profile AppData folder in some circumstances. Hit Windows-R (i.e. hold the windows key down and hit R) and then copy paste the whole of the following line into it (including the quotes) and hit OK. "%USERPROFILE%\AppData\LocalLow\Squad\Kerbal Space Program"

Well, Squad did a lot of work to eliminate per-frame garbage creation but there may be some parts that do still cause more than others. However, in this case, the difference is more likely due to the difference in frame rate, e.g. the amount of garbage created per frame is probably similar but your save is doing 4x the FPS that mine does so it generates ~4x the garbage per second.

Ahhh, but it's a dry splat...

Yes, that's definitely the one. Check out this post and the two replies...

There should be an orbital period readout.

I'm pretty sure those memory figures are bogus. None of them should have 0 MB at the start (well, unless you've disabled the paging file). 33% memory in use and 0 MB free physical memory aren't consistent so something has got confused. The DLL that can't be found is, also, not an error. That's just the stack trace dumping code trying to work out what DLL corresponds to the address 0x000000e0 but there isn't a DLL loaded at that address. The code in AnimationCurveTpl<float>::GetKeyCount has called a bad function pointer (e.g. because some underlying object in Unity has already been deleted or it failed to allocate something leaving a null pointer) and ended up trying to run code from address 0x000000e0 but there is no real code there so the program crashed. My current best guess is that there's a problem when the active vessel is destroyed and the other nearby vessels get unloaded which can result in the encounter code still trying to use some object that it shouldn't and getting stuck in a loop and then the large amount of log spam is causing the actual crash (there have recently been some mod issues where extreme spamming to the log makes KSP crash). Possibly switching to map mode (or actually being in map mode) at the moment the vessel crashes could do it? @udidwht, is there any particular reason you're running the 32 bit version of the game?

Does this mod increase the mass (and size?) of asteroids in general? This person has (what appears to be) a class C asteroid that is ~10000 tons. I've never seen a stock class E above 3500 tons...

Welcome to the forums. Well done for providing the logs etc. Somewhat ironic, given your name, but could you describe what you were doing just before the crash...? From the log it appears that you crashed a vessel called Thunderbird and then the game unloaded a couple of debris vessels, updated the record altitude and speed and then started spamming: CheckEncounter: failed to find any intercepts at all ...a considerable number of times before dying. It certainly looks like a pretty serious stock bug but it may be difficult to reproduce, especially without details of what you did actually do (the logs can be misleading, especially in regards to the timing of what happens).

It is complaining about this bit because it is saying "add a new value called heatProduction and set it to the existing value of heatProduction multiplied by 2.5" but this is illogical. Just add an @ to the start, e.g. @heatProduction *= 2.5 The error message is a little misleading, the "@MODULE[ModuleEngines*]" bit makes it look like this is the bit with the problem but it is actually the section the problem is in...

No, that is the last official release and is only for KSP 1.1.3. Go here: ...and get the latest dev version...

Just to follow up more explicitly on this part, KSP 1.2.1 fixed the severe memory thrash when both AA and part highlighting are turned on but there is still a bug in this area that causes the game to crash to desktop, e.g. if you have both turned on and then hit F12 to enable the aero overlay, the game will probably crash within a few seconds.

For a potentially better workaround (assuming you have a reasonable amount of memory free) check out the MemGraph mod linked in my sig below. As well as displaying a graph of how much memory is being used, it also allows you to pad the Mono heap so that it takes significantly longer to fill up resulting in longer intervals between the stutters...

This sounds very strange. I don't recall anyone reporting such a problem before and the only likely way of something like this happening is if another mod is having a problem which is upsetting the core game and/or KER. Do you have other mods installed? Log files can be uploaded to any file sharing website, e.g. DropBox, Google Drive, etc., and a link posted here. It may also be helpful to see a screenshot or two of this issue occurring. These can be uploaded to somewhere like Imgur and again a link can be pasted here.

It is now... It hadn't occurred to me despite quite a bit of messing with the target stuff, thanks for bringing it up...

You could try reading what you need into variables in your class in FixedUpdate, and then using them in Update (assuming what you are doing is render related, if you are trying to do something physical with the values then do it all in FixedUpdate)...

Well, it certainly isn't random. In your screenshot, MemGraph is currently showing about 4MB/s of usage (on average) and the difference between the Heap Min and Heap Max values is about 40MB so it took 10s to fill it up. If you now applied the default heap padding of 1024 MB (assuming you have the memory available) then the intervals should increase significantly. In your example, MechJeb is causing the regular memory spikes every 5 seconds and is also generating ~1MB/s of the baseline usage. As a substantial amount of the memory usage happens in the Update code that is called every rendered frame, your high framerate will also be making things worse. A larger vessel that only runs at 30 fps will result in quite a lot less garbage being created. You should see an improvement by limiting your framerate to 60 (I would estimate the usage rate would drop to about 60% with a corresponding increase in the stutter intervals).

He is implying that you don't understand the readings you are getting because you don't understand that a program that is running continuously on a multi-core machine almost never shows 100% for any core because the OS will switch the program from one core to another, often several times per second. E.g. the total CPU usage in your first screenshot is 340% which means that there are 3.4 cores being fully utilised. If you aren't running anything else major then KSP is probably using 3 full cores worth, the fact it is spread over all the cores is irrelevant. KSP is (generally) CPU bound. The calculations that it does are not easy to run in parallel so using ~3 full cores worth is actually pretty good going. There are still areas of the game that could be optimised further, no-one is denying that. The aero effect shaders (the highest quality ones anyway) are one such area. The way the game looks has no bearing on the complexity of the CPU bound calculations it has to do. No, it doesn't use all 8 cores of your CPU but, as was said, a lot of the work it has to do is not at all easy to do in parallel. And all he was saying is that the speed of the game is not (generally) limited by the complexity of the graphics. [citation needed] Actually, a citation would be impossible in this case, the graphics rendering quality could (and can with mods) be improved considerably without any major effect on the frame rate.

Yes, you're right, I was mis-remembering, you only get the AN and DN when you have a target. "That number", like the post-burn Ap and Pe, is readily available so it should be pretty trivial to add a "Post-burn Inclination" readout...

Well, it's how the VesselModule mechanism in KSP has been implemented. Basically, after loading all mod assemblies, KSP enumerates all the classes that are derived from VesselModule and will then create one of each for every vessel that's loaded. Squad implemented it like this to make it easy for mod authors to create VesselModules.

A copy of the savefile just before you set the target (assuming it's mostly stock) and a description of exactly how you are setting the target would be helpful. The only issue I can see in your log is a bit of log spam that appears to be coming from the core KSP orbit rendering code... Maneuvers don't have an inclination. To get to a zero inclination just create a maneuver at either the AN or DN and adjust it, checking the AN/DN on the predicted orbit. Alternatively, there is a relative inclination in the rendezvous section though this may require a target to function (I don't remember off-hand and can't try it right now).

There was a bug in a recent version where all asteroids were 150 tons, regardless of class or size. This has apparently been fixed though 10000t would be very high even for a class E. Do you have any mods installed that mess with the asteroids? Have you checked any asteroids in a stock install? A list of your mods and a log file would be a help, check the "How to get support" sticky thread near the top of this sub-forum for details of where to find the log etc. Edit: I've checked the savefile from a stock install and, while all asteroids are initially created with a mass of 150t, as soon as you get within physics range of them (i.e. they get properly loaded), they get assigned a sensible mass. I created a new sandbox, timewarped a few days in the tracking station until I had a dozen or so asteroids, tracked them all, put a mk1 pod on the pad, used the alt-f12 cheats sections to rendezvous with each in turn and then returned to the space center. Then I checked the save file and found all the asteroids has reasonable masses ranging from about 4 tons up to ~2300 tons.

I really don't think it would. If you are convinced of this then set up a completely stock install and create a vessel that suffers from it and post it in the stock support forum. The game doesn't store rotations like that. It uses quaternions and these do not suffer from the sort of issue you are imagining.

How much RAM have you got and how much is KSP using? MemGraph is showing only a fairly reasonable memory allocation rate for the amount of mods you appear to have (certainly not anything like the highlightling/AA was causing in 1.2.0) but the Heap min and max are only 25 MB apart which doesn't take long to fill up. Did you apply the padding in that screenshot and, if so, at what point in the graph and with what settings?