Padishar

You should be able to set them to None, e.g. keyCycleRotate = None

Thanks for the report, is there any chance you can post a few screenshots and/or the craft file you're using? The same area of code is also implicated in a similar issue with RealFuels (shows 0 dV in flight scene once engines are ignited) but I've not had any spare time in the last few weeks for modding due to other commitments. I'll try to take a look at it soon...

Indeed, as could showing the KER Vessel window which shows per-stage figures, not to mention not drawing on the screenshots obscuring potentially helpful values...

I suspect that KER is simulating burning all the fuel before decoupling anything but MJ is probably decoupling one of the next stages before burning (hence getting more deltaV). Without a craft file (or a verbose simulation log from KER) it is difficult to tell...

Yes, applyPadding causes the padding to be applied very soon after the game starts (before most of the loading process). This can help to (slightly) speed up the loading process but a substantial amount of the padding will get clogged up by the data the game loads so it is only really advised if you have lots of memory and have increased the amount of the padding. You can reapply it at any time but this causes the old padding to be released and new padding to be allocated and this can cause the overall memory usage of KSP to increase so it should be avoided unless really necessary. It can result in longer intervals but this is because some of the initial padding still serves as padding because the pages are held in memory despite MemGraph "releasing" them due to the core game having allocated some blocks from those pages. If you have limited memory then you will probably be better off waiting until in the editor or flight scene.

Hitting it multiple times doesn't really do much unless the game has allocated more long-lived objects since the first time. The way to increase it is to edit the padhead.cfg file in the MemGraph/PluginData/MemGraph folder and change the value on the total= line. The value is in MB so you may be able to increase it from the default of 1024 to something like 1200 or even 1500 without causing immediate crashes. Also, wait until you've loaded your save and gone into the flight scene before hitting Alt-End for maximum benefit. You're welcome, I'm glad it's helping...

MJ isn't really too bad garbage-wise though a garbage related issue was fixed in a very recent dev build. All mods that have a lot of old-style UI will generate more garbage than they should but some are a lot worse than others (and mods often cause garbage in non-UI related code too). Only having those bits of UI showing that you really need should improve things. Otherwise, I would suggest following all the advice you can find on reducing the memory usage of KSP (use OpenGL and reduce the texture resolution to minimum) to free up as much as possible and then increase the MemGraph heap padding total value as much as you can without the game crashing (or the performance crashing due to VM thrashing). As KSP's memory usage tends to increase over time, you will need to allow for this, not much point if you can extend the intervals but then only play for half an hour before it dies.

They're getting there. The version on GitHub mentioned in this post: ...should have my latest tweaks and the disabling mouse over on the KER button feature but will still say 1.1.2.8. You should just need this file: https://github.com/CYBUTEK/KerbalEngineer/blob/master/Output/KerbalEngineer/KerbalEngineer.dll Hopefully cybutek will get a chance to do another release soon.

According to the Unity profiler the memory usage is happening in MainMenuGui.OnGUI. I've not rebuilt a debug version to get more information about where in the function the big usage is but I can see several quite worrying things about the function anyway. First, you appear to be calling your MonoBehaviour's Awake function from it and this is adding a handler to an event which will allocate a number of memory blocks and, called repeatedly, is presumably causing the list of handler functions to be reallocated to double the size when the available space fills up. Second, you are recreating all sorts of things on each call rather than caching them in the class instance. This includes a number of GUIStyle and Rectangle objects. Third, your use of the various GUILayout functions that return a GUILayoutOption is exceedingly rampant. Every time you call one of those functions (looks like mostly Width and Height) it allocates a new object from the heap. These can also be created once and cached in class instance. If fixing the repeated adding of the event handler fixes the bulk of the problem then you would probably be better off changing the UI to use the new system rather than the old one. GUILayout, in particular, still generates a large amount of garbage even if you optimise the style and layout option usage. However, there may be something else going on that will require a debug build of the plugin (or a more in-depth examination of the code) to locate...

Good job on tracking it down, @HebaruSan also has that installed so, hopefully, removing it will fix his issue too... Have you reported it to the CraftImport author?

Well, while the text caret is in an old style GUI text control it does seem to be ignored but not when in the new style stock controls. No input lock is set while the caret is in the ship name or description controls but the stock KSP key shortcuts (c, x etc) don't get triggered when typing so there must be some way of doing it... Edit: it looks like the editor probably avoids problems with the name and description controls by using the EditorLogic.NameOrDescriptionFocused() function...

Hmmm, I thought I'd made that interlock correctly with text entry controls but I must either be mistaken or the UI changes with Unity5 have interfered in some way. I'll try to take a look soon and sort it out...

You may well have done, in which case I am glad to stand corrected... I don't usually run with MJ and it was actually more than a "few" weeks ago (unless you consider 10 a "few")...

I certainly wasn't trying to imply that you had done nothing to improve the garbage creation of MechJeb, other mods or KSP itself, just that you haven't yet (as far as I know, the MechJeb thread disappearing hasn't helped ) looked at the specific issue I reported a while ago with the significant spike that happens every 5 seconds...

The messages since this one: ...were about the general GC issue rather than anything MechJeb specific and shouldn't really have been moved. Sarbian was informed about the odd garbage creation profile of MechJeb a few weeks ago but I don't think he's got around to looking at it yet.

What does this mean? What were they measuring? Overall runtime, proportion of time spent doing GC, length of individual GC runs, or something else? Yes, I'm not disputing that, there is likely to be some sort of "improvement" when looked at in the "right" way but there's no guarantee this will translate to any improvement in game performance or the gameplay impact of any stutter that does still occur. The main problem with a generational collector for KSP is that there are quite a lot of objects allocated that live for a considerable period, in some parts of the code, enough is allocated to fill any reasonably sized nursery. On a nursery collection, any object in the nursery that still has references gets physically copied into the next generation so the nursery has to be kept reasonnably small to avoid the possibility of having to copy too much in one nursery collection. Large blocks (and I'm not talking that large in KSP terms) skip the nursery altogether, further eroding the theoretical performance benefits. This doesn't sound much like: You have to be making quite a chain of assumptions to be able to relate random benchmarks to the perceived seriousness of the stutter in KSP. I'm not saying it's the norm but it does happen. Just check out the last few posts in the MemGraph thread for an example of what a (presumably) dodgy mod can do... Even 20 MB/s is a ridiculous allocation rate, what on earth (or Kerbin) is it being used for? (That's rhetorical, by the way ). If the heap only has 100 MB of headroom then this will fill up in 5 seconds. With the current collector, a significant improvement in the length of the stalls would probably be got by multithreading the mark phase but you've seen that doesn't work in Unity and I'd be wary of it in any future version of Unity using SGen too due to the complexity of Unity's threading usage. With SGen, the frequency of the stalls is likely to improve some due to the nursery reducing the allocation rate in the next generation but exactly how much can't even be ball-park estimated at the moment and I certainly don't expect the length of the stalls on a full collection to improve that much all the time there are several hundred megs of old generation to scan through. The thing is that writing good code is required whichever GC is used but if the code were good enough then a better GC would give very little benefit at all...

[citation needed] Specifically, what possible reasons do you have to believe that SGen would cope better with stock KSP's garbage creation, let alone a situation where mods are generating over 200 MB/s...?

Each column of the graph is basically the "Last" value from the top of the window. This is the amount that the allocated size of the heap increased by in the last second (approx). The columns with a red background indicate that at least one garbage collection ran during that second. If it wasn't garbage being collected then that rate of memory allocation would run you out of memory very quickly. The Min, Cur and Max values show the allocated size of the heap itself, Min is after the most recent garbage collection, Cur is the current value and Max is before the most recent garbage collection. So, the difference between Min and Max is approx. the amount of garbage collected by the last collection (actually more than this is collected because that counts only 4k pages that are completely freed up during the collection). "Traditional" leaks aren't really possible in C#, that's the whole point of garbage collection based systems. These happen when the programmer throws away their reference to a bit of memory, or overwrites it with a reference to a newly allocated bit of memory, so they can not then manually delete it. In a garbage collection system, the collector will detect that the original block no longer has any references to it and it will be collected. However, due to the hybrid nature of Unity, combining the Mono runtime with a "normal" C++ program, it is possible for the different memory allocation systems to clash which can cause what look a bit like "traditional" leaks but this requires a mod that makes use of Unity C# objects that have a corresponding object in the C++ world. I don't think this is happening in this case, instead I suspect that some mod is doing some operation on a list (in a way that generates excessive garbage, e.g. some complex bit of LINQ code) on every frame but is also adding items to that list regularly so the amount of garbage generated each time increases fairly linearly. I wouldn't be surprised if it turns out that there is simply a missing call to List<T>.Clear() somewhere...

The graph really shouldn't look like this. It appears that some mod is not only generating a lot of garbage, but tthe amount it generates increases rapidly over time. Were you doing anything in the editor (i.e. did you load/build something) or was it just sat there empty? I think the best bet is probably to do a "simple" binary chop to locate the problem mod. E.g. on a separate copy of your KSP installation remove half of the mods (move them to a temp folder) and test. If it still happens then empty the temp folder and repeat removing half the remaining mods (move the into the temp folder again). If it doesn't happen, then delete all the mods remaining in GameData and move half of the ones in the temp folder back in. Test again and repeat until you've narrowed it down to the mod at fault. Obviously, some mods rely on others to function correctly so these will need to be kept together. However, the most likely cause I can think of is one of the mods that messes with the part categories and/or crew assignment. You should probably try removing those first. If that doesn't fix it then continue as described above. If you have no luck then I would be willing to test a smaller subset of your mods to try to work it out. If you can eliminate all the very large mods (filesize) then you could zip up your whole GameData folder (except the Squad folder) and PM me a link to it and I'll give it a go with the Unity memory profiler... Edit: and @HebaruSan too...

I'll try to take a closer look tomorrow but the first obvious thing that stands out is that the vessels have different root parts. The first one appears to have the engine as root and the second one has the crew cabin as root. Why this appears to stop the simulation from staging correctly isn't clear yet though it might help if you could repeat the second screenshot with "All Stages" turned on...

This bug isn't specific to the launchpad and it has already been reported (see the post at the top of this page and follow the chain of quotes). It can actually happen randomly any time you switch vessel with the rendezvous panel open or open the panel after switching. I've still not yet had time to look into it in detail...

Sure, I've not been directly involved with the listing on CKAN so feel free to poke someone to update it... Hmmm, didn't notice that, sorry. I'll fix the online .version file but I don't want to to do another release to fix the version in the download unless it is absolutely necessary...

Quite possibly. In the past, various things about engines weren't initialised correctly in the editors but this may have been improved at some point. I'll need to run some tests to determine if the activation state can be used safely (e.g. what happens with odd staging setups etc.).

No, unfortunately I've not yet had time to look into that. There is certainly more to it than that but I'll bear it in mind when I do get a chance to look at it. Are you talking about during flight or in the VAB/SPH? Yes, others have encountered it. See the posts by tg626 and my replies further up this page. As mentioned there, I'm planning to add some detailed debug logging to the code concerned and release a test version to gather more information but I've been too busy to get around to it...

Your best bet would be to post an output_log.txt and some screenshots showing the MemGraph window in a number of situations (with the scale set reasonably so it isn't all solid green). Also, some more details of your machine would be helpful, e.g. at least your total RAM and your free physical memory once you've loaded your save in KSP. Inactive missions shouldn't be creating large amounts of garbage as Squad fixed the main cause of this for 1.1.x but there have been reports that seem to imply that having a large number of tracked asteroids does nasty things. Do you have lots of asteroids? If the save game is (mostly) stock (at least in terms of part mods) then you could upload that so others could try it. Even if it uses quite a few part mods, someone may find the time to investigate it (or already have most/all of them installed)...