Flight Plan [0.10.7 for KSP2 v0.2.2+]

[dmsilev]

A few degrees worth, so not a huge amount of dv. The real advantage was that the timing worked out to be able to use a Tylo flyby to take care of the vast majority of the cost of insertion into the Jool system.

[stephensmat]

Interplanetary Transfer isn't working for me , but I don't know if it's the mod, or the base game. I had FP calculate a transfer to Duna, and the calculation was done, but when I tell it to make the burn, no maneuver node appears on the 'ball', and there's no burn.

(I also use K2D2 and Alarm Clock, if that makes a difference. I was using both to get to the transfer window, and direct it to make the burn.)

Edited January 22 by stephensmat

[jinvenzo]

Hi!! In the "main menu" of Flight Plan I can't switch from Celestial to Vassel in order to make an intercept. Tried with the vassel target marked as target..

 

Edit.. Selecting the target i bypassed that problem...

 

Edited January 22 by jinvenzo

[schlosrat]

7 hours ago, stephensmat said:

Interplanetary Transfer isn't working for me , but I don't know if it's the mod, or the base game. I had FP calculate a transfer to Duna, and the calculation was done, but when I tell it to make the burn, no maneuver node appears on the 'ball', and there's no burn.

(I also use K2D2 and Alarm Clock, if that makes a difference. I was using both to get to the transfer window, and direct it to make the burn.)

If you're following the procedure I've posted above with the example for Jool then it should be working. Unfortunately, the procedure is a bit more complex than just selecting a body and asking for anode, but FP should give you a node to work with that you should be able to fine-tune with MNC. In some cases, the procedure above can give a node that results in an encounter straight away, but in any case, if you follow the procedure above I think you should be able to get a node that you can use MNC to fine-tune for a better encounter.

When you say "I had FP calculate a transfer to Duna" can you elaborate on this part? Obviously, Duna had to be selected as a target or you would not have been able to get to the tab with the Interplanetary Transfer button.

When was FP indicating the next transfer window would be? With the current version of FP I recommend time warping to just before the window so that FP will be telling you the next window is ~1 day away or less. If you overshoot a little that should not be a problem, but being just a day away from the window should work.

Which burn option did you select? I recommend using "as soon as possible" in conjunction with time warping to just before the transfer window.

What message did FP display as a status for you after you clicked "Make Node"?

Did you get a Burn Timer display above your time warp bar in the game's GUI?

If the start time for the burn is in the past, then K2D2 will not want to execute the node. In such cases, you may be able to use MNC (or other means) to move the time for the node so that it's in the future and then K2D2 will be willing to execute it. I also highly recommend using MNC to fine-tune the node by watching for the encounter in Map View. Once you've got an encounter, MNC is great for tweaking the node so the predicted encounter is to your liking.

[stephensmat]

13 hours ago, schlosrat said:

If you're following the procedure I've posted above with the example for Jool then it should be working. Unfortunately, the procedure is a bit more complex than just selecting a body and asking for anode, but FP should give you a node to work with that you should be able to fine-tune with MNC. In some cases, the procedure above can give a node that results in an encounter straight away, but in any case, if you follow the procedure above I think you should be able to get a node that you can use MNC to fine-tune for a better encounter.

I tried again after a restart, and this time the burn happened as planned. Currently tinkering with course corrections to get me into a good orbit of Duna.

[Rezania]

Love the mod, really a peak QOL feature that should be available in the base game honestly.

I do have an issue though, for a few days the timers for transfer windows are counting up instead of down. This is for targeting vessels, planets and moons. It wasn't a problem while staying in the Kerbin system, but when going interplanetary it is a bit difficult.

[schlosrat]

19 hours ago, Rezania said:

Love the mod, really a peak QOL feature that should be available in the base game honestly.

I do have an issue though, for a few days the timers for transfer windows are counting up instead of down. This is for targeting vessels, planets and moons. It wasn't a problem while staying in the Kerbin system, but when going interplanetary it is a bit difficult.

Thanks for the feedback! I’m glad you’re enjoying the mod.

I’ve not yet observed the transfer window counting up instead of down. I’ll need to be able to reproduce this at my end to be able to run it to ground. Can you offer any info on the sorts of situations where you’ve observed this?

when I think of transfer window this is only associated with transfer to a planet from another planet so I’m a bit confused about how this relates to moons or vessels targeted. Those can have an optimal time for a Hohmann transfer but they don’t have a transfer window time displayed in FP. Can you clarify what you were seeing for that? Any info may help

[dmsilev]

2 hours ago, schlosrat said:

when I think of transfer window this is only associated with transfer to a planet from another planet so I’m a bit confused about how this relates to moons or vessels targeted

At least for moons, that can make sense. Consider going from Minmus to the Mun, or between moons in the Jool system. That's functionally the same as transferring between planets, and indeed in KSP1, the MechJeb transfer planning code handled the inter-moon case as well. Timescales are shorter since the relevant period is the month rather than the year, but that's about it. 

[schlosrat]

10 hours ago, dmsilev said:

At least for moons, that can make sense. Consider going from Minmus to the Mun, or between moons in the Jool system. That's functionally the same as transferring between planets, and indeed in KSP1, the MechJeb transfer planning code handled the inter-moon case as well. Timescales are shorter since the relevant period is the month rather than the year, but that's about it. 

FP doesn't give you this option. The math may be fundamentally the same, but the UI simply doesn't give this option so you can't get this from it. The logic governing which tabs are available has to do with what sort of body you're orbiting and what sort of object (if any) you're targeting. The only way to get the Moon tab is to be orbiting a moon - and that tab only has one maneuver on it - Return from Moon. If you're at a planet and select one of its moons, then that tab (Target Relative Maneuvers: Celestial) will show you a Next Window. If you're at a planet and have another planet selected, then you can get to the Orbital Transfer Maneuvers: Planet tab and it too will display Next Window info.

The time displayed for Next Window is being dynamically recalculated and updated. I've only ever seen it decrease, but then I've not been watching for this.

[Rezania]

 

On 1/25/2024 at 2:24 PM, schlosrat said:

Thanks for the feedback! I’m glad you’re enjoying the mod.

I’ve not yet observed the transfer window counting up instead of down. I’ll need to be able to reproduce this at my end to be able to run it to ground. Can you offer any info on the sorts of situations where you’ve observed this?

when I think of transfer window this is only associated with transfer to a planet from another planet so I’m a bit confused about how this relates to moons or vessels targeted. Those can have an optimal time for a Hohmann transfer but they don’t have a transfer window time displayed in FP. Can you clarify what you were seeing for that? Any info may help

 

Ah yes, my bad, it's not a transfer window in the proper sense if you target a vessel or moon yes. Although, you're still going from one orbit to another, so in my mind it's all the same.

I just tested it with a fresh install of Flight Plan and its dependencies. Fresh campaign as well. I build a rocket, went to the launch pad, brought up Flight Plan, target Moho, transfer window timer is counting up. It continues counting up when I'm in orbit around Kerbin or Kerbol as well.

Think it might have something to do with what kind of orbit you're in. I'm in an orbit around Kerbol between Kerbin and Duna. The timer to Moho and Eve are counting down, the timers to Kerbin and Duna are barely moving, and the timers to Dres, Jool and Eelo are counting up. The strange thing is, the timers also don't seem to be consistent in their counting up or down, some are faster than others.

Edited January 26 by Rezania

[schlosrat]

22 hours ago, Rezania said:

 I just tested it with a fresh install of Flight Plan and its dependencies. Fresh campaign as well. I build a rocket, went to the launch pad, brought up Flight Plan, target Moho, transfer window timer is counting up. It continues counting up when I'm in orbit around Kerbin or Kerbol as well.

Think it might have something to do with what kind of orbit you're in. I'm in an orbit around Kerbol between Kerbin and Duna. The timer to Moho and Eve are counting down, the timers to Kerbin and Duna are barely moving, and the timers to Dres, Jool and Eelo are counting up. The strange thing is, the timers also don't seem to be consistent in their counting up or down, some are faster than others.

Thanks for the elaboration. This is helpful, and I've been able to confirm your observations.

For Moho targeted from the pad, Next Window was monotonically increasing at a rate of about 0.5s per second of game time. In LKO it's also increasing at about the same rate.

When I teleport that vessel to a low orbit around Kerbol (well inside Moho's orbit), then the time for the Next Window is counting down at about 1 s per second of game time. but when I teleport to an orbit that's between Moho and Eve it's counting up again.

In the orbit between Moho and Eve, when targeting Eve, the time in Next Window is counting down as it should be.

So, the effect we're observing is that if you're in an inferior orbit (lower than the orbit of your target) then the time counts down, and if you're in a superior orbit (higher than the orbit of your target) then the time counts up.

I'm looking at the code now to see if I can work out why this is.

UPDATE: I believe I've found and fixed the issue. I will need to release updated versions of both Flight Plan and Node Manager as part of the issue was there as well.

Edited January 27 by schlosrat

[laotumsn]

I'm having some problems:
After I set the maneuver points, I click on the k2d2 icon to start the execution, and everything works fine, but when it's time to execute, the rocket engine doesn't work automatically, and at the bottom of the Flight Plan UI, it says "K2D2:Turning:" Everything seems to change to a manual operation.

This usually happens after deleting a maneuver point and resetting other maneuver points.

[schlosrat]

Updated to 0.10.0

• Updated to the latest mod template for better development and maintainability.
• Added fonts to the asset bundle in preparation for localization work - this makes the size of the download much bigger, but does not affect performance in the game otherwise and will enable localized versions of FP in the future.
• Corrected issue with calculation of the next transfer window time where the time to go was not computed correctly for transfers to orbits lower than the originating orbit.

Note: this update requires you also update Node Manager to 0.7.2+ if you want to get the corrected Next Window calculations. In all other respects, it's compatible with NM 0.7.1

GitHub: https://github.com/schlosrat/FlightPlan/releases/tag/0.10.0

SpaceDock: https://spacedock.info/mod/3359/Flight Plan

Edited January 28 by schlosrat
Added download links

[schlosrat]

Updated to 0.10.1

• Added Click-through Blocking

GitHub: https://github.com/schlosrat/FlightPlan/releases/tag/0.10.1

Edited February 3 by schlosrat

[Poppa Wheelie]

Thank you for this mod!  And for the combination of Flight Plan, Maneuver Node Controller, and K2-D2.  I use these all the time.

I've noticed one issue with Flight Plan and/or Maneuver Node Controller:

If I create a node, then load a save previous to this node creation, Flight Plan and Maneuver Node Controller still have a node.

Also for Flight Plan:

When Flight Plan creates a node to do something at a particular point (eg, Circularize at the next Ap), the node is created right on the Ap, which will not result in the most circular orbit (possibly with the Pe still in atmosphere).  When I look at the expected future results in a case like this, I do not see a circular orbit.

In these cases, I manually adjust the created node, by walking backwards in time to find the "best" circularization.  Could this feature of placing nodes directly on specified points be updated?  I think that in every case, we don't really want the resulting node to begin its burn directly on the selected point.

[schlosrat]

8 hours ago, Poppa Wheelie said:

Thank you for this mod!  And for the combination of Flight Plan, Maneuver Node Controller, and K2-D2.  I use these all the time.

I've noticed one issue with Flight Plan and/or Maneuver Node Controller:

If I create a node, then load a save previous to this node creation, Flight Plan and Maneuver Node Controller still have a node.

Also for Flight Plan:

When Flight Plan creates a node to do something at a particular point (eg, Circularize at the next Ap), the node is created right on the Ap, which will not result in the most circular orbit (possibly with the Pe still in atmosphere).  When I look at the expected future results in a case like this, I do not see a circular orbit.

In these cases, I manually adjust the created node, by walking backwards in time to find the "best" circularization.  Could this feature of placing nodes directly on specified points be updated?  I think that in every case, we don't really want the resulting node to begin its burn directly on the selected point.

Thanks for the feedback. I'm glad you're finding these mods useful!

The first problem is actually in Node Manager - which is a mod FP and MNC depend on that runs in the background. It's maintaining a list of nodes, and apparently, this is not being cleared and reset when you load a save - hence the stale info from before. I'll get to work on this as it clearly should be handling this more gracefully. Once fixed in NM, the problem should vanish in FP and MNC.

For the second problem, I may need a bit more info, and it also may help if I cast a bit more light on what FP is really doing. I'll start with the latter.

tl/dr: FP is already backing the node off to make it star before the actual point you want the burn to be centered on.

When FP creates a node it does base the *initial* position of the node on orbital mechanics equations that assume the burn is an instantaneous impulse. This is part of the MechJeb heritage and has the virtue that the equations are well-known and not hard to model. However, KSP2 handles burns a bit differently than KSP1, so FP carries on to adjust the time of the node, and consequently the direction of the node so that it will instead start earlier by 1/2 the burn duration. This is a two-putt approach because to get the burn time we must first *create* the node and let the game work out how long the burn needs to be for that craft to get that delta v. So, create the node, get the burn duration, back the node start time off by 1/2 the duration, and then (crucially it turns out) adjust the direction of the node.

The crucial node direction adjustment is most apparent in the circularize after ascent problem. The thing here is that burn vectors are in Prograde, Normal, and Radial, and when you back a node off it will be at an earlier part of the trajectory where the prograde and radial vectors were very likely pointed in a different direction, so FP does a little math to make sure that the node, when positioned at an earlier time, has new P/N/R components that will point in the same direction the original non-adjusted node would have.

Hopefully, that makes sense - now on to the request for more info!

In the example you're using are you basing this on a very steep ascent profile? By steep, I mean one where you've begun your turn quite high and late in the ascent and so arrive at the Ap with not much horizontal velocity. If so, then I have your answer, but if not then I'll need more detail about the example problem so I can try to reproduce it and see what FP may need to do. What type of trajectory are you starting with: suborbital or orbital? for the initial orbit, what are the Ap and Pe?

If you are talking about the problem of circularizing after a very steep ascent trajectory, then here's my answer.

In such cases, particularly when the Ap is not all that far outside of the atmosphere, you can get into a situation where the node FP gives is not ideal.  This is because such a trajectory is developing very little horizontal velocity resulting in needing a much longer circularization burn, and this is coupled with a more tightly turning prograde vector at the Ap of the suborbital trajectory. The solution to this is to fly a better ascent profile where you begin the turn earlier and arrive at the Ap with more horizontal velocity. That's more efficient, too. Alternatively, you can use MNC to make precision adjustments to the node, which you can even do with the game paused! So if you prefer the steeper inefficient trajectory, then as soon as you've got a circularization node from FP, press pause and bring up MNC. Now you'll be able to make very precise adjustments without worrying that your Ap is getting closer by the second, and when you un-pause you'll have a node to get the orbit you want.

[schlosrat]

12 hours ago, Poppa Wheelie said:

Thank you for this mod!  And for the combination of Flight Plan, Maneuver Node Controller, and K2-D2.  I use these all the time.

I've noticed one issue with Flight Plan and/or Maneuver Node Controller:

If I create a node, then load a save previous to this node creation, Flight Plan and Maneuver Node Controller still have a node.

Node Manager has been updated to 0.7.3 which should correct the issue of stale node info remaining from a previous session when you load a different save. This does not address FP starting raised in the new session with the previous tab and maneuver type already selected from the previous session. That will necessitate an update to FP, which is forthcoming.

https://spacedock.info/mod/3366/Node Manager

https://github.com/schlosrat/NodeManager/releases/tag/0.7.3

[Poppa Wheelie]

3 hours ago, schlosrat said:

you can use MNC to make precision adjustments to the node, which you can even do with the game paused!

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.

[Aerius]

Hi!

I like the tool, it's great to avoid Try&Errors with the current KSP2 UI.
It's working great with basic maneuver and rended-vous.

I dont know if it's a bug or some corruption on my side : On the last versions, when I'm planing a interplanetary transfert, the maneuver time is  not matching the next windows.

Here is a screenshot :

I just created a Transfert Maneuver to Moho.
Next Window to Moho is in 11 days.
The freshly Interplanetary Transfert node created is in 90 days.
It's not working to intersect Moho, as displayed on the map.

It's the same for all planets.

I manually tested the maneuver at the suggested "Next Window" for Duna :  timing is accurate and recreating a similar maneuver is a valid transfert solution.

I watched the tutorial video, I don't think I'm doing anything wrong : take-off, circularisation, target selection, creating a Interplanetary transfert.

I'm using the 1.10.1 version of the mod. I think the issue appeared with the 1.10.0.1 version or KSP2 patch 0.2.1.0.

Before those versions, I precreated the same  interplanetary maneuver to Moho .
The solution was valid but I didn't executed the maneuver
I saved the game, Few days passed, KSP2 patch 0.2.1.0 update came, with Flight Plan 1.10.0.1.
When I reloaded the starship, the nod had a 0 dV. I recreated the maneuver and noticed the date was totally off compared to the previous planning.

Is it a known issue?

[schlosrat]

11 hours ago, Aerius said:

Hi!

I like the tool, it's great to avoid Try&Errors with the current KSP2 UI.
It's working great with basic maneuver and rended-vous.

I dont know if it's a bug or some corruption on my side : On the last versions, when I'm planing a interplanetary transfert, the maneuver time is  not matching the next windows.

Here is a screenshot :

I just created a Transfert Maneuver to Moho.
Next Window to Moho is in 11 days.
The freshly Interplanetary Transfert node created is in 90 days.
It's not working to intersect Moho, as displayed on the map.

It's the same for all planets.

…

Is it a known issue?

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. 

 

Hmmm… That forum link doesn’t seem to be working correctly when I test it. Go back to page 7 on this thread and look for some long posts from me on 1/21 with a lot of pictures. That will show you the workaround

Update for version 0.10.2

• Fixed issue where Flight Plan would retain settings from a previous session after loading a new game session

SpaceDock: https://spacedock.info/mod/3359/Flight Plan

[Redacted]

Seeing the following error just recently during re-install: 

"CKAN.InvalidModuleFileKraken: FlightPlan 0.10.2: C:\Users\1Smug_stand-up guy\AppData\Local\CKAN\downloads\downloading\B8934B49-FlightPlan-0.10.2.zip has SHA1 0BBDC9A7D9FB356D139FF7FCE5D0E4009BA91DA7, should be 07737EEE69A10698037C3DF4B1DEAC1B84AC1284
   at CKAN.NetModuleCache.Store(CkanModule module, String path, IProgress`1 progress, String description, Boolean move, CancellationToken cancelToken)
   at CKAN.NetAsyncModulesDownloader.ModuleDownloadComplete(Uri url, String filename, Exception error, String etag)"

After dismissing the notification, I can either retry or skip. With retrying looping back to the original message.

 

Note using CKAN 1.34.4 and current KSP2 science release. With mods, BepInEx, SpaceWarp,UTIK for KSP2, Maneuver Node Controller, Node Manager,

Edited February 5 by Redacted

[jinvenzo]

31 minutes ago, Redacted said:

Seeing the following error just recently during re-install: 

"CKAN.InvalidModuleFileKraken: FlightPlan 0.10.2: C:\Users\1Smug_stand-up guy\AppData\Local\CKAN\downloads\downloading\B8934B49-FlightPlan-0.10.2.zip has SHA1 0BBDC9A7D9FB356D139FF7FCE5D0E4009BA91DA7, should be 07737EEE69A10698037C3DF4B1DEAC1B84AC1284
   at CKAN.NetModuleCache.Store(CkanModule module, String path, IProgress`1 progress, String description, Boolean move, CancellationToken cancelToken)
   at CKAN.NetAsyncModulesDownloader.ModuleDownloadComplete(Uri url, String filename, Exception error, String etag)"

After dismissing the notification, I can either retry or skip. With retrying looping back to the original message.

 

Note using CKAN 1.34.4 and current KSP2 science release. With mods, BepInEx, SpaceWarp,UTIK for KSP2, Maneuver Node Controller, Node Manager,

Same error and same mods...........

[-dbv-]

Same for me - Deleting and reinstalling leads to the same message.

[Mach1av3ll1]

Temporary workaround I found is to switch to mod version 0.10.1 in CKAN, that downloads correctly it seems.

[schlosrat]

2 hours ago, jinvenzo said:

Same error and same mods...........

 

2 hours ago, -dbv- said:

Same for me - Deleting and reinstalling leads to the same message.

 

3 hours ago, Redacted said:

Seeing the following error just recently during re-install: 

"CKAN.InvalidModuleFileKraken: FlightPlan 0.10.2: C:\Users\1Smug_stand-up guy\AppData\Local\CKAN\downloads\downloading\B8934B49-FlightPlan-0.10.2.zip has SHA1 0BBDC9A7D9FB356D139FF7FCE5D0E4009BA91DA7, should be 07737EEE69A10698037C3DF4B1DEAC1B84AC1284
   at CKAN.NetModuleCache.Store(CkanModule module, String path, IProgress`1 progress, String description, Boolean move, CancellationToken cancelToken)
   at CKAN.NetAsyncModulesDownloader.ModuleDownloadComplete(Uri url, String filename, Exception error, String etag)"

After dismissing the notification, I can either retry or skip. With retrying looping back to the original message.

 

Note using CKAN 1.34.4 and current KSP2 science release. With mods, BepInEx, SpaceWarp,UTIK for KSP2, Maneuver Node Controller, Node Manager,

Yes, I've confirmed this issue. It relates to a problem I encountered last night with GitHub, and now CKAN is confused about what to expect for the hash. The file is actually OK, but CKAN has no way to know this. You can download the file manually from GH or from SpaceDock and install it easily if you're comfortable with that process. I've been working for a bit on this, and it's beginning to look like the only way I can get CKAN to be happy is if I release a new version of the mod. I don't like doing that when there are no functional changes, but I do want people to be able to install using CKAN, so...

Stand by and expect a FP 0.10.2.0, or something foolishly named like that.