Padishar

I would suggest you read this thread over in the modded support forum, follow the advice within and then, if you haven't managed to resolve the problem yourself, post your own thread in that forum with all the details and logs etc. mentioned in the thread...

All versions of KSP (since at least 0.23) have had a garbage collection related stutter though different people suffer from it in different amounts. There are numerous things that affect it but, with a large save (high vessel and/or total part count) or when flying a large vessel, it will usually be fairly noticeable. Just search the forum for stutter and you will see several quite long threads discussing the problem. Unfortunately, there isn't any guaranteed way to reduce it other than keeping your saves as simple as possible and, even then, it can still be very noticeable for some people. Making changes to your graphics settings can improve matters (basically, by making it more likely the GC pauses will fall in moments where the game is waiting to display the next rendered frame, but, once the memory usage gets above a certain level the pauses will usually last for several frames. Squad are aware of the issue (and of some of the areas of the code that are particularly bad) and have plans for various changes that should improve the situation considerably.

It sounds like you craft is broken in some way so it would be most helpful if you could upload it somewhere and post a link so others can try it out. Also, an output_log.txt file including one or more of these launch attempts would probably be helpful as would a list of what mods you have installed...

The way that the UI works to split symmetry groups has changed but it is still possible to do it in the VAB. It's a bit of a pain to describe, probably easier to just play around with a central fuel tank and 6x symmetrical radial decouplers until you figure out how it now works. I think the main issue is that when you click to expand the group and then click on a member it just deselects that member leaving the others selected, if you then click on it again to select just that one then it just selects it again. So, you simply need to click to expand the group, then click on all the parts you don't want to move leaving just those you do and then drag one of the still selected ones...

If this is a question then, no, it doesn't plot fps on the graph but it does have the ability to show a little HUD with fps and/or 4 memory related numbers on screen. Hit Mod-F to toggle the display or click the Config button in the main graph window and play with the options. If it was more of a request then you may get a more favourable response (or any response at all) if you word it a little more politely...

I've now done a more detailed examination of this behaviour and conclude that, during flight, there is a rate of memory allocation that is proportional to the total part count of all the on-rails vessels in the save. This results in large and complex saves suffering significantly more with GC related stutter. This file contains the various saves the tests were run on. They are all based on the "Platonic Stations" save which contains the top stage of a KerbalX in a ~200km orbit and four stations with part counts of 308, 308, 642 and 1017. The other saves all have one or more of the stations terminated to reduce the overall part count with names that indicate what is present, e.g. TetraOcto is the version with 1 tetrahedron (308 parts) and the octahedron (642 parts). This table shows the approx. allocation rate from the screenshots above. Save On-Rails Parts Alloc Rate KB/s JustJeb 0 600 Tetra 308 1400 TetraTetra 616 2100 Octo 642 1900 TetraOcto 950 2600 TetraTetraOcto 1258 3300 Platonic 2275 4900 This shows a pretty consistent increase with overall part count. The only exception being TetraTetra allocating more than Octo despite the slightly lower part count. I suspect this is due to there being a per-vessel component as well as a per-part one. This only seems to occur in the flight scene. In KSC and the astronaut complex all of the saves allocate around 200-240 KB/s. In the tracking station they allocate slightly more but still fairly constant with this small number of vessels though I suspect the tracking station will allocate quite a bit more with many vessels. The code that determines if an on-rails vessel enters the physics bubble is the only bit I can think of right now that relates to on-rails vessels and only happens in the flight scene so this may be a good place to start looking. I'll be posting this to the bug tracker in the near future...

Steam does only download the 32 bit version on 32 bit versions of Windows so, are you certain you have a 64 bit version of Windows? Also, the name of the 64 bit Windows executable is KSP_x64.exe

The devs are currently on a two week break after the release crunch so you shouldn't expect to hear any news for at least another week, and given the random nature of the problems, it is likely to take a few days for them to make any significant progress on it...

Please follow the advice in this sticky thread from this very sub-forum...

Another small update to add the current total of heap allocated (HWM). The new screenshot in the OP shows an "interesting" (not to mention, in need of some serious optimisation) issue. The point earlier in the graph where the memory allocation rate was ~5 MB/s was when flying the identical vessel to in the screenshot but in a save that also contains 4 fairly large space stations (2 of ~300 parts and 2 of ~700 parts). The point where the shot was taken was in a copy of the original save with the stations terminated and shows a rate of ~500 KB/s. That's a lot of memory usage for 4 vessels outside of physics range that should be needing little CPU and certainly shouldn't need to be allocating anything like that much memory.

Thanks, though I was really wanting to see the per-thread CPU usage displayed in the Properties dialog on the KSP process, and especially so if the usage goes high in any scenes other than the editors...

Try following the advice in this sticky thread in this very sub-forum...

I can't see any reason why it should in the situations you describe. There is a, not totally understandable, higher CPU usage in the VAB (up to between 3 and 4 full cores worth), but, sat on the runway with no other vessels within physics range, it certainly shouldn't be using much more than 1. Can you try the Process Explorer test described in this post: ...and post the screenshot. Preferably, do two shots, one while the usage is "normal" and one after it has increased...?

What @Red Iron Crown said, the cheeky ninja...

I believe it is a limitation of Unity, the method used is the only API that can be used to load assets that aren't packaged up so is the only way to support mods (and the Squad folder in GameData).

This is probably the common issue caused by the presence of extra inactive (usually virtual) network adapters. The usual culprit is Hamachi though other similar programs can also cause it and even some network adapter drivers can create extra virtual adapters that do the same. If you have Hamachi installed then remove it and test. Otherwise, check your network adapters in control panel and disable or remove any extra ones that you can't account for. I believe it has also been known for a machine using wireless that also has a disconnected ethernet adapter to have the same problem. If this is the case then disable the ethernet adapter, either in the network adapters list or in device manager.

What other mods do you have? Have you used a fuel switch mod to change the tanks to LF only? Please click the settings button, click the verbose simulation log button, wait for it to pop out and then quit and upload your output_log.txt file somewhere and post a link. Actually, while that is good advice in general when problems are had with the deltaV calculations, the problem in this case is simply that you have the engine and the radial decouplers all in the first stage so the droptanks are being dropped at the start. KER should really show an extra "stage" in situations where something gets decoupled in the first stage so that the full mass of the vessel is displayed. This was mentioned sometime in the last few pages...

Indeed it is. Try installing this mod and then, once at the main menu, hit Mod-F2 to display the log window. When I did this earlier I was getting ~28 KB/s sat at the main menu but nearly 5 MB/s when the log dialog was open... I've also written a simple profiler for the internals of KSP that graphs the percentage of time the main thread spends in various functions. A mod can easily be profiled by inserting the start and stop calls directly in the mod source or the PatchAsm part could be extended to support patching of different assemblies.

You should be able to look at ModuleDockingNode.state. This is a string of the name of the current state of the docking state machine. I think the state should be "Acquire" or "Acquire (dockee)" when it is actively pulling in. Not sure what it will be after undocking but before port reset but it should be easy enough for you to log it and find out...

Just released a small update to 1.0.0.1 to slightly optimise the UI code (changed from using GUILayout to GUI).

Hehe, nice. I only suggested not using it because it was completely non-functional in the pre-release 1.1 versions and, while Squad did "fix" it for the release, it has always been inherently iffy especially with some graphics shaders. It certainly sounds like there is something wrong with your DirectX installation or your video driver as the default DX9 mode should work fine...

I see a few exceptions before the main bulk of them start but the most suspect looking one is one from Contract Configurator. I suggest trying to remove that mod (and presumably any other mods that depend on it) and try like that.

You would be better off asking in the threads specific to the mods in question rather than in this sub-forum which is dedicated to developing plugin code.

Upload your output_log.txt file to a file sharing site and post a link as described in here: Is this the first version of KSP you have run or did you previously run 1.0.5 or an earlier version. If so, then make sure you aren't starting the game with the -force-opengl or -force-d3d11 switches. In any case, the output_log.txt (and preferably a DxDiag report) should help to narrow down the cause.

Yes, I meant to reply to this: ...so he would know why he can't find it and what he might be able to do to get access to some of the posts, but I guess I clicked wrong somewhere...