Re-entry auto pilot enhancements.

[Aquilux]

With the upcoming addition of re-entry heating effects, as well as the presence of mods that add this functionality now, I think we should be able to manually set our reentry path. I see something similar to the assent curve editor, where you could set the entry angle and see the projected path to target.

You could do a number of things to expand on this window, such as:

Varying the color of the line from blue to red dependent on g-force (as a reliable predictor of heating).

Use an orange/yellow border line of varied thickness to indicate estimated burn during a powered descent.

Display estimated remaining delta-V for each descent milestone on the line (end of de-orbit burn, end of course corrections, end of descent burn, touchdown)

Display countdown to major events on the line (start of each burn, touchdown)

Add toggle to designate either a powered or unpowered re-entry.

Add a slider to adjust mech jeb's priority during a powered descent between efficiency and accuracy (prioritised to efficiency = suicide burn).

Add fields so that we can have mechjeb autostage to a set stage upon reaching a set altitude

Predict the reentry path while accounting for the changes of drag and mass that occur because of said events.

Calculate impact speed (useful for unpowered reentry, as well as when using parachutes and low t/w engines)

Grey out all inputs after a decent has been started, but keep updating the screen live if it's open so we have an up to date monitor.

[asmi84]

This is not super-critical feature though as currently landing tool actually follows maneuver nodes if there are any, so you can plan reentry in advance using it and the tool will show you predictions based on as if this maneuver is executed. I have Deadly Reentry installed and I have completed numerous successful reentries using abovementioned approach. Besides it's absolutely impossible to predict amount of heating you'll get beyond trivial cases like bare capsule as amount of heating is extremely attitude-dependent, and it's not given that MJ could actually maintain whatever attitute MJ decides is best to be held during reentry - infact it's quite opposite. The reasons include part shielding and heat transfers from one part to others.

[Aquilux]

1- The fact that mechjeb is incapable of plotting a reentry that does not fail under Deadly Reentry using any heat shield that matches the pod/parts it is protecting is damning. Somehow the two must be reconciled so that this is possible. Considering that heat buildup will be directly related to entry speed, the most flexible method to do this would be to at least allow user control over the reentry angle so that the failure can be blamed on the user and not the program. This also allows flexibility to take into account any changes in Deadly Reentry, or a change over to the stock KSP implementation.

2- The appeal of Mechjeb is that, theoretically, most if not all operations could be handled entirely by the autopilot as long as it's given workable parameters. To achieve this with D.R., or with the eventual stock implementation, there will have to be some way of affecting the reentry profile to account for vehicle mass, speed, drag, and capabilities. Considering that this is nearly impossible to implement automatically, as you said, I simply suggest adding the base capability to alter the reentry profile in the same way you can alter the accent profile.

3- Please excuse my language, but I call bullshit on heating prediction. If it is impossible to predict how much maximum heating will be experienced, how is it that mechjeb is capable of predicting the maximum g-load? They are both a function of speed and atmospheric density, and should both be subject to the same uncertainties caused by orientation. If there is truly a worry about orientation and it's effect on the prediction, use a retrograde orientation considering that's the most common capsule reentry attitude and leave it to the user to design and fly their craft in a sustainable way. If you want to be nice you can add in the option to use prograde, or even a user defined offset if you feel ambitious (notice that key phrase, like my earlier suggestions, they're JUST SUGGESTIONS and you do not need to dismiss the whole post because of it)

Which brings me to my last point

4- If you're going to dismiss something just because you've done it yourself and don't feel the need to make the software more capable, then why are you even involved with the mechjeb project in the first place?

[tavert]

I have no authority and the following are only my opinions, feel free to ignore. I could be wrong here but it doesn't look like asmi84 is a MechJeb dev either, so you can always apply the same to him...

Putting features into MechJeb specifically because of a mechanic that only exists in a different unrelated mod seems like it would naturally be a low priority. From what I've seen the KSP devs have said stock re-entry heat will require a revamped aerodynamics system (a ways out), so anything in MechJeb that relies on the stock aerodynamic mechanics will need to be rewritten when that happens too. Deadly Re-entry is a mod that makes the game harder, whereas MechJeb is a mod that makes the game easier, so some incompatibility in intent and priorities is inevitable. The heating implementation in Deadly Re-entry is not necessarily indicative of the final stock implementation whenever that happens, and it doesn't make much sense to put things in MechJeb that only apply to Deadly Re-entry. I'd say talk to the Deadly Re-entry devs and see if a prediction/visualization system could be incorporated into that mod (possibly reusing some of the MechJeb landing prediction code, as long as it's properly attributed and obeys the license).

A re-entry profile right now is really just apoapsis and periapsis of the orbit before hitting the atmosphere. Active re-entry would be throttle and/or staging control (and orientation control for craft with wings) during the descent. Have a look through the landing autopilot code - there is a target speed calculation in there right now, but at the moment it uses as much aerobraking as possible without any throttle until final landing. What you're suggesting would require user interaction with this target speed calculation, potentially complicated from a UI standpoint. What could be an interesting intermediate step in the direction of what you're proposing would be a visualization of the internal atmospheric landing simulation results. But IMO there are higher-priority bugs and easier-to-add (or missing relative to MJ1) features to address first.

[Aquilux]

First off, that's the point of having user control hidden away in a window, like the assent window. This includes functionality, with the maximum flexibility, and minimum clutter possible. We know it will be implemented in stock. KSP devs have stated they want to have KSP finished in 1 to 1-1/2 years, so it's not that far off. Mods have already implemented it. So the functionality is, in fact, relevant.

Second, r4m0n is the "owner" of both of these mods, so it's not that farfetched to want one to work with the other.

Third, by passing the decisionmaking to the user, the method I propose for adjusting the reentry profile will require the least possible re-coding when DR changes or when KSP implements reentry heat.

[asmi84]

Aquilux, Max G-load predictions are only possible and are reliable now because stock "aerodynamics" doesn't care about attitude (winged craft excluded), once that changes it will also become unreliable just as it is right now for winged aircraft. Just go out and try reentering with the same winged craft but different attitudes, and compare predicted G-load with an actual one - looks like you're up for a surprise. Same goes for landing predictions - itfact my experiments show that different attitudes cause landing point to shift up to as mush as 100 km away from predicted landing site. With proper aurodynamics in place this variability will be hundreds of kilometers. Also if you feel like doing some research on subject, take a look at reentry calculator plugin for Orbiter to get an idea of what it's going to be like after proper aerodynamics goes vanilla. Next, as it was pointed out, the Deadly Reentry's implementation case is relevant here for two reasons - first off the dev is not in Squad, and the second one it that whatever implementation will be it WILL be attitude-dependent just because physics of it require it to be so. And lastly, I did not tell that I don't want this to be implemented - I just said that current MJ has a ton of higher-priority issues that need to be taken care of, and tried to explain why reentry heat predictions are not reliable and can not be made reliable.

[Aquilux]

My apologies, looking back I realise I shouldn't post late at night. (I tend to sense more hostility when I'm tired, and that gets even easier to do when there's no tone of voice to give me a better picture) I still don't understand why we can't have something just like the assent profile editor for the decent.

Yeah, it wouldn't be able to forecast heating for all attitudes, so just have it assume your craft will sit prograde through reentry, or have a button to pick between prograde or retrograde. If someone feels extra generous, they could give the user the option to enter yaw/pitch/roll from forward motion, now that that's an option in smartASS. In this case, it'd be up to the user to design a craft capable of being held in this position (by smartASS, or manually) as to make this prediction true.

As for the relevance... yeah, there are bug-fixes and functionality to be restored that take precedence, but you had sounded like you were dismissing the idea instead of saying it's something to consider further down the road. I think that it'd be useful to a number of people now and would be a proactive step in preparing for the vanila implementation, instead of you guys having to react to changes. I don't know for sure, because I don't know how to code (or else I'd be helping you guys if I could), but I know enough about computers and how mechjeb is working with ksp to guess that the basic implementation would be easier than the assent profile was.

On a related note, I posted this plugin request on the KSP forums to make heat shields more customizable/function more realistically [ http://goo.gl/U4d9n ]. This is an open request for anyone to take up if they wish, but I feel as though it'd be best implemented directly by r4m0n in his D.R. plugin. If he/someone wants to add this to D.R., or whip up a quick .dll, it'd be awesome. But like you said, you're all busy, so I'll hope someone else out there gets their hands on it.

[asmi84]

The way it's done in aerobrake MFD plugin for Orbiter is that it assumes you're maintaining current attitute, so as you change attitude the values gets updated. And given the success of that mod for Orbiter - it's basically a "default mod" I'd suggest that this way is working.

[Aquilux]

Maybe holding attitude could eventually be implemented in the reentry autopilot in the same way as the spaceplane guidance can land you on the runway. When proper aerodynamics come into play (through either a mod, or through vanilla), changing your attitude during reentry will be able to affect your flight by generating lift (like this http://youtu.be/aW5ozq4Tqew?t=12m8s). Maybe one day mechjeb will be able to do something like this to fly a proper reentry path (don't go too deep, too fast) and arrive on target during an unpowered decent (like this http://youtu.be/aW5ozq4Tqew?t=14m18s).

[asmi84]

Yea I know all of that since I played Orbiter a lot :) The problem is that until we see this aerodynamics implemented there is no way we could guess what it's going to be like. Second problem is for multipart craft - hypersonic shockwave acts more like a concrete wall so once it's there it will cause a serious strain applied to these parts, and it can collapse the ship inside itself. Given how glitchy current physics in KSP is I suspect that it would be hard to predict that kind of process. However typical reentry speeds in KSP are much lower than in real life (7-8M vs 25M+) so there will be more tolerance to slight imperfections of reentry path. If you want go get a feel of it you can try FAR plugin that implements proper aerodynamics for stock capsules (if I remember that correctly), or play some Orbiter :) Bottom line - yes I'd like to have something like that implemented, but at the same time I realize that there are many "If"'s...

[Aquilux]

I've already played around with it, the only reason I didn't continue is because of how buggy it was and I didn't want to go in and modify the .CFGs to convert my whole library. I understand your hesitation on putting that eventual functionality in too early, that's why I said eventually. But the basic implementation of the reentry profile editor, I don't see why that can't be added next time you guys have more spare time on your hands.