[1.12.x] Transfer Window Planner v1.8.0.0 (April 11)

[TriggerAu]

I feel that I should mention that upon attempting to download this file from KerbalStuff, Chrome tried to stop the download because it thought your mod was malware. You may want to get that checked.

Thanks, I've downloaded it today and no chrome malware warning. That thing is quite painful - it flagged KSP as malware last time round

How does this handle games with planet orbits that have been modified? Specifically I'm planning to put my entire game on a 23 degree inclination with hyperedit to simulate axial tilt, and I'm wondering if this tool will still function for the transfer burns to other planets.

All the math is done based on the obits in game, so it works with modded installs just fine. You should be all good

[Sharpy]

I wonder if it would be possible for the planner to generate a maneuver node for clicked point on the current orbit of the current vessel. And accept highly eccentric orbits too.

For example, my Duna mission is currently orbiting Minmus after refuelling there. The departure will be through Oberth maneuver with Kerbin flyby. The node is bound to be tricky and the burn even more so, as the craft is very large and powered by only four nukes.

[ebigunso]

Is it possible for this mod to give transfer windows (launch windows) for going to orbiting vessels?

I want to see exactly when I launch to get my stuff to the space station, since in RL you literally only have one second of launch window to get to the ISS so if you could get that kind of precision you save fuel right?

I'm sick of launching to find out the station has gone way ahead or way behind me. This also applies to landers meeting up with the mother ship in orbit.

[eddiew]

Remember that the ISS is on a heavily inclined orbit, so if you're ahead/behind in your schedule, you end up with a very expensive orbit adjustment. If your station is equatorial, as would be the default in KSP, it really doesn't matter; the launch cost will be the same, but the time until an efficient hohmann transfer to it will vary

(I don't think the tools exist to allow you to adjust your course as carefully as would be necessary to arrive at your station's altitude at the exact time the station does. It's very common to just loop a few orbits and transfer later.)

[Fyrem]

Thanks for the update, TriggerAu

[TriggerAu]

I wonder if it would be possible for the planner to generate a maneuver node for clicked point on the current orbit of the current vessel. And accept highly eccentric orbits too.

For example, my Duna mission is currently orbiting Minmus after refuelling there. The departure will be through Oberth maneuver with Kerbin flyby. The node is bound to be tricky and the burn even more so, as the craft is very large and powered by only four nukes.

Theoretically it would be possible, but the maths is beyond my ability sorry.

Is it possible for this mod to give transfer windows (launch windows) for going to orbiting vessels?

I want to see exactly when I launch to get my stuff to the space station, since in RL you literally only have one second of launch window to get to the ISS so if you could get that kind of precision you save fuel right?

I'm sick of launching to find out the station has gone way ahead or way behind me. This also applies to landers meeting up with the mother ship in orbit.

Sorry no. It works out the math between two bodies orbiting the same central one. As the landed vessel isnt orbiting so it cant work that out. The way I usually do those kind of launches is to time my launch for when the vessel is under the orbit path (I use KAC Launch Rendezvous alarm for that) and then use an orbit with a different eccentricity to catch/wait for the station, So one launch into the orbital plane for the station, and then its just time to wait for a rendezvous burn - you dont waste much fuel if any, and just need to wait for the distance to come in. Getting the vessel into the orbital plane of the target object is the key to saving fuel (thats my opinion anyways )

[thegreatgonz]

I'm getting some fairly sketchy results from this plugin. Here's an example: try plotting a transfer from Kerbin@80km to Duna with no insertion burn, with a time window of year 1 day 150-225, and a time of flight of 65-100 days. If your results match mine, you'll see delta-vs that never gets above 4000, whereas if you plot the same parameters in AlexMoon's launch window planner, the delta-vs get close to 10,000. Even the basic pattern of the porkchop plot is different: in the mod, the "stripes" go from top right to bottom left (shorter travel time requires less delta-v), but in AlexMoon's planner they go from top left to bottom right (shorter travel time requires more delta-v).

If I actually execute a burn using parameters from the mod in this region, the orbit I get doesn't take me anywhere close to Duna. The orbit does get me pretty close to infinity, though: it seems to be almost exactly parabolic, right on the threshold between elliptical and hyperbolic (this also plays havoc with the way KSP renders it, but that's a separate issue). This happens pretty consistently with all the solutions I've tried, and that seems awfully coincidental. My guess is that the mod's solver is for some reason unable to produce a hyperbolic trajectory, so when it gets a travel time/departure date combo that requires one, it just gets as close as it can with an elliptical trajectory.

[TriggerAu]

I'm getting some fairly sketchy results from this plugin. Here's an example: try plotting a transfer from Kerbin@80km to Duna with no insertion burn, with a time window of year 1 day 150-225, and a time of flight of 65-100 days. If your results match mine, you'll see delta-vs that never gets above 4000, whereas if you plot the same parameters in AlexMoon's launch window planner, the delta-vs get close to 10,000. Even the basic pattern of the porkchop plot is different: in the mod, the "stripes" go from top right to bottom left (shorter travel time requires less delta-v), but in AlexMoon's planner they go from top left to bottom right (shorter travel time requires more delta-v).

If I actually execute a burn using parameters from the mod in this region, the orbit I get doesn't take me anywhere close to Duna. The orbit does get me pretty close to infinity, though: it seems to be almost exactly parabolic, right on the threshold between elliptical and hyperbolic (this also plays havoc with the way KSP renders it, but that's a separate issue). This happens pretty consistently with all the solutions I've tried, and that seems awfully coincidental. My guess is that the mod's solver is for some reason unable to produce a hyperbolic trajectory, so when it gets a travel time/departure date combo that requires one, it just gets as close as it can with an elliptical trajectory.

The results are never exactly the same, but Alex is the author of the Lambert solver thats part of the plugin - the maths are a little above my head. The maths arent exactly the same though - but they are close. I ran both those scenarios with values in the web and plugin with results as below. I can see the diff in the plots, the diffs being in the more unusual places to burn as the input values here do give you a very fast flyby style intercept:

Adding a node at that best angle with that velocity change, and then dragging it slightly I get the below - which is pretty bang on hitting - leaving at 225, 100days travel and 2200m/s

Do the screens here match up with what you are seeing? and when you say the selected burn doesnt get you close, where on the porkchop is the value thats not working for you?

[ibanix]

Is there a way to get a display for ejection angle and phase angle for your target, in game? Because that's what I can never figure out.

[thegreatgonz]

Do the screens here match up with what you are seeing? and when you say the selected burn doesnt get you close, where on the porkchop is the value thats not working for you?

It looks like you've chosen a burn in a region where the two porkchop plots basically agree. The trouble comes where they disagree by large amounts (like, thousands of dV)-- try something near the bottom left corner, or anywhere below the top-left/bottom-right diagonal. Note that if you try to actually perform a burn in that region, I think you'll find that the plotted trajectory comes out looking really screwy, but I think that's an unrelated stock bug where it doesn't render near-parabolic trajectories very well. In any event, the path your craft actually follows is more sensible (in fact you can trace the correct trajectory with your mouse pointer by looking for where it highlights the "bubble" to add a new maneuver node). The closest-intercept markers look correct, although I haven't run a full mission to verify that, and they're far apart from each other.

[Red Iron Crown]

Is there a way to get a display for ejection angle and phase angle for your target, in game? Because that's what I can never figure out.

Kerbal Engineer Redux can provide both. PreciseNode will give you ejection angle of a node, and I believe Protarctor will give you phase angle (and possibly ejection angle, too, not sure).

[TriggerAu]

It looks like you've chosen a burn in a region where the two porkchop plots basically agree. The trouble comes where they disagree by large amounts (like, thousands of dV)-- try something near the bottom left corner, or anywhere below the top-left/bottom-right diagonal. Note that if you try to actually perform a burn in that region, I think you'll find that the plotted trajectory comes out looking really screwy, but I think that's an unrelated stock bug where it doesn't render near-parabolic trajectories very well. In any event, the path your craft actually follows is more sensible (in fact you can trace the correct trajectory with your mouse pointer by looking for where it highlights the "bubble" to add a new maneuver node). The closest-intercept markers look correct, although I haven't run a full mission to verify that, and they're far apart from each other.

Thanks thegreatgonz - love that screen name - I'll have a fiddle on that one tonight. I could see those variations, but was really testing the "best" dV value that both produce, I think once you get too far away from the optimum you are gonna struggle to place the node too with the precision the game allows as well. I'll see what I can do/find

- - - Updated - - -

Is there a way to get a display for ejection angle and phase angle for your target, in game? Because that's what I can never figure out.

RedIronCrowns suggestions are good ones. With the time you get from the plugin for when to have your ejection burn you can "see" the phase angle in game - the angle between the two planets using the "center" as the point. The phase angle one is always the hard one for me to visualise - I tend to use the diagrams here (http://ksp.olex.biz/) to get it straight in my head

[cantab]

Transfer Window Planner is good, but there's a couple of things I feel are missing from it.

Firstly, details of the transfer orbit. Alexmoon's planner gives that, TWP does not as far as I can tell. For me this is the important thing for a transfer. Exactly how you get into the transfer orbit doesn't matter, if you leave at the right time and aim for the given apo and peri round the Sun you'll get your transfer. For example if you want to leave Laythe, snag a slingshot off Tylo, and get to Kerbin Transfer Window Planner is never going to tell you the exact ejection burn from Laythe orbit but if you know the solar apo and peri you want you can work towards that.

Secondly, and adding more complexity, the ability to specify the inclination and longitude of the ascending node as well as the altitude of the parking orbit. Alexmoon's planner and TWP both assume an equatorial parking orbit and that's fine in the stock system, but in a system with inclination such as RSS or New Horizons it's plainly an inefficient way to go about things.

Thirdly, the ability to actually work out the ideal transfer orbit inclination. I'll grant that will add some considerable complexity. Perhaps one way to do it would be to minimise the normal component of the ejection burn.

[ibanix]

The planner appears to be giving me data that does not work correctly. See this screenshot:

(Ignore the bug with Precise Node reporting the year as '1' instead of '3'; the UTC is correct. I've reported the Precise Node bug.)

[ibanix]

So I tried this on a different install of KSP, and still got the same answers which when plugged into the game, do not result in an intercept.

Is anyone else having this problem?

[ibanix]

It turns out that you can not use the time given as an exact time. The angle of ejection will be wrong.

If I take the time given, plug that in, and then adjust to the correct angle of ejection by moving the node, I can get to interception. But the time will be off by up to 1/2 of your initial orbit time.

[Gaarst]

The ejection angle shown in your precise node manoeuvre is 83.2º to prograde (heading 0.31º north) while the transfer manoeuvre mentions an ejection angle of 129.38º (heading 85.34º).

If you set your manoeuvre angle correctly I'm pretty sure you'll get an encounter (or at least get closer to one).

Edit: ninja'd

[TriggerAu]

So I tried this on a different install of KSP, and still got the same answers which when plugged into the game, do not result in an intercept.

Is anyone else having this problem?

Hi Ibanix,

The "challenge" here is the the UT for departure is the best time from the perspective of the Origin Planet and not necessarily the position of the specific vessel with respect to the time to leave. What this means is that the values there should give you a very intercept for an exactly circular orbit at the time when the phase angle matches.

The way I use this is to set the burns prograde and normal dV and then move it around the orbit till the path is on the money - usually there is a little fiddling as a circular orbit is pretty much impossible to get

Give that method a go and see how you do

[01010101lzy]

Does this use the ecliptic plane or the equator plane to calculate the transfers? (from a user in RSS)

[TriggerAu]

Does this use the ecliptic plane or the equator plane to calculate the transfers? (from a user in RSS)

If I understand the maths correctly its the ecliptic plane, but I havent played with it in RSS in a long time to review that one

[01010101lzy]

If I understand the maths correctly its the ecliptic plane, but I havent played with it in RSS in a long time to review that one

Thanks. It's just a little bit difficult to calculate what the target orbit's inclination and Argument of Periapsis is when I want to launch into the right ejection orbit in RSS...

What I need to calculate: (Bad drawing skills...)

And the ejection stats...

-update-

And, well, I found that the forth 'maybe' feature you have written down in the early posts haven't been created yet... Which is, creating manuver nodes automatically...

Edited October 11, 2015 by 01010101lzy

[JT2227]

No matter what I do, I can't get a transfer window to Mars in RSS with the information given. When I try to set an intercept to mars, the intercept is either away from mars by 10 degrees or so of Mars' orbit, is more than 100 days longer than planned, or requires ridiculously long braking burns at Mars. Any tips?

[TriggerAu]

v1.4.0.0 Now Available 

Download from GitHub or Download from Curse or Download from KerbalStuff

Here's the usual list of stuff:

• adjusted angle names, etc to make em consistent - to retrograde, to prograde, etc
• fixed issues with log spam and map view (Issue #35)
• fixed issue with KACAlarms and margins (Issue #38)
• Added new Angle Renderer to display phase and ejection angles

This biggest thing here is the angle display component. I've hopefully explained it sufficiently in here:

 

 

 

 

[Speadge]

its just Dec 2nd; not 3rd

[theJesuit]

19 minutes ago, Speadge said:

its just Dec 2nd; not 3rd

Not in my part of the world.

Peace.