[1.0.5] GravityTurn version 1.3.1 - Automated Efficient Launches (1.1 pre-release available)

[Probus]

Was just about to ask for a feature request, but you already have it in there.  Great job @Overengineer1!

(It was total dV spent)

[Overengineer1]

Sneak preview:

The learning guess settings are working very well now, and the logic that exists now is what I'll be releasing in 1.3.  In short, we care about up to 4 launches:  The best one, the one that ended in fiery death, the second best one, and the one that turned just aggressive enough to be inefficient but didn't explode.  We will iterate in a line from the second best to one step beyond the best launch.  If that's close to what we previously determined will either explode or be less efficient, then we'll go half a step between those.  These half-steps take us closer and closer to what would be considered a perfect-ish launch for the ship in question.  This whole process is more or less agnostic to the steepness of the ascent, since some ships require steeper ascents than others, and instead relies on the actual TotalLoss results for each launch and moves in the direction that improves those numbers.  Maybe it's just me, but I find the cold math to be a lot more daring than I generally am with my human guesses, so this has led to launches that are better than I've ever done by hand with a given ship.

I expect I should be able to release early this week, or possibly tomorrow.  This will be a major release so I want to get as many other planned features rolled in as possible.  The current dev build in GitHub as always includes the very latest fiery awesomeness.

[mcirish3]

I am looking forward to this release.  I tested the current release on a space shuttle design I am currently using a lot.  ( have a link to it in my signature)  It worked better than my usual launch.  THough it was minus a payload so that may have made the difference.  I really want to see how your new trial and error method works on this ship with the upcoming release.

[Ixenzo]

About fairing jettisoning. Yes, it's added dead weight, but with usual fiery ascents how else should one provide heat defense to the payload? Sometimes the fairing would heat up to 1800 K and not many probes and parts can withstand that. Having a radiator or some other kind of heat shielding part on the payload itself is just the same dead weight but now you'd either have to haul it with you to your destination as a part of payload or construct some mechanism of ditching it, making the craft more complex than needed and/or have more mass. 

I can sacrifice extra 100-200 m/s of dV for couple dozen km during ascent to ensure half the payload doesn't blow up earlier than needed.

[mcirish3]

6 minutes ago, Ixenzo said:

About fairing jettisoning. Yes, it's added dead weight, but with usual fiery ascents how else should one provide heat defense to the payload?

Interesting point.  Perhaps the fairing jettison should be optional.  (a little check box you can check when you are ready to let it go)  The new release will have the learning system so it will learn not to burn up your ship.  so there is that too.

[Overengineer1]

I'll be adding a Staging Setup window, and "Fairing Pressure" will be one of the items.  10,000 is the default dynamic pressure that I'm starting with, but that might have to go down a bit.  Higher values will pop the fairing lower in the atmosphere, lower values will pop higher in the atmosphere, 0 would theoretically pop at atmosphere exit.

[tater]

I'm playing in a scaled up system with stock parts (planets 3.2X, distances 6.4X), and the new fairing option will be nice to see as even set slightly steeper than your best guess, I don't just get flame effects, but overheating and part destruction. If the fairing deploys early, thenI end up will all the surface attached parts getting scrubbed off.

[damerell]

1 hour ago, Ixenzo said:

About fairing jettisoning. Yes, it's added dead weight, but with usual fiery ascents how else should one provide heat defense to the payload?

Move the fairing up the staging order?

[Overengineer1]

Version 1.3.0 released.  Should be picked up automatically by CKAN later today.

[DerekL1963]

Does the learning system detect ass-over-teakettle tumbles?   That seems to be cause of most of my losses, the vehicle flipping because the first turn is too agressive.

[Overengineer1]

@DerekL1963 If you don't reach orbit, the code considers this a failed launch.  It should make a better guess on the next run.  Usually I would think this would mean a less aggressive guess in this case, but that's really up to how the math works out.

[Joco223]

Could you make so the best guess doesn't change the destination altitude? Every time i set destimation altitude and click best guess it changes it litte above atmosphere

[AndyMt]

A "lock this parameter" button at each (or some) of the values would really be nice. Specifically:

- destination height

- Sensitivity (I prefer not to throttle down too much).

- Inclination

- Roll

 

The latest update is really fantastic! The learning system makes any launch extremely efficient. Even with the wierdest rocket designs.

[Miravlix]

According to Exception Detector GravityTurn throws a hissy fit over something with RCS on re-entry.

 

GravityTurn's menu isn't visible, so I find it odd it's active at all.

[Overengineer1]

@Miravlix I have no idea what you're trying to say.  If you found some issues, provide me the KSP.log from your KSP folder and I'll have a look.

[fourfa]

"Lock this parameter" would be really great.  I always always always build facing east, and it always always always wants to roll to -90.

[Overengineer1]

As far as locking parameters goes, I think this is not a good idea for most parameters.  If you change the inclination or destination altitude, then the calculations done from previous launches are no longer valid.  What works best at 0 inclination going to 80km does not necessarily work best at 90 inclination and 240km.

Roll might be the exception to this.  I'll look later at making it leave that value alone when guessing.

[sergioberg]

I think "learning system" should preventing of increasing overheat. Best result shouldn't based only on "TotalLoss".

[Overengineer1]

@sergioberg: I disagree.  The whole idea is to find the settings that give you the best launch.  Launching straight up in the air until 70km would be the least likely to overheat, and is also one of the worst launch profiles you can have.  GT will find the most efficient profile that doesn't overheat past 95% of critical temperature.

[tater]

Do you have to allow the craft to be totally destroyed for learning, and if you did so, then reverted?

[Overengineer1]

@tater:  It's best to let each "learning" launch continue until it ends one way or the other.  A successful launch won't be logged as successful until atmosphere exit (and/or destination AP for moon launches).  An overheating launch won't be considered overheating unless it has a part that exceeds 95% of its critical temperature (skin or internal).  If you can catch it right at 96-99%, then you can revert before it explodes and still have a valid result to learn from.  If the launch exceeds 95% heat but does successfully exit the atmosphere, then it's still considered a failed launch for future launches.  A launch exceeding 100% critical heat for any part will not be considered a "previous best" launch under any circumstances, even if it was not a vital part that overheated, but it is possible for a "Previous Best" launch to heat parts up to 99% if that's truly the best launch.

Reverting during flight before exiting the atmosphere will mark the launch as unsuccessful.  This may or may not have an impact on future guesses, depending on circumstances.  Reverting after exiting the atmosphere is the normal use for this learning feature, the launch was recorded as successful the instant the craft crossed the atmospheric boundary.

[Shalfar]

@Overengineer1: I love the "learning" feature, it really helps on my low TWR launches with FAR.  I am having an issue with high inclination launches where it seems to overshoot the inclination and then tries to correct, which causes too much drag and the rocket tumbles.

[JAFO]

3 hours ago, Overengineer1 said:

13 hours ago, Joco223 said:

Could you make so the best guess doesn't change the destination altitude? Every time i set destimation altitude and click best guess it changes it litte above atmosphere

^^ This.

3 hours ago, Overengineer1 said:

As far as locking parameters goes, I think this is not a good idea for most parameters.

 

 

Best Guess should not alter the player's pre-set altitude. If I set for a 100km orbit, I want GT to calculate the best guess for that altitude, not have it decide that I should be aiming for 80km instead, and change my setting without asking.

[Miravlix]

5 hours ago, Overengineer1 said:

@Miravlix I have no idea what you're trying to say.  If you found some issues, provide me the KSP.log from your KSP folder and I'll have a look.

 

It seems your not shutting down GravityTurn when the menu isn't active, resulting in wasted CPU time, in my case when RCS is enabled on a ship returning to Kerbin.

Most addons including GravityTurn down create much activity for Exception Detecter to "detect", even if it is used to control a ship, but then on re-entry I got 30-40K calls to GravityTurn.SomethingSomething.RCSThuster while I was returning a ship to Kerbin.

[Overengineer1]

@JAFO  You can either have the mod try to get you the most efficient launch (which is in fact to 80km in the case of Kerbin), or you can enter custom settings.  The loss numbers for a 100km launch are just artificially inflated by including the extra transfer distance.  So a 100km launch data are not valid for an 80km launch, or vice versa. Even worse, a 100.001km launch data are not valid for a 100km launch.

Find the best launch for your vessel by allowing GT to do its thing.  Then once you have those optimal settings, alter them for each individual launch as needed.