AndyMt

The launch DB files actually only serve the purpose to find the best launch parameters for "start turn" and "angle". Some more fields might be saved because of shared code with the vessel files. I intended to clean this up with the next big release - which hasn't come far, unfortunately... I want to refactor the mod to separate data, logic and UI better than it is now. The gt_vessel files are used - they contain the "locked" default values for a specific vessel. I also want to introduce a "named save.Cfg" feature, so you can save a set of parameters you can use for launching similar vessels. The "x" on the stats window was actually a requested feature, so you can keep it open while the main GT window is closed. For that to work the hack was to fiddle with the close buttons. I don't recall exactly, but that's of course something I'd like to fix, too. Anyway as described a few pages further up I want to change the UI completely. When I branched this mod I was very happy with what it did and just wanted it to work on the latest KSP release. But I also saw some things I'd like to improve and change, but that requires some major refactoring. Unfortunately I don't have the time for this right now (looking for a new job).

Yes, RO/RSS compatibility has been suggested before and it is on my list of future features. But I have no idea when I have time for it.

Each craft has to go through it's own improvements in efficiency. I actually plan something similar to what you suggest, have a look at the issue tracker, including the basic requirements: https://github.com/AndyMt/GravityTurn/issues/17 I think that should allow you to select the proper launch settings for a class of crafts. I'm thinking about allowing to put the name of the launch configuration into the "description" field for a craft with some given syntax like "This craft uses launch configuration <<NameOfConfigFile>>" etc. But I'm still reworking the entire source code, so don't expect anything to happen soon.

Maybe I can help here: I've recently started to experiment with an IVA for a 1.25m 2 seater pod. Turns out it's impossible to fit 2 seats in a 1.25m pod. Creating 1.8m pod I found pointless as long as there are no tanks, engines etc. for it. Doing them myself, that I don't have time for on top of maintaining the GravityTurn mod. So: I could contribute an IVA if you like... Probably a very simple basic one. Textures probably won't be that great, but I can see you have the skills for those and you could continue from there. What tool chain do you use? I use Blender + Unity.

I must admit: I don't have an explanation for the differences right away. Since I looked into this (existing) mod I haven't reverse-engineered all of the calculations in it... I'm currently refactoring the whole code to separate data/logic/UI - so I will get to the losses in general at some point. I'll then try to figure out what the difference between MJ and GT actually is. Probably both mod's loss calculations are correct, just they don't mean the same. But I can't tell at the moment.

@razark, @damerell and everyone else tempted: we've read all these arguments on the first few pages of this thread. Please don't start it again, ok? Thx.

Separating the "optional maneuver node at Ap to circularize" is on my list actually. As for KAC integration: I just checked and @TriggerAu conveniently provides an interface for KAC: http://triggerau.github.io/KerbalAlarmClock/api.html So - I'll add that to the list, too.

I would like to keep GT's functionality to it's core task: performing a gravity turn launch into orbit with a given set of parameters. But I'm open to implement an interface to/from any other mod which's author is willing to cooperate. But first I have to finish the UI overhaul and refactoring of logic/data etc. Which is quite a big task and progress over the holidays was... minor... I've observed this already, too - and sometimes it causes trouble - but mostly not (in my case). I'll consider it, but it has to queue in the issue tracker further down the list at the moment: https://github.com/AndyMt/GravityTurn/issues/38

I actually plan something similar, details you find in the Github issue tracker: https://github.com/AndyMt/GravityTurn/issues/17 But that requires the UI overhaul to be completed.

Thanks a lot for testing this. I'm happy to see it can be used with RO. Probably some adjustments are needed, like taking orbital velocity into consideration for the initial values - or not try throttling down/shut down for engines with only 1 ignition. And by the way - that' must be a hell of a monitor on your desk - or 3 big ones in any case... Wow, thanks a lot for this post. If it is ok, I'll use part of this as a basis for the upcoming wiki/KSPedia (haven't decided which way to go yet). I must admit I haven't looked in detail at the explanation texts when I've continued with this mod based on the original authors work. As I want to change the UI anyway, the texts will get an overhaul as well. In any case I'd like to hide most of the parameters on the basic UI, so that new users of the mod can just start without having to worry about all the details. Just enter destination height, inclination and roll, decide on auto staging, press "Launch" - that's it.

Yes, it won't work in 1.1.3 because of changes in the KSP API. Is there any real scale planet mod for 1.2.x yet?

I honestly don't know, but I would like to. For sure it will be limited, as it heavily relies on throttling to hold the time to apoapsis. So it would heavily depend on the design of the rocket so that the stages and engines match the needed TWR as close as possible. What it could do is pitching downwards (within limits) to control the time to apoapsis. Right now the algorithm prevents this from happening, it only allows pitching upwards. I've briefly experimented with removing this constraint and setting the sensitivity parameter to 100% (= no throttling down). That didn't work too bad, but it really depends on the engine's TWR on all stages to be close to what is needed. Otherwise the vessel pitches down too much and may break up due to atmospheric forces. Also a problem: engines with limited amount of re-ignitions (or none) especially with the upper stages when coasting towards the end of the atmosphere. If FAR would be an issue at all I can't tell. Atmospheric forces are not really pre-calculated and taken into account. The initial turning height and angle are calculated with a very simple algorithm - which might not be appropriate for RSS sized systems. So - as soon as there is a RSS or RO mod available and I've completed the UI/code refactoring, I'll have a look. Because I really, really would like to do a career play through in RO - just not launching manually all the time. I do for new rockets usually.

I' might very well come back to your offer . Programming was my daily business until a few years back - and I miss it so much I do side projects of this kind... Now I'm doing requirements and systems engineering without actually producing anything - but earning twice the money... I don't complain... Regarding learning from failures: actually it should. I have to check the code, but if the maximum achieved altitude is above the current altitude and you revert, then that set of parameters should not count. Same for crash and overheating (=exploding). But I guess they might currently not be looked at properly because of the "improve guess" issue - which starts to annoy me as I thought to have it fixed in 2 versions already...

Thanks a lot for your extensive testing and proper description of it. I might well use some of it for the planned wiki page, if that's ok?. Let's answer your questions: TWR: below 1.2 the initial suggestion will always be 100/10 (on Kerbin). The "improve" button" will increase angle and decrease turn height as it would for higher TWR. Save button: yes, it saves the defaults. That's the values used for new vehicles Improve button: looks like there is still an issue with it. The algorithm takes dV and heat into account. I haven't looked into the code for the heat calculations yet, I suspect that this causes this issue. Values changed: "improve" will only change speed and angle that's correct. But the other values would be overwritten by the defaults if not locked. I'm thinking about changing this behavior. I plan to overhaul the UI drastically as mentioned a few posts/pages earlier. One of the thinks is the "locked" feature etc. It is actually a workaround necessary because of the inherited code from the original mod. I'm in the middle of refactoring the source code entirely in order to separate data, calculations, controllers and UI. This will take a few more weeks. Because of the holidays etc. don't expect any new release before January. After the UI overhaul I also plan to provide a wiki page, but it doesn't make sense to do this for the current version, because it will be quite different and I would have to do the work almost 2 times.

You are doing everything right... If you are using the latest version 1.7.6, then the mod should iterate a few times (max. 5) and then you should have the (close to) optimum launch values. There was a problem with this algorithm which I thought to have fixed in version 1.7.5. Looks like this is not the case (still). Sorry for that, but at the moment you have to write down the values... Usually the suggested values are not too bad, but a tad too steep (depends on the TWR of the 2nd stage, too). The 2nd guess usually is quite close to the optimum and the 3rd guess sometimes is already too aggressive.

I've released 1.7.6 now on the opening post and on CKAN. I'll keep an eye on the initial roll and pitch behavior anyway. I have a hotfix branch in case anything else needs to be fixed. Now I'm working on the major code refactoring to separate UI, logic/calculations and data in preparation for the redesigned UI. I'm eager to try the new Unity UI which would reduce performance impact and garbage. It also allows much fancier designs... but requires the UI to be rewritten entirely and strictly separated from any KSP related code (separate assemblies in fact). So don't expect a new release any time soon. And we are getting close to Christmas already...

I'm not really sure what problem you describe here, I'll try with my own words: you rotate a vessel in the VAB you put it on the launchpad, change the roll parameter in GT to 0 you time warp a bit then you launch. Now I don't understand what happens: => the vessel doesn't roll as expected? It pitches and keeps the heading? => the vessel DOES roll, but it should not? And then keeps the heading Is there an inclination involved? Because what ever I do - GT rolls and pitches how I expect it to. If I time warp before or not. So I must do something different than you.

Thanks. As soon as there is a stable RSS mod for 1.2.1, I intend to give this a try in any case. I know where and how to change the calculations.

I've implemented a hotfix V 1.7.6 which solves the initial roll issue. Download here V1.7.6: hotfix for issue #36 Can you guys please test if this solves the problem? Only one line of code to be changed actually...

This is on the border of what GravityTurn is intended for. But fairing deployment already is sort of, too. So I'll consider it, but no promises.

Oh! Well - that is not what I intended... I'll look into it.

Hello everyone - I need your input :-): As I mentioned I'd like to restructure the UI a bit. The plan is to offer a "simple" UI with the most basic parameters, but also improve the way to open the additional windows like stats, map etc. (via mouse over on the toolbar icon). For that I need to categorize the parameters GT offers right now. First step is to separate the addon specific settings which users don't change on a per-vessel basis (usually). And I'm not sure about which to classify for "addon settings" and which ones for "vessel/launch parameters". Here's how I see it at the moment: Simple launch parameters: Destination Height, Inclination, auto staging, auto deploy fairing. Advanced launch parameters: Destination Height, Inclination, Turn Height, Turn Speed, Staging parameters, etc. Addon Settings: Show Stats, Show Map, create circularisation node, use MechJeb, use TimeWarp, save vessel defaults. I'm not sure if "use mechjeb" or "use timewarp" are vessel specific or addon global. Or if this split does make sense at all... What are your thoughts?

Thanks a lot . To give you some more arguments: I didn't read the instructions before and this is my very first GitHub based project. I've used Jira and Microsofts Team Foundation server before extensively and other tools in the decades before, so I know this kind of stuff. But even if you use something like this for the very first time - it's really easy to use. If you'd like more arguments, write me a PM - so we do not clutter this thread.

After a few days I feel confident V 1.7.5 is a stable release, so I release it now. It will also be on CKAN after a while. Download here V1.7.5 (issue tracker): New feature: showing orbital info in stats window (apoapsis, periapsis, time to those). improvement: roll program starts after vessel has cleared it's own height. improvement: launches with inclination much more precise now, no wobble and overcompensation. improvement: Navball switches to orbital display when switching to orbital insertion pitch program. improvement: main window hides as soon as destination height is reached successfully. bugfix: solved stuttering issue and further reduced memory garbage bugfix: Hiding all TG windows when pressing F2 Next I really want to update the UI. I'd like to utilize the "mouse hover" feature of the stock toolbar, showing buttons to the left: [main][staging][stats][map][settings] The main window I'd like to have as a tabbed interface with a "simple" and a "standard" tab. Simple will just allow to enter destination height and inclination. Standard will be what we have right now, minus some of the setup button for staging, the toggles for stats, launch map etc.

It's Pre-Release time . See the implemented bugs/features for V 1.7.5 in the issue tracker I'd like some of you to test 3 specific topics with this one (among all the others): Stutter when not using staging. And stutter in general. Behavior when launching into inclined orbits. Test negative inclinations, too. Calculated values for other celestial bodies than Kerbin. I've tested Minmus, Mun and Duna. Download (not on CKAN) I hope this release fixes the 3 topics above. If the feedback is positive, I'll make this an official release.