Flight Plan [0.10.6 for KSP2 v0.2.0+]

[schlosrat]

Release 0.10.2.1

• Update to appease the CKAN gods who've been deeply offended by the mischievous machinations of the GitHub demons - we can't have that!
  • No actual code was harmed, modified, improved upon, or in any other way molested in this process.
  • All features are precisely the same as they were in version 0.10.2
  • Warranty void if speed exceeds c

Download on SpaceDock

Edited February 6 by schlosrat

[Aerius]

14 hours ago, schlosrat said:

Yep, it’s a well known issue that’s been present for some time. Here’s a fairly recent post where I explain what’s going on and what thee work around is.

Crap, I couldn't identify the issue on the bug tracker or release notes so I thought it was a new regression.

Thank you for the workaround.

If you want, I could submit the issue on github.

 

[schlosrat]

3 hours ago, Aerius said:

Crap, I couldn't identify the issue on the bug tracker or release notes so I thought it was a new regression.

Thank you for the workaround.

If you want, I could submit the issue on github.

 

I believe this issue is actually related to two issues documented on GitHub.

The first one (Issue 10) was an early one I created on May 8th, 2023, when I first noticed the problem with some Hohmann transfers, and in that one, I note it's affecting both transfers to moons and interplanetary transfers. The second one (Issue 31) reported on Oct 30th, 2023, identified a related problem with Moon Return. I've since then learned more about the underlying cause, but still have not gotten a solution. The new info I've got will hopefully help me to put this to bed, but it will not be easy.

Since these are all related issues, I'll close those and open a new one that includes the workaround info.

Edited February 5 by schlosrat

[Fizzlebop Smith]

I know that a lot of bugs are being worked out, will be worked out and such...especially as updates mess with all of your fine craftsmanship.

I just wanted to say that mechjeb2 was extremely buggy with regard to certain features. Other feathers like orbital calcs were inclined to bug out occasionally as well.

One instance i recall trying to 'return from a moon' @ 20KM would toss me out at 2.4m KM from Kerbin. I know that manual adjustments can be made and often the end result, but i kept altering the desired orbital distance and would get slight variation in end Kerbin AP, but not really anything when considering cosmic distances. Reloaded saves and nadda. After a while i realized i had  wasted way too much time doing nothing at all and ate dinner, went to sleep. Next day after a fresh restart and reboot of the game can you believe that 'return from moon' @25KM and ended up 100KM from where i wanted.

Anyone familiar with Mechjeb2 knows that distance was rarely close on that feature. Depending on your relationship to the ecliptic on return and such. I know this may not have bearing on all the things encountered in this thread. Most may be legitimate issues to fix. Others may just be the result of some quirky *interactions between the game* & a Marvelously Cobbled together (constructed) Glory of complicated code. 

Sometimes, the digital gods are just angry at us. 

Should i remedy the sleep deprivation now? ...
or play some more KSP2

[schlosrat]

Release 0.10.3

• Corrected issue where the "at an altitude" burn time option was interpreting the altitude to be from the center of the body rather than above the reference level (sea level) as other altitudes are specified throughout Flight Plan. In this version, when selecting the "at an altitude" burn time option, the burn will be scheduled for the next time the orbit is at the specified altitude above sea level (bounded between the current orbit's PeR and ApR).

Download on SpaceDock

Edited February 6 by schlosrat

[Redacted]

Thank you schlosrat !

[CrossHorizon]

Installed everything as per instructions on page one. 
 

How do I open Flight Plan?  

Never mind, I figured it out. 

 

Edited February 6 by CrossHorizon
Found the answer.

[Poppa Wheelie]

On 2/4/2024 at 10:19 AM, Poppa Wheelie said:

Yes, this is what I have been doing.  This MNC ability to edit a node with the game paused is fantastic!

I may not be able to get to it for a few days, but I'll see if I can set up a good scenario, with screenshots, etc., and I'll report back here.

I really enjoy the ability to edit nodes while the game is paused, but perhaps editing while pausing is what caused my initial suspicion that Flight Plan needed to move Burn Start times up before the selected creation point.  However, I looked back over my screenshots, and I see that once time is taken off of Pause, the Burn Start time has indeed been moved up.  So all is well on that front.  I did notice, though, that with a little more manual tweaking of the Burn Start time, I still got a better predicted result (ie, closer to circular, lower Eccentricity).

1 minute 13 seconds to Ap

Immediately after the node to Circularize at the Next Ap was created (with time paused), I noticed that the Start Burn time and the Time to Ap were matching.  This led to my belief that the Start Burn time was locked on to the selected point (Ap in this case)

After unpausing time, and then pausing again, the Start Burn time has been adjusted

Flight Plan created node has projected Ecc of 0.004

With a little more tweaking of the Burn Start time, I got an Ecc of 0.002

Edited February 6 by Poppa Wheelie

[schlosrat]

@Poppa Wheelie Thanks for the detailed checking and the screenshots. Ending with an ecc of 0.004 is not unusual for FP when circularizing. My operating hunch is that backing off the node start time by exactly 1/2 the burn time is close to optimal, but clearly, something better could be achieved. The optimal result would be ecc 0.000. I believe this has to do with the fact that as you burn the node your mass decreases while thrust stays the same, and so acceleration increases and you're gaining more delta v in the second half than you did in the first half.

The problem here is that the optimal amount to back off the node time is not a fixed percent. Depending on how much fuel you've got, what your thrust is, what your payload fraction is, and perhaps some other factors, the optimal for one craft will be different than for another. It's possible that some sort of optimization routine could be run around the problem where the offset factor of 0.5 burn duration is just an initial guess. This same thing will be in general true for all planned maneuver nodes since the cause is not unique to circularization.

My priorities at the moment are to try to fix some things that are working very poorly, but it may be a good idea at some point to circle back and clean up the smaller problems like this one.

The bigger questions I'm currently looking at include these.

1. Why is it that a moon return from Mun works so well, whereas a moon return from Minmus works so poorly? Curiously, if you change the time of the moon return burn at Minmus by about 1/2 an orbit you can play with the time until you do get a good or very good result, but why is it that when at Minmus the node time is so far off?
2. Why is it that when making a Hohman transfer from Kerbin to Minmus there is often no encounter and the node is not even getting the new Ap out to the orbit of Minmus, but when going to the Mun it will often give you an impact encounter? Both typically need some help from MNC. It would be very nice if they didn't need the help.
3. Why is it that the Interplanetary Transfer works so very poorly unless you're selecting the "as soon as possible" burn option after time warping to be within a day of the next transfer window?
4. Major problems with the Advanced Planetary Transfer make it not workable at all as it can't even get an encounter and so fails to make a node and there's nothing for you to adjust with MNC
5. Wouldn't it be nice if you could give Flight Plan a landing point (lat/long) and then it could at least give you the deorbit node that would put you on a course toward your destination so that K2D2 could then land somewhere near there?

Those are the things that keep me up at night much more so than circularization giving an ecc of 0.004! Still, it would be nice if this was my big problem instead of those others...

Edited February 8 by schlosrat

[Poppa Wheelie]

1 hour ago, schlosrat said:

Those are the things that keep me up at night much more so than circularization giving an ecc of 0.004!

I enthusiastically agree that the issues you listed are much higher priority.  I can continue to manually optimize from the starting point provided by Flight Plan.

[Rezania]

Hate to say this, but the bug with the transfer window timer counting upwards is back again. LKO, target Dres, timer is counting upwards.

[schlosrat]

Release 0.10.4

• Multiple fixes/improvements to Resonant Orbit Maneuvers Tab
  • Fixed handling of Synchronous Alt, Semi Synchronous Alt, and SOI Alt to display altitude instead of radius from the center of the body being orbited.
  • Fixed Diving prohibition to account for atmosphere depth. You are now (correctly) prevented from setting up a diving resonant orbit around a body with an atmosphere where the Pe would be inside the atmosphere - which, I think we can all agree, would be bad.
  • Updated FixPe and FixAp Maneuver buttons to allow for "after a fixed time" burn time option and also force a better default ("at Ap" for FixPe, and "at Pe" for FixAp)

Download on SpaceDock

[schlosrat]

21 hours ago, Rezania said:

Hate to say this, but the bug with the transfer window timer counting upwards is back again. LKO, target Dres, timer is counting upwards.

That is sooo weird! I tested with Moho, Eve, Duna, and Jool before releasing 0.10.2 and they all work fine (still do, too). I tested again with Dres and by Jove you're right - it is indeed counting up for the window.

I'll look into this and sort it out. Thanks for bringing it to my attention.

[Rezania]

2 hours ago, schlosrat said:

That is sooo weird! I tested with Moho, Eve, Duna, and Jool before releasing 0.10.2 and they all work fine (still do, too). I tested again with Dres and by Jove you're right - it is indeed counting up for the window.

I'll look into this and sort it out. Thanks for bringing it to my attention.

Using version 0.10.4 now, and the timer is counting down.  Same conditions, LKO and Dres targeted.

[schlosrat]

1 hour ago, Rezania said:

Using version 0.10.4 now, and the timer is counting down.  Same conditions, LKO and Dres targeted.

Well, that's odd. I verified it in 0.10.4 with Node Manager 0.7.3. In fact, I just reverified it in a debug build - so I've verified that the bug is possible in both the release and debug versions of FP 0.10.4 Since I'm able to reproduce it I should be able to get to the bottom of it.

In my test case, I'm at UT 1y, 3d, 1:22:03 and flipping back and forth between Duna (which seems to work) and Dres (which is showing the bug). At Duna, I see this

• Relative Inclination: 0.06
• Phase Angle to Target: 134.531 (counting down)
• Transfer Window Phase Angle: 44.361
• Transfer Time: 302d 0:13:23
• Synodic Period: 2y 57d 2:04:17
• Next Window: 227d 4:51:33 (counting down)

At Dres, I see this

• Relative Inclination: 5.00
• Phase Angle to Target: 8.414 (counting down)
• Transfer Window Phase Angle: 82.056
• Transfer Time: 1y 177d 0:55:54
• Synodic Period: 1y 101d 5:22:42
• Next Window: 107d 5:22:42 (counting up)

The difference here is that in one case (Duna) Phase Angle to Target > Transfer Window Phase Angle, and in the other (Dres), it's not. It's also not for Moho or Eve at this UT, but those have Phase Angle counting up - which Dres does not. For any case where the target is in an inferior orbit, you can expect that the Phase Angle to Target counts up, and vice versa.

All of this points to a bug in my logic where I was checking to see if Phase Angle to Target > Transfer Window Phase Angle when I should have been checking to see if the target is in an inferior or superior orbit relative to the starting planet. I've fixed this in 0.10.5 and verified it with all the stock planets. I should have a release out for you shortly.

 

[schlosrat]

Release 0.10.5

• Corrected issue where in some cases the Next Window time for a transfer window would be computed incorrectly and count up rather than down.

Download on SpaceDock

[Ace76inDC]

48 minutes ago, schlosrat said:

at's odd. I verified it in 0.10.4 with Node Manager 0.7.3. In fact, I just reverified it in a debug build - so I've verified that the bug is possible in both the release and debug versions of FP 0.10.4 Since I'm able to reproduce it I should be able to get to the bottom of it.

In my test case, I'm at UT 1y, 3d, 1:22:03 and flipping back and forth between Duna (which seems to work) and Dres (which is showing the bug). At Duna, I see this

 

24 minutes ago, schlosrat said:

Release 0.10.5

• Corrected issue where in some cases the Next Window time for a transfer window would be computed incorrectly and count up rather than down.

Download on SpaceDock

Awesome, I thought I was crazy.  Great work great mod!

[Rezania]

1 hour ago, schlosrat said:

Well, that's odd. I verified it in 0.10.4 with Node Manager 0.7.3. In fact, I just reverified it in a debug build - so I've verified that the bug is possible in both the release and debug versions of FP 0.10.4 Since I'm able to reproduce it I should be able to get to the bottom of it.

In my test case, I'm at UT 1y, 3d, 1:22:03 and flipping back and forth between Duna (which seems to work) and Dres (which is showing the bug). At Duna, I see this

• Relative Inclination: 0.06
• Phase Angle to Target: 134.531 (counting down)
• Transfer Window Phase Angle: 44.361
• Transfer Time: 302d 0:13:23
• Synodic Period: 2y 57d 2:04:17
• Next Window: 227d 4:51:33 (counting down)

At Dres, I see this

• Relative Inclination: 5.00
• Phase Angle to Target: 8.414 (counting down)
• Transfer Window Phase Angle: 82.056
• Transfer Time: 1y 177d 0:55:54
• Synodic Period: 1y 101d 5:22:42
• Next Window: 107d 5:22:42 (counting up)

The difference here is that in one case (Duna) Phase Angle to Target > Transfer Window Phase Angle, and in the other (Dres), it's not. It's also not for Moho or Eve at this UT, but those have Phase Angle counting up - which Dres does not. For any case where the target is in an inferior orbit, you can expect that the Phase Angle to Target counts up, and vice versa.

All of this points to a bug in my logic where I was checking to see if Phase Angle to Target > Transfer Window Phase Angle when I should have been checking to see if the target is in an inferior or superior orbit relative to the starting planet. I've fixed this in 0.10.5 and verified it with all the stock planets. I should have a release out for you shortly.

 

Ah yes, current angle vs transfer angle could be the issue indeed. When I checked just now my current angle was bigger than the transfer angle, before it was the other way around. That supports your logic, nice find.

[Mike S]

I am enjoying this very useful mod.  However, I am running into an issue in regards to using the tool to change SOI from Gilly back to Eve, as I chose to drop off a lander on Gilly first before dropping the second onto Eve.  The tool refuses to give me the option and forces a return to Kerbin as the only thing I can do with it.   While it isn't really that hard to do this manually in this instance, I thought it might be worth while bringing this up as something to allow the user to decide which planet it should focus on, or allow to toggle it off when not needed perhaps.

[schlosrat]

17 hours ago, Mike S said:

I am enjoying this very useful mod.  However, I am running into an issue in regards to using the tool to change SOI from Gilly back to Eve, as I chose to drop off a lander on Gilly first before dropping the second onto Eve.  The tool refuses to give me the option and forces a return to Kerbin as the only thing I can do with it.   While it isn't really that hard to do this manually in this instance, I thought it might be worth while bringing this up as something to allow the user to decide which planet it should focus on, or allow to toggle it off when not needed perhaps.

Are you saying that you’re orbiting Gilly and you don’t have a Moon tab with a Moon Return maneuver or that the Moon Return maneuver isn’t giving a good Pe at Eve in this case but is sending you out of Eves SOI?

Any time you’re orbiting a moon there should be a Moon tab. You would not need to target Eve or anything really to be able to use it, though it does recommend that you be in a low inclination/low eccentricity orbit for best results. I’ll test the Gilly to Eve return when I get back to my PC, but it may help if you can describe more about your situation and the options you’re getting in FP

[Gorby1]

On 2/7/2024 at 9:22 PM, schlosrat said:

• Wouldn't it be nice if you could give Flight Plan a landing point (lat/long) and then it could at least give you the deorbit node that would put you on a course toward your destination so that K2D2 could then land somewhere near there?

Why yes, it definitely would be! 

[schlosrat]

18 hours ago, Mike S said:

I am enjoying this very useful mod.  However, I am running into an issue in regards to using the tool to change SOI from Gilly back to Eve, as I chose to drop off a lander on Gilly first before dropping the second onto Eve.  The tool refuses to give me the option and forces a return to Kerbin as the only thing I can do with it.   While it isn't really that hard to do this manually in this instance, I thought it might be worth while bringing this up as something to allow the user to decide which planet it should focus on, or allow to toggle it off when not needed perhaps.

OK, I'm home now and I've been able to do some simple testing at Gilly, perhaps this is the problem you've encountered...

In a 15.7km x 15.7km circular orbit at 0 inclination at Gilly, I used the Moon Tab to get a Return From Moon trajectory with no target selected. As with performing a Moon Return at Minmus, the result is a good burn vector at a very silly time. By a "good burn vector", I mean the Prograde, Normal, and Radial components are good - but as with returns from Minmus the node time is just plane wacky as you can see below.

The resulting trajectory, while not headed all the way back to Kerbin (it's only a 221 m/s maneuver), is definitely leaving both Gilly's and Eve's SOI. In fact, if you turn the camera so you can see where Eve is in relation to all this, you'll clearly see the node time is just wacky.

For a good Moon Return, or for that matter any transfer from a higher orbit to a lower orbit, we need to burn in a direction that will decrease the orbital energy so that the Pe will drop. In other words, we need to take off in more or less the opposite direction of the moon's orbital velocity about its parent. Fooling about with Maneuver Node Controller, I was able to get a not too terrible result with only modification to the time of the node.

Here, the node time has been pushed out by about 2:10 - which is a lot for this orbit and results in a Gilly ejection that is headed in about the opposite direction of Gilly's motion as shown below.

 

This problem has been reported before (by me and by others) and is being tracked on GitHub with this issue: https://github.com/schlosrat/FlightPlan/issues/49

The good news is that there is a relatively simple (albeit tedious) workaround, and also that I am aware of this and working on it. Not fantastic news, I'll grant you - but not bad news either.

55 minutes ago, Gorby1 said:

Why yes, it definitely would be! 

I am also working on this one! In fact, with this one, I feel closer to a solution than I do with the Moon Return problem, but we'll see.

Edited February 12 by schlosrat

[schlosrat]

In the (very brief) testing I've done, the only moons where I've seen this problem are Minmus and Gilly. In every other case, I get pretty good results, although with Bop and Pol the returns to Jool are not nearly at the requested 100km Pe and instead at a few thousand Km Pe. Not really a bad result when we're talking about Jool - I mean, do you really want to be swinging around within 100km of its "surface"?

I had thought I'd find the same problem at Bop and or Pol given their very small size, but apparently not - though my testing was hardly exhaustive. I do wish I had a good theory for why this happens in some cases and not in others...

[Mike S]

6 hours ago, schlosrat said:

OK, I'm home now and I've been able to do some simple testing at Gilly, perhaps this is the problem you've encountered...

In a 15.7km x 15.7km circular orbit at 0 inclination at Gilly, I used the Moon Tab to get a Return From Moon trajectory with no target selected. As with performing a Moon Return at Minmus, the result is a good burn vector at a very silly time. By a "good burn vector", I mean the Prograde, Normal, and Radial components are good - but as with returns from Minmus the node time is just plane wacky as you can see below.

The resulting trajectory, while not headed all the way back toKerbin(it's only a 221 m/s maneuver), is definitely leaving both Gilly's and Eve's SOI. In fact, if you turn the camera so you can see where Eve is in relation to all this, you'll clearly see the node time is just wacky.

For a good Moon Return, or for that matter any transfer from a higher orbit to a lower orbit, we need to burn in a direction that will decrease the orbital energy so that the Pe will drop. In other words, we need to take off in more or less the opposite direction of the moon's orbital velocity about its parent. Fooling about with Maneuver Node Controller, I was able to get a not too terrible result with only modification to the time of the node.

This problem has been reported before (by me and by others) and is being tracked on GitHub with this issue: https://github.com/schlosrat/FlightPlan/issues/49

The good news is that there is a relatively simple (albeit tedious) workaround, and also that I am aware of this and working on it. Not fantastic news, I'll grant you - but not bad news either.

I am also working on this one! In fact, with this one, I feel closer to a solution than I do with the Moon Return problem, but we'll see.

I hope I didn't give you the impression I was having issues with accuracy here in respect to any maneuver being planned.  It has a bit more to do with the tool switching to "return from moon" mode automatically (as your screen caps have shown) without giving me the option to do anything but that.   If I were orbiting Eve, I would have the other maneuver options available. The behaviour isn't limited to Eve/Gilly...any planet with a moon will do the same thing and deny the ability to do anything but "return from moon" if I am orbiting a moon.  Which isn't what I want to do and not necessarily just the host planet orbit either.  In the case of Eve/Gilly, I stopped at the moon first to drop off a probe before going on to Eve to place a second probe and learn a bit about it (I consider myself a year long "newbie"). 

The tool would not give me the option to create a plan from Gilly to Eve.  As I said, it was an easy maneuver for me to manually create a path to Eve without the tool.  I was hoping it is a simple matter of a toggle to enable the other options on demand.  Eve to Gilly, the tool allows a maneuver to be planned, but not return back to Eve using those same tools...on a multi-moon system for example, I cannot use it to go to the other moons as is.  I can return to the host planet and THEN the tool will allow a maneuver to be created to another moon.  (Kerbin and Minmus/Mun) As you no doubt know, this is an aweful waste of fuel.  Unless I missed something important, it seems restricted.  I never got far enough in KSP1 (severely buggy when modded), but I think Mechjeb had something like that...maybe others who know that tool and have used it to plan maneuvers from moon to moon...I never got far enough in that game to try it, so I don't know how it works from experience.

Anyway, still love the tool regardless.

 

[schlosrat]

21 hours ago, Mike S said:

I hope I didn't give you the impression I was having issues with accuracy here in respect to any maneuver being planned.  It has a bit more to do with the tool switching to "return from moon" mode automatically (as your screen caps have shown) without giving me the option to do anything but that.   If I were orbiting Eve, I would have the other maneuver options available. The behaviour isn't limited to Eve/Gilly...any planet with a moon will do the same thing and deny the ability to do anything but "return from moon" if I am orbiting a moon.  Which isn't what I want to do and not necessarily just the host planet orbit either.  In the case of Eve/Gilly, I stopped at the moon first to drop off a probe before going on to Eve to place a second probe and learn a bit about it (I consider myself a year long "newbie"). 

The tool would not give me the option to create a plan from Gilly to Eve.  As I said, it was an easy maneuver for me to manually create a path to Eve without the tool.  I was hoping it is a simple matter of a toggle to enable the other options on demand.  Eve to Gilly, the tool allows a maneuver to be planned, but not return back to Eve using those same tools...on a multi-moon system for example, I cannot use it to go to the other moons as is.  I can return to the host planet and THEN the tool will allow a maneuver to be created to another moon.  (Kerbin and Minmus/Mun) As you no doubt know, this is an aweful waste of fuel.  Unless I missed something important, it seems restricted.  I never got far enough in KSP1 (severely buggy when modded), but I think Mechjeb had something like that...maybe others who know that tool and have used it to plan maneuvers from moon to moon...I never got far enough in that game to try it, so I don't know how it works from experience.

Anyway, still love the tool regardless.

 

Thanks, this does help me understand the issue better. When you’re looking for a way to plan a Gilly to Eve trajectory the tab you need is indeed the Moon tab, and the maneuver is Moon Return. Of course going the other way it’s not this tab and you’re just planning a simple Hohmann transfer. Right now the Moon Return maneuver is giving poor results for Gilly to Eve, but that is the one intended for this purpose.

It sounds to me like you’re finding this arrangement of maneuvers and tabs counterintuitive, and if you are then others may be as well, but this arrangement is by design.

When you go from Eve to Gilly, you’re starting in an orbit about Eve and going to another object also orbiting Eve. Consequently the tools you need are basically the same as you need if you want a Hohmann transfer to rendezvous with another ship also orbiting Eve.

When you go from Gilly to Eve, OTOH, your starting orbit is not about the same body that your target is orbiting, thus the math is a little different. There is still a hohmann transfer involved, but you need to escape Gilly’s SOI first, and to do so in such a way that your excess velocity puts you on a Hohmann transfer to Eve.

Tab availability is situational. If you have two ships both orbiting the same body and one targets the other you’ll get the Target Relative Maneuvers tab for Vessels. This should work at any body including moons. If you target a celestial body that’s orbiting the same body you are then you’ll get theTRM tab for Celestials. If you’re orbiting a planet and target another planet you’ll get the Planet tab which gives you interplanetary transfers. You don’t get this at a moon, which may be frustrating or confusing, but again this is because the interplanetary transfer tools are not designed to get you out of a moons SOi, and then out of a planets SOI after that to put you on a transfer to your destination.

Your use case of moon to moon transfer (at Kerbin or Jool) is a good one. I’ll explore if interplanetary transfer code can be used for this since the situation is analogous