Best Way to Integrate Transfer Windows into Existing KSP GUI/Environment

[arkie87]

This form is to compile suggestions i've come up with for integrating transfer windows into KSP GUI/Environment.

I am a fan of intelligently integrating features into the current KSP GUI/Environment. The best example of a plugin that integrates perfectly into KSP GUI environment is a mod called "landing height." When landing, you obviously are more concerned with height above ground than height above sea level. However, in stock KSP, altimeter always shows height above sea level (in IVA mode, altimeter shows height above surface, but this view is less helpful when landing). You could use Kerbal Engineer (or numerous other plugins), which would display height above ground (in addition to height above sea level); however, a better approach to integrate better into the game is that when navball is in "surface mode" altitude displayed on altimeter is height above ground, whereas when navball is in "orbital" mode, altitude is above sea level, and the "landing height" plugin does this exactly ( http://forum.kerbalspaceprogram.com/threads/76320 ).

So in keeping with the theme of "intelligently integrating features into KSP GUI/Environment, I have two suggestions for integrating transfer windows:

For players who just want to be told the information (possibly enabled/disabled via difficulty settings):

The transfer window should be shown in map view as a (purple?) dotted line. This functionality should be activated only when an applicable object is targeted using KSP targeting feature. Only showing one transfer window prevents clutter in map view and integrates nicely into existing KSP functionality.

For players who prefer to have the tools needed to easily find the transfer window on their own:

An automatic toggle in map view to switch the reference body used to draw the orbital trajectory should be created. For instance, if you are orbiting Kerbin, it shows you trajectory around Kerbin (and you can click on it to add maneuver nodes). When you zoom out far enough such that this trajectory is no longer visible, it automatically toggles to show your trajectory around Kerbol instead, and you can click on this trajectory and add maneuver nodes. You can then use maneuver nodes showing trajectory around Kerbol to find optimum transfer window on your own, since you can slide maneuver node along the orbit around kerbol.

Note: I am aware that when displaying trajectory around Kerbol whilst orbiting Kerbin, the trajectory would technically be helical; however, for the purposes of the drawing and simplicity, it can just take the trajectory of the body it is orbiting i.e. Kerbin.

Thought? Additional/Better Suggestions?

[JimmyAgent007]

Id stay away from colours that are already being used, or use them based on the planet or body window is for.

[arkie87]

Id stay away from colours that are already being used, or use them based on the planet or body window is for.

Sure. That's a better idea, and it "integrates" into KSP theme perfectly.

[LethalDose]

The first suggestion makes assumptions about how how the transfer is being made (e.g. Hohmann) and discourages players from investigating alternatives (e.g. bi-elliptic transfers).

I don't see how the second suggestion meaningfully differs from using a maneuver node to draw an escape velocity now.

[arkie87]

I don't see how the second suggestion meaningfully differs from using a maneuver node to draw an escape velocity now.

With the current maneuver node system, you can draw one maneuver to just barely escape kerbin SOI, so as to minimize eccentricity (though an eccentricity will always be present); and then draw another one to find rough transfer window. But as mentioned before, this transfer window is less than optimal, since the plotted orbit always has an eccentricity.

My suggestion allows to make just one maneuver node (thereby eliminating the need to finely tune a maneuver node to "just barely" escape kerbin SOI) using the actual orbit of Kerbin (no eccentricity), and will allow you to make this maneuver node from the launchpad, so you can time warp at 100,000x on the ground without having to switch to the space center/tracking station or another craft/satellite in a location that allows 100,000x time warp...

Edited November 12, 2014 by arkie87

[scy]

Instead of a transfer planner could we not just have better tools? E.g.

1. From orbit around Kerbin, there should be an easy way of creating an ejection burn by specifying the ejection angle (relative to planet's prograde), delta-v and time (number of orbits before this takes place).

2. Add some way of comparing projected position with the position of other objects; e.g. mousing over some point in the trajectory projection would show projections of where other objects will be when you arrive at that point.

3. Fix up the trajectory projections; e.g. if floating point errors cause uncertainty on arrival at the planet then (a) indicate that uncertainty and ( allow maneuver planning relative to the time at which you enter the SOI, using some local projection which doesn't wobble all over the place (even if the current projection deviates a little from the one shown).

[arkie87]

Instead of a transfer planner could we not just have better tools? E.g.

1. From orbit around Kerbin, there should be an easy way of creating an ejection burn by specifying the ejection angle (relative to planet's prograde), delta-v and time (number of orbits before this takes place).

2. Add some way of comparing projected position with the position of other objects; e.g. mousing over some point in the trajectory projection would show projections of where other objects will be when you arrive at that point.

3. Fix up the trajectory projections; e.g. if floating point errors cause uncertainty on arrival at the planet then (a) indicate that uncertainty and ( allow maneuver planning relative to the time at which you enter the SOI, using some local projection which doesn't wobble all over the place (even if the current projection deviates a little from the one shown).

I like #1 (though i'm pretty sure you can do this with PreciseNode, but i would favor a more integrated functionality to the current GUI). If you could specify ejection angle, deltaV, and number of orbits into the future, and the results displayed on the map view (as is done with a normal maneuver node), then this would be sufficient for finding transfer windows (though it would require you to already be in orbit, which restricts time acceleration and/or requires you to switch crafts to increase time warp factor).

Perhaps, in the regular maneuver node GUI, there could be a button to toggle specification criteria i.e. from prograde-normal-radial to magnitude and angles. a button to tell maneuver node to predict what happens if maneuver is executed on the next orbit would be useful (though for window planning you might have to press "+1" 100's of times).

[bv1]

I think that they should just bite the bullet and integrate Kerbal Alarm Clock, with its orbital transfer calculations included.

Considering that they're adding upgradeable buildings, they could have it as an unlockable feature that gets attached to the Tracking Station and thenceforth becomes available to all spacecraft.

[arkie87]

I think that they should just bite the bullet and integrate Kerbal Alarm Clock, with its orbital transfer calculations included.

Considering that they're adding upgradeable buildings, they could have it as an unlockable feature that gets attached to the Tracking Station and thenceforth becomes available to all spacecraft.

I dont know if i agree with implementing KAC to stock with all of its features. I do think some sort of alarm clock will be necessary if the game is intended to be Kerbal space Program rather than Kerbal Space Simulator... though i also think the "program" part of KSP implies some sort of autopilot so that you can focus on sending and building/designing craft rather than flying them (once you've gotten the flying thing down pat)

I also think that by default, the game should not let you time warp past a maneuver node... i dont know why that hasnt been implemented already

[StormKat]

What if there was some way to file a flight plan before launch? It could then use the contract modules for the different milestones needed.

[arkie87]

What if there was some way to file a flight plan before launch? It could then use the contract modules for the different milestones needed.

Not sure if i understood you... it seems like you are suggest the contract shows you the flightplan via maneuver nodes on screen i.e. the contract tells you how to get there/complete it?

[StormKat]

Not sure if i understood you... it seems like you are suggest the contract shows you the flightplan via maneuver nodes on screen i.e. the contract tells you how to get there/complete it?

For example, right now you can get a contract that wants you to test a part in orbit at a minimum altitude of 90,000m and a maximum altitude of 110,000m.

What if you could go into the Tracking Station or the Launch Complex and file a flight plan to go to Jool. A series of contract-like milestones show up:

Reach Kerbin orbit at an <height> altitude by <date> date.

Reach escape trajectory by <date> date. (this is where I get fuzzy)

Reach Jool orbit at an <height> altitude by <date> date.

After each milestone, a maneuver node is created for the next milestone.

As long as your reach all the milestones in order, you've just made it to Jool!

Edited November 18, 2014 by StormKat