[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[vitorboschi]

13 hours ago, Arrowstar said:

I'm not sure.  I can't reproduce any propagation error on either Windows or Linux.  Can you try to duplicate the error in a clean MAT file?  And double check you're seeing "v1.6.7 PR9" in LVD's output area, of course.

Alright, I'll try to redo the .mat from zero and let you know if I face the problem again.

[Arrowstar]

3 hours ago, Snoman314 said:

OK, here's the .mat file:

https://drive.google.com/file/d/1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy/view?usp=sharing

This was made in pre-release9, if it matters.

Issue resolved for next release.

[Arrowstar]

By the way, if anyone has outstanding bugs or issues that I haven't already addressed, please let me know ASAP.  I want to put out a pre-release tomorrow before I take a break for a few weeks for Christmas.  Thanks!

12 hours ago, vitorboschi said:

Alright, I'll try to redo the .mat from zero and let you know if I face the problem again.

Any luck with reproducing your error?

[Arrowstar]

Hey guys, changes are coming to the LVD engine data dialog box that I want to show off tonight.  Previously, users entered in the engine's sea level and vacuum thrust and Isp and the code linearly interpolated between these data w.r.t. the ambient pressure outside.  While this was simple, it also posed some limitations for high pressure environments like sea level on Eve, where the pressure is significantly greater than Kerbin's sea level pressure.  Namely, engine thrust and Isp were not computed correctly at these pressures.

Coming in the next pre-release, you'll now see those text areas replaced with two new buttons for editing custom thrust and Isp curves.

These buttons open a dialog box identical to the existing "throttle modifier profile" button.

Engines must have two data points, one at Kerbin sea level and one at vacuum.  Other data points can be added, and intermediate points are interpolated linearly.

Existing engine data will be automatically ported over to the new system when you first load an LVD case, and no action is necessary by the user to make the update.  It should "just work."

Please let me know if you have any questions!  Thanks.

EDIT: You can also import data into the engines (thrust, isp, min and max throttle) directly from KSP engine config files now.  It's a right click context menu in the Edit Engine dialog box, if you right click on the thrust or isp buttons or min/max throttle text areas.

Edited December 19, 2020 by Arrowstar

[Arrowstar]

Hi everyone,

Tonight I've pushed out KSPTOT v1.6.7 pre-release 10.  This pre-release has a few new features and bug fixes. Here's the change log.

• LVD: View axis limit and camera information is now properly stored for various camera properties in the view profile. The information is recalled correctly if the user does not wish for view axes limits to be updated after propagation.
• LVD: Fixed bugs regarding vessel orbit import from KSP and SFS files in initial state and set kinematic state UIs.
• MA: Fixed bug with propagating to node calculations.
• LVD: Engines now model thrust and isp as a function of pressure through the use of curves and not the hard-coded vacuum and sea level pressure points.
  • The interpolation scheme also moved to griddedinterpolants that use linear interpolation and nearest neighbor extrapolation.
• LVD: Engine data can now be imported from KSP engine config files.
  • Right click in the edit engine dialog box on the thrust and Isp buttons.

Please let me know if you find any bugs.  Thanks!

Edited December 19, 2020 by Arrowstar

[DBowman]

I've had some reasonable success with LDV (achieved orbit, and able to improve excess prop via optimizing), but my method is a bit "brittle", and I really want to find a global maxima, not the local one I was near. Could you advise me on a more flexible way to get it done?

My current method is to have a few "pitch segments" which I setup by hand (intending to let the optimizer tweak them later), the last one has -ve pitch and terminates when Ap alt reaches 250 km. The optimizer then controls pitch and duration for the circularization burn at Ap. If I (or the optimizer) tweaks one of the pitch segments "too much" the desired Ap is passed before the event that terminates on reaching Ap - so it never terminates. Adding a constraint on Ap alt doesn't seem to help. I guess I don't know how to tell it that it's a infinity weighted importance, and if it did bail it wouldn't have a gradient to follow (if that's how its' working). 

How should I approach it? Like the tute doc? 7 pitch segments and constraints on (C3 & Ap alt or Pe alt),  (speed & Ap & Pe), something else? How close do the initial pitch segment settings need to be for the optimizer to "find something"

[vitorboschi]

On 12/18/2020 at 8:05 PM, Arrowstar said:

By the way, if anyone has outstanding bugs or issues that I haven't already addressed, please let me know ASAP.  I want to put out a pre-release tomorrow before I take a break for a few weeks for Christmas.  Thanks!

Any luck with reproducing your error?

Sorry for the late response @Arrowstar. I couldn't reproduce the problem so far.

[vitorboschi]

@Arrowstaris it possible to add the "Upload maneuver node" feature to LVD (for impulsive Delta-V actions)?

[Arrowstar]

11 hours ago, DBowman said:

How should I approach it? Like the tute doc? 7 pitch segments and constraints on (C3 & Ap alt or Pe alt),  (speed & Ap & Pe), something else? How close do the initial pitch segment settings need to be for the optimizer to "find something"

Here are some thoughts:

• "How close do I need to be?"  While there's no good answer to this, the best I can provide is "reasonably close."  If it looks like your current trajectory is off in the weeds, it probably is.  Use the variable adjuster (Optimization -> Adjust Variables) to accomplish this.
• Seven pitch rate changes is probably a bit much.  I bet it's possible to get by with 4-5.  To many variables can confuse fmincon() in highly non-linear problems like this.
• I would actually recommend using radius, velocity, and flight path angle as your final orbit insertion targets.  Use the appropriate astrodynamics calculator (Tools -> Astrodynamics Calculators) to get these values from SMA, eccentricity, and true anomaly. 
  • I can tell you from real life experience that constraining to Rp and Ra (or altitudes) doesn't work nearly as well. 
  • Additionally, remember that if you constrain C3, you've also constrained SMA so you should not then go constrain Ra and Rp (or altitudes).  You can pick one but don't do both. Otherwise you over-constrain the problem.
• For a powered ascent from the surface, it's generally best to make all of your event termination criteria "event duration," especially if you're using them for orbit insertion targets.  Trying to use other quantities can make things highly non-linear and cause issues, like you experienced.  Convert your current termination criteria to event duration and  set constrains where you need them instead.
  • The only time it's acceptable to use non-time event termination criteria, in my opinion, is when you can be absolutely sure that you won't blow past them.  For example, for lift off from the Mun, you might do a short vertical rise to a specified altitude.  You can't miss it if you know you start below that altitude, so then it's okay.

Let me know if you have other questions, and good luck! :)

8 hours ago, vitorboschi said:

@Arrowstaris it possible to add the "Upload maneuver node" feature to LVD (for impulsive Delta-V actions)?

Sure, I'll look into adding that.  Good suggestion. :)

9 hours ago, vitorboschi said:

Sorry for the late response @Arrowstar. I couldn't reproduce the problem so far.

Okay, no worries. :)

[Snoman314]

On 12/20/2020 at 11:21 AM, Arrowstar said:

Please let me know if you find any bugs.  Thanks!

Thanks again for all your work on this. 

I think I've found a bug though. I keep getting this error message when trying to optimise in the Mission Architect:

Mission file: https://drive.google.com/open?id=1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy

Log file: https://drive.google.com/open?id=136mMM_Dxa8itown92urP4s-UbsLqvAvZ

I've tried turning off Parallelisation, restarting KSP TOT completely, and changing optimisation algorithm. Same results every time.

 

[Snoman314]

Now for another one unfortunately:

I tried to set up the same mission in the LVD. (I can set initial state now, so that's working )

I didn't get as far as optimising this one however. I had two main problems

1. Putting in coast events to True Anomalies (to coast to apoapsis or periapsis), it didn't always propagate to where I'd expect. i.e. if I set the Termination condition to a TA of 0, the event would end immediately at apoapsis. 90 degrees and 45 degrees both got the graphic to display periapsis.
2. When I set two body propagation, I get this:

Mission file: https://drive.google.com/open?id=1wA1JKlEH4mB0ktQwRr1apYdFEpOb10TD

[Arrowstar]

8 hours ago, Snoman314 said:

Thanks again for all your work on this. 

I think I've found a bug though. I keep getting this error message when trying to optimise in the Mission Architect:

Mission file: https://drive.google.com/open?id=1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy

Log file: https://drive.google.com/open?id=136mMM_Dxa8itown92urP4s-UbsLqvAvZ

I've tried turning off Parallelisation, restarting KSP TOT completely, and changing optimisation algorithm. Same results every time.

 

Issue resolved for next release.  Thanks for the report.

8 hours ago, Snoman314 said:

Now for another one unfortunately:

I tried to set up the same mission in the LVD. (I can set initial state now, so that's working )

I didn't get as far as optimising this one however. I had two main problems

1. Putting in coast events to True Anomalies (to coast to apoapsis or periapsis), it didn't always propagate to where I'd expect. i.e. if I set the Termination condition to a TA of 0, the event would end immediately at apoapsis. 90 degrees and 45 degrees both got the graphic to display periapsis.
2. When I set two body propagation, I get this:

Mission file: https://drive.google.com/open?id=1wA1JKlEH4mB0ktQwRr1apYdFEpOb10TD

1. Yeah, the true anomaly termination condition has always been a pain in the neck.  I think figured out a decent way to do it this morning.  It seems to work in all my tests, anyway.  But really this is a much harder problem than it looks for a numerical integrator because of the annoying instances when your true anomaly has to go through 0 to get to the point you want.  Hopefully my new technique is good enough.
2. The issue here is that you switched to the two body propagator.  This propagator can take large steps because the equation of motion is so simple (M_dot = n).  The solution here is to specify the step size of the integrator directly in the events that you use it.  Open the event, click integrator options, and then set the step size to something reasonable and greater than 0.  Aim for about ~100 steps per integration in your step size.  Do not just set it to 1 second or something super small, the code will take forever to run.

I'll try to get a PR11 build out today with these fixes, but be aware that it will be Windows only as I'm away from my Linux environment.  

[vitorboschi]

@ArrowstarNot sure whether it's a bug or the memory requirements is really high: on the Flyby porkchop plotter, if I put a sequence like this: Kerbin, Jool, Eve, Moho and let everything else at default, KSP-TOT will run for a while until logs this error:

Out of memory. Type HELP MEMORY for your options.

Error in multiFlybyObjFunc (line 97)


Error in flyByPorkchopPlotterGUI>@(x)multiFlybyObjFunc(x,numRevsArr,wayPtBodies,false,false,celBodyData) (line 513)


Error in flyByPorkchopPlotterGUI>computeFlybyPorkchopPlotButton_Callback (line 514)


Error in gui_mainfcn (line 95)


Error in flyByPorkchopPlotterGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)flyByPorkchopPlotterGUI('computeFlybyPorkchopPlotButton_Callback',hObject,eventdata,guidata(hObject))

Error using waitforallfiguresclosed (line 9)
Error while evaluating UIControl Callback.

This is happening on a system with 48 GB of ram.

 

Another one:

While messing around on LVD, I removed one of the sequential events that contained an Impulsive Delta-V action that had all 3 components as  variables that should be optimized. However, when starting the optimizer, I could see that there were 3 variables more than it should be on the variables graph (the one at the top). After closing KSP-TOT and reopening the .mat, the problem seemed to be fixed. I guess some reference was left dangling (I think there were constraints referring to that event, but not sure). Unfortunately I forgot to keep a copy of this .mat for you

 

[Arrowstar]

47 minutes ago, vitorboschi said:

@ArrowstarNot sure whether it's a bug or the memory requirements is really high: on the Flyby porkchop plotter, if I put a sequence like this: Kerbin, Jool, Eve, Moho and let everything else at default, KSP-TOT will run for a while until logs this error:

Out of memory. Type HELP MEMORY for your options.

Error in multiFlybyObjFunc (line 97)


Error in flyByPorkchopPlotterGUI>@(x)multiFlybyObjFunc(x,numRevsArr,wayPtBodies,false,false,celBodyData) (line 513)


Error in flyByPorkchopPlotterGUI>computeFlybyPorkchopPlotButton_Callback (line 514)


Error in gui_mainfcn (line 95)


Error in flyByPorkchopPlotterGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)flyByPorkchopPlotterGUI('computeFlybyPorkchopPlotButton_Callback',hObject,eventdata,guidata(hObject))

Error using waitforallfiguresclosed (line 9)
Error while evaluating UIControl Callback.

This is happening on a system with 48 GB of ram.

I couldn't reproduce.  Can you give me the exact steps I need to take to get this to happen?

Quote

Another one:

While messing around on LVD, I removed one of the sequential events that contained an Impulsive Delta-V action that had all 3 components as  variables that should be optimized. However, when starting the optimizer, I could see that there were 3 variables more than it should be on the variables graph (the one at the top). After closing KSP-TOT and reopening the .mat, the problem seemed to be fixed. I guess some reference was left dangling (I think there were constraints referring to that event, but not sure). Unfortunately I forgot to keep a copy of this .mat for you

Thanks for the report!  This one is resolved for next release.  I have been trying to track down this one for ages, so I'm glad it's finally taken care of.

[vitorboschi]

2 minutes ago, Arrowstar said:

I couldn't reproduce.  Can you give me the exact steps I need to take to get this to happen?

I simply open the multi-flyby porkchop plotter, change the waypoints to that sequence: Kerbin, Jool, Eve, Moho and hit the button to compute the plot.

Do you have an idea about the expected peak memory consumption for a case like that?

Quote

Thanks for the report!  This one is resolved for next release.  I have been trying to track down this one for ages, so I'm glad it's finally taken care of.

Awesome!

[Arrowstar]

Hi everyone,

This afternoon I've built KSPTOT v1.6.7 pre-release 11.  Here's the change log:

• LVD: Upload impulsive delta-v maneuver from "Add Impulsive Delta-V" event action is now available.  Right click on an event in the sequential events list with an "Add Impulsive Delta-V" action and click on the upload maneuver menu item.
• MA: Resolved issue with computing position wrt Sun of other spacecraft.
• LVD: True anomaly termination condition should now work properly.
• LVD: Event actions with variables now correctly remove those variables when the action is deleted.

Please let me know if you find any further bugs.  Thanks!

28 minutes ago, vitorboschi said:

I simply open the multi-flyby porkchop plotter, change the waypoints to that sequence: Kerbin, Jool, Eve, Moho and hit the button to compute the plot.

Do you have an idea about the expected peak memory consumption for a case like that?

Can you try out PR11, above, and see if it resolves your issue.  I still can't reproduce, so maybe I fixed whatever is causing your issue.   (Unless, you're on Linux, right?  I can't build for Linux right now, so unless you have a Windows system around, we might have to just wait for a bit.)

Memory consumption should be pretty low.  It certainly wouldn't consume 48 GB.  You might be running into a bug somewhere... hopefully I can fix it, if I haven't already.

Can someone else follow @vitorboschi's instructions in MFMS  in PR11 and see if they can't reproduce?  Thanks!

Edited December 22, 2020 by Arrowstar

[vitorboschi]

20 hours ago, Arrowstar said:

Hi everyone,

This afternoon I've built KSPTOT v1.6.7 pre-release 11.  Here's the change log:

• LVD: Upload impulsive delta-v maneuver from "Add Impulsive Delta-V" event action is now available.  Right click on an event in the sequential events list with an "Add Impulsive Delta-V" action and click on the upload maneuver menu item.
• MA: Resolved issue with computing position wrt Sun of other spacecraft.
• LVD: True anomaly termination condition should now work properly.
• LVD: Event actions with variables now correctly remove those variables when the action is deleted.

Please let me know if you find any further bugs.  Thanks!

Can you try out PR11, above, and see if it resolves your issue.  I still can't reproduce, so maybe I fixed whatever is causing your issue.   (Unless, you're on Linux, right?  I can't build for Linux right now, so unless you have a Windows system around, we might have to just wait for a bit.)

Memory consumption should be pretty low.  It certainly wouldn't consume 48 GB.  You might be running into a bug somewhere... hopefully I can fix it, if I haven't already.

Can someone else follow @vitorboschi's instructions in MFMS  in PR11 and see if they can't reproduce?  Thanks!

Yeah, Linux user here. I'll see if I can get my hands on a Windows machine to perform some tests

[Snoman314]

I found someone interested in letting me play mission control with  the MCC RTS, for them as they play KSP. Doing a search of this thread, it looks like we'll need to forward ports 8282 and 8295. Anything else?

[Snoman314]

I'm also finally getting into Ion engines. I have questions about the  manoeuvre execution assistant (MEA), as well as finite duration DV manoeuvres in the Mission Architect.

The questions are around when the burn will be executed for the finite duration burns, and where the rocket is pointed for both.

For time, am I correct in assuming that the for finite duration manoeuvre's, the idea is that the burn will start at the end of the previous event (e.g. coast to a specific TA etc)? (As opposed to impulsive dV Manoeuvre's, where I'm used to starting the burn before the node's time, so that 1/2 dV is before, and 1/2 after the node time).

For the MEA, is the idea here to just aid in executing/timing impulsively calculated dV Manoeuvre's? It looks like the idea is to point at the manoeuvre node in-game as well? (instead of say, sticking to prograde). If that's the case, I can continue to use my manoeuvre node timing code I wrote for kOS, and not worry about this tool.

But the finite duration manoeuvres in the Mission Architect confuse me no end. How are they supposed to be executed? I tried pointing at the node, and starting the burn and t = 0, and that did not work, lol.

[Arrowstar]

15 hours ago, Snoman314 said:

I found someone interested in letting me play mission control with  the MCC RTS, for them as they play KSP. Doing a search of this thread, it looks like we'll need to forward ports 8282 and 8295. Anything else?

You actually want ports 8282 through 8295 open.

13 hours ago, Snoman314 said:

For time, am I correct in assuming that the for finite duration manoeuvre's, the idea is that the burn will start at the end of the previous event (e.g. coast to a specific TA etc)? (As opposed to impulsive dV Manoeuvre's, where I'm used to starting the burn before the node's time, so that 1/2 dV is before, and 1/2 after the node time).

This is correct.  Maneuvers start and end at the start and end of their event.

Impulsive DV maneuvers in MA actually work the same way.  it's just that their duration is 0 seconds, and so the start and end time is the same.

Quote

For the MEA, is the idea here to just aid in executing/timing impulsively calculated dV Manoeuvre's? It looks like the idea is to point at the manoeuvre node in-game as well? (instead of say, sticking to prograde). If that's the case, I can continue to use my manoeuvre node timing code I wrote for kOS, and not worry about this tool.

 

Yes, that's correct.  MEA was designed to help with executing impulsive manevuers in KSP, with the caveat that the maneuver duration needs to be "considerably shorter" than the orbital period of the initial orbit.  (If this assumption doesn't hold well, then the impulsive approximation to the finite burn will not hold either.) 

Quote

But the finite duration manoeuvres in the Mission Architect confuse me no end. How are they supposed to be executed? I tried pointing at the node, and starting the burn and t = 0, and that did not work, lol.

Ah, right.  So the maneuver node uploaded to KSP is the attitude of the vehicle at the start of the burn, and the node is placed at the start of the burn.  You are responsible for executing the rest of the maneuver according to the steering law you've picked.  If that's inertial steering, then you can just hold that attitude.  If it's orbital frame steering, then you need to keep the same attitude relative to the prograde/normal/radial markers on the nav ball.

Let me know if that helps or if you have any other questions.

[Snoman314]

7 hours ago, Arrowstar said:

You actually want ports 8282 through 8295 open.

Good to know, thanks!

7 hours ago, Arrowstar said:

This is correct.  Maneuvers start and end at the start and end of their event.

Impulsive DV maneuvers in MA actually work the same way.  it's just that their duration is 0 seconds, and so the start and end time is the same.

Yes, that's correct.  MEA was designed to help with executing impulsive manevuers in KSP, with the caveat that the maneuver duration needs to be "considerably shorter" than the orbital period of the initial orbit.  (If this assumption doesn't hold well, then the impulsive approximation to the finite burn will not hold either.) 

Ah OK, that all makes sense, thanks.

7 hours ago, Arrowstar said:

Ah, right.  So the maneuver node uploaded to KSP is the attitude of the vehicle at the start of the burn, and the node is placed at the start of the burn.  You are responsible for executing the rest of the maneuver according to the steering law you've picked.  If that's inertial steering, then you can just hold that attitude.  If it's orbital frame steering, then you need to keep the same attitude relative to the prograde/normal/radial markers on the nav ball.

Let me know if that helps or if you have any other questions.

OK, I've dabbled with the LVD, so I at least know what you're talking about when you say 'steering law', but I've yet to figure that one out fully. I'll assume for now your reply there will make more sense as I figure the LVD out more.

In the meantime, using the Mission Architect, does this mean that if I want to be able to continue following the manoeuvre node in-game (for a finite duration burn), I need to set the mission up using inertial vector mode? Can you give me a hint as to where the X/Y/Z components point relative to Prograde? Not knowing what those values mean is the reason I've never tried that mode.

Thanks again for your help 

[Snoman314]

A slight side-track, so a separate post, but this last conversation got me thinking about how everyone else executes manoeuvre nodes.

The reason I want to be able to follow the in-game node pointer, is that I can access that vector from inside kOS, and I've written a manoeuvre node execution program that can get extremely high burn accuracy, by adjusting the pointing direction to follow the node vector to compensate for any errors during the burn, and throttling down to a stop with sub mm per second precision. It's so good that I have to be careful using the Rendezvous Maneuver Sequencer (sic), because I'll usually end up impacting the target vessel near the end of the second burn if I don't do something to prevent it.

BUT!, that's for high TWR ratio vessels! Now that I'm playing around with high ISP engines with low thrust, my old methods don't work so well.

Reading some of @Arrowstar's comments above, it would be easy enough to use kOS to point the craft at a given attitude or whatever, and burn for a given amount of time, sure. But without the feedback I get from the game in regards to dV remaining, and the direction of the remaining dV vector changing due to small errors, I will not have the same accuracy as I'm used to.

So, how do you guys do it?

[Arrowstar]

18 hours ago, Snoman314 said:

So, how do you guys do it?

I think I see what you're after.  Unfortunately, I think you're going to need to change your workflow if you want to use MA or (especially) LVD in KSP.  Try something like this:

1. Create an nominal initial mission plan in MA or LVD.
2. Launch your spacecraft.  If you're using LVD for your mission and you're modeling the launch, too, then skip to the next step and do it for the launch.
3. Update your initial state (in MA/LVD) to your spacecraft's current state (from KSP) and remove any events that occur prior to the updated state (in MA/LVD).  Your new initial state should be pretty close to the nominal mission plan you create in step (1).
   1. In MA, there's an "Advance to Event" option in the mission script you can use for this.  In LVD, you'll need to do it by hand.
   2. Here's how I would do it by hand in LVD:
      1. Turn off auto-propagation of the mission script.
      2. Remove the events that occur prior to my KSP state.  You may want to save a new LVD file prior to doing this each time, in case you need to go back.
      3. Go into the initial state dialog and update the orbit from KSP (right click on an orbit element).
      4. You'll need to update your spacecraft propellent masses too.  Best way to do this is to spit out the masses in each tank in Graphical Analysis prior to deleting events, and then use the tank masses that correspond to the start of each new initial state.
4. Reoptimize the mission with the new initial state.  You're now ready to execute your first maneuver.
5. You'll need to rewrite some kOS code to get this to work.  It needs to do one of the following:
   1. If you're using MA:
      1. Write code to point the spacecraft's thrust vector along either an inertial vector or a vector fixed in the orbit frame (prograde/normal/radial).
      2. For the next burn in MA, record the optimized pointing direction and duration, create some sort of text file or kOS input, and supply your kOS burn code with the time of the burn start, the duration of the burn, and the burn direction and reference frame.
   2. If you're using LVD:
      1.  Use the Graphical Analysis tool to spit out the inertial thrust vector elements (X,Y,Z) as a function of time in a CSV file.
      2. Have kOS read this file and use it to know when the burn starts, how long it goes for, and what direction to point at as a function of time.
      3. It may be helpful to decrease the integrator output step size of your burn segments to 1  second or so, to make sure you have good fidelity on the pointing and some simple linear interpolation of x, y, and z coordinates will still be pretty close.
6. Go back to step (3) and repeat 3-5 for each burn.  Basically the sequence for each burn is: Advance mission plan and update state in MA/LVD, reoptimize mission, and upload new burn parameters to kOS/KSP.

Quote

But without the feedback I get from the game in regards to dV remaining, and the direction of the remaining dV vector changing due to small errors, I will not have the same accuracy as I'm used to.

You're absolutely not going to have the same accuracy you're used to.  But that's okay!  In real life, our models don't match the "real world" perfectly either, and we have to go with the fact that it's "close enough" and will get us there eventually with minor tweaks to the mission and burn plans.

Let me know if you have any questions.

18 hours ago, Snoman314 said:

Can you give me a hint as to where the X/Y/Z components point relative to Prograde? Not knowing what those values mean is the reason I've never tried that mode.

Inertial X, Y, and Z don't line up with the prograde/normal/radial in any specific way.  They are relative to your orbit and current position in your orbit.

Edited December 28, 2020 by Arrowstar

[Snoman314]

Thanks for taking the time to give me such a thorough reply.

Steps 1-4 are pretty much what I already do, with my current 'step 5' being to upload a manoeuvre node to execute.

From what you're saying, it comes down to just coming up with a direction to point the vessel, burning for a set time, and hoping for the best. I'll just have to put up with any steering and velocity errors and do a later mid-course correction or something like that.

8 hours ago, Arrowstar said:

Let me know if you have any questions.

Inertial X, Y, and Z don't line up with the prograde/normal/radial in any specific way.  They are relative to your orbit and current position in your orbit.

OK, I still don't have the first clue how to use the X/Y/Z mode. Given that step one for, say, a trans-munar injection burn would be to create a manoeuvre node prograde with approx 840m/s, roughly 90 degrees behind the Mun's current position, and then let the optimiser figure out where to go from there - where do I start if using X/Y/Z? How do I input a burn that's in the ballpark, so that the optimiser has a place to start?

[vitorboschi]

17 hours ago, Arrowstar said:

You're absolutely not going to have the same accuracy you're used to.  But that's okay!  In real life, our models don't match the "real world" perfectly either, and we have to go with the fact that it's "close enough" and will get us there eventually with minor tweaks to the mission and burn plans.

Out of curiosity, do you know how precise are real life orbital maneuvers today? In terms of dV/timing/thrust direction?