Maneuvering needs a complete overhaul

[Klapaucius]

This is my plea to take the maneuver node UI, dispose of it and start over.  I apologize, as I know a lot of work has gone into this, but I am very, very frustrated. I've spent most of my time on Kerbin, but on my few adventures to other planets, the game has just had the wind taken out of my sails.

 

I really think the maneurving in KSP2 is a major step backwards.  The UI is cluttered and more importantly, it is very difficult to use. I have been trying to fly to Dres. I try, fail, give up and come back thinking things will be better.  They are not. 

 

I've been recording my play, and from the time I achieved orbit around Kerbol until I gave up trying to get an encounter with Dres, I spent 15 minutes of real time.

Wondering if I am just terrible, I opened KSP1.  I recorded my progress.  It took me 30 seconds to set a maneuver and get an encounter.  So, it is not operater error.   The system is actively fighting me.

 

Also, compare the readability of KSP2 compared to KSP1.  The text in KSP1 is clean, and the whole area does not feel cluttered.  Note also how simple and useful the encounter nodes are in KSP1.  I have no idea what the 1A and 1B etc are supposed to indicate.

 

 

Edited April 17, 2023 by Klapaucius

[Little 908]

I don't like that planets are now displayed as circles on the map

[LeroyJenkins]

45 minutes ago, Klapaucius said:

I have no idea what the 1A and 1B etc are supposed to indicate.

Though I agree with you, that the UI needs some clean up and improvement in the UX area. 1A 1B and 2A and 2B are the close approach point pars for the rendezvouses with your target (Dres). These were the two sets of flag markers in KSP1. The 1A/1B set is the first approach opportunity and 2A/2B is the second. You sent up your maneuver node so that one or both of these sets are as close together as possible, just like getting the to marker flags halves in KSP1. Yes, not intuitive at first. Took me some time to figure out which ones were a pair. The number or the letters.

39 minutes ago, Little 908 said:

I don't like that planets are now displayed as circles on the map

I think those circles are to represent the SOI boundary and the dot in the middle represents the planet. Though the circles should not be the same size for every planet, since each planet has a different gravitational force (ie, SOI). Again, more work needs to be done on cleaning the UI/UX up, have better help bubbles and explanations in the tutorials which are still being developed.

[Little 908]

4 minutes ago, LeroyJenkins said:

I think those circles are to represent the SOI boundary and the dot in the middle represents the planet.

Nope, that appears not the case, as when you zoom in, it shrinks with the zoom. Also the dot in the middle is just the orbit line of the moon (s) orbiting the body.

Edited April 18, 2023 by Little 908

[LeroyJenkins]

1 minute ago, Little 908 said:

Nope, that appears not the case, as when you zoon it, it shrinks with the zoom. Also the dot in the middle is just the orbit line of the moon (s) orbiting the body.

Well darn it, then they are even more useless than I thought. Thank you for confirming what they are.

[Buzz313th]

I would bet that almost everything UI wise in KSP2 are just placeholders for better, more functional and prettier icons and symbols.  The game is still in very early development.

[pandaman]

5 hours ago, LeroyJenkins said:

Well darn it, then they are even more useless than I thought. Thank you for confirming what they are.

They seem to be just a visual indicator as to where the planet is (centre of the circle).  As an alternative to a big 'dot' or out of scale image of the planet which would give a false impression of scale.  Makes sense, but I did think they were SoI boundaries at first.

[Spicat]

While I agree that the UI of the maneuver needs some tweaking to improve, I disagree that it needs a complete overhaul (If you mean by that: reverting to ksp 1 UI)

They maybe did the 1A and 2B thingy for colorblind people, I actually suggested some tweaking in another topic that I think is better and less confusing (with a sketch):

Tell me what you think.

Edited April 18, 2023 by Spicat

[HenryBlatbugIII]

7 hours ago, LeroyJenkins said:

1A 1B and 2A and 2B are the close approach point pars for the rendezvouses with your target (Dres). These were the two sets of flag markers in KSP1. The 1A/1B set is the first approach opportunity and 2A/2B is the second. You sent up your maneuver node so that one or both of these sets are as close together as possible, just like getting the to marker flags halves in KSP1.

Yeah, it looks like that's what's intended, but from looking at the image in the OP, it's clearly wrong.  2A and 2B (Dres' position at closest approaches) are shown just behind Dres' current position, but with the orbits shown on the screen they should be near 1A and 1B.

It looks to me like the points of closest approach are being calculated on a different orbit than we expect.  A back-of-the-envelope calculation shows that 2A and 2B are pretty close to where Dres will be when the ship is at 1A and 1B on its second orbit.

[Spicat]

7 hours ago, pandaman said:

They seem to be just a visual indicator as to where the planet is (centre of the circle).  As an alternative to a big 'dot' or out of scale image of the planet which would give a false impression of scale.  Makes sense, but I did think they were SoI boundaries at first.

I think it's to show that it's not only one planet but more of a SOI (even if it's not actually the SOI like big dots in ksp 1 are not actual planets).

In ksp 1 one dot shows only one planet and no other bodies (moons for example) so showing a circle is more intuitive.

It makes even more sense with Rask and Rusk which is a binary system so one dot wouldn't make sense.

[Davidian1024]

I don't mean to be come off as disrespectful to the OP here or anything.  I get how aggravating it can be when any UI/UX takes you down a road of frustration.  But, I for one really like the new maneuver planning UI.  I think it's definitely still rough around the edges but I like the direction it's heading in.  I think it's a significant improvement over the one from KSP1.

I know I found the KSP1 interface  confusing when I was new to that.  I think what they're building in KSP2 is already clearer and more intuitive.  Not only that, it's really not that different fundamentally.

On the bit about the flag markers being swapped out form 1A/1B and 2A/2B markers.  When I first started dealing with this, it made me realize I didn't fully understand what the KSP1 maneuver UI was telling me.  I actually had to finally get my head around more of what it had been trying to communicate.  Now that I have, I feel like my ability to get around the solar system has dramatically improved.

So, I for one am hoping that the devs do not dispose of the maneuver UI in it's current form and start over.  That said, it does need work.  But, I think they know that.

[Lyneira]

I'm OK with the design of the maneuver planner UI overall, getting used to the 1A and 1B target markers wasn't much of a problem. It helps that, like Ap and Pe, you can now pin these 1A and 1B markers, and it immediately makes it clear what they mean in the pin description with "vessel @ intersect" and "target @ intersect". The maneuver node widget does need work to make dragging on the handles or the node itself a bit more predictable, the handles sometimes disappear at certain camera angles. We need a way to move the node an orbit (or multiple) forward and a way to precisely nudge the location of the node without dragging. And while I can't point at any concrete examples right now, I have the feeling there are often click priority issues with the map view in general.

Sometimes I would like to be able to focus on a target world to fine tune an encounter, but to get a good view of the encounter trajectory, I have to look away from where the maneuver node actually is, forcing me into a view angle that is a poor compromise between maneuver node and encounter visibility.

[dr.phees]

The idea of having the node at the start of the burn is, in many cases not very helpful, though. If the game does not understand my rocket (unusual/on the fly staging for example, or something happens^tm to it), I cannot properly set up nodes. Why would anyone think that was a good idea? At least let me decide if I want to set a node for burn time start or as a classic, 'instantaneous' node. I understand that long burns should be calculateable in KSP 2, but it does not make sense to treat all the burns like that. Planning is much easier if you can set up the node like you want it. Best version would be to allow me to toggle the node back and forth between both modes.

It would be nice if the predicted start and end of the burn could be visually presented, though. An example: Color the trajectory before and after the node red or yellow to indicate burn time visually. Now that would be cool.

Edited April 21, 2023 by dr.phees

[EvelynThe Dragon]

14 hours ago, Lyneira said:

I'm OK with the design of the maneuver planner UI overall, getting used to the 1A and 1B target markers wasn't much of a problem. It helps that, like Ap and Pe, you can now pin these 1A and 1B markers, and it immediately makes it clear what they mean in the pin description with "vessel @ intersect" and "target @ intersect". The maneuver node widget does need work to make dragging on the handles or the node itself a bit more predictable, the handles sometimes disappear at certain camera angles. We need a way to move the node an orbit (or multiple) forward and a way to precisely nudge the location of the node without dragging. And while I can't point at any concrete examples right now, I have the feeling there are often click priority issues with the map view in general.

Sometimes I would like to be able to focus on a target world to fine tune an encounter, but to get a good view of the encounter trajectory, I have to look away from where the maneuver node actually is, forcing me into a view angle that is a poor compromise between maneuver node and encounter visibility.

The Maneuver Node Controller mod over on Spacedock makes it a lot easier to manipulate nodes. You can adjust all velocity vectors and maneuver time, it will snap to various orbital features (Ap, Pe, etc.) and it allows you to move the start time to future orbits as well. It also displays the adjusted orbital parameters at the completion of the burn.

It is pretty good, give it a try. But, it still needs some work. I would love if it allowed typing entries into it instead of having to use buttons to adjust things. 

To be honest, this should be built into the game IMO. I am very much a keyboard warrior with KSP1 and I wish KSP2 worked the same.

I am still trying to figure out the intercept markers, and I wish they showed the distance BY DEFAULT.

[Lyneira]

35 minutes ago, dr.phees said:

The idea of having the node at the start of the burn is, in many cases not very helpful, though. If the game does not understand my rocket (unusual/on the fly staging for example, or something happens^tm to it), I cannot properly set up nodes. Why would anyone think that was a good idea? At least let me decide if I want to set a node for burn time start or as a classic, 'instantaneous' node.

I've encountered situations like that myself where the burn was just a bit long relative to the orbital period. I think this can still work fine with non-instantaneous maneuver plans we have now, it just needs way to set the maneuver marker to be the burn's halfway point. But the red trajectory and the burn start time dynamically extend a little before the node as you increase the maneuver. This way you can avoid burning radial quite so much and wasting Oberth effect.

When doing an ejection or Hohmann transfer to/from circular orbit, you can manually do it now by moving the maneuver backwards a bit and adding a bit of radial component to adjust the Pe to where you want the middle of the maneuver to be. It's quite a bit of move, adjust maneuver and repeat though.

Edited April 21, 2023 by Lyneira
Explain node suggestion better

[EvelynThe Dragon]

5 minutes ago, Lyneira said:

I've encountered situations like that myself where the burn was just a bit long relative to the orbital period. I think what is needed for this is actually just the node marker to be the burn's halfway point. So the burn start time extends a little before the node. This way you can avoid burning radial quite so much and wasting Oberth effect.

That's an instantaneous or impulse approximation of delta V.  It's how KSP1 works by default. It is best when you have a high TWR (acceleration capability) that makes the error from that assumption smaller. Long burns present a problem in both estimating final trajectory as well as maneuver steering during the burn. It's a tough nut to crack. But a time offset setting for the start of burn is a compromise that should be an adjustable parameter.

[Lyneira]

Just now, EvelynThe Dragon said:

That's an instantaneous or impulse approximation of delta V.  It's how KSP1 works by default. It is best when you have a high TWR (acceleration capability) that makes the error from that assumption smaller. Long burns present a problem in both estimating final trajectory as well as maneuver steering during the burn. It's a tough nut to crack. But a time offset setting for the start of burn is a compromise that should be an adjustable parameter.

My initial explanation was a bit poor and I've tried to edit it to make it a little clearer that I don't mean a return to "instant impulse" maneuver planning. Instead, the suggestion is for the game to base the maneuver direction on where you placed the maneuver on the orbit and, if desired, set the start point at half the burn time (or whatever time you want, really) before the maneuver's location. Then simulate the trajectory the same way it currently does. Effectively a convenience tool to make it easier to plan the most efficient burn possible.

[EvelynThe Dragon]

13 minutes ago, Lyneira said:

My initial explanation was a bit poor and I've tried to edit it to make it a little clearer that I don't mean a return to "instant impulse" maneuver planning. Instead, the suggestion is for the game to base the maneuver direction on where you placed the maneuver on the orbit and, if desired, set the start point at half the burn time (or whatever time you want, really) before the maneuver's location. Then simulate the trajectory the same way it currently does. Effectively a convenience tool to make it easier to plan the most efficient burn possible.

KSP1 allows you to change the relative start time of the burn for every maneuver node if you wish, and I took that as what you meant while also mentioning the KSP 1 default mechanism. This is completely missing functionality for KSP2.

[Lyneira]

Just now, EvelynThe Dragon said:

KSP1 allows you to change the relative start time of the burn for every maneuver node if you wish, and I took that as what you meant while also mentioning the KSP 1 default mechanism. This is completely missing functionality for KSP2.

I guess that goes to show how little I've played KSP1 in its later years! I don't recall this functionality existing from the times I played. You just had to divide the burn time by 2 and start when "Node in ..." got to that number...

[EvelynThe Dragon]

One thing I am finding is supremely annoying is that when you set up a maneuver node to do a transfer from one planet to another you can sort of set something up that looks right but when you cross the SOI boundary of the body you are leaving from, it completely messes it up and your orbit isn't what you thought it was going to be. This makes mission planning a real mess.

 

[Lyneira]

42 minutes ago, EvelynThe Dragon said:

One thing I am finding is supremely annoying is that when you set up a maneuver node to do a transfer from one planet to another you can sort of set something up that looks right but when you cross the SOI boundary of the body you are leaving from, it completely messes it up and your orbit isn't what you thought it was going to be. This makes mission planning a real mess.

It might be caused by this bug?

Edited April 22, 2023 by Lyneira

[EvelynThe Dragon]

21 minutes ago, Lyneira said:

It might be caused by this bug?

Yeah, that looks like the same thing, definitely buggy.

[SirDeadPuppy]

I hate the node its like pure guess work how to get anywhere im new as hell never played 1 but at this point i just try to get to a planets sphere of influence and just manually go into orbit ...in fact most times its just me praying i get close enough to a world that i can just brute force my way to it ...this sucks they need a better system or to explane it like how the hell am im suppose to know when a window is? they never mention it they have no way to find one i got eye them from a graph on reddit ....so far i only been to the moon and juel every thing else is LOL got to mars once by turning on infifnt fuel and just spent hours just flying to it and more hourse trying to slow down and orbit it  LOL 

[Wetzelrad]

7 hours ago, SirDeadPuppy said:

I hate the node its like pure guess work how to get anywhere im new as hell never played 1 but at this point i just try to get to a planets sphere of influence and just manually go into orbit ...in fact most times its just me praying i get close enough to a world that i can just brute force my way to it ...this sucks they need a better system or to explane it like how the hell am im suppose to know when a window is? they never mention it they have no way to find one i got eye them from a graph on reddit ....so far i only been to the moon and juel every thing else is LOL got to mars once by turning on infifnt fuel and just spent hours just flying to it and more hourse trying to slow down and orbit it  LOL 

Brute force is fine when you're starting out, but I would encourage you to soak up everything the tutorials have to say about orbits. Learning the right way to fly to the Mun is key. Once you have that mastered, applying the same principles to fly to Duna is not so hard, only complicated by the change in frame of reference.

Transfer windows are a problem for sure, and it remains to be seen how KSP2 will hold the player's hand through that. I'm sure more tutorials are planned.

[s_gamer101]

On 4/25/2023 at 8:39 AM, SirDeadPuppy said:

this sucks they need a better system or to explane it like how the hell am im suppose to know when a window is?

Now this doesn't have anything to do with the maneuvering UI. KSP 1 didn't tell you when to launch either. What you are looking for is something like this. (it's for KSP 1 but should work for 2 as well)

More tips below the spoiler tag:

Spoiler

Duna (to which you are referring to as "Mars") is the planet you want to practice with, since you don't have to worry about inclination there. Go to the site that I've linked and use it to calculate the so-called "phase angle", the illustration on the site shows you what this angle is. For now, don't worry about the other angle, that's something you can worry about when you'll do more advanced stuff. Launch your ship to low Kerbin ("Earth") orbit and time warp until Duna and Kerbin approximately have the right phase angle, eyeballing it should be close enough. Then, you need to do your prograde burn on the dark side of Kerbin (the side that currently doesn't get sunlight), as always when travelling to a location in the outer solar system. Plan your prograde burn with a maneuver node. You should now get a Duna encounter with only after just some small adjustments.

But so much about "the new features make the game more accesible for new players"

Edited April 26, 2023 by s_gamer101