Add a mid course plane change option with node creation

[mgalyean]

Feature Request

Describe the solution you'd like

If the mid course plane change option is active, then the first node will have a normal/antinormal vector that will place a relative AN/DN in an inexpensive interval of the transfer orbit (nearer the apoapsis, but prior to reaching target SOI; would vary whether going inward or outward from transfer orbit body (Sun in most cases). Then a midcourse plane correction maneuvernode would be created at that relative AN/DN.

If the midcourse option is selected and valid departure times coincide with the initial body being at a relative AN/DN between the first node body and the target body then the first node would be created that accomplished the plane change during the initial burn, or alternatively, a "pre-first" node that puts the craft in a circular orbit at an inclination and LAN that will match the desired plane change at the time of the normal first node burn. This initial node could be burned by the player long before the normal first node burn time arrives in prep for actual departure.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

[maneatingape]

Thanks for the suggestion!

Do you have any examples/situations where a mid-course inclination change is an advantage over a ballistic transfer? Stock is ideal, but modded planet packs are fine too.

The reason I ask is to consider the cost/benefit of this feature.

[mgalyean]

To get an efficient rendezvous at some point you have to match inclinations with the target. If left until capture then it is done at capture. But matching inclinations is always most efficient at the highest radius relative AN/DN. Going sunward, most efficient is departing at the relative AN/DN. Does RSVP always put the first node in time at a relative AN/DN (the begin body being at that relative AN/DN in its orbit)? I just started using it. Going outward from the Sun, like Jool, or Duna even, the most efficient plane change will be nearer the target body.

Also once one has ISRU and mining going on Minmus and fuel is far less of an issue one can depart for, say Eve, prior to a relative AN/DN and do the inclination match en route even in cases where it will cost a bit more fuel, but save time. I guess it comes down to time efficiency being more important than fuel cost in certain phases of the game.

For the stock system, matching Jool's inclination results in an equatorial injection (or close enough that I can't tell the diference) making Laythe aeobraking or Tylo sling-shotting/braking a lot easier to set up. When going from Bop to Pol, one can depart sooner and match planes mid course and so arrive many days ahead of waiting for the starting body to reach a relative AN/DN for the first burn.

Lastly comet intercept contracts, and some wild rescue contracts, often require leaving nearly immediately if you want to intercept it near perihelion at all and being in the same plane at some point makes rendezvous far easier

[maneatingape]

To get an efficient rendezvous at some point you have to match inclinations with the target. If left until capture then it is done at capture. But matching inclinations is always most efficient at the highest radius relative AN/DN. Going sunward, most efficient is departing at the relative AN/DN. Does RSVP always put the first node in time at a relative AN/DN (the begin body being at that relative AN/DN in its orbit)? I just started using it. Going outward from the Sun, like Jool, or Duna even, the most efficient plane change will be nearer the target body.

RSVP usually finds transfers that intercept the destination at AN/DN (or leave the origin at AN/DN), so that the inclination velocity component is folded into the insertion burn, where it can take advantage of Oberth. Delta-v values match well with predicted values from other Lambert solvers (e.g Alex Moon) or the orbital transfer subway map.

Is there a transfer where a mid-plane inclination change is a better strategy?

For the stock system, matching Jool's inclination results in an equatorial injection (or close enough that I can't tell the diference) making Laythe aeobraking or Tylo sling-shotting/braking a lot easier to set up.

For this specific scenario (intercepting a Joolian moon), run RSVP twice, first to get a Jool intercept with a target PE near the desired moon's orbit, then a second time once inside Jool's SOI to intercept. RSVP will handle the tricky details of a good intercept, even when you are coming in towards Jool at a slight inclination.

Lastly comet intercept contracts, and some wild rescue contracts, often require leaving nearly immediately if you want to intercept it near perihelion at all and being in the same plane at some point makes rendezvous far easier

This feels like the strongest potential use case - time restrictions forcing a departure where a ballistic trajectory is sub-optimal over a plane change. However RSVP can calculate transfers that would be painful to find manually, so there would have to be a significant delta-v advantage.

I'm enjoying this conversation and please understand, do not intend to come across as overly critical on your suggestion at all! RSVP already has to handle a number of complex edge cases already for common scenarios, so my philosophy is to focus on handling the 90% of common scenarios as best as possible. Adding a feature with niche application that complicates the code base, may not have a good cost/benefit ratio.

Hence metaphorically "kicking the tires" to see if there's a compelling benefit.

[mgalyean]

To get an efficient rendezvous at some point you have to match inclinations with the target. If left until capture then it is done at capture. But matching inclinations is always most efficient at the highest radius relative AN/DN. Going sunward, most efficient is departing at the relative AN/DN. Does RSVP always put the first node in time at a relative AN/DN (the begin body being at that relative AN/DN in its orbit)? I just started using it. Going outward from the Sun, like Jool, or Duna even, the most efficient plane change will be nearer the target body.

RSVP usually finds transfers that intercept the destination at AN/DN (or leave the origin at AN/DN), so that the inclination velocity component is folded into the insertion burn, where it can take advantage of Oberth. Delta-v values match well with predicted values from other Lambert solvers (e.g Alex Moon) or the orbital transfer subway map.

Is there a transfer where a mid-plane inclination change is a better strategy?

For the stock system, matching Jool's inclination results in an equatorial injection (or close enough that I can't tell the diference) making Laythe aeobraking or Tylo sling-shotting/braking a lot easier to set up.

For this specific scenario (intercepting a Joolian moon), run RSVP twice, first to get a Jool intercept with a target PE near the desired moon's orbit, then a second time once inside Jool's SOI to intercept. RSVP will handle the tricky details of a good intercept, even when you are coming in towards Jool at a slight inclination.

Lastly comet intercept contracts, and some wild rescue contracts, often require leaving nearly immediately if you want to intercept it near perihelion at all and being in the same plane at some point makes rendezvous far easier

This feels like the strongest potential use case - time restrictions forcing a departure where a ballistic trajectory is sub-optimal over a plane change. However RSVP can calculate transfers that would be painful to find manually, so there would have to be a significant delta-v advantage.

I'm enjoying this conversation and please understand, do not intend to come across as overly critical on your suggestion at all! RSVP already has to handle a number of complex edge cases already for common scenarios, so my philosophy is to focus on handling the 90% of common scenarios as best as possible. Adding a feature with niche application that complicates the code base, may not have a good cost/benefit ratio.

Hence metaphorically "kicking the tires" to see if there's a compelling benefit.

I think that time priority rather than fuel priority covers all the cases I brought up really. There is a point in an ISRU game where you leave mostly when you want to as fuel is not the main issue. Waiting for an outer planet relative AN/DN can take a very long time in that flavor of game (Jool to Eeloo, lol), whereas dealing with the relative AN/DN when you cross it, or dealing with it at the destination if it comes to it, can be a lot more useful.

But of course it is completely up to you as it is your baby. Just throwing it out there for pondering

[mgalyean]

One last thing, something kept nagging me about your statement about making use of the Oberth effect for doing the plane change at start or destination body. It is my understanding that the Oberth effect only makes a difference for prograde/retrograde burns, and actually makes normal/antinormal burns less efficient (or has no effect, can't remember). But there is a reason inclination changes are typically much cheaper the further from the body one can make them

[maneatingape]

One last thing, something kept nagging me about your statement about making use of the Oberth effect for doing the plane change at start or destination body. It is my understanding that the Oberth effect only makes a difference for prograde/retrograde burns, and actually makes normal/antinormal burns less efficient (or has no effect, can't remember)

The greater the velocity the higher the benefit. Doesn't make any difference what direction that velocity is pointing. In the case of an insertion burn RSVP only cares about reducing the total velocity magnitude below the threshold to elliptical (to which the inclination contributes a component).

But there is a reason inclination changes are typically much cheaper the further from the body one can make them

Yup, the slower you're going the lower delta-v is needed for inclination changes. So if you'd like to adjust the inclination post-capture then that's best done at a high AP as possible.

[mgalyean]

I'm fairly sure that Oberth only applies if thrust is parallel with the velocity vector because that is the line on which the kinetic energy of the craft exists and it is the kinetic energy on which the effect rests. If it applied to any direction then inclination changes would be more efficient closer to periapsis instead of farthest. The faster one is going, the harder it is to change direction. Newton law's and all. The effect works because it affects direction very little while affecting speed very much; so prograde/retrograde yes, but a 90 degree change in direction is just fighting Oberth, not gaining from it. In other words, an orbiting craft's normal/antinormal non-thrusting velocity is exactly zero by definition of an orbit, so how can it gain from the Oberth Effect when thrusting normal or antinormal?

[maneatingape]

I'm fairly sure that Oberth only applies if thrust is parallel with the velocity vector because that is the line on which the kinetic energy of the craft exists and it is the kinetic energy on which the effect rests

Yup, that's the scenario we're considering here. Say you use RSVP to plot an transfer from Kerbin to Moho so that you arrive at Moho's AN. There's no need to match inclination (since you have an intercept) but the velocity difference due to inclination remains. So when thrusting retrograde for the insertion burn the velocity vector will be inclined (relative to Moho's equator) and the resulting orbit post-capture inclined also.

[mgalyean]

I think we are merely differing on which orbit matters at what points in a transfer. It seems you are focused on the beginning and ending bodies while I'm trying to consider the intervening solar orbit. And if the moons around the destination body are mostly in equatorial orbit, and that orbital plane mostly matches the parent's orbital plane, then the solar orbital aspects for plane changes are worth considering. Especially when allowing for promoting time constraints and dialing down efficiency constraints