Overengineer1

Here's an initial working version of the DLL for KSP 1.1: https://github.com/johnfink8/GravityTurn/raw/master/GameData/GravityTurn/Plugins/GravityTurn.dll This should not be considered a stable version yet, especially since 1.1 isn't even stable. There's a lot that isn't tested in this version, and quite a few pieces of the code are affected by the new 1.1 API so there might be a few issues. I'll resume active development now that 1.1 is out, though. I'll do a formal release when it's ready.

@mcirish3 I'm not clear that there's actually a problem to solve here. My understanding is that the MJ hand-off works as intended, but the user was confused about how it works. Did I miss something? I do intend to run a check to see if the node executor has been unlocked in the tech tree to keep consistent with the MJ unlock path. The ascent module isn't involved, though.

@sarbian I didn't tell them to seek support from you. But it's true, MechJeb is the one doing that, since all I did at that point was call "ExecuteOneNode" from your assembly. The user can't do anything to GravityTurn at this point to stop the execution, he has to do it in MechJeb since MechJeb is driving.

@FrontLineFodder Yes, there is a good chance of that. This will go along with the rest of the learning changes, perhaps later this week.

1.3.1 released to address SRB issues

@armegeddon It looks like a problem with that engine. Either it doesn't activate properly or because it doesn't burn fuel, either way it breaks the staging calculations in a way that I don't think I can fix. Logically this doesn't seem like something to be fixed here, since every engine should consume some resource, whether it's ElectricalCharge or EnrichedUranium or whatever. Instead this part actually seems to generate power and thrust for free from nothing, which isn't really compatible with reality.

Yes I already said that. I've just changed it to set APTimeStart as 99% of the calculated value, which seems to work, and this would react instantly instead of waiting an additional 10 seconds. This works well in my tests. I'm looking at another issue reported by someone else, and I'll do a minor version release tonight.

I can see that if the rocket is a little overbuilt with SRBs and the main engine together, it does seem to leave the throttle a little higher than it should. This is an oversight, since I'm calculating the AP TIme Start to make the Hold AP Time exactly what it currently is, the throttle calculations work out that it thinks it should be holding what it has. I'll fix that. But really, if you don't want your main engines running with your SRBs at all, you shouldn't stage them together.

@numerobis That's why. GravityTurn can't throttle down a SRB any more than you can. Your actual Time To AP is going to go where it's going to go, so GravityTurn just accepts it. A recent change made the APTimeStart increase when the SRB pushes the actual HoldAPTime out beyond the original setting. This is to avoid going to the next stage and staying at zero throttle until the AP time comes down, which actually just loses speed and is pretty much never a good idea. This way the AP Time fades down to the original desired setting as the rocket ascends, so the rocket will continue to use a reasonable amount of thrust throughout the launch.

@numerobis Do you have solid booster engines running when this happens?

@Sir_Robert GravityTurn isn't timewarping to Apoapsis. MechJeb is. GravityTurn stopped all operations as soon as you left the atmosphere and handed it over to MechJeb.

I take all suggestions very seriously. If you follow the trail of this thread, most of the new features and fixes follow reports or suggestions from the users. I'm still thinking about how I want to handle this. I know what the mod is currently doing is not enough, I'm pretty sure in some ways it's just ignoring the inclination and destination height, which isn't appropriate. I need to figure out how to best balance adding complicated logic and UI that would confuse some users, vs. adding a sanity check to the learning mechanism that some users will find restricting. Something in the middle is where we'll end up, but this will have to be backed up with actually producing the best results. You'll have to be patient at this point. We've passed the 90/10 line: 90% of the work takes 10% of the time, 10% of the work takes 90% of the time. I've already done 90% of the work, which means I'm really just getting started.

@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.

@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.

@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.