Padishar

The reason for the KER problem is because (I assume, you've not posted a link to your source as per the addon posting guidelines, so I can't tell) you are changing the active vessel from a GUI function. The GUI functions in a mod are called multiple times per frame and if they happen to create a different number of GUI objects in these different calls then you get the error seen. It may work better if you set a flag and then do the actual vessel switch somewhere else in the code (e.g. directly from Update or LateUpdate)... I would expect the KER UI to sort itself out on the next frame so, unless this doesn't happen, this isn't exactly a critical issue...

Right, assuming the default config adds 900MB and you want it to use 16GB then divide 16000 (1 GB is approx 1000 MB) by 900 to give approx. 17.8. Now change all the lines in the file by this amount, e.g. 8 : 1690000 ...becomes: 8 : 30082000 You don't need to be particularly accurate so could just use 30000000 in this case.

For anyone else suffering with stuttering in map view, I have made some fixes to the on-demand texture loading in Kopernicus that should fix this issue. I have released a test version over in the main Kopernicus thread here: Note, this is based on version 1.0.5 of Kopernicus so make sure you have that before replacing the DLLs. I realise the OP says it works best with 1.0.4. Are there known issues with 1.0.5 or are you just playing it safe? I've not noticed any issues so far (except for the ones I've been explicitly trying to fix) but I haven't been doing very much...

Not a problem, that did get a bit technical. I have made various changes to Kopernicus to fix issues and released a test version over in the main Kopernicus thread: You can try this to see if it fixes your problem (remove Sigma's fix again). I will be testing it with a variety of planet packs today and will explicitly test EVA in this pack and others. Edit: Note, this fix is based on Kopernicus 1.0.5 so make sure you have that version before replacing the DLLs.

I have now made some further fixes to the on-demand texture loading that reduce the garbage creation still further. I would appreciate it if interested parties could give it a test and report back on how well it works. Simply download this zip and extract the two DLLs it contains into your GameData/Kopernicus/Plugins folder (and make sure to remove any configs that disable the on-demand loading). If you have any issues such as crashes or obviously missing (or wrong) textures then please upload the full output_log.txt/player.log file and either post a link here or in the PR itself mentioning your mods, what you were doing and what went wrong.

Increasing the amount of padding should always increase the time between the stutters until the point where your machine decides to start using virtual memory. However, the benefit is likely to be outweighed by the increased time it takes to do garbage collections at some point. The numbers in the configuration are simply the number of blocks of each size that are pre-allocated. The approximate usage for each size of block can be calculated by multiplying the count by (size + 16) though this will come out a bit low especially for the larger block sizes. Simply calculating the ratio between what your current settings give and what you want and then multiplying all the numbers by that ratio should get you to (roughly) where you want though it would probably be beneficial to add some padding for some of the larger blocks too (e.g. for 664, 800 and 1008, the others start to get really wasteful).

Are you certain you got rid of the fix .cfg when testing this? I'm not saying it's impossible, by any means, but it does seem a bit of a weird interaction. I submitted a pull request for Kopernicus to fix the stutter issue with panning the camera around in map or tracking station but there is also the "maps" (used to generate the actual surface) that use the on demand mechanism and these may need a similar tweak to avoid the textures being unloaded and then immediately reloaded again. If it is related to the map textures rather than the scaled space textures then there should be some messages from the on demand system in the log, though why anything should be causing the body to go inactive is a mystery. If you don't see any messages saying "Enabling body" or "Disabling body" then it will, presumably, be the scaled space textures that are being reloaded for some odd reason, but again, they get unloaded when a particular body goes out of view in scaled space so why this would happen while on EVA would be another mystery.

Just go to this page and mouse-over their names... http://forum.kerbalspaceprogram.com/index.php?/staff/

Well, for a considerable chunk of time, FAR was spamming the following exception: NullReferenceException: Object reference not set to an instance of an object at FerramAerospaceResearch.FARAeroComponents.FARVesselAero.CalculateAndApplyVesselAeroProperties () [0x00000] in <filename unknown>:0 at FerramAerospaceResearch.FARAeroComponents.FARVesselAero.FixedUpdate () [0x00000] in <filename unknown>:0 ...though that appears to be unrelated to the crash, the stack trace shows the crash happened while the Toolbar mod was doing something, though that doesn't necessarily mean that it was the cause.

It looks like a vessel in your save uses a part that contains a resource whose definition isn't installed. Have you removed or updated any mods recently? As with all bugs, a full output_log.txt file (uploaded to a file hosting site such as dropbox) may well give more clues as to which resource/mod is the problem...

The button being white means you most likely have the mod installed incorrectly. What is the KER folder in GameData called?

As mentioned elsewhere, I have submitted a pull request to Kopernicus to (mostly) fix the garbage issues with its on-demand planet texture loading code. I also plan to make another optimisation to reduce the garbage further. In the meantime, you can use the following MM patch to disable the on-demand textures (thanks to @Sigma88): @Kopernicus:FINAL { %useOnDemand = False } Just save that as, e.g. disableOnDemand.cfg somewhere in your GameData folder and it should totally eliminate the thrash from moving the camera in the map view/tracking station. KSP will use more memory as it will keep the textures for all planets loaded all the time but if you've got plenty this will probably be preferable.

Just ignore the warning for now. The latest release should work fine in KSP 1.1.2 (barring the occasional bug which you can read about in the last few pages of this thread).

Hello again... After a little chat with @Thomas P., he quickly pointed me in the direction of the code at fault and I have now submitted a PR fixing the issue...

I'm well aware of what it is and why it was created. You appear to have missed the entire point of my post, you certainly haven't answered the question and you appear to believe that, despite it being your free choice to use a "minority browser that doesn't work the same as any other browser", other developers should drop what they're doing and fix their stuff to work with it...

Why does that follow? If the agent string is the only difference, then the server is returning different data depending on the agent string and/or the javascript included in that data does different things depending on the agent string. Most decent web applications these days avoid sniffing agent strings as much as possible and instead use feature based detection, though there are some things that can't be determined, so it is still sometimes necessary. Your problem is that when the application thinks it's on Firefox, your browser does something different to Firefox and, when it doesn't think it's on Firefox, your browser does something else different to how other browsers do it. Either way, unless there's a very good reason, it makes much more sense to fix the browser so it does work the same in at least one of the cases rather than the forum being fixed (in what could be quite a tricky issue to even diagnose, let alone fix) to work with a browser that can pretend to be, or not to be, Firefox while not working the same as either and, probably makes up <0.01% of users. Far better for the forum developers to concentrate on other bugs/issues/features that will impact a much larger portion of their userbase.

For the original announcement of the downtime being on the 27th, I'd have to agree, that was rather short notice for anything considered worthy of giving notice for. However, for a pretty minor downtime like this was, does it really matter? Surely you can find something else to do for an hour (like play KSP for instance ). Given that Firefox itself works correctly on the forums, don't you think this would be better reported to the authors of your browser as a bug in their "firefox compatibility mode"? There's a chance that the authors of the forum will be willing to make specific fixes for a minority browser but it wouldn't come very high up my priority list if I were developing it and I presume it won't come very high up theirs either. Yes, it started around noon GMT yesterday (22 and a bit hours ago) and was back (mostly) alive again in under an hour. The re-indexing of the various activity stream and search stuff appears to be finished now as well...

I'm really not sure about this one but I have to wonder if Windows isn't simply trimming the working set because a large chunk of KSP's RAM usage is not accessed very much but every so often KSP/Unity does a purge of assets that aren't required and this (or some other similar Unity quirk) results in a hit on virtually every page causing them all to be loaded back in (and whatever has been stuck in the physical RAM in the meantime to be swapped out first). Like you say, on SSD it probably shouldn't be this slow though we are talking nearly 2 GB of data to shift (and up to another 2GB to shift the other way) and the access pattern could easily be quite random, avoiding sequential reads and adding more overhead, so it's possible. One thing to check would be to run baretail (or similar) on your output_log.txt and see if it says anything around the times it happens...

Or some different friends...

Glad you like it. It isn't currently possible to make it apply automatically though it should be quite easy to implement as an option (it needs to be an option at the moment for easier testing and comparison purposes). Watch this space...

Have you changed the stock UI scaling? It's possible that KER doesn't play nicely with this (e.g. reducing the scaling reduces the size of the windows but doesn't reduce the size of the fonts used).

Well, your reports are already useful as they clearly show that something is being exceedingly rampant in its garbage creation (it might be interesting to try the same thing without the heap padding to see what the stutter is like then ). Those peaks you are seeing, at what looks like a pretty regular interval, are often going out of the top of the graph, so more than 256 MB/s, which is just insane. You have a lot of mods installed and there's a fair few I don't recognise from their toolbar buttons so it's tricky to suggest any likely culprits. I would probably start by removing purely cosmetic mods and testing again. Then, try without any mods that you can think of that might do things on a regular schedule (KAC, auto-backup, life support etc.). It certainly shouldn't be anything to do with purely part based mods (unless they use stock KSP modules in really bad ways) so you can probably ignore most of those. Edit: @Wiseman, for career only I guess the most likely thing is something contract related. Do you have Contract Configurator and a shed load of contract packs? If so, try removing that (or anything else you can think of that might be career only). Also, probably worth doing a Science mode run too in case it is something to do with science experiments instead... Edit 2: It's probably also worth testing a stock career game to see if that does anything similar. It may be a stock career issue that is exacerbated by mods...

There's nothing stopping you, it reads padheap.cfg every time you hit the Mod-End shortcut... Edit: though once you get settings you like the look of you should try them on a fresh start of KSP to ensure your previous tests haven't skewed the results...

I spent quite a while writing a detailed response to this but the forum went down for maintenance just before I posted it... So, I'm not going to type it all again but the tl;dr of it was that your installation is a mess. You need to totally remove KER and reinstall it from a release download rather than the GitHub repository download you currently have. Lots of your mods are throwing the same toolbar related exception so I presume that is also installed incorrectly or is out-of-date. There are also a number of other plugins that are failing to load because they are either built for the wrong version of KSP or for the wrong version of the .NET runtime. ContractConfigurator is also reporting a lot of errors about duplicate names, use of obsolete features and unexpected attributes which would appear to imply that several of your contract packs are out-of-date. I would be seriously tempted to start again from a fresh install, installing only those mods you actually need or want (and only if they are clearly advertised as being 1.1.2 compatible) making sure to follow any installation instructions for the mods carefully.

Do you mean something like this: