Padishar

They did fix the highlightling/AA memory thrash in KSP 1.2.1. Or do you mean something else by "that"?

I've only tried disabling the Anti-Aliasing option but I think others have said you need to turn off both of those highlighting options if you want to keep AA.

Well, it certainly isn't a common problem. There should always be an output_log.txt file in the KSP_x64_Data folder. If you have restarted the game then it will have been overwritten. It may not tell us much but it might help...

The problem here is that, on 32bit Windows, KSP can only use 2 GB of RAM, not 4 or 3.5 or any of the other numbers bandied about. The only real solution to running on Win32 is to reduce the texture resolution in KSP's settings to minimum (or possibly setting the command line option to force dx11 or opengl mode, not sure if these still use a lot less memory).

A little update on the sort of stutter improvement possible in a mostly stock install of KSP 1.2.1. This has KER installed but I deliberately kept all its windows closed to avoid it skewing the results. I ran KSP 1.2.1, loaded the save with the vessel in my avatar (this is a 1410 part vessel) and switched to it from the tracking station. The garbage collections were happening at 20 second intervals. I then applied the default MemGraph heap padding of 1024 MB and waited for the next garbage collection. And waited, and waited some more. This shows the initial game loading process and the first three garbage collections that happened at 20s intervals. After applying the padding, it got to the end of the graph (10 minutes since starting the game, about 8 minutes since applying the padding) without another collection: I left it running until the next collection happened: This improvement will not be the same in all cases, mods that allocate lots of large blocks of memory will significantly reduce the effectiveness, but this sort of improvement should be common in mostly stock installs...

You're welcome. Indeed, you can have it applied automatically on startup by setting the applyPadding value in GameData\MemGraph\PluginData\MemGraph\settings.cfg to true. The padding is then applied very early in the startup of KSP. Because it's so early, a significant amount of the padding gets used by the permanent data that KSP loads which does slightly reduce the effectiveness. For maximum benefit, the padding should be reapplied from time to time but, each time it is re-applied can cause the heap to become more fragmented, resulting in it tending to grow over time. So, it's a bit of a balancing act and I've not decided what to do about it yet but, for the moment, you should probably apply the padding again with the hotkey after loading your save and then only try reapplying it if the stutter gets noticeably worse... You can also hide the window by default by setting visible to false and you can change the hotkeys (or disable individual ones by setting them to None).

It isn't currently possible but it shouldn't be too difficult to make it configurable. I'll see what I can do...

Why do people keep posting that it was a surprise? Squad said they were working on some fixes for a 1.2.1 patch in the October 21 KSP Weekly and they announced in the KSP Weekly on Friday that 1.2.1 had been pushed to experimentals sometime during last week. Maybe the release being this week rather than next was a surprise but we knew it was coming sometime fairly soon...

I've sent my thoughts about the supposed interference, and about the fine rotation feature in EER in general, directly to LGG, but I'll just point out here that the main features of PAD are that it displays the attach angle of the part and allows you to change the angle increment of the stock part rotation keys (normal and fine) and also set increments for the Alt-WASDQE keys. This allows you to easily set the rotation to any arbitrarily accurate angle, e.g. the vessel in my avatar required angles to be set to 31.72 degrees.

I'd like to help out with Kopernicus development but I've got too much on my plate already for the amount of free time I have available...

I agree that the colours of everything should really be configurable but a lot of the UI code needs an overhaul to reduce the garbage creation and it doesn't make sense to do this before that's done. Indeed, 1.1.2.4p should work in 1.2.1 as well as it did in 1.2.0. There will be another test release shortly to stop the version checking complaining... This is a bit strange. If they are normal engines then they should calculate something unless the are falling foul of the changes to resource flow in 1.2 (they may override the default flow mode of monoprop). Yes, as mentioned several times in the last few pages, the deltaV calculation code has not yet been updated to cope correctly with all the changes to the fuel flow in KSP 1.2. I explicitly tested these when making the changes to fix ion engines the other day so I am surprised at this. Can you provide more details (example craft file and screenshot of build engineer window in all stages mode)?

The most likely reason for that file to be missing is that it was removed in KSP 1.2 (the code it contains is now in Assembly-CSharp.dll). You should simply remove the reference to KSPUtil.dll from your project and it should build fine. If you still have problems then the "Plugin Development Help and Support" sub-forum would be the best place to get help... http://forum.kerbalspaceprogram.com/index.php?/forum/29-plugin-development-help-and-support/

Try posting in the (modded) technical support forum after reading the "How to get support" sticky thread that explains what info you will need to provide for people to help you...

Thanks for the kind words (and to any others that I've not acknowledged previously). This game is too good for me to avoid playing because of annoying stutter so I had to try and find a work-around...

Oops, sorry about that. Here's version 1.1.2.4p... https://www.dropbox.com/s/tl7xdbwcvou2tw9/KerbalEngineer-1.1.2.4p.zip?dl=1

Have you changed the stock KSP "modifier" key binding? MemGraph uses that in combination with the numpad keys or the end key. If you have copied your settings.cfg file from a linux install then this may be set to the right shift key instead of the default (on Windows) of Left Alt. If "modifier" is set to Alt and Alt-NumpadMultiply doesn't toggle the window display and Alt-NumpadPlus/Minus don't change the scale then something is odd about your keyboard. Any chance you can run KSP, try to apply the padding with Alt-End (or whatever your modifier key is actually set to), quit out of the game and then upload the KSP_x64_Data/output_log.txt file to a file sharing site (e.g. dropbox, etc) and post a link to it? Disabling just the anti-aliasing on a default stock install definitely does stop the highlighting related memory allocation for me. The log file may shed some light on why it doesn't for you, or you could try deleting the settings.cfg and letting the game recreate the defaults to see if that makes a difference (especially if it was copied from a linux install).

You are decoupling the engine from the root part in the same stage that you light the engine, hence 0 dV... Edit: Actually, it isn't that. Your Xenon tanks are empty (look at the Resources panel at the bottom of the screenshot)... Edit 2: Also, your fairing is quite tight around your payload. I would recommend testing that it doesn't break your payload when you jettison it...

First, it would be helpful if you actually stated the versions of KSP and KER you are using. I'll assume you are using KSP 1.2 and KER 1.1.2.2p, in which case, this is a bit strange as the first commits in my pull request that this version is built from are specifically to fix an issue with Xenon/Monoprop flow in complex, drop-tank configs. However, a simple test shows you are correct and it turns out that my changes are causing any tanks that are never decoupled from the root part to be ignored by the calculations. I have fixed this and both simple and complex ion craft now appear to work correctly. Unfortunately, despite my suggestion to @TriggerAu helping him to fix the crash on vessel switch issue in KAC, I've not yet been able to fix it in KER. Well, this isn't strictly true, I believe that I have probably got a fix for the crash but I am now seeing an issue where having the KER rendezvous panel open when switching vessel (by any method, even the stock map-view switching) will occasionally result in a total hang of KSP after the switch. I've not yet managed to track this down so it may not be much of an improvement but I've included the fix anyway... There are also a few other fixes and garbage improvements that I had hanging about in another branch, so, without further ado, here is test version 1.1.2.3p... https://www.dropbox.com/s/rda6frbmf2kzg6e/KerbalEngineer-1.1.2.3p.zip?dl=1

Incidentally, this issue has already been reported a number of times (the most recent I could find is http://bugs.kerbalspaceprogram.com/issues/13035)

More specifically, this one: However, there should be another test build later today...

There are nearly as many potential causes of GC stutter as there are stars in the sky. This particular one that stops when you turn off AA actually appears to be part-count dependent. I put one of your vessels on the pad and got the same result, then I put just half of it on the pad and still got a lot of garbage but much less. I then put various different chunks of the vessel on the pad and got various other smaller rates of garbage. I then did the same thing with a couple of stock vessels and a few of my own and the problem seems pretty universal. I'll be writing up what I've discovered so far in a bug report later this evening and also reporting another bug that I've stumbled over while testing this. Can you confirm you don't mind your save (and name?) being attached to a Squad bug report?

Well, MechJeb is responsible for some of the garbage but the bulk of it with your vessel can be eliminated by turning off AA. I suspect that one of the parts on the vessel is triggering the issue with the highlighter. I'll have a go at working out which this afternoon if nobody else does first.

When running under the debugger, certain things are done from a different thread to the main one. You are probably initialising some variable with the result of that function in a constructor (or just directly in the class definition). Set it to a sensible value there instead (e.g. 0) and then do the call to get_realtimeSinceStartup in the Start or Awake function of your class... BTW: a link to github or other way to view the source is always helpful when trying to get help with plugin development...

Well, the highlighting sort-of works with AA turned off though some parts don't seem to highlight and the highlighting also seems to get occluded by some parts. I've already mentioned it to some Squad folks in IRC and, as soon as they tell me where best to report it properly, I will do...

After downloading a totally fresh copy of KSP 1.2, only installing MemGraph 1.1.0.2 and using your save with no MJ, I can now reproduce the issue. I've looked at it with the Unity profiler and, for some reason, with this vessel but not with the pod on the pad, the part highlighting system in KSP decides to recreate a 0.8 MB cache bitmap on every frame... I'll investigate some more and report it. I'd like to know why my other installs don't do it, perhaps I changed the highlighting settings... Edit: my other installs have antialiasing turned off, this totally removes the effect... The reported allocation rate peaks around 750 KB/s just before each GC (due to the way that the display in MemGraph works this is the closest to the real rate) and the collections are over a minute apart...