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.

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.

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

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

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

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.

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'm having it build a kind of "database" of launches for a particular ship design. It is tracking things like total loss and max critical heat, so yes, burning up is something that it will learn from. Messing around with the AP time settings is a little hard to quantify for the guess. Right now I'm thinking of adding a special case for SRBs to extend the APTimeStart, so that the rest of the launch fades gradually down to a 40 second AP Time, instead of currently where the SRB stage will push the AP time out to a minute or more and the mod will throttle all the way back. This will make a big improvement at least for a lot of my personal ship designs. Version 1.3 will include this SRB feature as the only adjustment to AP Time settings. The 1.3 guess improvements will be made only to the Start Time and Turn Angle for this version. Later on maybe I can better quantify when/how/where/why to make other changes to the AP Time guess, but I have to take it one step at a time.

@FiiZzioN That's why the pressure cutoff setting is available, a lower value will wait until the atmosphere is thinner at higher altitudes. If you don't want to pop the fairing at all, either put it higher on the staging order or disable automatic staging.

@tater Test it yourself. Your available delta-v will go up substantially when the fairing pops. This is well known and well researched, by others and by me.

@tater Fairings are almost never worth carrying past about 20km. It takes more fuel to carry their weight than they save in drag above that point. You can adjust this behavior by changing the pressure cutoff setting. You will probably make your launches less efficient if you make a drastic change from the default value.