triggerau / transferwindowplanner Goto Github PK

It is very difficult to use this map on a 4K screen as the mod does not scale with the KSP-wide UI scaling option. Please add a UI scaler or just scale the UI to the same value set in KSP settings.

Need this so I can get the details of the ejection and injection burns for the details

One thing that I would like to see is an option for the "Add KAC Alarm" button to create (2) alarms instead of just one. These two alarms would define the start/end of the transfer window instead of just the selected point in time. They should be the earliest or latest departure times, with identical travel duration, less then 102% of the chosen point in time's dV.

So if I pick a point with 3025 dV, I'd want to see the earliest and latest that I can leave for for 3055 dV (1% more) before/after that point in time.

http://forum.kerbalspaceprogram.com/index.php?/topic/84005-10x-transfer-window-planner-v1400-dec-3/&do=findComment&comment=2310719

F2 toggle removes slow down

Look in the DrawGUI routine

The default for the origin planet is the 3rd planet, so if Kopernicus adds a planet closer to the sun than Kerbin, the default selection will change. Eg if there's one new planet closer to the sun than Eve, Eve will be the default selection. Maybe a dropdown list in settings to select the default origin would be good? Or even just a line in the settings.cfg to change it, doesn't need an in-game GUI really.

Time Entry draw Routines

http://forum.kerbalspaceprogram.com/threads/93115-0-90-Transfer-Window-Planner-v1-1-3-0-%28Dec-20%29?p=1619794&viewfull=1#post1619794

http://forum.kerbalspaceprogram.com/index.php?/topic/131381-requestidea-kerbal-training-and-other-time-based-kerbal-mechanics/#comment-2395559

When end departure window is hidden then adjust the end date based on departure start and the calculated range

When we're doing pre-calculations of gravity assists with bi-impulse transfers, we will need this solution of transfer to minimize the insertion burn, cuz depature burn (from the last intermediate planet) can be get from various ways as relative speed lmao
For example, recently plotting a KEKKJ-Dres solution and we can get literally any speed from jool via various boosts of Tylo and laythe. So I need to figure out what is the smallest Dres insertion burn with any speed from Jool......

I think it would be useful to toggle the view so that you could see a plot of arrival date versus departure date instead of just travel time versus departure date.

When I send Jeb out there, sometimes I want to know what's the cheapest to get him there the soonest, and the current plot can sometimes be hard to figure that out.

Plot would be like these NASA plots: https://en.wikipedia.org/wiki/Porkchop_plot#/media/File:Porkchop_plot.gif

for travel and return
Travel out
Period of Stay
Travel back

Pressing escape, F3, or when any other unity box pops up also brings up the transfer window.

Folks noticed this when using Alien Space Programs to relocate the KSC to Laythe, but this happens on an otherwise stock game as well, with only Transfer Window Planner installed.

Plots from Laythe to other Jool moons look correct, and plotting from Vall back to Laythe looks correct too.

[After checking Alexmoon's tool] The original tool puts this large gray area in the middle of the plot, with the optimal areas just to the edge of that gray area. Maybe the original code has this problem too.

It's been brought up and resolved in at least one of your other mods (e.g. Kerbal Alarm Clock), but I want to bring this one to your attention, since TWP stores the date when it checks a version, which changes once a day and forces Module Manager to reload the entire patching process during game start.

Show it in the right pane, when you click plot, it then hides em with an icon in the top right

Create a man Node from selected Transfer

Needs to find place on current vessels orbit around time of transfer when ejection angle matches

I'm looking to play with the 'develop' branch, I'm wondering if you have cmake files anywhere or build instructins I could use.

Cheers

They are confusing

In order to have a good reason to do a 1.9+ recompile, could you confirm that TWP is currently handling Hohmann transfert in the same way the original Alexmoon webapp, and that the following PR for it:

alexmoon/ksp#27

couldn't also apply to TWP ?

http://forum.kerbalspaceprogram.com/threads/93115-0-90-Transfer-Window-Planner-v1-2-3-0-%28Jan-11%29?p=1669093&viewfull=1#post1669093

Trying to run the test cases. Get this error message:

Whenever a new planet is selected, this happens:

_[EXC 18:41:33.852] NullReferenceException: Object reference not set to an instance of an object
TransferWindowPlanner.TWPWindow.HideAngles ()
TransferWindowPlanner.TWPWindow.ddlDestination_OnSelectionChanged (KSPPluginFramework.DropDownList sender, Int32 OldIndex, Int32 NewIndex)
KSPPluginFramework.MonoBehaviourWindowPlus+DropDownList.DrawBlockingSelector ()
KSPPluginFramework.MonoBehaviourWindowPlus+DropDownListManager.DrawBlockingSelectors ()
KSPPluginFramework.MonoBehaviourWindowPlus.DrawWindowPre (Int32 id)
KSPPluginFramework.MonoBehaviourWindow.DrawWindowInternal (Int32 id)
UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, Int32 instanceID, UnityEngine.GUISkin skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
[LOG 18:41:39.487] 6/12/2019 6:41:39 PM,TransferWindowPlanner,Generating DeltaV Values
[LOG 18:41:39.751] 6/12/2019 6:41:39 PM,TransferWindowPlanner,Working out Log Values to determine DeltaV->Color Mapping
[LOG 18:41:39.753] 6/12/2019 6:41:39 PM,TransferWindowPlanner,Generating DeltaV Color Palette
[LOG 18:41:39.753] 6/12/2019 6:41:39 PM,TransferWindowPlanner,Placing ColorIndexes in array
[LOG 18:41:39.756] 6/12/2019 6:41:39 PM,TransferWindowPlanner,5.7695243002966
[LOG 18:41:39.756] 6/12/2019 6:41:39 PM,TransferWindowPlanner,ERROR: Background Worker Failed
Object reference not set to an instance of an object
at TransferWindowPlanner.TWPWindow.SetTransferDetails () [0x00000] in :0
at TransferWindowPlanner.TWPWindow.bw_GeneratePorkchop (System.Object sender, System.ComponentModel.DoWorkEventArgs e) [0x00000] in :0
[LOG 18:41:39.818] 6/12/2019 6:41:39 PM,TransferWindowPlanner,Placing Colors on texture-292x292

KSP.log

Is 1.3.1 compatibility coming in future?

Playing with Galileos Planet Pack, TWP works fine for a few hours of game uptime, but after a while I tried to plot a new transfer, and KSP crashed.

Crash_2022-04-15_094442860.zip

TWP seems to only offer ballistic transfers, why one can be preferable over the other is explained here:

It all depends on how expensive it is to do the plane change required to intercept your target. The two factors that go into determining how expensive the plane change is are:

• The delta-v required for a plane change is directly related to your orbital velocity. So if you're in an eccentric orbit, the closer you are to apoapsis the cheaper it is.

• The delta-v is also related to the sine of the half angle of the inclination change you need to make. Your inclination change is smallest if you change your plane 90 degrees before intercept and increases to 90 degrees if you wait until you're directly "under" your intercept point before making your plane change maneuver.

So for a transfer to an outer planet the mid-course strategy works to find the point at which the decreasing delta-v because you are getting farther from the sun starts to get counteracted by the increasing delta-v as the angle you have to achieve increases towards 90 degrees.

Now, when you're doing a ballistic transfer the raw delta-v for the inclination change is probably a lot higher than the inclination change delta-v for the mid-course strategy. For one thing, your orbital velocity around Kerbin is probably pretty high, and for another to shift your transfer orbit by a degree might take several degrees of inclination change to your ejection orbit (compare your ejection orbit inclination with your transfer orbit inclination to see what I mean). Both of those factors would seem to suggest that the mid-course plane change should always be better. However, there is one big factor in the ballistic strategy's favor and that is the law of cosines.

What the law of cosines says is that if you combine two maneuvers into one you don't have to spend the sum of their delta-v's, instead it's related to the square root of the sum of their squares and the cosine of the angle between them (for a 90 degree angle, this is just the pythagorean theorem). So if we combine our ejection burn with the plane change burn the net delta-v becomes: sqrt(v0^2 + (v0 + dv[ejection])^2 - 2v0(v0 + dv[ejection])*cos(angle)).

For a typical Duna transfer, the ejection delta-v without any plane change is about 1040 m/s. To do a ballistic transfer takes about a 2 degree ejection inclination in order to get about a 0.1 degree transfer inclination. Doing the plane change alone in a 100km Kerbin orbit (which has an orbital velocity of about 2250 m/s) would take about 80 m/s. Plugging into the formula we get sqrt(2250^2 + 3290^2 - 2 * 2250 * 3290 * cos(2)) = 1044 m/s. So by combining the maneuvers we get to do an 80 m/s plane change maneuver for only 4 m/s more than the ejection would otherwise take.

TL;DR: It works out that for transfers outer planets with small inclination changes and for transfers to inner planets with moderate inclination changes the ballistic transfer tends to be cheaper because the benefits from combining the maneuvers outweigh the cost of doing the plane change at a less optimal time. However for transfers to outer planets with significant inclination changes or transfers to inner planets with extreme inclination changes the benefits of a cheaper plane change exceed the benefit from combining maneuvers.
Like

https://forum.kerbalspaceprogram.com/index.php?/topic/30367-web-app-launch-window-planner/&do=findComment&comment=516122

edit: fixed the dead link

Set to shipcontrols, not all

When creating a Kerbal Alarm Clock alarm from the transfer window planner, the configured margin is applied in the wrong direction.

I.e. if the calculated departure is in 150 days and I configure a margin of 10 days (60 hours), the time to alarm will always be 150 days (i.e. directly at the departure time, no matter how the margin was configured) and the time to event is reported as 160 days (departure plus margin, i.e. 10 days too late).

Time to alarm should be 140 days (departure minus margin) and time to event 150 days instead.

Edit: Transfer Window Planner v1.3.1.0 and Kerbal Alarm Clock v3.4.0.0 installed via CKAN on KSP 1.0.5 Linux amd64

Phase Angle and Ejection Angle

use current date instead of 1y 1d as the default value for earliest departure time

• New Axis texture - White based
• Color Palette - build in game
• Selected Transfer indicator - Circle/target
• On Mouse over axis - whiteish cross that moves

The dropdown menu has a bad clickthrough. Can't select the items from the menu without carefull mouse placement.