Padishar

It would be much more helpful if you could post uncropped screenshots (so they show the staging setup of the vessel) with the KER window not in "Compact" mode and with the "All Stages" button pressed. Uploading the craft files would also be handy, especially if the same thing happens with a totally stock vessel...

You're welcome. From the look of your graph you must have one or more mods generating a very large amount of garbage, 130 MB/s is very high. You should probably have a look to see if any of your mods have updates available. My first guess would be that you have an older version of the Contract Configurator mod and you have quite a few active contracts. If this is the case then there is a newer version available that fixes this. However, their could be other mods that are also causing too much garbage. If you could post a list of your mods (or upload an output_log.txt file somewhere and link to it) I may be able to suggest which mods are most likely to be causing the problem. Also, which version of KSP are you running? Version 1.2.0 had a serious garbage issue when both part highlighting and anti-aliasing were switched on. This was fixed in 1.2.1 though that introduced a crash issue in the same area of the game code. This crash has been fixed in version 1.2.2. If you are running anything earlier than 1.2.2 then you should disable either the part highlighting or the anti-aliasing to avoid either the garbage thrash or the crash.

Yes...

Can you try running the game, let it get to the main menu, try Alt-NumPadMultiply, Alt-NumPadPlus and Alt-NumPadMinus (their effects should be obvious from the graph window) and then try Alt-End. Then quit the game and upload your whole output_log.txt file to somewhere like dropbox and I'll take a look...

In this case the KSP.log file may also be useful as it includes timestamps...

Yes, sorry, that was the first thing that occurred to me but then I spotted the thrust and TWR were different so I've just tested it and see the same thing. I'll investigate... Edit: @peteletroll, it appears that I introduced this problem back in September and it has been present in every KSP 1.2 compatible version there has been so far. Rather annoying that neither I nor anyone else spotted the problem in one of the many test builds since... I've submitted a pull request to fix the issue though I've not had time to build a test version yet...

You have to turn it on in the settings...

I stand corrected, thanks for that. It would be nice if MSDN said something about it actually disabling the AVX instructions in the CPU but it isn't the first bit of MS documentation that's wrong or misleading...

Since version 1.1.2.5p it should be calculating using the new KSP 1.2 rules. Nobody has reported any issues with this so far...

In the interest of (hopefully) removing confusion about the fuel flow changes in KSP 1.2.x, I will describe the main differences here: Neither fuel lines or node attachments now have priority for providing fuel to a part. Pre 1.2, fuel lines were always scanned first and if any fuel line managed to provide fuel then the scan would stop. If they didn't provide fuel then it would go on to scan the node attached parts, then the part itself and finally, a surface attached parent. Post 1.2, priority is handled completely differently (see below) and fuel lines have no effect other than allowing fuel to flow between two parts that don't have a direct, crossfeed enabled, connection. Fuel can now flow both ways between a part and a surface attached child. Pre 1.2, a part would never draw fuel from a surface attached child part. A part surface attached to its parent could draw fuel from the parent but only after fuel lines and node attached parts had provided all their fuel and only if the part had crossfeed enabled and the part wasn't an enabled tank for the type of fuel. Radial decouplers had their crossfeed enabled so they would draw fuel from the parent tank (usually) they were attached to but a fuel tank attached to the decoupler wouldn't be able to draw fuel from it due to being a fuel tank. Post 1.2, fuel will happily flow both ways across a surface attachment, only being prevented by the crossfeed setting on the parts. This is why, in 1.2, the boosters on your old asparagus designs (or new ones that don't use fuel lines) no longer stop burning when the fuel in the boosters runs out. You need to explicitly disable the crossfeed on the radial decouplers and still use fuel lines (to get a one way flow across the decoupler) rather than trying to use the new priority mechanisms to control the flow. Basically, the way the fuel flow now works is that it follows all part connections subject only to their crossfeed settings and adds all the parts to a list. It then draws the fuel from all the parts that share the highest priority number (and have some fuel). E.g. if an engine can draw from 4 tanks with priorities 0, 1, -10 and 0 then it will initially draw the fuel only from the tank with priority 1. Then it will draw from the two tanks with priority 0 and finally it will draw from the tank with -10. When drawing from multiple tanks simultaneously, it will drain proportionately to the amount of fuel in each tank, e.g. if you have two tanks containing 10 and 90 units and something draws 10 units, the old system would draw 5 units from each but the new system (the _BALANCE modes, specifically) will draw 1 unit from one and 9 units from the other. The only ways you can affect it are: Adjust the priority offset of the tank in the advanced tweakables. Change the stage the tank is considered in (the base priority is 10*stage, a tank that never decouples from the root part is considered in stage -1). Change the crossfeed setting of parts or insert crossfeed disabled parts between other parts. Add fuel lines to create one way connections between otherwise disconnected parts. Change to a non _BALANCE flow mode to restore the "equal amount from each tank" behaviour. This should work, in theory, but needs to be done in the engine's config (or possibly using a TweakableEverything type mod). This system is much easier to understand than the old system was but it isn't directly compatible and you may need to tweak more advanced vessel designs (both planes and rockets) to make them behave the same as they used to... I know your intent is for landing approach so things are generally flat, but it should really also work when you're a significant way round the planet where "horizontal distance" isn't well specified. I presume you actually mean great-circle distance at the altitude of the target point. A bit picky, but when there is significant curvature it will be quite a difference... Well, if I'm reading it right, then it's going to be some kind of target point, usually near the start of the runway. I'll initially implement it just reading the normal target (with a beacon vessel) and see how that works but I'll also investigate Waypoint Manager and see if that can provide a point to use (e.g. if there's an easy way to read the next waypoint location from another mod then I can probably use that). Don't worry, KER won't be doing any inaccurate maths. It'll just be providing a number of readouts using different units that real pilots are used to using for quick mental maths. Adding a calculated current glide slope readout (and slope to target) would also be a good idea. Would it be best as an angle (e.g. 3°) or as a ratio (e.g. 1:20), or even switchable by clicking on it...?

Given the only mention is in the deformables section, which KSP doesn't use, I wouldn't expect anything in KSP/Unity to be any faster. The MS documentation for this option indicates that it disables the use of the XSAVE instruction in the Windows kernel. Nothing to do with AVX as far as I can see, it concerns the saving of the processor state so is only relevant to CPU context switches. The bit of software on your machine most likely to use AVX is your graphic card driver (or video encode/decode stuff but that's irrelevant to KSP) but even this is unlikely to make any significant difference as it just won't get used enough to be significant. If only 1% of the time is spent doing things using AVX instead then you will never see more than a 1% improvement (and probably more like 0.25%). Indeed, SSE2 is an absolute requirement for Unity 5 (and probably 4 too) games. SSE2 was introduced in the first Pentium 4 CPUs so I really wouldn't want to play KSP on a machine without it, even if it were possible...

Actually, the calculations aren't as "more complex" as I thought. The readouts, as they stand, while making it possible to do pretty accurate suicide burns, do still have some accuracy issues and need you to understand what the readouts mean so you watch the correct one to know when to start the burn. I would recommend that you watch the video mentioned in the pull request linked above. In any case, here is version 1.1.2.7p including these changes for testing. This is built from my withpr95 branch. Issues with these new readouts, ideally, should be added to the author's pull request, but if you don't have a GitHub account then post them here. I anticipate that another readout that gives "time to start of suicide burn" will be requested. This should be reasonably easy to approximate from the other values calculated... I can see the attraction. The easiest way to implement it is probably to simply add four new readouts that give these values in these units rather than implementing a general system to change the units displayed. I have a couple of questions though. First, what should the distance be to, a target (e.g. a beacon at the start of the runway) or something else? Second, what should be used for 0 height, sea-level (messes up nice calculations if landing spot is at high altitude), current terrain altitude under vessel (inaccurate if ground is not level on approach) or the height if the same thing the distance is measured from (this sounds best to me)?

I suggest you check whether you are running the latest dev version. The deltaV calculations were updated in version 1.1.2.5p (and another update has been released since then). See my sig for a link to the relevant post in the KER thread... Edit: In KSP 1.2.x, you don't need fuel lines for fuel to flow from side tanks unless there is a part in-between that has crossfeed disabled. If you have a vessel that you think is calculating wrong with version 1.1.2.6p then please post in the KER thread giving the craft file, a screenshot of the BuildEngineer window in "All Stages" mode (or the flight engineer window showing all the deltaV readouts) and a description of what you think is wrong. An output_log.txt file after doing a verbose simulation log (in the settings in the VAB or a special readout in the Misc section for in flight) could also be a help, especially if you use mod parts... Edit 2: Also, @TheRagingIrishman, this thread was a month old when you posted, it should really have been left to slip quietly into history, except for, perhaps, the OP returning to say thanks for the answers...

Or, slightly more accurate, not yet. There is this pull request that adds readouts that use considerably more complex calculations. Given the release of KSP 1.2.2 will probably be a little longer, I may try to release a test version that includes this code later today as, if it gets tested in the wild (and works well), Cybutek may be more inclined to include it in the next release...

Well, I'm not aware of any remaining serious problems caused by the KSP 1.2.x updates so I'll probably recommend to Cybutek that he looks at merging it and doing an official release shortly after the KSP 1.2.2 release which should be happening soon (it was announced as being in experimentals last Friday). There are still various new features, optimisations and other tweaks that I have planned but they shouldn't need to delay the release...

Not as far as I know. I had a very quick go at writing a mod to add a "Leave seat" action to the command seat back in 0.25 (I think it was, it may have been even earlier). This would've let you add your command seats to an action group and trigger a mass exit that way, but there were a number of problems, mainly related to the automatic vessel switch to the Kerbal happening multiple times, that I gave up on it. I'm not saying the problems were impossible to solve, I just wasn't motivated enough to bother trying very hard...

For useful background reading about garbage collection matters, you would do well to check out some of the following threads: Also, check out this page from the Unity docs... https://unity3d.com/learn/tutorials/topics/performance-optimization/optimizing-garbage-collection-unity-games

Well, it's certainly not just you breathing... As for whether those values read 0 for me, I really don't remember off-hand, though I assume they do or I wouldn't have used Sarbian's GCMonitor to watch it or gone on to write MemGraph... Hehe, thanks, though it's actually Cybutek's mod and I help develop it because I feel similar...

I can't try it right now but I suspect that they've either never worked correctly or they were disabled at some point because they made it very obvious that the game had extreme garbage thrash issues.

@Caswallon, yes, it's this pull request on Cybutek's repo: https://github.com/CYBUTEK/KerbalEngineer/pull/105

Without seeing your logs it's difficult to say, but I suspect you are running the 32 bit version of the game and it is hitting its memory limit of approx. 3.6 GB. If this is the case then try running the 64 bit version instead (either right click in steam and choose the relevant option or just run KSP_x64.exe directly).

The problem is that you are running the 32 bit version of KSP and trying to load that many mods is causing it to run out of the max 4GB of address space that a 32 bit program can use. Just run the 64 bit version of the game instead (right click the game in steam and select the option or just run KSP_x64.exe directly from explorer)...

The problem is that you are running the 32 bit version of KSP and trying to load that many mods is causing it to run out of the max 4GB of address space that a 32 bit program can use. Just run the 64 bit version of the game instead (right click the game in steam and select the option or just run KSP_x64.exe directly from explorer)...

Have you been able to repeat it from scratch? Did you cheat the lander to Bop with the kerbal inside or was he on the ladder and you moved either the lander or the kerbal? Basically, how, exactly, did you do the move to Bop and what did you do once you were there? That isn't a reliable indication of a stock install, certainly not reliable enough to be "sure of it". Plugin mods don't have to add an icon to the AppLauncher and purely part mods can't so there could be any number of mods installed without any visible effect... (Edit: oh, and the OP replied, saying it was unmodded, 4 hours before you posted).

There is no way of changing this at the moment, as far as I know. I may be adding the ability to totally disable the tooltip separately to the panels at the bottom fairly soon but am unlikely to make this configurable. Otherwise, your only solution will be to get a different mouse. Personally, I would consider any mouse which is difficult to click the middle button without scrolling, to be broken...