Padishar

It sounds like you don't have enough free memory before you start. How much actual RAM do you have? Other machine specs? What OS are you running? What other mods do you have installed and how much memory is KSP using when you get to the main menu? How much after loading your save game? Have you changed the padding settings at all? Can you upload an output_log.txt file and link it here? What situation were you in when that screenshot was taken? There were no physics updates during the previous second and 46 rendered frames, which implies that game time was suspended but the game wasn't locked up, was the game paused?

It's the latest build of my development branch. It won't be a "release release" until my pull request is merged into Cybutek's repository and he puts out a release. We're getting close to the stage where my branch is considered good enough but we're not quite there yet. The deltaV calculation code has only supported the new KSP 1.2 fuel flow for 4 days so it needs a bit more testing out in the wild before I'll be happy there isn't some strange problem. I'm going to run some tests of my own when I can but I'd be particularly interested to hear from anyone using it with different mod engines that use non-standard resources...

Yes:

You certainly shouldn't have to. The KER settings are global to the installation of KSP so all saves in the same installation should use the same ones...

No, just download the link in this post: It is exactly the same as a normal KER install zip. All you need to do is open it and copy the KerbalEngineer folder into your GameData folder.

The settings aren't stored in the save. If you actually mean how do you copy the settings from one install of KSP to another, then you can just copy the contents of the GameData\KerbalEngineer\Settings folder (tell it to skip HelpStrings.xml because that is supplied in the install and may have been updated in the new version).

Yes, it might be. I've been thinking about changes to this area for a while. It would also be useful to be able to select which part of the orbit the orbital values display so you can see what is happening after SOI changes. This same ability should be available for the post-burn values, e.g. you could set up a node for a Mun transfer and set the post-burn readouts to show the part of the trajectory around Mun so you can easily see your resultant Pe and inclination. The post-burn values should also support multiple nodes, so you could set up both nodes of a Hohmann and see the values of the final resulting orbit. I'm thinking these selections could be made with special readouts, [<] Node 1 [>] to select which node for the new Maneuver panel and [<] Kerbin [>] to select which section of the trajectory is shown...

Yeah, it makes sense to delete, extract and restore settings for more major changes (e.g. when files are added or removed) but I've only been changing the main DLL so you could even just overwrite that. I'm only packaging the whole thing up, rather than releasing just the DLL like I did last time, because the project build process now zips it up automatically and all I have to do is copy it to my dropbox (and add the p to the name)... On the subject of which, here is the latest version of my development branch, 1.1.2.6p. https://www.dropbox.com/s/b3yudz7k0gap76h/KerbalEngineer-1.1.2.6p.zip?dl=1 Since there haven't been any issues reported with the deltaV calculations, I've left it alone except for two minor tweaks, one to support parts with priority < -1000000 and the other to make STACK_PRIORITY_SEARCH do a balanced drain of the parts with max priority. This also includes: Planes and Relays added to target selector Post burn period readout Post burn inclination readout Fixed issue with target selector not resizing correctly when target is changed by another method Fixed a couple of description typos Enjoy...

You should be safe to overwrite everything. The customised windows are stored in files in the Settings folder and these files are not supplied in the download so won't get overwritten...

Back in the day, you got a higher altitude from a pod and hammer if you turned the thrust limiter down. This is no longer the case, it really is quite difficult now to go fast enough for the drag to make a difference. Aerodynamic stability is the main problem with going fast now, e.g. the vessel in the Goddard thread I linked above will flip once the engine burns out if you launch at full throttle and the extra drag will kill the altitude, but throttling down before mach 1 and keeping the throttle low until you get above 10k before flooring it again will get you out of the atmosphere now where it was very hard to get above 62k back in KSP 1.0.4. Adding a bit more payload mass, e.g. a few extra stack batteries, should reduce the altitude it gets to and may make it less flip happy. But this may also result in full throttle getting a higher altitude so it may need more drag to keep it interesting...

The aero display causing crashes is a known problem. It should be possible to work around it by turning off the part highlighting in the settings. Version 1.2.0 had a bug where having the part highlighting and antialiasing enabled caused a huge amount of garbage thrash with larger vessels. Squad fixed this in 1.2.1 but it appears that the fix now results in a crash if the aero display is toggled. Hopefully, there will be another patch fairly soon to address this...

You're welcome. Yes, that bug was fixed in 1.1.2.3p...

Stabilising it manually is exactly what's usually meant by a pitchover of 5-10 degrees, you move the nose 5-10 degrees off vertical and then you leave it there. Because you do this at a low speed, the aero forces don't return you to vertical before the sideways thrust shifts the prograde vector to match and then go beyond your heading. As you speed up more the rocket more strongly follows prograde. The point of my message (that I didn't really make very well) was that the "turn" in "gravity turn" is describing the curve in the trajectory, not the turning of the vessel's heading. Gravity is responsible for shifting your acceleration vector "below" the direction the nose is pointing, which causes prograde to move "down". You need something else (aero forces or control inputs) to make your nose follow prograde or you'll keep burning in the original direction and the curve in your trajectory will be very much less...

No, the ideal "gravity turn" has almost nothing to do with gravity. The force due to gravity acts through the vessel's CoM and therefore produces no rotational moment that makes it turn or "fall over by itself". The reason the rocket turns is that you manually start burning slightly sideways which causes the direction you are travelling in to move away from vertical. It is then the aerodynamic forces on the rocket (the big fins and generally wider structure at the bottom) that cause it to follow the prograde vector. The more it follows the prograde vector, the more of the thrust is acting sideways and the faster the prograde vector moves away from vertical. With a well designed rocket you can do a real "gravity turn" on Kerbin with SAS turned off and no control inputs after the initial pitchover of 5-10 degrees. Try the same thing on a body with no atmosphere and you will just continue to climb at 80-85 degrees...

This is a classic rocket science problem (google for Goddard problem). There was a fun challenge thread about this back in 1.0.4 Basically, you want to always keep accelerating upwards but it can improve your altitude to throttle back through the transonic region. It only takes a very small difference in speed when your engines burn out to make a considerable difference to your final altitude...

I will need either a save file or an output_log.txt file containing a simulation log (add the "Miscellaneous/Log Simulation" readout to one of your Flight Engineer windows and click the button when the window is showing the wrong values). However, at this point, I'm not really interested in any issues in older versions of KER. If the issue happens in KSP 1.2.1 with my latest dev build of KER (currently 1.1.2.5p) then I will do my best to find a solution but logs/saves/craft and a decent description of what you think is wrong will make it much more likely that I'll succeed...

Careful, public discussion of moderator actions is against the rules and could get you another one...

I suggest you go and read the thread (a number of real, problem situations have been described) rather than just jumping in with a poorly-informed opinion. I almost always see it switch from surface to orbital during launch and it has caused an issue on at least two occasions when I was set to follow prograde and trying to launch to an accurately inclined orbit. I've also had it switch from orbital to target during a burn that was supposed to adjust a phasing orbit for a close encounter. Then there's also the issue where a rover can switch into orbit mode while still on the ground on certain bodies. This has never caused me a problem but it's still very silly... An option to totally disable the auto-switching wouldn't hurt anyone. Nor would an option that prevents auto-switch during a burn (possibly only if SAS is set to a potentially dangerous setting).

No. Squad have stated that they had started recruiting new people before 1.2 came out. In any case, as far as the console ports are concerned, it's Flying Tiger that is (supposedly) doing the work and we know virtually nothing about their staff (how many are actually working on KSP, their experience etc.)... Despite (and given) the above, I agree with this, I'm not going to expect a fix for some time, that way I'll get to be pleasantly surprised if one does show up...

Now consider the situation where the display changes during a burn causing your SAS (when set to prograde or retrograde) to suddenly change the direction your vessel is pointing...

Have you read any of the posts in the last couple of pages? The latest dev version that works in 1.2.x was released in this post:

See this bug reported on 1.1.2. http://bugs.kerbalspaceprogram.com/issues/9723

Inb4 someone submits an entry from the ISS...

Not specifically. The only thing you're "supposed" to do is whatever is needed to get the vessel to do what you want. If throttling down around maxQ with a certain vessel means you get to orbit without flipping then do it. You might be better off redesigning so you don't have to but, with some vessels (and some players) that may not be easy...

Don't worry, the only one of your suggestions that won't be particularly easy (and, hence, is unlikely to get done for quite a while) is the RCS deltaV, the others should all be reasonably straightforward. I know that there's a pull request on KER to add an alternative to the suicide burn stuff as the current readouts are not particularly helpful and that may already include a countdown. The altitude from the bottom of the vessel has bugged me for a long time, just not quite enough to make me do something about it, and I think the closest approach distance should be easy to get via the stock code.