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

[vardicd]

@Overengineer1 @5thHorseman, and everyone else that was trying to offer me advice on how to redesign my rockets the other day, Thank you very much, it took me 2 days of different redesigns, but I finally got one to make orbit using this mod:

The Z-5 Prototype

[RA3236]

Is it normal for GravityTurn to cause your final Ap on the other side of the planet? Cool mod though, it decreased my fuel usage by 30%.

[JAFO]

I'm very impressed with this mod, so far.

However, having played around with it some, I have a few suggestions and thoughts on improving it.

As has been mentioned already, GravityTurn really does need to remain active if the window is closed during launch. Also, the open/close button appears in the flight view toolbar, but not the map view toolbar, making it necessary to exit map view before the window can be closed. Having the button accessible in both view toolbars would be a big help.

If the 'Abort' button is pressed, it would be nice if one could then click a 'Resume' button. At the moment, once you abort, that's it.. no second chances.

The MechJeb integration is neatly done, but not yet complete. If playing in career mode, with the MJ Manoeuvre Planner not yet unlocked, GravityTurn does not exit gracefully, but rather, as soon as the ship exits the atmosphere, the throttle setting reverts back to the default 50% mark that was set on the launchpad, meaning that the engine immediately starts pushing the apoapsis higher. GravityTurn needs to check for the MJ Manoeuvre Planner being unlocked, not just for MJ being installed.

 

Other than the above, I like GravityTurn very much. Nice job.

Edited January 19, 2016 by JAFO

[linuxgurugamer]

1 hour ago, RA3236 said:

Is it normal for GravityTurn to cause your final Ap on the other side of the planet? Cool mod though, it decreased my fuel usage by 30%.

Yes, that is just the most efficient path to orbit

[linuxgurugamer]

Just got to use the mechjeb integration.

Works very nicely, just a couple of comments:

1. I'd like to have the option to have the integration work or not, preferably by a checkbox in the GT setting window
2. It was a little jarring when control switched from GT to MechJeb, in the sense that suddenly the ship started changing attitude.  It would be nice if a small (optional) dialog opened up indicating that GT was handing control over to Mechjeb.  While I personally prefer a dialog, even a status line in yellow similar to what the game does would be good

Overall, a great 1.2.1, looking forward to 1.3

[RA3236]

18 minutes ago, linuxgurugamer said:

Yes, that is just the most efficient path to orbit

Just thinking, I end up having to wait ten minutes before time warp because of stupid SAS.

[JAFO]

14 minutes ago, RA3236 said:

Just thinking, I end up having to wait ten minutes before time warp because of stupid SAS.

That's what 4x physics warp is for..

[RA3236]

4 minutes ago, JAFO said:

That's what 4x physics warp is for..

And I run out of electric charge because the ship keeps shaking.

[JAFO]

4 hours ago, RA3236 said:

And I run out of electric charge because the ship keeps shaking.

That's one of the things Stock Bug Fix Modules is specifically designed to fix..

(Besides which, you don't need to enable SAS before using GravityTurn anyway.. so far as I can tell, GravityTurn doesn't need or use it)

Edited January 19, 2016 by JAFO

[kananesgi]

Not sure if this has been caught yet. I looked through the thread and didn't see a mention of it. It appears GT isn't compatible with FMRS. If FMRS is active in the flight, the GT window is slaved into FMRS' window, cannot be moved, and is too small to use. If you deactivate FMRS, GT's window works fine.

[RA3236]

4 hours ago, JAFO said:

That's one of the things Stock Bug Fix Modules is specifically designed to fix..

(Besides which, you don't need to enable SAS before using GravityTurn anyway.. so far as I can tell, GravityTurn doesn't need or use it)

It prevents you from using it. It is just overpowered reaction wheels. I'll have a look at the mod.

[sarbian]

https://github.com/johnfink8/GravityTurn/blob/master/GravityTurn/GravityTurn/GravityTurner.cs#L389

windowPos = GUILayout.Window(1, windowPos, WindowGUI, "GravityTurn", GUILayout.MinWidth(300));

The window ID needs to be unique among all the displayed windows. 1 is hardly unique. That would explain some mods conflict. Mash your numpad a bit.

[Overengineer1]

@sarbian Thanks a lot.  That's a shocking vulnerability for cross-mod interference.

Version 1.2.2 released with a fix that should resolve a lot of compatibility complaints.  Should update to CKAN automatically some time tonight.

[mcirish3]

FYI I am surprised no one congratulated @Overengineer1 for making Modding Mondays.  Congratulations!!!!!!!  Sorry about the belated congrats I just noticed a couple hours ago.

[JAFO]

3 hours ago, Overengineer1 said:

Should update to CKAN automatically some time tonight.

Thanks for making it available on CKAN.. and congratulations on getting featured on Modding Monday!

[linuxgurugamer]

Like the new version.  (as usual) comments and suggestions:

The LaunchMap is really nice.  But hard to fully understand without any scale.  so:

1. Can you make the resolution changable?  I did a launch and saw the track go across the flight map 3 times
2. Can you put a scale at the bottom showing elapsed time?
3. Can you put a scale along the edge showing altitude?

 

[Overengineer1]

@linuxgurugamer I'll try to get some numbers in there.  Writing text to a dynamically generated texture is not something that is handled very well by Unity, as far as I can find, so maybe I can get something on the outside.  The y-axis is altitude, just as you guessed, and it goes from zero to atmosphere depth, or zero to destination height if there is no atmosphere.  The x-axis is not time, it's horizontal distance.  I'm keeping the current behavior of overlapping itself, because the x and y axis are using the same meter-to-pixel scale, which I think is more useful from a data point of view than dynamically shrinking the x scale as the flight progresses.

Originally the map is meant to chart the ship's capabilities to improve the guessing mechanism for a particular ship.  Red represents the percent of critical heat for the part closest to critical temp, green is atmospheric drag, and blue is the percent of thrust compared to the ship's overall maximum (usually the first stage full throttle).  If I save the map for a particular craft ID (or design name, I haven't decided), I can parse it at launch time and decide if I want to increase or decrease the aggressiveness of the profile based on previous results.  It also looks pretty, so I figured I'd go ahead and display it to the user.

[linuxgurugamer]

2 hours ago, Overengineer1 said:

@linuxgurugamer I'll try to get some numbers in there.  Writing text to a dynamically generated texture is not something that is handled very well by Unity, as far as I can find, so maybe I can get something on the outside.  The y-axis is altitude, just as you guessed, and it goes from zero to atmosphere depth, or zero to destination height if there is no atmosphere.  The x-axis is not time, it's horizontal distance.  I'm keeping the current behavior of overlapping itself, because the x and y axis are using the same meter-to-pixel scale, which I think is more useful from a data point of view than dynamically shrinking the x scale as the flight progresses.

Originally the map is meant to chart the ship's capabilities to improve the guessing mechanism for a particular ship.  Red represents the percent of critical heat for the part closest to critical temp, green is atmospheric drag, and blue is the percent of thrust compared to the ship's overall maximum (usually the first stage full throttle).  If I save the map for a particular craft ID (or design name, I haven't decided), I can parse it at launch time and decide if I want to increase or decrease the aggressiveness of the profile based on previous results.  It also looks pretty, so I figured I'd go ahead and display it to the user.

Ok, thanks.

At least label the axises with what they are, even if you can't get numbers there.  I assumed the horizontal was time, distance does make more sense,but a label would have helped.

I haven't checked, have you fixed the problem of the mod shutting down if the button is clicked to hide the window?

[Overengineer1]

Minor update 1.2.3.  The autopilot will now continue when the window is closed, and the flight map now includes axis labels.

[Dr.LoveJoy]

OverEngineer, this is quite possibly one of the best user experience mods I have come across since MechJeb. :-) In fact, Kottobos said it best in that "This mod is trying to just do one thing, and it does it REALLY well" Thanks so much for taking the time and energy to make this mod and support it so well!

I have done the "follow time to Apoapsis" manually and it is an incredible pain to do. I am very very happy you have automated this launch approach, since it the most efficient, non advanced mathematical method for producing a good launch profile.

I'd suggest that for RP0/RO you simply add a checkbox option (by default unchecked) for turning down the nose earlier during the entire launch profile, and include an 'aggressiveness' factor in how hard it does it in atmosphere, to handle non throttle-able engines. It will be up to the user to figure out how to tweak it for a particular craft.

I have been thinking about tackling this in terms of predictions using more hairy math, but Im a ways off from doing it. ;-) Kudoes!

 

EDIT; Oh I would also put a checkbox for "Dont cutoff the engines when burn is complete" for RO/RP0.

Edited January 21, 2016 by Dr.LoveJoy

[tater]

Wrong tab! Sorry!

Edited January 21, 2016 by tater

[FrontLineFodder]

On 19/01/2016 at 6:16 AM, sarbian said:

https://github.com/johnfink8/GravityTurn/blob/master/GravityTurn/GravityTurn/GravityTurner.cs#L389

windowPos = GUILayout.Window(1, windowPos, WindowGUI, "GravityTurn", GUILayout.MinWidth(300));

The window ID needs to be unique among all the displayed windows. 1 is hardly unique. That would explain some mods conflict. Mash your numpad a bit.

better idea than mash the numberpad, use this forum post number (129607)

 

@Overengineer1 I'm liking this mod muchly, thank you.

can you explain some of the losses detailed in the newer versions ? Air/Gravity/Vector ?

what design considerations can be made to reduce each (if any) ? I've noticed that the air drag goes up if I stage fairings while in atmo so that makes sense, keep parts flush means less air drag.

scratch that, I just re-read the first post. 

Edited January 21, 2016 by FrontLineFodder

[Shalfar]

I'm seeing an issue where shortly after the beginning of the gravity turn the craft attempt to return to vertical flight for just a moment.  This is very pronounced for small rockets.  With stock physics this is troubling but can be overcome, but with FAR it sends the rocket tumbling.

[Snarfster]

12 hours ago, Overengineer1 said:

Minor update 1.2.3.  The autopilot will now continue when the window is closed, and the flight map now includes axis labels.

Love this mod. Just one suggestion, add a toggle to use physics time warp during coast to orbit.  

[linuxgurugamer]

14 hours ago, Overengineer1 said:

Minor update 1.2.3.  The autopilot will now continue when the window is closed, and the flight map now includes axis labels.

Woohoo!!   Hype!

Thank you!

 

Stand by for comments :-)