The new non-impulsive maneuver editor

[mcwaffles2003]

So I read about the new maneuver editor and it was specific in saying it was "non-impulsive".

On 10/21/2022 at 3:03 PM, Intercept Games said:

New tools to optimize your exploration of the universe: Along with other massive new UI/UX improvements, you can now use time warp while accelerating and plan complex maneuvers with ease using the new non-impulsive maneuver planner. New sphere of influence and atmosphere indicators take the guesswork out of interplanetary maneuvering!

I'm curious if it will always simulate non-impulsively (I'm assuming an impulsive maneuver would mean an instant delta V injection in one direction) or if it will change between impulsively, as most here I assume are familiar with, and brachistichrone. Personally I always align prograde throughout a transfer instead of burning while locking a node  just because maneuvering a little radial in then radial out seems wasteful to me for most burns. IDK entirely where Im going here, just wondering what kind of maneuver nodes we'll see since it looks like the old single node in an instant is being evolved on. Thoughts?

[intelliCom]

I was confused about its wording. Did they mean "non-intrusive"?

What's a "non impulse" maneuver planner?

[TROPtastic]

10 minutes ago, intelliCom said:

I was confused about its wording. Did they mean "non-intrusive"?

What's a "non impulse" maneuver planner?

As suggested by HebaruSan in the Early Access announcement thread, non-impulsive most likely means that thrust maneuvers in the maneuver planner won't be modelled as having all the delta-v be spent at a single instant (the KSP1 model that created the advice to "take your total burn time, divide it in half, and then start burning at that length of time before the maneuver node"). 

This new maneuver planner will be very useful for anything that requires long periods of thrust, such as ion engines in general and future engines on interstellar transfers. However, the details of how it will be implemented will certainly be interesting (hence this thread).

Edited October 29, 2022 by TROPtastic
quoted as requested

[intelliCom]

36 minutes ago, TROPtastic said:

As suggested by HebaruSan in the Early Access announcement thread, non-impulsive most likely means that thrust maneuvers in the maneuver planner won't be modelled as having all the delta-v be spent at a single instant (the KSP1 model that created the advice to "take your total burn time, divide it in half, and then start burning at that length of time before the maneuver node"). 

This new maneuver planner will be very useful for anything that requires long periods of thrust, such as ion engines in general and future engines on interstellar transfers. However, the details of how it will be implemented will certainly be interesting (hence this thread).

In other words, a maneuver planner that takes the duration of the burn into account accurately?

That would be especially good for long-duration burns. Imagine a week-long burn using a fission fragment engine, and having that actually having a correct maneuver. Am I getting this right?

[intelliCom]

I have some suggested thoughts for non-impulsive maneuver planner. Next to each suggestion is stars between 1-3 to indicate difficulty of implementation, just in case actual devs see this:

1. ★★☆ - Ability to specify between a range of possible DV usage, between minimum and maximum
   • "Minimum" refers to the usual Hohmann transfer we're all used to; the minimal DV usage for an interplanetary transfer
   • "Maximum" refers to using all the DV in the craft for the fastest one-way brachistocrone trajectory possible.
   • Before generating the maneuver, the player can see how long the transfer will take based on their chosen DV amount.
2. ★★☆ - Any slight deviation from the first maneuver (e.g, being off by about 2 m/s out of 2000) and the game will adjust future maneuvers to follow as closely to the original as possible.
   • This was always a really annoying problem in KSP1. You would set a chain of maneuvers up, only for you to have finished one maneuver slightly off. This required adjustment to all the other maneuvers. Having the game automatically adjust them based on subtle variation in the previous maneuver would be extremely helpful.
3. ★☆☆ - Allow a chained maneuver plan to be generated by the player, back at the VAB (or any other launch site)
   • This means that the spacecraft's DV can be planned to follow the maneuvers, instead of the other way around.
4. ★★★ - Gravity assist generation
   • This is pretty difficult, so implementation of such a feature would be a miracle. But if it were included, it would allow players to minimise the DV on their spacecraft and get more science done.

Edited October 29, 2022 by intelliCom

[intelliCom]

52 minutes ago, dogecoin investor said:

Principia in KSP1 already models maneuvers non-impulsively (at least I think that's how it works, anyway). It uses some toggle buttons so the instant-impulse burn can also be modelled as an alternative.

Unfortunately, I cannot use that because I am a PersistentRotation user. Also a CKAN pleb.

[RKunze]

22 minutes ago, intelliCom said:

Unfortunately, I cannot use that because I am a PersistentRotation user

If it is only persistent rotation: You don't need the extra mod with Principia, persistent rotation is already built into it.

Other than that, Principia allows for some interesting stuff that doesn't exist with patched conics. Like low-energy transits, or orbiting Lagrange points.

[intelliCom]

3 minutes ago, RKunze said:

If it is only persistent rotation: You don't need the extra mod with Principia, persistent rotation is already built into it.

Other than that, Principia allows for some interesting stuff that doesn't exist with patched conics. Like low-energy transits, or orbiting Lagrange points.

Would the Outer Planets mod be a problem? Also, again, I'm a bit of a CKAN pleb. I don't know what goes into installing and uninstalling a mod. I tried it before, but there were too many issues arising so I went with CKAN as a result.

If OPM isn't an issue, do manual installs and CKAN mix just fine?

[intelliCom]

16 minutes ago, dogecoin investor said:

One thing I would like in KSP2 is some way of chaining multiple low TWR burns in succession with a single button, instead of having to calculate them and set up each burn manually. So a simple splitter where you input the delta V total along with the number of burns you want to split it into, and it does the rest. This would make low TWR burns so much less time consuming.

So basically a chain of periapsis kicks? That would also be nice, and would allow for more efficient usage of really low-thrust engines like the Dawn.

[RKunze]

1 hour ago, intelliCom said:

Would the Outer Planets mod be a problem?

Probably not. I did not play with Principia and OPM myself, but JNSQ and Principia work well.

1 hour ago, intelliCom said:

Also, again, I'm a bit of a CKAN pleb. I don't know what goes into installing and uninstalling a mod.

To install: Download the ZIP file from the link in the Principia thread (or in Github) and unpack it in your KSP directory.

To uninstall: Delete the GameData/Principia subdirectory.

I'm using CKAN for most mods myself, works pretty well with the occasional mod installed manually.

[intelliCom]

40 minutes ago, RKunze said:

Probably not. I did not play with Principia and OPM myself, but JNSQ and Principia work well.

To install: Download the ZIP file from the link in the Principia thread (or in Github) and unpack it in your KSP directory.

To uninstall: Delete the GameData/Principia subdirectory.

I'm using CKAN for most mods myself, works pretty well with the occasional mod installed manually.

Going to try JNSQ. Looks amazing, like a better Astronomer's Visual Pack (I always disliked Jool's slight teal tint).

Last few things before I give it and Principia a go:

• Is there incompatibility with Astrogator? I've been using that to generate a lot of my interplanetary maneuvers, but Principia seems to use a new system.
• Is there incompatibility with Kerbalism? The way it handles communication is pretty brutal, and upload speeds for science really suffer going past Duna. It also has its own specific science experiements, which may not work for the new planets in JNSQ.
• Are there any notable incompatibilities with either Kerbalism or JNSQ outside of PersistentRotation?
• How dangerous is it to change an already-existing save with a new solar system and adding Principia? Been working on a career save in OPM for a while now, and wish I could keep my progress.

Edited October 29, 2022 by intelliCom

[RKunze]

1 hour ago, intelliCom said:

Is there incompatibility with Astrogator

Don't know, haven't used Astrogator myself.

1 hour ago, intelliCom said:

Is there incompatibility with Kerbalism?

No. Principia and Kerbalism work fine.

1 hour ago, intelliCom said:

Are there any notable incompatibilities with either Kerbalism or JNSQ

Not that I know. JNSQ even has dedicated support for Principia (mostly changing some orbits which would not be stable otherwise - most visible of those is that Minmus is Kerbins inner moon with Principia).

 

1 hour ago, intelliCom said:

How dangerous is it to change an already-existing save with a new solar system and adding Principia? Been working on a career save in OPM for a while now, and wish I could keep my progress.

Depends on where your craft and stations are - stations in orbit around or bases on bodies that do not exist in the new system will probably be in trouble. And even orbits around bodies that are unchanged may be different with N-body physics instead of patched conics.

I'd recommend to backup your save before you try.

[magnemoe]

7 hours ago, intelliCom said:

I have some suggested thoughts for non-impulsive maneuver planner. Next to each suggestion is stars between 1-3 to indicate difficulty of implementation, just in case actual devs see this:

1. ★★☆ - Ability to specify between a range of possible DV usage, between minimum and maximum
   • "Minimum" refers to the usual Hohmann transfer we're all used to; the minimal DV usage for an interplanetary transfer
   • "Maximum" refers to using all the DV in the craft for the fastest one-way brachistocrone trajectory possible.
   • Before generating the maneuver, the player can see how long the transfer will take based on their chosen DV amount.
2. ★★☆ - Any slight deviation from the first maneuver (e.g, being off by about 2 m/s out of 2000) and the game will adjust future maneuvers to follow as closely to the original as possible.
   • This was always a really annoying problem in KSP1. You would set a chain of maneuvers up, only for you to have finished one maneuver slightly off. This required adjustment to all the other maneuvers. Having the game automatically adjust them based on subtle variation in the previous maneuver would be extremely helpful.
3. ★☆☆ - Allow a chained maneuver plan to be generated by the player, back at the VAB (or any other launch site)
   • This means that the spacecraft's DV can be planned to follow the maneuvers, instead of the other way around.
4. ★★★ - Gravity assist generation
   • This is pretty difficult, so implementation of such a feature would be a miracle. But if it were included, it would allow players to minimise the DV on their spacecraft and get more science done.

1 agree, but you should be able to cap dV use, I found porkshops in Mechjeb to be very nice then doing high dV burns as in 20-70 km/s with orion pulse nuclear mods. 
Benefit is that you can see the best time to launch although with an 50 km/s burn your only issue is passing to close to the sun  
Porkshops is also very nice going between Mun and Minmus as you can refuel at both. And in the Jool system. 
2 This will work for the Mun but not Minmus as it has an inclination, even with the same craft.  
Also I tend to do Minmus runs in down to 3 days, its only cost 50-100 m/s more, yes you need up 300 m/s or more getting into orbit. Now this depend a lot of the craft, if its something I want and has the dV I go fast, If its an returning tanker and I have enough fuel in LKO, I can leave more fuel and go slow. 
3 don't see the point here, maneuver depend on craft and how much fuel it has who depend on how precise your launch was. 
An better way to set up multiple burns to raise Ap however would be nice.  
4 yes that would be interesting, you can do it to some degree in KSP 1 making nodes inside the SOI, done it a bit around Jool. 

[Gargamel]

I actually had to check the thread title to remember what we were supposed to be talking about.     Let’s keep the discussion to the KSP2 maneuver planner, and take add-on discussion to well, add-on discussion.   

[mcwaffles2003]

I wasn't simply taking about something like a better burn time indicator, that is just something to help approximate an impulsive maneuver node. I'm trying to talk about a node that shifts direction throughout the burn, similar to how prograde changes direction throughout an orbit.

When we lock to a maneuver node during a burn it can seem like we are burning in a straight line, but we actually are burning in a curved path on a Non-Euclidean surface which means our burns are slightly inefficient and wasteful though they are simpler and can keep things like a periapsis in a much more steady position for burns which take multiple orbits to complete, helping to more greatly utilize the Oberth effect. I get that this is a very subtle type of nitpick, but I have found making prograde burn maneuvers to save a not necessarily insignificant amount of delta v (like 20-30 m/s dV on a kerbin - mun transfer).

In the end I'm just curious about what non-impulsive maneuver nodes will look like/behave or operate.

Edited October 29, 2022 by mcwaffles2003

[Wubslin]

If it works anything like it does in Children of a Dead Earth, I'll be happy. Here's a ship in orbit of Mars. I simultaneously burn retrograde and normal to put myself in a polar orbit. The burn lasts an entire hour, and the curved path my ship follows while firing its engines is highlighted in orange. If the KSP 2 devs have built an iterative trajectory plotter for orbit around Rask and Rusk, that's probably the same technology they'll use for non-impulsive maneuvers just like in CoaDE. When multiple dynamic forces are exerted on your ship at the same time you really have to discretize the motion into little steps to accurately predict how it'll move. Firing your engine while in orbit of a body is almost like being in a Rask/Rusk system where one of the bodies is infinitely massive and infinitely far away (thus a constant acceleration gradient against the direction your ship is pointing, the same as firing your engines.) In this example, You can imagine a source of gravity in the direction of the orange burn arrow attracting my ship by a constant 60 milli-Gs for an hour. Mathematically, solving that motion looks similar to being in free fall around a binary pair like Rask and Rusk. In any case, just having the line show where you're going to go is fine.

You can see an arrow indicating the direction my ship will be burning in at the outset of the burn. For very long burns, many of these arrows are present all along the orange trajectory illustrating the direction the ship will be pointing.

And after the burn, a polar orbit of Mars:

 

 

 

 

[OHara]

I would guess KSP2 will plan slow-burn manoeuvres by assuming the craft will rotate during the burn to follow the prograde/normal/radial directions.  Principia does this.  Very-low-thrust craft that raise their orbits in a long spiral would need to point continuously prograde.  A planner that has the burn follow prograde would help to plan such spirals.

The other choice could also work well: planning under the assumption that long burns follow a fixed direction in space, and giving us a pointer to that direction analogous to   in KSP1.  Plane changes are more efficient if you burn while pointing in a fixed direction, rather than always follow the rotating normal vector as your orbit rotates.

I would guess that KSP2 will "always simulate non-impulsively" for the sake of simpler UI.  To figure the results of an extended-burn, KSP2 will need to know what throttle level we plan to use, but it may just assume full throttle and let us thrust-limit the engine when we need different.  The extended-burn calculation naturally converges to the 'single-impulse' approximation when the burn is short enough.

[kerbiloid]

The new maneuver GUI is called "non-impulsive" because it's made so much better, that you stop impulsively hitting the buttons with fist, exclaiming "What the thing does it mean?!"

[intelliCom]

14 minutes ago, kerbiloid said:

The new maneuver GUI is called "non-impulsive" because it's made so much better, that you stop impulsively hitting the buttons with fist, exclaiming "What the thing does it mean?!"

Literally me dealing with Radial Out and Radial In. Like Prograde and Retrograde are forwards and backwards respectively, Normal and Antinormal tilt the orbit. What exactly is the Radial pair doing?

[ColdJ]

2 minutes ago, intelliCom said:

Literally me dealing with Radial Out and Radial In. Like Prograde and Retrograde are forwards and backwards respectively, Normal and Antinormal tilt the orbit. What exactly is the Radial pair doing?

Changing the shape of your orbit, depending on where you are in comparisson to PE an AP at the time you use them.

[intelliCom]

Just now, ColdJ said:

Changing the shape of your orbit

This is literally every maneuver node. They all change the shape of your orbit in different ways.

[ColdJ]

1 minute ago, intelliCom said:

This is literally every maneuver node. They all change the shape of your orbit in different ways.

Sorry. I thought you were well versed and so didn't need to make it more complex.

Say you have an uneven orbit where your PE is a bit close. You do not want to change the speed you are orbiting at, you just want to even out the orbit so that PE and AP are about the same. Radial in, I think at the halway point from PE to AP and you will decrease AP and increase PE. Inversely Radial out after AP on the way to PE will do the same. It also is usually more frugal than Pro or retro.

Also remember, Prograde is the path along which your craft is flying. It is not your relationship to the planet. That is why with the  point of closest intercept window you can far more efficiently decrease your intercept distance with the craft you are targeting, just using your RCS. You are changing your prograde in relation to your target, side to side in 2 planes, rather than increasing or decreasing your velocity. Makes it much easier to arrange a meeting for docking.

[intelliCom]

33 minutes ago, ColdJ said:

Sorry. I thought you were well versed and so didn't need to make it more complex.

I mean, it's not like I haven't used radial in/out before. I really only use it if I'm trying to circularize my orbit more precisely.
To my understanding, radial out puts the periapsis behind me and the apoapsis ahead of me, while radial in does the reverse.

I guess what I'm really trying to understand is how it's useful beyond circularisation?

[ColdJ]

2 hours ago, intelliCom said:

I guess what I'm really trying to understand is how it's useful beyond circularisation?

Well, to do the opposite too I suppose. Either to decrease PE at the appropriate point for insertion into the atmosphere or increase AP at the right place so as to more efficiently break free of the influence of a planet and head out to to another one. In each case without significant change in velocity. The trouble with only speeding up or slowing down is that you then have waste more fuel to compensate when you get where you are headed. Using it to get closer at PE means that if you do it correctly you can use atmospheric drag to slow you and use less fuel. Using it to choose where in orbit your AP is means setting up where is most efficient to accelerate to a course to get free of the planets influence or get captured by the Mun etc.

This is just in relation to nodes of course. When not using nodes it is a way of targeting the nearest celestial body.

[mcwaffles2003]

6 hours ago, intelliCom said:

Literally me dealing with Radial Out and Radial In. Like Prograde and Retrograde are forwards and backwards respectively, Normal and Antinormal tilt the orbit. What exactly is the Radial pair doing?

changes position of periapsis and apoapsis