New Maneuver Node Editing Tool

[Morse]

25 minutes ago, michelcolman said:

- Maybe add the maneuver direction icons (prograde, normal, radial) to make it clear which one you're adjusting.

Yes, of course. I didn't include the icons in the mockup, but they'll be there.

26 minutes ago, michelcolman said:

- "Orbit mode:" would probably be better named "Conics mode:" since escape trajectories are not technically orbits.

- Not sure what the "+orbits" and "-orbits" buttons do, does that change CONIC_PATCH_LIMIT? In that case it's certainly a good idea to include it, but it might be confused with the +/- buttons on the standard maneuver nodes which go to the next and previous orbits. Since it's changing a setting just like the "orbit mode" buttons that are directly above, it's probably better to add a label "Number of conics" for better visual consistency, or even better "Display 3 conics" with "+"/"-" buttons behind it that change the number.

The question is, if the term "conics" is that familiar to the general public. As for +/-, I'll think of a way to make it more clear what they do. And I don't think I can show the number of displayed conics since there is no API for that (maybe they introduced something, I should check).

29 minutes ago, michelcolman said:

- Can you also display the three individual delta-v components instead of just the total delta-v? And maybe to a higher than 0.1 m/s precision. With atomic engines, I often make really tiny adjustments by pressing shift and immediately X again. Nice if you want to leave a gravity assist trajectory exactly in the orbital plane, for example. Doesn't matter much when you're just going to the Mun, but makes a huge difference when pingponging in the Jool system.

This gizmo is not for precise corrections. For that you should use the default view, which is already implemented in both Precise Maneuver and Precise Node mods.

32 minutes ago, michelcolman said:

- Stock maneuver nodes are relative to the new path for some reason. When you add a normal burn, the node axes twist around so that the normal vector is really applying some unwanted retrograde. It would often be useful to define the node relative to the old path. I understand it may take a lot of work to convert between the two, but if it's at all possible, it would be a great addition if users could switch between "relative to old" and "relative to new". (The actual node will probably always be relative to the new path, but your window could display and manipulate a converted set of values)

Don't think I'm getting you here. When you're applying normal, it's normal component that gets changed, and nothing else. The ability to turn orbit is already implemented in both Precise Maneuver (as a "turn orbit" control) and Precise Node (as "intuitive maneuver" switch), but there is no such thing in the stock gizmo.

38 minutes ago, michelcolman said:

- An "execute maneuver" button like the one in Mechjeb would be nice, too. But try to make it more precise, Mechjeb's execution only has about a 0.1 m/s accuracy, so I usually have to do the last bit of the burn by hand to get exactly the path I want.

Ah, yes, the "execute maneuver" button was the one I wanted to add for a long time. The problem is, it's easier said than done. After looking at MechJeb code for maneuver execution I was surprised at how complicated this task is. There is no way you could take this functionality to this mod without bringing half of MechJeb's code. As for additional precision, it's not needed actually. The accumulated floating point error for long-range trips is just about the same 0.01 as MechJeb gives you. So while you can change the error threshold to 0.001 or even less, it won't change anything. You'll still have to do mid-trip corrections. This is also the reason why I didn't include the step less than 0.01 to Precise Maneuver. It is just pointless.

[michelcolman]

Quote

And I don't think I can show the number of displayed conics since there is no API for that (maybe they introduced something, I should check).

That's strange, you can increment and decrement it but you can't get the current value?

Quote

Don't think I'm getting you here. When you're applying normal, it's normal component that gets changed, and nothing else. The ability to turn orbit is already implemented in both Precise Maneuver (as a "turn orbit" control) and Precise Node (as "intuitive maneuver" switch), but there is no such thing in the stock gizmo.

I haven't actually tried the current version of precise node/maneuver yet, and right now I'm running the KSP beta, but maybe "intuitive maneuver" already does what I was looking for. Just to make sure it's the same thing: the stock maneuver nodes have the annoying "feature" of lining up with the new trajectory rather than the old one. So as you input more normal component, the node twists around so that "normal" becomes something in between normal and retrograde. And if you want to reverse the direction of your craft with lots of retrograde, you can't because the node flips around when your predicted speed passes through zero, making prograde and retrograde switch places. It would be nice if we could use a node that remains lined up with the old trajectory so that 100 m/s "normal" really means "point the nose towards the triangle, then burn 100 m/s". But if that's what "intuitive maneuver" does, then great, you've already implemented it :-)

Quote

The accumulated floating point error for long-range trips is just about the same 0.01 as MechJeb gives you. So while you can change the error threshold to 0.001 or even less, it won't change anything.

I do use such minuscule corrections when I'm bouncing around in the Jool system. On my last trip, after setting course to Jool from somewhere around Duna, I used a grand total of 18 m/s to

- get captured by Jool using a gravity assist from Laythe

- pass through the Jool upper atmosphere using an assist from Tylo

- set up further assists to get all high and low science from all non-polar biomes of the three inner moons.

All of that with 18 m/s, so the individual corrections were just a few m/s each. In that context, 0.003 m/s can make the difference between exiting a moon's SOI precisely in the orbital plane, or ever so slightly out of the plane. I could really see the path jump a little with a 0.01 m/s change. The hyperbolic trajectories multiply the error quite a bit and make subsequent encounters (which also had to be as near to the orbital plane as possible) significantly more costly to set up.

But anyway, if it's such a lot of work, never mind, I'll just keep doing it the old-fashioned way.

Thanks,

Michel

[Morse]

30 minutes ago, michelcolman said:

That's strange, you can increment and decrement it but you can't get the current value?

Pretty much. At least I didn't find it.

31 minutes ago, michelcolman said:

So as you input more normal component, the node twists around so that "normal" becomes something in between normal and retrograde. And if you want to reverse the direction of your craft with lots of retrograde, you can't because the node flips around when your predicted speed passes through zero, making prograde and retrograde switch places.

Sounds like you want a re-implementation of a stock gizmo. I don't think that any mod will ever do it.

33 minutes ago, michelcolman said:

In that context, 0.003 m/s can make the difference between exiting a moon's SOI precisely in the orbital plane, or ever so slightly out of the plane.

Yes, it could. I didn't say that any corrections beyond 0.01 do not change the trajectory, they do. The problem is, there is no way to predict what kind of change such corrections will introduce. If you take Precise Node or Precise Maneuver mod, and start adding and subtracting 0.01 m/s for a far-off trip, you'll see that after adding and subtracting it the trajectory will change, although it should've remained the same. That is the cumulative floating point error, which makes it pointless to change the dV with better precision, since the impact from the error is bigger than from the change itself.

[michelcolman]

Quote

Sounds like you want a re-implementation of a stock gizmo. I don't think that any mod will ever do it.

I was thinking you could have a switch between "relative to old" and "relative to new" in the PreciseManeuver window which would only affect the display in that window. The stock gizmo will always show "relative to new", but the values in the PreciseManeuver window could be converted values that are relative to the old trajectory. Whenever you change those values, they get converted to the new trajectory for the actual maneuver node. If you change the maneuver node directly, those values get converted to the old trajectory in PreciseManeuver.

So even if you can't change the stock gizmo, your window could give the impression of showing a node relative to the old trajectory, with transparent conversions back and forth.

For a minute I thought that was what your "intuitive maneuver" did, but now it looks like that's something different after all?

Quote

Yes, it could. I didn't say that any corrections beyond 0.01 do not change the trajectory, they do. The problem is, there is no way to predict what kind of change such corrections will introduce.

I understand what you mean, and it's true over long distances, but in the Jool system in my experience it really was very precise.

I have indeed seen trajectories that looked completely different after adding and then subtracting 0.1 m/s, especially for interplanetary intercepts where the final result was nowhere near the prediction. But I've also seen trajectories that consistently moved in the same direction with successive inputs of less than 0.01, and the final flown trajectory matched the prediction. That was for small corrections over a timescale of a few hours in the Jool system.

[Morse]

Show what exactly "relative to old" or "relative to new"? Both mods show only the raw dV values, you add them to "old" to get the "new". How can you show them relative to anything?

intuitive maneuver changes the way the "normal" change is applied, so that it not added the raw normal dV, but instead turned the orbit in the normal direction without changing it's form. But it doesn't change the way anything is shown. You still see the same raw values.

[michelcolman]

I'm really sorry, I've done some experimenting and I finally understand what's going on with these stock maneuver node gizmos. Even though for some weird reason the gizmos are twisting to match the new trajectory, the actual inputs are still relative to the old one! That's so counterintuitive it's unbelievable it made it into the released game this way and hasn't been corrected since.

I just gave it a try: started with a circular horizontal orbit, used the stock gizmo to add lots of normal. Track twists up, normal vector now points to the right, but more normal only makes it go up more (NOT in the direction of the handle, but in the direction the handle was pointing in originally). Meanwhile the prograde handle is now pointing up, in the new direction of the trajectory. But if I now pull that handle upwards, it does not change the track in that direction but actually moves it towards the original prograde direction, so back towards horizontal even though you are pulling a handle that is pointing vertically. That's just so wrong it staggers the mind. Why does the gizmo rotate if it still gives inputs in the unrotated reference frame? The gizmo should just stay put!

I was thinking that the handles were pulling the trajectory in the current direction of the handle, which would have meant that some kind of complicated calculation was going on behind the scenes with inputs being given in the new coordinates (handle pointing to the right means raw delta-v to the right), but I was overthinking it. In fact the maneuver gizmo is simply pointing in the wrong direction and all inputs are really given in the original reference frame. I think I'll file a bug report because that makes no sense whatsoever. I bet I won't be the first one, though.

Anyway, that means you don't have to change anything to your code, sorry about the confusion!

[sal_vager]

This really needs HarvesteR's attention, you're pinned for April @Alshain!

[Pthigrivi]

This has been a great idea for a long time

[sarbian]

On 3/31/2016 at 0:34 PM, Morse said:

 And I don't think I can show the number of displayed conics since there is no API for that (maybe they introduced something, I should check).

Uh?!? . What to you use the get the nodes ? vessel.patchedConicSolver.maneuverNodes is a List, so getting the count is trivial.

[Morse]

And if it was the number of nodes that was needed to be displayed, you'd be totally correct. But we were talking about conic patches, totally different thing.

[sarbian]

 vessel.patchedConicSolver.patches.Count ? Or flightPlan. All those are public.

[Morse]

Can't say for sure, but probably not. patchedConicSolver doesn't deal with drawing, this count probably tells the total number patches, not how many of them are on the screen.

Anyway, I'll investigate it further somewhere down the line. Right now I'm busy learning how this infernal prefab-driven GUI works.

[sarbian]

then it is vessel.patchedConicRenderer where you have patchRenders & flightPlanRenders.

[swjr-swis]

On 3/31/2016 at 9:55 AM, Morse said:

what kind of visual effects should show the usage of the controls (the hover-on glow is a no brainer obviously, but when you click and drag, should it be a stretch, or an increasing glow, or both, or what).

A suggestion: maybe an animated dotted line through the axis that 'moves' in the direction of the control applied. Probably easier to render than a stretching arrow, and avoids differences in user sensitivity to things like colour or glow level.

[John FX]

I like this idea. Add me to the people who would want a way of entering numbers to make a node. For example I know that for a FRT around Mun I need 872Dv and then I adjust the time of the burn for a FRT. It would be really nice to be able to just enter 872 in the prograde box...

[mattssheep4]

I wouldn't mind having a "click at desired apoapsis, then periapsis" function, then deal with small adjustments (decreasing the sensitivity of dragging the controls).

[John FX]

On 31/03/2016 at 8:55 AM, Morse said:

Hi, author of the Precise Maneuver mod here.

I'm about to update my mod for 1.1, and to overhaul it a little in the process. I want to do it modular, and I'm thinking about adding this kind of gizmo as one of the modules. I imagine it to look something like this (a rough mockup, icons are not shown, but they'll be there):

All the modules should be optional (i.e. node selector module, orbit mode module and so on) so in the extreme case you'll be able to disable all the modules except the one, and have a window very close in the functionality and look to the proposed in this thread. I'm still not sure about the details, and what kind of visual effects should show the usage of the controls (the hover-on glow is a no brainer obviously, but when you click and drag, should it be a stretch, or an increasing glow, or both, or what).

Suggestions are welcome. I intend to start coding during the weekend, hopefully it'll be ready for 1.1 release.

Yes please, that looks rather nice. If there is some way to enter numbers at the same time as this window being open that would be great.

[StarManta]

I have a feature to add to this: Undo. If you have dragged it too far in one direction, or dragged it until you realized it was the wrong direction to drag it, you can undo.

[Buckley]

+1

The maneuver node is, I believe, 2nd only to the Navball in terms of importance and commonly used parts of the interface.  (Ok, so the VAB/SPH editor could be up there too, but I digress...)

 

As such, it should get all the love possible and all the little annoyances of the existing should be solved with extreme prejudice. . Seriously though, in terms of return on investment in terms of player experience it's a no brainer.

Your proposal could be a fantastic leap for Kerbal kind.

[cfds]

On 31.3.2016 at 9:55 AM, Morse said:

Hi, author of the Precise Maneuver mod here.

I'm about to update my mod for 1.1, and to overhaul it a little in the process. I want to do it modular, and I'm thinking about adding this kind of gizmo as one of the modules. I imagine it to look something like this (a rough mockup, icons are not shown, but they'll be there):

 

I don't understand why anyone would want to pull at some handles instead of just entering the values by hand or do customizable steps. Precise manoeuvre is perfect as it is now,  if it ain't broken, don't try to 'improve' it with appleish extras.

[Alshain]

26 minutes ago, cfds said:

I don't understand why anyone would want to pull at some handles instead of just entering the values by hand or do customizable steps. Precise manoeuvre is perfect as it is now,  if it ain't broken, don't try to 'improve' it with appleish extras.

It depends on if you want to use outside calculators to get those numbers or just plan a maneuver on your own.  FWIW, I don't know this mod, but I don't believe he intended to remove the old, just add on to it with another mode so you can choose.  Entering numbers is useless unless you either have a calculator to give them to you or are skilled enough to determine them yourself.  That is the reason Squad hasn't done numbers.

Personally I welcome a demonstration of the original idea, if anything just to convince Squad how much it is needed in stock.

Edited April 14, 2016 by Alshain

[Morse]

1 hour ago, cfds said:

Precise manoeuvre is perfect as it is now,  if it ain't broken, don't try to 'improve' it with appleish extras.

Just of curiosity, what do you mean by "as it is now"? Because the old version can't be perfect since it won't work with 1.1, and the new version is still pre-release, and has some bugs and some unimplemented bits. So leaving it unchanged is not the best idea, whether you want this gizmo to be added or not.

[cfds]

Perhaps I am confusing it with some other mod to edit manoeuvre nodes in a deterministic way and I meant "ho it works in 1.0.4". But in what circumstance will "pull on a handle" ever be preferable to "add specified quantum of dV by clicking on a little button"?

[Morse]

It will be preferable to people who are used to pulling the handles, who are comfortable with pulling the handles, and just want that the handles were more convenient. No doubt they will ask you: "why on earth do you prefer clicking the buttons, when you can just pull the handles?"

[Alshain]

13 hours ago, cfds said:

Perhaps I am confusing it with some other mod to edit manoeuvre nodes in a deterministic way and I meant "ho it works in 1.0.4". But in what circumstance will "pull on a handle" ever be preferable to "add specified quantum of dV by clicking on a little button"?

In what circumstance will "click a button 1000 times" ever be preferable to "drag the maneuver to where you want it".  Do you use all keyboard shortcuts on your OS or do you use a mouse to point and click to the program you want to start?