Padishar

Yes, mods do create garbage, some significantly more than others. Some parts of KER have been highly optimised in this respect, e.g. the VesselSimulator that calculates deltaV/TWR etc. uses object pooling and other techniques to prevent rampant memory allocation, but other parts are less than optimal and do cause quite a bit more garbage than they should. I have various optimisations planned based on 3 specific strategies to reduce garbage: Avoid language constructs and/or library functions known to cause excessive garbage. Avoid rebuilding strings when the value they represent hasn't changed. Reduce update rate of readouts as most recalculate either every physics update or every rendered frame (and allow rate to be adjusted by user). These will require changes to quite a lot of code, including some fundamental changes to decouple the readout update from the display, and I need to write a little plugin to measure the effect of the changes, so it will take a bit of time.

Thanks for that, it looks much better now. I'll get the PR sent to Cybutek as soon as possible. This is most likely the same issue with ActiveVessel being null that has already been fixed. Try the version I linked above which should also include the fix for it.

I have found and fixed a few bits of code that could be responsible for the object pooling issues. If anyone wants to give it a try then just copy the DLL from the zip linked below over the one in your GameData\KerbalEngineer folder (make sure you are using 1.1.0.2 first). KerbalEngineer_poolfix.zip I can't test it right now because I'm "working" but I will be giving it a bit of a test later this evening. Edit: If you're interested in seeing the changes then see the morefixes branch on my github repo.

From the change log at the "Online ReadMe and ChangeLog" link in the OP: 1.0.19.1, 2016-11-09 Added: Key binding editor accessible under 'Settings' on the Build Engineer. Does this not do what you need?

Thanks for that. This log shows some very strange things happening during the simulations, e.g. for the last run the vessel only has 5 parts but the scans for fuel sources are looking at parts with ids up to 17, including a parachute and a mystery goo, neither of which are on the vessel. There are also mentions of multiple different parts with the same id. It looks very much like there is some fundamental issue with KER's object pooling mechanism. I presume that you did have a vessel loaded at some point in that session that had at least 17 parts and that references to some of these parts have been left in some objects that have been returned to the pool for reuse. I'm rather surprised that the deltaV calculations are working at all reliably with a fundamental issue like this but I will take a close look at some of the code to try work out where the problem lies...

Sure, test it by all means, I may be mistaken. On the subject of RDP, I used to do a fair bit of mod development and testing over RDP (when testing the deltaV code in KER or my angle rotation mod it doesn't really matter if I only get a few fps and, actually, I think the game runs at a higher speed but the RDP connection just drops some of the updates) but, unfortunately, KSP no longer renders correctly when run remotely since the upgrade to Unity 5. This is a Unity issue, the same thing happens with the Unity editor, which has upset quite a few people in the Unity forums...

I wouldn't expect KER to function at all without that DLL. I can't see how the app launcher button during flight can possibly work without it and I'd be surprised if it even allows the main KER DLL to load with a missing hard dependency...

Or just learn to use ModuleManager to make the alterations for you so you don't have to change the original cfg files and your changes won't conflict with changes that other mods may make to the same parts...

Unfortunately, that isn't the right log. Rather than the KER specific log, I would need to see the output_log.txt (or player.log on mac/linux) file as it contains a lot more diagnostic output from the simulation code (i.e. it shows how the scan for fuel sources is working). This is probably a separate issue with the code that decides when to stage during the simulation. If you deliberately unbalance the LF and O then it can decide to not stage until all the currently active engines stop burning. This causes the effect where asparagus stages all get lumped together because it doesn't stage the empty boosters until all the engines have stopped. If anyone does see this issue (or any other issue where you think the deltaV calculations are going wrong), then please generate a "verbose simulation log" and upload your output_log.txt/player.log file (not directly in a post, just a link to a file hosting site please). In the VAB/SPH you click the KER Settings button and then click the "Verbose Simulation Log" button. Once the button has popped out again you can quit and upload the log. In flight you will need to add the "Log Simulation" readout from the Miscellaneous section to one of your windows and then click the button. Please also include a screenshot of the "wrong" readings, in the VAB turn on "All Stages" and turn off "Compact", and in flight make sure that both the total and staged readouts are enabled (unless changing the readouts, somehow, affects the issue).

I can't think of any obvious way that KER could be causing this but I guess the most likely thing is an exception being thrown in the FixedUpdate handling. Could you repeat the issue and post an output_log.txt? See the "how to get support" sticky thread in the modded support forum for instructions on how to do this.

Discontinuing the 32bit build would do more than inconvenience those users who run 32bit Windows. The current state doesn't significantly inconvenience anyone, let alone 90%, most users don't need to run the 64bit version and it isn't that much of an annoyance to have to right click and select the 64bit version explicitly. I'd rather they simply added an option to let you select which one to launch, then everybody can be happy...

I think it was more like 10% but even if only 5%, that still makes it a considerable number of users for a product that has sold well over a million copies, representing a significant amount of money. It would also be seen as a pretty dodgy thing to do if they removed the 32bit version now, all the people on 32bit who have already bought it would be denied the upgrade. The main thing that has to be remembered is that there is actually very little point in running the 64bit version unless you are modding the game fairly heavily. If you are modding the game (at all, let alone heavily) then it is highly recommended that you create a copy of the entire KSP install outside of Steam and mod that so that you don't get nasty problems if/when Steam decides to update your game, potentially breaking mods and possibly corrupting saves due to non-functional mods. In some situations the 64bit version is slightly faster than the 32bit version and it is much less likely to crash due to running out of memory but the stock game in 32bit can and does still provide a lot of entertainment for a lot of people. As I implied above, the fact that people still use 32bit Windows and hence need the 32bit version has no bearing on which version Steam decides to run on 64bit Windows. Steam knows you are on 64bit (it doesn't download the 64bit version on 32bit Windows) so it could very easily (as is obvious from the various different implementations we have seen in the last week) launch the 64bit one by default or give you an option to choose...

This is a known "issue" that has been around for a long time but appears to have got significantly worse in 1.1. There are several other threads discussing it: ...and probably several others...

On 32bit Windows, Steam only downloads the 32bit version, so it's even more of a mystery why it doesn't automatically run the 64bit when it's available. I never actually launch from Steam so it doesn't bother me in the slightest but I guess, if I did, I would like to be able to configure which version it runs when you launch the game, rather than having to right-click and choose it from a menu to be sure...

Because: ...this is, simply, the wrong way to write code that runs under Unity (or any other system that uses a garbage collection based allocator). If you actually mean "why is KSP like this?" then the main reason (IMO) is that it is very easy to make this sort of mistake, the developer has to be constantly aware of how much memory is being allocated on the heap and write the important bits (i.e. any code that is run on every frame or physics update) to create the minimum garbage possible. The Squad developers have not done this, but as for the real "why", only they can say. It would certainly have been very easy, while the game was in early development, to just ignore this and write code the "simplest" way (which is often highly inefficient in memory allocation terms).

This is actually a well known and (fairly) well documented limitation of the Unity engine due to how it is implemented. There are many places that discuss ways to reduce the effect, all boiling down to reducing the amount of garbage the game code creates during scenes. KSP can quite easily allocate and discard over half a megabyte of memory on every rendered frame which is, simply, far too much. If this were reduced to a few k per frame then the garbage collection would run ~100x less frequently. Would you complain if the stutters only happened once every 10 minutes? It certainly isn't like driving with square wheels but, to use an equally silly car analogy, it is more like Squad have forced us to drive with the handbrake on, there's nothing really "wrong" with the engine, it just isn't being used in the "correct" way. You can "strongly suggest" anything you like. However, I know that a lot of the stuff mentioned in that thread is very out-of-date and quite a few parts are not exactly accurate because it is aimed at people who do not have the detailed technical knowledge to fully understand the real issues. In that particular case, there used to be a horrible audio stutter along with the visible one but this was (almost entirely) fixed sometime during the life of Unity 4 and the GC no longer (well, almost never) blocks the audio threads any more.

Not by anyone that knows what they're talking about...

For this example KER is treating the decoupler as if crossfeed is enabled. Are you sure you didn't change it? I wouldn't expect MJ to be going wrong in that situation but, as far as I can tell, KER doesn't either... Can you click settings and hit the Verbose log button and then upload your log?

I'm pretty sure that nasty issues in 5.3.x were mentioned in a devnote sometime in the last few months... Edit: In fact, a post in this very thread from a Squad dev linking to a Unity release note:

It isn't really a good idea to rename the exe in the way you describe. In fact, I'm a little surprised it would actually work without you also replacing the KSP_Data folder with the KSP_x64_Data folder too (I thought there were some native DLLs in there that wouldn't load into the wrong version and that the player generates the name of the data folder to use directly from the exe name). You would be better off just running the KSP_x64.exe directly from explorer or creating a shortcut to it. Have you tried restarting your steam client or manually telling it to check for updates?

Yes, my understanding is that KSP 1.1 currently uses Unity 5.2.4 and the wheel issues have already been fixed in Unity 5.3.x but, unfortunately, that introduces some other issues with KSP that are even more serious so it will probably not happen until KSP can use Unity 5.4.x. That has recently gone into beta so will probably be evaluated by Squad once the current release and patches are out of the way...

If that's all the readouts you have then I'm surprised it's having as much effect as it seems to be. Of those, only the setup code for the deltaV simulation (used for the TWR and deltaV readouts) should be taking any noticeable time (the actual simulation runs in a background thread but the vessel's state needs to be copied so the background thread can run safely). Can you try adding the slider that controls the simulation rate, set it much higher (e.g. all the way up) and see if the speed improves?

Only you can really answer that. Some of the readouts have to do some quite complex calculations so it can cause a noticeable slowdown especially if you happen to be showing several of the more complex ones. Also, at the moment, most of the readouts get updated either on every graphics frame or on every physics update, and this is probably quite a bit more often than they really need to be. I have been thinking about adding a new control that lets the user slow down the update rate to reduce the impact (e.g. a slider similar to the one that controls the time between runs of the deltaV simulation code, but affecting all the other in-flight readouts instead). I don't think this should be too tricky to add, simply make the code that currently triggers the update check how much (real) time has elapsed and only run the updates when more than the current setting. If you provide a screenshot showing all the readouts you have visible then I can probably suggest which ones are likely to be having the largest effect. You can then probably move some of these to a custom section that you don't keep open most of the time. E.g. you don't really need the code to be trying to recalculate the impact location and biome except when you are on a sub-orbital trajectory, the intake air calculations are only needed when in an oxygen atmosphere, etc.

Thanks for doing the legwork there, I was pretty certain he was wrong...

[citation needed] As far as I'm aware it has always been a Unity game since before the first versions were made public...