AndyMt

I agree - it's in for the next release.

I kind of understand what @Daveroski wants and why. Many arguments as to why this is not happening are already mentioned. As well as to why it would be a good thing. For me as a addon developer the effort would just be too big. Configuration and version management is time intensive. Companies employ full-sized departments doing nothing else. But I'll anyway carefully consider for my addons (GravityTurn for now) what functionality to include and what not in order to not bloat it over it's initial purpose. If I ever feel the need to do something like "GravityLander" (or whatever) then most likely that would be a separate addon, sharing code with GT and maybe offering some kind of interaction between them. For anything else I plan to implement ways to hide some the complexity of any non-core functionality on the UI. But of course - what is "core" or not is different for most players... I hope this is a good compromise...

No - not yet. I hope to release the next version until end of this week where a fix for this is incorporated. Until then: launch, wait for the initial turn to complete and then change to the desired inclination.

Thanks for all the feedback, especially regarding stutter. I've noticed it myself, but only during the pitch maneuvers with craft having a lot of parts and when having EVE installed and active. I'll perform some tests now and try to replicate some of the behavior some of you described and also the workarounds.

I wasn't aware that this is even possible, I expected Unity or KSP taken care of that. It's on the list now and will be in the next release.

Yes, I'm aware of that problem. Fortunately @okder posted some recommendations including code changes a few pages back and its on the list of improvements for one of the next releases. And actually I was just starting to look into it today.

Let's see about the finally ... The problem was that the comparison if an entry already existed really compared floating point numbers bit-by-bit. So even if the numbers were only different 10 digits after the comma => different and a duplicate entry was created... So now the check allows a little difference.

I've fixed a few things and implemented a first algorithm to adapt the start turn speed depending on surface gravity: Download the mod here V1.7.2: Calculation for start speed is based on current surface gravity bugfix: topmost fairings were always staging bugfix: "improve guess" didn't always improve because of duplicate launch db entries. Have fun

Actually I just figured out that this is not always working as expected. Something I have to fix...

Yes - set the staging limit parameter in the autostagin setup to 1 and move all fairings to the top of the stack.

Yes, I'm aware of that problem. At least for now you can save your own defaults, because the defaults are stored on a per-planet/moon basis. So GT will use Minmus defaults if you've found some that worked well there. A pure "time to Ap" start of the turn is possible, though it would usually result in a pretty high start velocity (depending on TWR) and then the turn angle would need to be pretty steep (with all the problems that would cause in the atmosphere). I'm thinking more about using 10 times surface level gravity as a basis for the calculation. For Kerbin that's about 10x10m/s => 100m/s and then go from there. For Minmus that would be roughly 10x0.5m/s => 5m/s for Duna approx. 30m/s. It's on the issue tracker now and part of the planning for the next release :).

Both does the same thing basically. It's still a guess, so not always perfect.

I had the forum mods move this thread into the "Add-on Releases" section. I consider to create a dev-thread again if the release thread gets too messy.

There indeed was an issue with the Sepratrons. It should be fixed now.

Can you please move my GravityTurn mod thread from "Add-on Development" into "Add-on Releases" ?

I've finally managed to get V 1.7.1 ready: Download the mod here Source on GitHub License: GPL V3 V1.7.1: Storing default parameters for new crafts Locking parameters so they are not overwritten. Autostaging of top fairings and interstage fairings. Option to speedup of launches via timewarp Smother pitching maneuvers Bugfix: Detection of MechJeb assembly. Some more, see issue tracker See opening thread for more details and what's next. I'm still not sure if the staging problem is really fixed. I've fixed some situations, but the cases where 1st stage radial decouplers didn't stage a few seconds into the flight I was never able to reproduce.

Thanks. That 1.7 was a test-release to hunt down a specific issue. That's why I didn't want to release 1.7 officially back then. I'll update the thread when 1.7(.1) is really done .

This particular issues was already reported and discussed a few pages back and will be fixed with the next release. I prefer to add issues to GitHub myself. This one already is on the issue tracker under "closed" issues: https://github.com/AndyMt/GravityTurn/issues/18

You are right - it is as soon as the vehicle leaves the atmosphere and the apoapsis reached the destination height.

Yes "revert" counts as beginning. End is when you've reached the destination height.

It needs to be the identical craft, launching multiple times with using "improve guess" each time. Cited from the help button: Improve Guess will try to extrapolate the best settings based on previous launches. This may end in fiery death, but it won't happen the same way twice. Be warned, sometimes launches get worse before they get better. But they do get better.

The plugin version 1.6.1 you are using right now does have an error when doing the first suggestion. But you can try the test version 1.7.0 a little further up. But of course using "improve guess" should usually well - improve the parameters. Otherwise I would need a similar craft file only with stock parts to check myself.

Your Height and TurnAngle parameters are way too high (140/5). For this kind of craft and dV I would expect something like 80/15 to be much better.

I've identified this particular problem now: because the craft is above the atmosphere, timewarp skips into physics-less timewarp (the green arrows). Because of that, no thrust is applied or possible. I have to make sure physics warp is used in any case, independent of the current vessels altitude.

I've observed the problem with the stock "AeroEquus" craft, so there were no Sepratrons involved. And it happened when the first radial decouplers were due to be staged. But of course Sepratrons could be a problem, too. Then I would expect it to happen every launch, and not just sometimes. I've now run some first test with your craft and observed some strange behavior if the Timewarp option is used. Without that - it worked. So I'll look into that then and add some more debug logs etc.