Padishar

Try the MemGraph mod linked in my sig...

Well spotted, it appears the link should be https://kerbal.curseforge.com/projects/kerbal-engineer-redux

Not at the moment. It was requested a few weeks back in this post:

What is the problem? You can change the key (used with the standard KSP "modifier" key, which I believe is LeftCommand on a Mac) for each of the functions in the GameData/MemGraph/PluginData/MemGraph/settings.cfg file. Just use whatever values from this page that you want (if you set something, such as the keyRunTests one which is only really useful for developers, to None then it will be disabled): https://docs.unity3d.com/ScriptReference/KeyCode.html

Ahhh, the symptoms sound very much like what I was describing in this post: However, I've only seen that happen when actually switching vessels (by any means, KER or stock) with the rendezvous panel open. Are you certain it happened when you selected the target or did you click the button to switch (possibly a double click, the button may appear under the pointer when you select the target)? I did revert part of a change I made to fix a problem with setting a target because it was causing the panel to not resize itself properly so that could also be an issue. It sounds like I'll have to instrument this bit of code quite thoroughly and release a dev version to try to gather some more useful data...

Strange, if the kerbal died then I don't think his "Vessel" should've existed anymore. Did you switch vessel or otherwise change scene between him dying and you clicking him in the target selector? When you say the game crashed, what do you mean? Did KSP just close or do you mean something else? Yes, there are a lot of these being spammed: [WRN 21:23:56.204] KK: StaticDatabase.updateCache(): vPlayerPos is still v3.zero ...and also quite a few of these: [EXC 21:24:00.059] ArgumentException: GUILayout: Mismatched LayoutGroup.Repaint UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type layoutType) UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUILayoutOption[] options) MuMech.MechJebModuleManeuverPlanner.WindowGUI (Int32 windowID) MuMech.DisplayModule.ProfiledWindowGUI (Int32 windowID) UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) These: [LOG 21:57:55.609] dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN at System.Environment.get_StackTrace() at Orbit.GetDTforTrueAnomaly(Double tA, Double wrapAfterSeconds) at Trajectory.UpdateFromOrbit(.Orbit orbit, Int32 sampleCount) at PatchRendering.UpdatePR() at PatchedConicRenderer.LateUpdate() Lots of these spamming: [LOG 22:02:17.419] [MechJeb2] Warppause : lastAskedIndex=5 CurrentRateIndex=4 WarpMode=HIGH MaxCurrentRate=5 Quite a few of these: [ERR 22:27:23.939] [DestructibleBuilding]: ID for this building is not defined correctly. Cannot unregister. This followed by lots of the NREs: [ERR 23:02:19.632] Can't remove Rigidbody because KSPWheelController (Script) depends on it [EXC 23:02:19.633] NullReferenceException VPWheelCollider.UpdateVisualWheel () VehiclePhysics.VehicleBase.LateUpdate () [EXC 23:02:19.642] NullReferenceException VPWheelCollider.GetGroundHit (UnityEngine.WheelHit& hit) VehiclePhysics.VehicleBase.CalculateSuspensionTravel (VehiclePhysics.WheelState wheel) VehiclePhysics.VehicleBase.FixedUpdate () Then there was a final vessel change and the last thing that happened was an autosave. Basically, it looks like KSP got seriously upset by something which upset both MJ and KER. This bad state may have been why the kerbal didn't get deleted properly or it may have nothing to do with it. Either way, it may be possible for KER to detect this bad state and avoid listing vessels that could cause a problem but it will be awkward as there is no indication of the click to set target at all so it's tricky to determine what could've been wrong with it...

No, it isn't normal. It may have a small impact but it shouldn't be anything like that much. I suggest you look in the logs for error spam etc...

That has nothing to do with what Scott Manley is calculating... I suggest you go and read/watch some general "rocket science" tutorial threads/videos as one of the first things you should learn is that deltaV is (by far) the most important value that can be calculated and is the only number that is really important when deciding if you can reach a particular body...

Why? What possible use is that? It just tells you how far the rocket goes while the engine is burning, which isn't exactly high on the list of important numbers where rocket performance is concerned...

No, KSP doesn't use .NET, it uses an old version of Mono built in to the KSP executable. However, the Unity profiler can be used to do the job instead, see this thread for details on how to set it up...

Well, it wouldn't be difficult to total up the memory allocated as it goes along so it needn't be slow. However, because of the inaccuracy inherent in the readings that MemGraph takes due to how the Mono heap and the padding mechanism works, I'm not sure it would be useful enough to justify the effort. The real allocation rate is actually what the graph displays in the time immediately before a collection, the average for the whole interval would often come out a lot lower than the real rate. Again, all the values can be rather inaccurate and combining two such values will make the result even worse, so I can't see it being much more useful than just making a judgement from the graph and values that are currently displayed.

I've just released 0.3.2.4 that should fix the .version file to correctly support KSP 1.2.0, 1.2.1 and 1.2.2.

Yes, this was reported and fixed just over a week ago: The test version 1.1.2.8p linked in my sig should include this fix (and another couple since)...

Exactly. The 30700 is the mass of all the parts that get decoupled at the end of that stage so it includes the "dry" mass of the SRBs and the mass of the decouplers. If you want to know the mass at burnout then you can either do a "verbose simulation" in the settings and dig the info out of the log file or you can simply tweak the fuel in the SRBs to 0 and see what KER gives for the overall mass (you'll probably need to turn on "All Stages" as that stage won't generate any deltaV and will be hidden)... Edit: also, the suggestion to add the actual fuel mass to the display has already been made, it just isn't easy to squeeze it in without needing to make all sorts of other adjustments to the window... Edit 2: Each BACC is 1500kg when empty and each decoupler is 25kg. This makes the mass at burnout 26195kg which gives the TWR of 3.89. Note, you should really use 9.80665 for g as that is what the game (and KER) uses, it can sometimes affect the second decimal of the TWR...

This is almost certainly a garbage collection induced stutter. Stock installs also suffer from garbage collection induced stutter. You certainly aren't the only one, try searching the forum for the word "stutter" and then go look at the thread linked in my sig...

Ahhh, by "previous version" you mean the previous major version which was last updated in October 2014 (and the version you show the screenshot of was released about 18 months before that). Actually, that's probably where I was remembering it from, too... Anyway, I've added a readout (currently in kPa) in my latest pull request...

Well, I thought there was but there doesn't seem to be. Should be trivial to add, what units would be most useful?

On that note, at least until Cybutek comes along and answers the question officially, can this thread get back to being specifically about KER, please?

Yes, you understand. The devs do know about the issue, they have been making significant improvements in the amount of garbage the stock game generates in both the 1.1.x and 1.2.x versions. Mod developers are also, generally, aware of the problem and most have been trying to make similar improvements. Yes, you can simply adjust the total line to make the stutters further apart. On a 16 GB machine with a lot of mods I would recommend not going much above 4096 or so, as many mods also use up memory for textures and models which are kept outside the Mono heap. 4 GB of padding should put the stutters pretty far apart unless your game is generating a really huge amount of garbage. I would actually recommend starting with 2048 and see what effect it has, then increase it if necessary...

This is just how the game engine works combined with code that generates too much garbage. Basically, Unity/Mono keeps a certain amount of free headroom in the heap and once this fills up the garbage collector is triggered which causes a short pause. The headroom is a certain fraction of the total size of the heap so when less memory in being used there is a lot less headroom and the stutters can happen quite frequently. The MemGraph heap padding feature both forces a large amount of extra headroom and, due to the increase in total heap size, makes Unity/Mono allocate more headroom itself.

Sorry for not replying to this sooner, you have a very large list of mods and it's likely that several are each contributing significantly but it's hard to say which ones. With a mostly stock install it should be possible to use the MemGraph heap padding feature to virtually eliminate the garbage stutters as long as you have enough physical RAM in your machine and the "Last" value at the top of the graph isn't showing a huge number. A screenshot of the graph window in this new install could be helpful, leave it running in flight for a little while with the stutter and then hit Mod-End, leave it running for some more and then take a screenshot. If that doesn't improve it enough and you have a reasonable amount of free physical memory while running KSP then you can change the total= line in the padheap.cfg file in the MemGraph/PluginData folder...

Here is usually fine, or you can add an issue in the GitHub repository linked in the first post. That readout does look wrong, though it appears to be as the ship passes the apoapsis rather than the periapsis. I'll take a look at the code concerned and see if I can see what's wrong. There was a change in KSP 1.2 to the range returned from some orbit related functions so this may be the cause if this is a new problem... It would be very handy if you could copy your save and delete all the other vessels, just leaving the one you've shown with this orbit, and then upload it. Just in case the issue only happens with certain configuration of orbit and proves awkward to reproduce... @Kertech, @kball and anyone else reporting problems, please include screenshots and/or craft files and/or save files and a detailed description of what you think is wrong...

There hasn't been an official release for KSP 1.2.2 yet but KER 1.1.2.8 should work as well as it did in KSP 1.2.1. The link in my signature is to my test build of the latest fixes I've done (vectored thrust and staged docking ports) built against the KSP 1.2.2 assemblies...

I have put a test version of my two PRs since 1.1.2.8 available here... https://www.dropbox.com/s/ectj7zquljl1m1n/KerbalEngineer-1.1.2.8p.zip?dl=1

Yes, that's what I assumed too. It turned out to be quite simple to make the simulation stage docking ports sensibly so I have submitted a pull request...