Padishar

That isn't how this mod works. This mod only increases the calling of the garbage collector, it forces a collection at the specified interval but, if lots of garbage is being created then the collections will still be run by Mono automatically. E.g. if, without the mod, the collections are happening every 4 seconds and you have the mod set to every 10 seconds then the heap will fill up and be collected after 8 seconds. After 10 seconds the mod will run another collection (which will only have 2 seconds worth of garbage to collect). Then it will take another 8 seconds to fill up again and then after another 2 seconds the mod will run it again. While it would be very nice if this did directly affect the random crashes, the nature of random crashes (especially ones that appear to be multi-threading related) is such that any change in internal program behaviour can have a significant effect. Two people with subjective reports are certainly not statistically relevant so please don't do anything that will flood this thread with people looking for a fix for the crashes.

Here is another post that breaks out of the message area in a narrow Chrome window...

The VAB is known to cause oddly increased CPU usage over other scenes, 60% on a quad core being about expected. I would recommend running a CPU temperature monitoring program to see what sort of temps you are getting as you may have poor contact between your CPU and heatsink.

You will need to provide more details about exactly what isn't working. Stack decouplers with enabled crossfeed should work correctly. The best thing is to provide a craft file (that's preferably totally stock unless the problem is with specific mod parts), a screenshot of your KER window (in all stages mode in VAB), a description of what you think is wrong and, if possible, an output_log.txt/player.log file after you have done a "Verbose simulation log" (in the VAB settings or you can add a special readout in flight).

No, the 32 bit version is also multi-threaded, Unity does quite a lot of stuff in the background and, in the case of the VAB, it isn't at all obvious why it does so much...

I have now sent a PR that ties the running of the GC to whether the window is shown and also has a considerably modified UI to reduce the garbage creation to a minimum (no buttons in the dialog, now uses Ctrl-NumPadPlus and Ctrl-NumPadMinus to change the rate). Edit: I tweaked the PR late last night to have a separate toggle for the collection on Ctrl-NumPadDivide so you can have it running with the UI closed.

Do you mean "what value in the Grumpy dialog corresponds to KSP default behaviour"? If so, then it doesn't work that way. The game normally doesn't manually call the garbage collector on any kind of schedule, it just lets Mono run it automatically when the heap fills up. This mod always calls it at the interval specified in the dialog whether the dialog is open or closed. It would probably be helpful to be able to toggle it off completely rather than requiring removal of the mod. I may send a PR to sarbian later if I get a few minutes...

I have just released version 1.0.0.3 that eliminates a couple of bits of garbage creation hidden in the UI code and moves various initialisers to Awake (I think it's only static ones that might cause upset but I've moved every reference member init to Awake to be sure). Edit: Another quick update to 1.0.0.4 to fix the window dragging (and I've actually updated the download link this time )

Well, it does on Windows though you have to have the window narrower than a certain limit.

A forum editor bug messed up some quoting which appears to cause issues for Chrome when displaying the thread. Load this thread in Chrome and see the post sticking out of the right margin and my quoting of it that does the same.

Ahhh, yeah, I suppose that makes sense. Interestingly, when I look at the page in Chrome, both his message and my quote of it break out the right side of the page...

No normal users are allowed to upload anything directly to the forum. You need to use imgur.com (or any other hosting site that provides direct links usable in forum posts) for best results. I'm pretty sure that there was a fairly recent post discussing a similar issue but I can't find it now so I guess it was probably in the 1.1 pre-release sub-forum. Regardless of what MJ was or wasn't being used for, it was installed, so this thread should be in the modded support sub-forum (and you should read and follow the advice given in the "How to get support" sticky thread). I suspect a moderator will move it at some point.

I've seen this argument made before on this forum but have yet to see any remotely rigorous proof that it's correct for a normal ascent profile. The current vessel drag is determined by its aerodynamic properties. Terminal velocity is the velocity at which the drag force is balanced by the weight force. It requires so much thrust to keep any reasonably sane rocket anywhere near terminal velocity that you will be better off using a smaller engine, hence less dry mass, hence less fuel mass required. The rocket will be much cheaper overall for exactly the same payload to orbit. The fact it expends slightly more deltaV is irrelevant, it needs to burn less fuel to do so in a launcher that costs significantly less.

Hmmm...

Then describe a use case...

Yes, it accesses the stock UI scaling info that Squad added in 1.1.2.

That is entirely up to cybutek, but I certainly won't be implementing it. Given the almost total un-usefulness of a terminal velocity readout, regardless of whether FAR is installed or not, I would actually vote for it to be completely removed instead. I would, however, quite like to see some of the values that FAR allows other mods to have access to be displayed in KER, though even that would come quite low down on my list of things to do...

You may be able to using the Unity profiler and/or a debug version of the player but if that was the case then I would have expected someone to have done so by now as the raised CPU usage in the VAB has been reported numerous times...

There is only one GC, this mod just calls it manually at regular intervals rather than letting Mono decide when to call it. The CTDs are very unlikely to be anything to do with the GC unless Unity have been making changes to it without telling anyone. The cause is much more likely to be a multi-threading related issue, especially as they seem to happen most frequently when in the VAB where the Unity engine does more processing in background threads (for some unknown reason).

In the VAB it appears that a large part of the memory allocation is caused by the UI that displays the parts on the left. This appears to use some rather non-optimal LINQ queries that result in large amounts of garbage, the more parts being displayed the more memory is allocated. In a stock game the extra allocation over sitting in KSC varies from approx. 400 KB/s for the smallest part group (command and control) to over 5 MB/s for the largest (utility). Having lots of part mods installed generally increases the size of the categories so increases the VAB garbage thrash. Squad are already aware of this and, hopefully, it will be fixed fairly soon. It shouldn't be too difficult to translate LINQ code into something more garbage friendly.

Yes, that's the one. Preferably with the "Start address" column dragged wider so the full contents can be seen, and in several different situations inside KSP.

Sorry if I didn't make it clear but I mean the Threads tab in the window that pops up when you right click on KSP in Process Explorer and select properties. This shows the CPU usage of each thread in the process and may shed some light on what it is using so many threads for...

You should hit Alt+NumPadPlus a few times to change the scale of MemGraph so you can see the garbage collections... Edit: but, nice vid...

I don't have access to much stuff at the moment but I think this is probably the one... GameEvents.onEditorPartEvent.Fire(ConstructionEventType.PartRotated, part);

Yes, that is one of the possibilities that I didn't bother to investigate (yet)... Another is, for rotation anyway, that there is an event that can be fired when a part is rotated but I don't know if the GizmoXXXHandles will respond to it correctly. There may be a similar event for translation.