Where can you see detailed Orbital Angles/info?

[JStevenson]

On KSP, where can you find extremely precise orbital position definitions in game? I'm trying to figure out how to time my interplanetary mission ejection   burns precisely. For example, the interactive calculator (I'm using the Illustrated one) provide very precise phase and ejection burn angles say for a typical Kerbin LEO to Duna of 44.36 deg and 150.91deg. But how can you be that precise?!   Clearly just "eyeballing" such things in the normal tracking station or map view can never achieve this sort of accuracy? 

Note I have experience playing Orbiter, which did provide such positional details in-game. I'm assuming a similar thing must exist somewhere in KSP, just I haven't found it yet?!

Or perhaps there some add on that does this (ie it would be handy to have the phase and ejection angles calculated somehow?)

Cheers and Thanks, 

J.Stevenson

[Gargamel]

It's usually a mod that does it, I don't believe there's a stock option for this. 

Kerbal Engineer Redux is probably what you want, I think. 

[regex]

Precise Node, MechJeb, and Precise Maneuver Node should all be able to show you the ejection angle of a burn, with Engineer and Mechjeb able to show you the ejection angle where you are in orbit. Protractor is defunct, IIRC, but it's the only mod I know of that ever showed phase angles, most people use Transfer Window Planner or Mechjeb to create initial maneuvers at the correct time. It's stock though, so just eyeballing it works plenty fine, it's not like getting anywhere is hard.

Edited July 17, 2017 by regex

[Pecan]

On 7/17/2017 at 4:37 PM, JStevenson said:

...Note I have experience playing Orbiter...

Remember KSP was always intended to be a sort of 'Orbiter Lite' (HarvesteR was a big Orbiter player).  As a consequence such detailed information is not in the stock game and, as regex says, not needed.

It'll probably be obvious to you too that it isn't usually possible to perform an ejection burn to anything like the sort of accuracy called for by such precise definitions of when to go.  If coupled to a time, for instance, it's quite probable you'll be on the wrong part of your local (eg; LKO) orbit at that moment, so have to wait half an orbit or whatever.

[Moach]

ksp tends to be more "pragmatically oriented" than Orbiter, which is very scientific and all about precision (most of the time, at least)

 

there was an early design decision taken to get players to first realize WHY they need a bit of information, and THEN give them a way of finding it - this was deliberately done throughout the design of the interface in order to exercise natural curiosity, instead of blunting ppl with a wall of intimidating numbers which they don't necessarily understand right away...

remember, most ppl are absolutely traumatized by math by the time they're through highschool - so KSP had to circumvent more than the usual non-familiarity of a new subject in its learning curve - for most people, densely packed numerical displays are often regarded as a "thing that does not look like it would ever be any fun" ....

not sure if this has changed since my days in school (which were thoroughly un-enjoyable in a majority of ways) - but most of my peers have many issues with this stuff nowadays

since HarvesteR and myself both have a severe enough case of ADHD, it probably helped that we just weren't paying attention back then anyways - and after we learned programming, we noticed that these once-horrible subjects became items of curiosity, as tools for realizing a personally meaningful project. and now, they appeared as welcome answers to nagging questions - and thus learning them was not just easy, but also extremely pleasant
 

putting that in practice, the KSP interface is built from a least-first approach, giving out no more information than one would THINK necessary, until that necessity comes around...  

this is why there is no ApA/PeA on the flight view, requiring one to switch to the map, as he'd intuitively do once such a level of orbital awareness becomes relevant.  on the other hand, a new user still learning the ropes of "keeping the hot end of the stick pointed backwards" would not really have much need for the details about an orbit he's not yet been able to reach

once space is reached, and the concept of "falling fast enough that you miss the ground" is established - then such specifics are naturally found by a quick glance at the map... a similar process takes place when dealing with orbital maneuvers and encounters, and so on...

 

ultimately, it was anticipated that by the time any player became experienced enough to desire this data in the convenience of the flight UI, and/or required more precision such as mentioned by the OP, then that player would most likely be perfectly capable of installing mods to his game

 

 

 

 

 

Edited July 19, 2017 by Moach

[Thiagobs]

1 hour ago, Moach said:

- snip -

 

That's a cool insight of the design process and decisions of making KSP!

Thanks for sharing!

[pandaman]

Fot getting a good 'eyeball' for an ejection burn i just hold an actual protractor on the map view.  It gives me a good enough guide as to where to put my manouvre node initially and from that i can 'wiggle it' to get the interception.

[DMagic]

4 hours ago, Moach said:

----

I agree that a lot of KSP's design is good for intuitively learning how to get around the Kerbin system. The orbit lines, encounter markers, and the maneuver node gizmo are all really good.

But it all sort of falls apart once you get outside of the Kerbin system. Without any outside tools or mods it can be incredibly difficult to get from one planet to another, you're left to just guess at what to do. Someone not familiar with transfer windows would probably end up lost when they try to get from Kerbin to Duna only to find wildy varying dV requirements to get there.

The game might reveal more information as you need, but it seems as if that design practice was just dropped at some point. Telling players to download a mod to give them more information when a significant number of those players can't physically do so, and a lot of other players either don't want to deal with the ever-shifting mod scene, or just don't like mods in general, seems like a cop out. Relying on external tools is a similarly poor solution.

I don't think a bunch of panels with numbers is a great solution either (I cringe whenever I see a screenshot of something like a rover with a dozen useless KER readouts for orbital parameters, dV, etc..., it's part of the reason why a made Basic Orbit, to only show you what you need, when you need it). But the stock game is sorely lacking in information once you move beyond Kerbin, and I imagine it drives a lot of players away after a short time.

[Vanamonde]

Nothing in the stock game does this, so the thread has been moved to the modding subforum. 

[HebaruSan]

2 hours ago, DMagic said:

The orbit lines, encounter markers, and the maneuver node gizmo are all really good.

But it all sort of falls apart once you get outside of the Kerbin system.

I think they're close, though; the stock map view needs about one more layer of abstraction. If there was an obvious way to "switch to" a planet to plan maneuvers from it, transfer windows would become much more apparent (by analogy with the timing of burns to Mun), and from there you just need a way to display the corresponding V_∞ vector at the SOI edge so the player can attempt to match an in-SOI maneuver to it. I.e., it should convey "you should be moving this fast in this direction at this time to execute your 'outer' maneuver," and then let the player see how far off they currently are in all those dimensions.

(*crosses fingers for the birth of "Basic_Transfers"*)

[Moach]

19 hours ago, DMagic said:

(...) I imagine it drives a lot of players away after a short time.

 

on the contrary - upon a player reaching a point where the efficiency of his interplanetary exploits are of concern, such a player is all the more likely to become community-involved, installing mods, and opening up whole new worlds of possibilities and possibilities of new worlds

 

it is hard to place ourselves in that position - and it was indeed rather difficult at the time, with many disagreements between myself and my brother about just what was the best way of pulling it off... the back and forth would eventually settle on something between "too much" and "not enough info"

it's even harder to say if the way it was done was indeed the very BEST way it could have been done... safe to say, it probably felt like that to my brother at the time he made it - anything that he felt was truly unsatisfactory in the long run, probably got changed eventually, leading to the format we got now

 

advanced players (of the kind that make mods, not just install them) are often estranged of many decisions taken over this UI - even I had many times insisted for more conveniently placed gauges in the flight scene and whatnot... but eventually I saw the reason too

it's not only because it would be intimidating to new players... that can be solved very easily with an "advanced" button or two -- but no, the main problem is that, upon reaching that level of expertise, players grow very unique personal requirements and opinions about their "ideal interface"  - so a more advanced interface was sensibly relegated to a case of "choose whatever mod you feel accomplishes that best" - in full understanding that those who requested these things were almost always mod-capable players, if not mod authors themselves

 

so in the end, the UI was made "least-first" - and kinda maxes out at point upon which it stops being possible to attain any degree of consensus about just how exactly it should be done.

 

personally, I really like that decision - since I'm more of a NanoGauges type player and less of a MechJeb user (I don't need precision, I got plenty more volunteers!)

others may prefer an Orbiter-style interface with more efficiently displayed numbers... in any of a myriad possible configurations 

I for one, am glad that the interface was designed such that we are able to choose

 

Edited July 20, 2017 by Moach

[DMagic]

 

 

I understand the desire not overwhelm players with information, some of my mods are made with the explicit purpose of providing the functionality of existing mods, but in a way that fits in better with stock, not only stylistically, but in terms of taking advantage of the existing UI and control elements.

And I can kind of see how the current design came to be, but again, that design really falls apart when trying to move around outside of the Kerbin system. Of course it's possible to do so, but there is a significant increase in the difficulty, complexity and time involved with doing so.

Once it was decided to release the game on console I feel like any decisions about information that were made with the availability of mods in mind are in need of revisiting. If a console user were told to install a mod to help with more advanced gameplay, they might justifiably feel insulted.

Regardless of why the UI was designed as it is, and regardless of why certain details were provided to the player, while others were not, the game as it stands now makes more advanced play significantly more difficult than it needs to be for a not-insignificant amount of players. Deciding on a single method for giving extra information to players might reduce some of those possible configurations that make KSP so great, but I'm confidant that any worthwhile mods could find a way to either work with stock tools, or just disable and replace them.

 

16 hours ago, HebaruSan said:

I think they're close, though; the stock map view needs about one more layer of abstraction. If there was an obvious way to "switch to" a planet to plan maneuvers from it, transfer windows would become much more apparent (by analogy with the timing of burns to Mun), and from there you just need a way to display the corresponding V_∞ vector at the SOI edge so the player can attempt to match an in-SOI maneuver to it. I.e., it should convey "you should be moving this fast in this direction at this time to execute your 'outer' maneuver," and then let the player see how far off they currently are in all those dimensions.

Do you mean something like this:

A target for the maneuver node trajectory, probably along with some timing info? That's an interesting idea.

Edited July 20, 2017 by DMagic

[regex]

21 minutes ago, DMagic said:

Regardless of why the UI was designed as it is, and regardless of why certain details were provided to the player, while others were not, the game as it stands now makes more advanced play significantly more difficult than it needs to be for a not-insignificant amount of players.

And the cry of "just install a mod, you have choice" is specious at best considering such advanced play is inherent to the base game.

21 minutes ago, DMagic said:

Deciding on a single method for giving extra information to players might reduce some of those possible configurations that make KSP so great, but I'm confidant that any worthwhile mods could find a way to either work with stock tools, or just disable and replace them.

They allowed this exact same thing for FAR, so why not?

[HebaruSan]

48 minutes ago, DMagic said:

Do you mean something like this:

A target for the maneuver node trajectory, probably along with some timing info? That's an interesting idea.

Yeah, kind of; just a visual marker consistent with other stock map elements. Here's an attempt to flesh it out a bit more:

[HebaruSan]

1 hour ago, Moach said:

it's not only because it would be intimidating to new players...

I think my mock-up above demonstrates this to be false. Such a marker in the map view would only appear when the user was knowingly and actively using the transfer feature. New players would not even see it.

1 hour ago, Moach said:

upon reaching that level of expertise, players grow very unique personal requirements and opinions about their "ideal interface"  - so a more advanced interface was sensibly relegated to a case of "choose whatever mod you feel accomplishes that best" - in full understanding that those who requested these things were almost always mod-capable players, if not mod authors themselves

That probably sounds familiar to many of us: "I can't figure out what a good UI for this would look like, so I'll pass the buck to the end user by making it configurable/moddable, and they can design their own UI." I've been there, but this urge is best resisted; most users are not good UI designers, so your product ends up with a poor user experience (or none at all, for those users who can't or don't want to get into mods).

[klesh]

You'll find it right next to the Schmelta-Vee button. 

[purpleivan]

On 19/07/2017 at 9:40 PM, pandaman said:

Fot getting a good 'eyeball' for an ejection burn i just hold an actual protractor on the map view.  It gives me a good enough guide as to where to put my manouvre node initially and from that i can 'wiggle it' to get the interception.

For the first couple of year playing the game I did this. In my case my protractor was an image I put together of a circle with segment lines from its center to edge every 10 degrees.

I 'd place the print of it on the map view, center it on the planet I was orbiting, then place a manoeuvre node at the desired angle. Fortunately the paper was thin enough that I could see the orbit curve and some other details through it.

Now though I use the angle display in the Transfer Window Planner mod.

[OHara]

On 7/19/2017 at 6:29 PM, HebaruSan said:

If there was an obvious way to "switch to" a planet to plan maneuvers from it, transfer windows would become much more apparent (by analogy with the timing of burns to Mun), and from there you just need a way to display the corresponding V_∞ vector at the SOI edge so the player can attempt to match an in-SOI maneuver to it.

Maybe we can show half-ellipse the Hohmann transfer orbit, as an extension of the target-planet's orbit, but in the dashed-line style of an orbital segment after a maneuver.  The correct magnitude and direction of V∞ puts us on that trajectory.

In the Tracking Station, we could show Hohmann transfers from Kerbin to each other body orbiting the Sun.  
If a body other than Kerbin has focus, or the craft in focus orbits a different body, we show the Hohmann transfers from that body to the other planets (or if the body is a moon, to the other moons around the same parent).   If there is no transfer window within the next orbital period, as is the case for Kerbin to Duna in the image below, we should probably omit that transfer.

In the Map View, we would need to zoom out to interplanetary scale to adjust the ejection burn to match the transfer orbit.  Having a target transfer orbit, that leaves at the correct time to meet the target, would alleviate my frustration with close-approach markers, which fail to show the close approach until the orbits and inclinations are very closely matched.  

Probably the transfer orbits should be ellipses, tangent to both starting and destination bodies, with a plane-change bend at the nodal line where the planets' orbital planes meet.  These transfers would not be the most fuel-efficient, but give a good starting point from which players can learn to include some plane-correction in the ejection burn.

Edited July 23, 2017 by OHara

[DMagic]

My thinking was that, rather than providing something that gives a very exact indication of the best transfer maneuver (even if they don't actually give the best transfer, they are still very precise) would be something that highlights the window which always transfers below some threshold dV amount. So maybe something that highlights a region of the planet's orbit with an icon that you can mouse over to give a range of dV, and the date range, and maybe the travel time range. Then you could have a similar method to highlight a region of the vessel's orbit to indicate the ejection angle range for the maneuver node, again with an icon to give info about the dV, etc...

You could click on a planet and have the popup (the "Target Planet"/"Focus On Planet" popup) give extra options for plotting a transfer window to activate the feature.

If you want to extend the feature you could maybe make options that allow for plotting the cheapest transfer window and a separate option for plotting the fastest window, with some adjustable threshold for what dV qualifies.

I'm just not a fan of something that says, here is the best option, plan your maneuver accordingly. It's a bit too much telling and not enough showing (on an unrelated note, this is one of my biggest problems with stock resource scanning, your indication of being in a proper orbit is a message telling you the kind of orbit to be in...).

[OHara]

1 hour ago, DMagic said:

My thinking was that, rather than providing something that gives a very exact indication of the best transfer maneuver [...] something that highlights the window which always transfers below some threshold dV amount.

After giving this some thought, I still like the presentation of dashed transfer orbits.  It is a graphical representation of what the Astrogator mod shows in its table.

Given precise orbits of the starting and destination planets, if we pick a mathematical rule to join those orbits, the math gives a precise transfer orbit.    

To specify a window of departure times that cost below a certain dV, we need to know the orbits around the starting and target bodies, and where you put a mid-course correction, if any.   I can't visualize a simpler interface than alexmoon.github.io/ksp/, and we have nearly that in the TransferWindowPlanner mod.

The acceptable-transfer window (for the acceptance criteria I can imagine) is generally not centered on the two-tangent transfer, but it can be visualized using that transfer as a starting point.   To reduce journey-time, you start later and arrive earlier.  To reduce fuel needs to get to Moho, you wait for the window that puts the plane-change near Kerbin, and depart at the plane change rather than follow the two-tangent transfer so you can do that expensive plane change in the ejection.