One Year of KSP2

[magnemoe]

27 minutes ago, MechBFP said:

This is what I have found.

Burn at the start time indicated, but then completely ignore the timer and simply look at the trajectory. I have never had an issue doing this.

However if I try to follow the timer it only sometimes works.

This, Long burns in KSP 2 is much better than in KSP 1, like how it sometimes to turns like coming in fast to Moho, you still mess up if burn is inaccurate. 
Also if you have low TWR its help a lot split up the burn and here low is <1 twr. 

Standard for my launches I have 600-1400 m/s in core chemical stage to kick me into at least close to an interplanetary trajectory but the 300 ton to Duna had me finish circulation on the large nuclear engine. 
Now plotting the Duna intercept, around 1700 m/s by the launch window calculator https://alexmoon.github.io/ksp/
But I needed 1900 m/s just to escape Kerbin SOI.
Solution was to do an 700 m/s burn then an 900 m/s burn at then close to Pe. 
K2-D2 does an pretty good job but its still some inaccuracy. 
Still doing an 2.5 km/s burn to Duna and end up inside the SOI is amazing, this was K2-D2. Then you do an correction burn, a month before encounter using RCS assuming an large ship. 

[herbal space program]

5 hours ago, magnemoe said:

Now plotting the Duna intercept, around 1700 m/s by the launch window calculator https://alexmoon.github.io/ksp/
But I needed 1900 m/s just to escape Kerbin SOI.

1700 m/s to go to Duna? It takes nowhere near that much dV to go to Duna from LKO.  It takes a bit more than 1km/s if you go straight there (go read what it actually says at your link), and you can  do it for around 900 m/s if you use a Munar assist on ejection.  If you have really lousy TWR, you can do about 80% of your ejection burn in a series of short periapsis kicks, so you only have to boost the last 200m/s or so on the final kick,  even less if you want to deal with the possibility getting captured by Mun. Of course the way the KSP2 maneuver node works is very ill-suited to that,  so I'm not surprised it caused you to expend almost twice as much dV as you would have actually needed if you did it right. But by all means, keep telling me about how great it is! 

[herbal space program]

So I will admit that I was wrong about one thing, which is that the KSP2 maneuver node does not in fact calculate your trajectory based on an instantaneous impulse at that spot, but rather tries to calculate your trajectory from wherever you placed your node if you start burning right there in the selected direction. That may seem like an improvement to some, but IMO it is most definitely not one, because it actually makes figuring out the optimal burn profile to achieve a particular final trajectory much harder instead of easier.  That's because the the most dV-efficient possible way to eject from orbit to some other (in-plane) destination is to deliver an instantaneous, exactly prograde impulse to your craft at just the right spot.  As that is not physically possible, the next best thing is to point your craft in the direction that would be  exactly prograde at that spot, and then burn along that heading in a manner that more or less evenly splits your burn time between before and after you hit that spot. So the problem with this supposed improvement is thus that while it's very easy to specify a purely prograde trajectory from some particular spot, that's not actually  the direction you need to be boosting in when you start your burn. Instead, in the new system you have guesstimate some radial inward component to your burn  that will be just enough to have you going parallel to the prograde direction halfway through your burn. How exactly do you do that? Worse, if you are doing multiple periapsis kicks, you'll have no real idea where to place your first node  or what direction to boost in to put your initial periapsis at the right spot for subsequent kicks. In KSP1, that was pretty much a no-brainer, because you could optimize your total impulse right at the outset, so you knew exactly where to place the next node. YMMV, but I have executed countless SOI transfers in KSP1 and quite a few also now in KSP2 my friends, and if you really want to do things efficiently the KSP1 way was definitely better.

[Superfluous J]

7 minutes ago, herbal space program said:

Instead, in the new system you have guesstimate some radial inward component to your burn  that will be just enough to have you going parallel to the prograde direction halfway through your burn. How exactly do you do that?

You could pull the radial gizmo inward.

I've planned on doing this the next time I play, to see if "burn the way the maneuver node tells you in KSP1 even though KSP1 assumes instant infinite thrust" is actually better than "here's a node that shows you how your ship will go throughout the burn, and yeah just burn prograde the whole time."

However, Balatro came out and I've spent every waking gaming moment playing it.

[herbal space program]

1 minute ago, Superfluous J said:

You could pull the radial gizmo inward.

Yes, but exactly how much inward? It's really much easier to have the game figure that out for you!

[Superfluous J]

1 minute ago, herbal space program said:

Yes, but exactly how much inward? It's really much easier to have the game figure that out for you!

The amount that makes your dV lowest while still achieving your goal.

Bonus: You can fiddle with it unlike in KSP1 where you just had to burn and hope you weren't so far off as to make it not work.

One thing you can't do in KSP2 nodes (or KSP1 nodes) is integrate the direction you go over time, which you do in KSP1 when you aim "prograde at the original node's point" throughout the entire burn. You could mimic this by making a couple nodes, one for the first half of the burn and the other for the 2nd half. You don't need to burn them, just do them long enough to prove that KSP1's nodes were inherently more accurate/cheap/whatever you are trying to prove.

Or you could do it and disprove that idea. I don't know which is "correct."

I'd imagine NASA, who have far more stringent fuel budgets than we do, would do it the cheapest way. I wonder if they hold prograde or hold a specific heading all burn during long burns.

[magnemoe]

6 hours ago, herbal space program said:

So I will admit that I was wrong about one thing, which is that the KSP2 maneuver node does not in fact calculate your trajectory based on an instantaneous impulse at that spot, but rather tries to calculate your trajectory from wherever you placed your node if you start burning right there in the selected direction. That may seem like an improvement to some, but IMO it is most definitely not one, because it actually makes figuring out the optimal burn profile to achieve a particular final trajectory much harder instead of easier.  That's because the the most dV-efficient possible way to eject from orbit to some other (in-plane) destination is to deliver an instantaneous, exactly prograde impulse to your craft at just the right spot.  As that is not physically possible, the next best thing is to point your craft in the direction that would be  exactly prograde at that spot, and then burn along that heading in a manner that more or less evenly splits your burn time between before and after you hit that spot. So the problem with this supposed improvement is thus that while it's very easy to specify a purely prograde trajectory from some particular spot, that's not actually  the direction you need to be boosting in when you start your burn. Instead, in the new system you have guesstimate some radial inward component to your burn  that will be just enough to have you going parallel to the prograde direction halfway through your burn. How exactly do you do that? Worse, if you are doing multiple periapsis kicks, you'll have no real idea where to place your first node  or what direction to boost in to put your initial periapsis at the right spot for subsequent kicks. In KSP1, that was pretty much a no-brainer, because you could optimize your total impulse right at the outset, so you knew exactly where to place the next node. YMMV, but I have executed countless SOI transfers in KSP1 and quite a few also now in KSP2 my friends, and if you really want to do things efficiently the KSP1 way was definitely better.

Yes figured this out, had two positive effects for me, first was testing out the Tylo landing, found that I could bring Pe down low over target area then make an braking node with would have me crash short of target but with some radial up vector I had an trajectory who have me mostly stopped couple of km up. did the burn then an adjustment burn then it was landing. 

Second had me trying to send the 300 ton lander to Duna, transfer window site said 1700 m/s total for mission. I needed 1700 m/s to escape Kerbin SOI.
Then I realized it was because of low TWR as it was only nuclear, payload was so heavy I had to finish circulate with the nuclear engines. Normally I have 600-1100 m/s left on the core orbital stage and burn that off first so initial TWR is good. 
Solution was to first do an 600 m/s burn then the follow up of around 500 m/s and I had an Duna intercept. 

So I prefer the new system, you get much more accurate burn, now I tend to used flight plan I think it is to set up circulation burns coming in but doing it manual its just to drag it forward of Pe until it gives best result as in resulting Ap is lowest as in KSP 2 you get an much better estimate. 

[AtomicTech]

Happy anniversary y'all 

[herbal space program]

10 hours ago, magnemoe said:

Solution was to first do an 600 m/s burn then the follow up of around 500 m/s and I had an Duna intercept. 

Well that's actually not bad, although it's not the same as what you said before.  Regardless of that, when I'm looking at an initial  TWR of 0.15-0.4 on LKO, which is usually how it is for my long-range transfer stages and space planes, I'll generally divide the dV required to get up to just short of Munar capture (~830 m/s) into at least 3 separate periapsis kicks of  2.5 minutes or less. If you divide those evenly across your point of ideal instantaneous ejection, i.e. where you'd place the node in KSP1, your cosine losses up to that point are pretty trivial. If you're going to Duna or Eve, you can set up a Munar assist from there that will get you an intercept for less than another 100m/s.  If you're not going to bother with that, you can do the rest for a little over 200 with just another final kick, still losing very little from boosting off prograde.  If  the destination is further out however, requiring more than ~400m/s above a minimal Kerbin escape trajectory, there are other things you can to reduce wasted dV on the long final  burn that's required. One of these is to raise your PE to 500-1000km from your distant  AP,  which  costs you a little in dV terms due to Oberth losses, but more than pays for itself with the reduced cosine losses you'll suffer doing that long burn out of a slightly slower and significantly higher-radius orbit. If you're doing a Munar assist, you can also divide your final burn  into two shorter ones at your Kerbin and Munar PEs, taking maximum advantage of the Oberth effect in both places. As I said before, I have done a whole lot of this sort of thing in KSP1, and planning such maneuvers under that system is something I can do in my sleep. In KSP2, I have still not figured out how to do it anywhere near this precisely.

Lastly, for Tylo or any other vacuum body, the most efficient possible (theoretical) landing plan is to set your PE to zero and do an instantaneous retrograde burn of exactly your surface velocity at exactly that point.  As this is of course impossible, the best physically plausible approximation of that is to plot a purely retrograde, continuously full thrust "suicide" burn, starting at whatever point prior to that tangent PE that will bring your velocity to exactly zero when you reach the ground. This is not an easy thing to do, especially for Tylo, and definitely not something you want to attempt with a marginal TWR, but to the extent you can approximate that descent profile, you will make it more efficient.  TBH, I never really use a maneuver node to try to set this up, because neither system will have you boosting in the most efficient, continuously retrograde manner. So I usually just seat-of-the-pants it, giving my F9 key some exercise if I come in hot or stop too short. On that score, I'd say that stopping at 2km up  on Tylo would probably be a do-over for me, as even a near-instantaneous braking burn near the ground from there will cost you over 210m/s, and in practice you'll probably spend closer to 400-500 to put yourself down safely.

[regex]

23 hours ago, herbal space program said:

Yes, but exactly how much inward? It's really much easier to have the game figure that out for you!

Set your initial delta-V expenditure prograde and then move the node around on the orbit until it achieves your desired intercept, there's no need to burn radial.

[herbal space program]

18 minutes ago, regex said:

Set your initial delta-V expenditure prograde and then move the node around on the orbit until it achieves your desired intercept, there's no need to burn radial.

Not in KSP1, but in KSP2 there is! In KSP1, the radial component is baked in after one does just what you said, because your maneuver vector at the start of your burn won't actually be prograde, but somewhere inward of that. In KSP2 it doesn't actually work that way, hence all this blablabla on my part.

Edited March 1 by herbal space program

[mattihase]

I've definitely had some instances where maneuver plans just vanish 400 or so m/s of delta V over the course of the burn, though it's been a while.

I have no idea how much of this is my fault for off-centre thrust, but I feel like the game should take that into account if it is the reason.

Edited March 1 by mattihase

[regex]

I've had much better luck with KSP2's maneuver node tool than the one in KSP1, which always required correction burns, especially with long burns. The new one produces far superior results, it just needs better controls.

[Superfluous J]

41 minutes ago, regex said:

Set your initial delta-V expenditure prograde and then move the node around on the orbit until it achieves your desired intercept, there's no need to burn radial.

KSP2 Devs don't want you to know this one neat trick.

[regex]

12 minutes ago, Superfluous J said:

KSP2 Devs don't want you to know this one neat trick.

Which I can also do by just moving the node back on the orbit to adjust the endpoint. Like I said, I've had much more luck with the new node, it just needs better controls.

[Superfluous J]

10 minutes ago, regex said:

Which I can also do by just moving the node back on the orbit to adjust the endpoint. Like I said, I've had much more luck with the new node, it just needs better controls.

I don't think you see it.

It's CHEAPER to burn off-prograde in the situation my ship was in. There was no way to do an all-prograde burn as cheaply as a burn that had equal amounts of prograde and radial-in.

And my ship wasn't in an uncommon situation. 100km orbit around Kerbin doing a multi-minute burn.

Sure you can move the node back or forward to eject at different angles and get better or worse ejections. But once you've done that, all-prograde is still worse.

Edited March 1 by Superfluous J

[MechBFP]

1 hour ago, Superfluous J said:

I don't think you see it.

It's CHEAPER to burn off-prograde in the situation my ship was in. There was no way to do an all-prograde burn as cheaply as a burn that had equal amounts of prograde and radial-in.

And my ship wasn't in an uncommon situation. 100km orbit around Kerbin doing a multi-minute burn.

Sure you can move the node back or forward to eject at different angles and get better or worse ejections. But once you've done that, all-prograde is still worse.

If you start your burn early (like what you would do in KSP1) but point prograde the entire time, what is the result?

[herbal space program]

1 hour ago, regex said:

I've had much better luck with KSP2's maneuver node tool than the one in KSP1, which always required correction burns, especially with long burns. The new one produces far superior results, it just needs better controls.

Different strokes I guess. I got to the point with KSP1 where my correction burns were generally done using RCS with the lightest touch possible. I'm nowhere near that with the new system.

[Superfluous J]

42 minutes ago, MechBFP said:

If you start your burn early (like what you would do in KSP1) but point prograde the entire time, what is the result?

You eject at the wrong angle, or don't have the required dV (or burn more to create that dV), or (more likely) both.

Edited March 1 by Superfluous J

[The Aziz]

How I don't eject at "wrong" angle if my final trajectory is exactly the same as predicted?

If anything, KSP1 predictions were wrong because they didn't take acceleration into account.

[Superfluous J]

2 hours ago, The Aziz said:

How I don't eject at "wrong" angle if my final trajectory is exactly the same as predicted?

Maybe I'm not understanding what you asked then.

I thought you were planning a node to get an encounter somewhere, and then burning differently than what the node said to do. That's how I interpreted it. I expect you're doing it for a specific purpose but I also was not able to interpret what purpose that is.

[herbal space program]

7 hours ago, The Aziz said:

How I don't eject at "wrong" angle if my final trajectory is exactly the same as predicted?

If anything, KSP1 predictions were wrong because they didn't take acceleration into account.

The point is that there is no way to eject from a circular orbit with maximum efficiency if you are pointed directly prograde when you start your burn and remain in that attitude the whole way through, unless you have infinite thrust. For maximum efficiency, you should be pointed directly prograde at the midpoint of your burn, but some amount inward of prograde at the outset, and somewhat outside of prograde at the end. Why else would people be setting up all these sequential periapsis kicks when they're using a low TWR transfer stage?

[kdaviper]

3 hours ago, herbal space program said:

The point is that there is no way to eject from a circular orbit with maximum efficiency if you are pointed directly prograde when you start your burn and remain in that attitude the whole way through, unless you have infinite thrust. For maximum efficiency, you should be pointed directly prograde at the midpoint of your burn, but some amount inward of prograde at the outset, and somewhat outside of prograde at the end. Why else would people be setting up all these sequential periapsis kicks when they're using a low TWR transfer stage?

Essentially what you need are:

1. The ability to create a position vector and to increase it's magnitude instead of adding different x,y,z components.

2. The ability to plan multiple burns at once.

If they can give you this you will have the best of both systems.

[herbal space program]

1 hour ago, kdaviper said:

Essentially what you need are:

1. The ability to create a position vector and to increase it's magnitude instead of adding different x,y,z components.

2. The ability to plan multiple burns at once.

If they can give you this you will have the best of both systems.

All that would be great, but for my part, all I would really need to make the new system work as well or even better for me than the old one would be for it to allow me to specify an arbitrary TWR  when placing the node. That way, I could set it to 100 (so that it works like the KSP1 node)  while I'm finding the spot on which to center my periapsis kicks, and then change to whatever it really will be when I plot my actual first burn  around that spot. Once you know the length of your burn, it's actually not so hard to pull radial inward on the gizmo until your projected trajectory defines a secant that intersects your orbit exactly at the beginning and end of it.

Edited March 1 by herbal space program

[The Aziz]

6 hours ago, herbal space program said:

For maximum efficiency, you should be pointed directly prograde at the midpoint of your burn, but some amount inward of prograde at the outset, and somewhat outside of prograde at the end.

Thankfully I stick to maneuver marker, not prograde, even if the maneuver in question has been pulled 100% prograde.

Regardless, point is, now we have a tool that shows the trajectory during the burn from start to end and it can be set up accordingly to needs. The guesswork over a blank sheet is gone.