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

[Arrowstar]

I'm uploading a new PR13 ZIP file with a fix for the TwoBodyImpactPoint constraints such that they don't return NaN anymore.  However, as I mentioned, it's best to just propagate to your impact point generally and set constraints for latitude, longitude, etc.  These specialized constraints are probably only really for when you can be certain that you're going to hit a body and optimization steps won't take you away from that.  (Think, for example, constraining the first stage impact point for your rocket launch.)

[vitorboschi]

12 hours ago, Arrowstar said:

Yeah, I see the issue now.  You're not hitting the body so the constraint sort of freaks out since there is no impact.  I would recommend just propagating to the impact point directly in LVD and setting your latitude, longitude, and altitude constraints for that point as desired.

Alright, I'll do it. Thanks for the explanation!

Maybe bug:

- LVD is somewhat unresponsive for some time after scrubbing the mission time slider.

QoL suggestions:

- Let the user select select (or do it automatically) the reference frame for the Spacecraft state panels (Initial Spacecraft State, Final Spacecraft State, view state after event). It would be a lot more useful for times where the spacecraft is at ground

- For the objective function, let the scaling factor be negative. This would allow us to, for example, minimize distance to body while maximizing spacecraft mass

Edited January 5, 2021 by vitorboschi

[vitorboschi]

@Arrowstar I'm trying to launch retrograde, but for some reason I can't get the pitch to go over 90 degrees. I have also tried to roll 180 degrees before pitching from 90 to 0, but it doesn't helped either. However, if I set the initial steering pitch to 90.01 instead of 89.99, at least the graphical visualization seems to be correct (the ship launches retrograde), but the pitch values still are between 90 and 0.

Question: What is the correct approach to get a retrograde orbit? Is this a bug?

 

[Arrowstar]

3 hours ago, vitorboschi said:

Alright, I'll do it. Thanks for the explanation!

Maybe bug:

- LVD is somewhat unresponsive for some time after scrubbing the mission time slider.

QoL suggestions:

- Let the user select select (or do it automatically) the reference frame for the Spacecraft state panels (Initial Spacecraft State, Final Spacecraft State, view state after event). It would be a lot more useful for times where the spacecraft is at ground

- For the objective function, let the scaling factor be negative. This would allow us to, for example, minimize distance to body while maximizing spacecraft mass

1. This has gotten a lot better over previous performance.  Unfortunately, there's not much I can do about the slider's performance at this point as it's all internal to MATLAB.  It can be a bit frustrating,  I understand, I'm just not sure what else to do about it.
2. This is an interesting idea, yes.  I don't think it'll make it into the v1.6.7 release as I'm itching to get it out, but I'll certainly keep it in mind for the v1.6.8 release.  Let me add it to my to-do/consider list on the OP.
3. Generally, the way to go about what you're trying to do is to set a constraint for the distance to body (since you probably have something in mind) and then maximize spacecraft mass.  Generally when you're in a situation where you want to minimize one thing and maximize another, there's a better way to formulate the problem where one of those quantities is actually a constraint.  Give that a try.

2 hours ago, vitorboschi said:

@Arrowstar I'm trying to launch retrograde, but for some reason I can't get the pitch to go over 90 degrees. I have also tried to roll 180 degrees before pitching from 90 to 0, but it doesn't helped either. However, if I set the initial steering pitch to 90.01 instead of 89.99, at least the graphical visualization seems to be correct (the ship launches retrograde), but the pitch values still are between 90 and 0.

Question: What is the correct approach to get a retrograde orbit? Is this a bug?

 

You can't get pitch over 90 degrees because pitch is only defined between -90 and 90 degrees. What you want to do is set yaw to 270 for a westward launch (90 being east and 0 being north) and then set pitch as you desire.  Roll only controls the vehicle around the x axis after yaw and pitch rotations have been carried out, so it doesn't point the vehicle at all.

[vitorboschi]

1 hour ago, Arrowstar said:

This has gotten a lot better over previous performance.  Unfortunately, there's not much I can do about the slider's performance at this point as it's all internal to MATLAB.  It can be a bit frustrating,  I understand, I'm just not sure what else to do about it.

Got it! I remember seeing some mentions about this problem earlier in this thread, but wasn't sure this was the same thing. Thank you for the clarification

1 hour ago, Arrowstar said:

This is an interesting idea, yes.  I don't think it'll make it into the v1.6.7 release as I'm itching to get it out, but I'll certainly keep it in mind for the v1.6.8 release.  Let me add it to my to-do/consider list on the OP.

Cool!

1 hour ago, Arrowstar said:

Generally, the way to go about what you're trying to do is to set a constraint for the distance to body (since you probably have something in mind) and then maximize spacecraft mass.  Generally when you're in a situation where you want to minimize one thing and maximize another, there's a better way to formulate the problem where one of those quantities is actually a constraint.  Give that a try.

Will do!

1 hour ago, Arrowstar said:

You can't get pitch over 90 degrees because pitch is only defined between -90 and 90 degrees. What you want to do is set yaw to 270 for a westward launch (90 being east and 0 being north) and then set pitch as you desire.  Roll only controls the vehicle around the x axis after yaw and pitch rotations have been carried out, so it doesn't point the vehicle at all.

That did it, thanks! Maybe it's a good idea to add an error message when the user try to set pitch (or any other parameter, really) to an invalid/out of range value.

[Arrowstar]

1 hour ago, vitorboschi said:

That did it, thanks! Maybe it's a good idea to add an error message when the user try to set pitch (or any other parameter, really) to an invalid/out of range value.

This is the tricky bit, because it's not really erroneous in the typical sense.  If pitch goes greater than 90 or less than -90, then what happens is that the yaw flips by 180 degrees and the new pitch becomes 180 degrees minus the old pitch.  This can actually be useful behavior in some situations where you want the vehicle to flip through the 90 degree point and back out the other side.

Edited January 5, 2021 by Arrowstar

[vitorboschi]

@Arrowstar Ok, I finally finished the mission planning stage (.mat is here: https://www.dropbox.com/s/m7g64hybdpsl2kz/Mun impact mission4.mat?dl=0) and generated the .csv out of it (https://www.dropbox.com/s/70r33wsk8lewfap/testKerbinLiftoff.csv?dl=0

Now, I tried to run it on the launchpad but it does not work:

- It seems to keep waiting at the first event with throttle = 0 (which is expect)

- When the time comes, the script will quickly jump until the coast event (number 9 at the .mat) without really running the other steps, which of course just crash the ship

Am I missing something?

[Arrowstar]

1 hour ago, vitorboschi said:

@Arrowstar Ok, I finally finished the mission planning stage (.mat is here: https://www.dropbox.com/s/m7g64hybdpsl2kz/Mun impact mission4.mat?dl=0) and generated the .csv out of it (https://www.dropbox.com/s/70r33wsk8lewfap/testKerbinLiftoff.csv?dl=0

Now, I tried to run it on the launchpad but it does not work:

- It seems to keep waiting at the first event with throttle = 0 (which is expect)

- When the time comes, the script will quickly jump until the coast event (number 9 at the .mat) without really running the other steps, which of course just crash the ship

Am I missing something?

Well that is interesting... so it looks like MATLAB's csvwrite function spits out data in scientific notation if the numbers get too long.  Let me investigate how to do this properly.  Thanks for sharing.  I'll try to get a new build up ASAP.

EDIT: By the way, just by looking at your CSV file, I see you may have an issue.  You need to up your data rate so the linear interpolation in the script doesn't get to wonky.  Try setting your global integration output step size to 1 second.  You can do this in Settings -> Integration Settings.  Then experiment to find a good balance between too much data and sufficient fidelity to capture the steering correctly.

EDIT 2: Okay, got it figured out and the new PR13 ZIP file with the fix is uploaded.

Edited January 5, 2021 by Arrowstar

[vitorboschi]

1 hour ago, Arrowstar said:

Well that is interesting... so it looks like MATLAB's csvwrite function spits out data in scientific notation if the numbers get too long.  Let me investigate how to do this properly.  Thanks for sharing.  I'll try to get a new build up ASAP.

EDIT: By the way, just by looking at your CSV file, I see you may have an issue.  You need to up your data rate so the linear interpolation in the script doesn't get to wonky.  Try setting your global integration output step size to 1 second.  You can do this in Settings -> Integration Settings.  Then experiment to find a good balance between too much data and sufficient fidelity to capture the steering correctly.

EDIT 2: Okay, got it figured out and the new PR13 ZIP file with the fix is uploaded.

Thank you! I'll retry now. I've also got a couple of suggestions:

1. I recommend using only lowercase chars for KOS filenames. The reason is that it'll convert to lowercase internally, which makes it unable to load files with uppercase characters on case sensitive filesystems (Linux and Mac, I think)

2. When exporting the CSV files, I think it makes more sense to be able to select only a few events (or time range) of the mission for exportation, because we'll usually have to tweak the mission after each burn to correct imprecisions.

3. The global integration output affects other things besides the CSV export, no? Would it make sense to let the user select a specific step size when exporting the CSV (so that other things are not changed)

[Arrowstar]

4 minutes ago, vitorboschi said:

Thank you! I'll retry now. I've also got a couple of suggestions:

1. I recommend using only lowercase chars for KOS filenames. The reason is that it'll convert to lowercase internally, which makes it unable to load files with uppercase characters on case sensitive filesystems (Linux and Mac, I think)

Great idea, I'll do this for the release.

Quote

2. When exporting the CSV files, I think it makes more sense to be able to select only a few events (or time range) of the mission for exportation, because we'll usually have to tweak the mission after each burn to correct imprecisions.

So I thought about this and almost did it.  However, with the ability to jump around in time and propagate backwards, it seemed like it would cause too much confusion to the user about which events to select.  Outputting everything and then using the new "advance to event" functionality to later jump past completed events spares everyone that confusion at the expense of just a bit of loading time in kOS.

Quote

3. The global integration output affects other things besides the CSV export, no?

The only big thing it impacts for most integrators is the number of data points output: the solutions themselves generally stay the same.  This is not necessarily true for ODE5, because it's a fixed step size integrator.  But I think "generally no" is a good answer to your question.

Quote

Would it make sense to let the user select a specific step size when exporting the CSV (so that other things are not changed)

No, because the integration would have to be redone anyway in order to get the states of the vehicle at those new step sizes anyway.  If it's not desirable to keep the small step sizes after outputting the  CSV file for kOS, one can always Edit -> Undo that change later.

[vitorboschi]

11 hours ago, vitorboschi said:

Thank you! I'll retry now. I've also got a couple of suggestions:

1. I recommend using only lowercase chars for KOS filenames. The reason is that it'll convert to lowercase internally, which makes it unable to load files with uppercase characters on case sensitive filesystems (Linux and Mac, I think)

2. When exporting the CSV files, I think it makes more sense to be able to select only a few events (or time range) of the mission for exportation, because we'll usually have to tweak the mission after each burn to correct imprecisions.

3. The global integration output affects other things besides the CSV export, no? Would it make sense to let the user select a specific step size when exporting the CSV (so that other things are not changed)

Ok, it seems to have worked now, although I couldn't yet make the launch work 'till the end because KSP keeps crashing mid flight (looks like a KOS issue), but I have found a small issue with roll: it happened many times that the ship performed a full roll while it shouldn't (roll was set to zero all the time), and I'm pretty sure this is because of the way it's represented in KOS/KSP-TOT: as a 0-360 degree value (or rad, but it doesn't really matter). Since the set value is 0, a small perturbation may make it wrap to something like 359.9, and the ship does a complete roll to fix that. Now, I'm not sure this is easily fixable into the KOS script or if it's something that should/must be fixed in KOS itself, but just setting the roll to a value far from 0 and 360 should workaround this problem.

@ArrowstarAnother suggestion to the KOS feature: if you transpose the data when exporting (so that each line represents a point in time instead of a column), it would be possible to make the script work by reading a line at a time. This would likely reduce memory usage, but most importantly, would cut the long loading time to zero

[vitorboschi]

@ArrowstarHow hard would it be to implement the CSV exporter as a plugin instead of being embedded into the application? I'm asking because it looks to me that it would be a great example plugin (that people can learn from in order to make their own) and also enable really easy customization.

[Arrowstar]

2 hours ago, vitorboschi said:

Ok, it seems to have worked now, although I couldn't yet make the launch work 'till the end because KSP keeps crashing mid flight (looks like a KOS issue), but I have found a small issue with roll: it happened many times that the ship performed a full roll while it shouldn't (roll was set to zero all the time), and I'm pretty sure this is because of the way it's represented in KOS/KSP-TOT: as a 0-360 degree value (or rad, but it doesn't really matter). Since the set value is 0, a small perturbation may make it wrap to something like 359.9, and the ship does a complete roll to fix that. Now, I'm not sure this is easily fixable into the KOS script or if it's something that should/must be fixed in KOS itself, but just setting the roll to a value far from 0 and 360 should workaround this problem.

I noticed this too, yes.  There's not much I can do about it, though.  This is a control systems issue.  kOS needs to be smart enough to find the short way rotation between its current and commanded attitude.  At the moment, it's not.  Maybe I'll file a bug report with the kOS devs.  At least it'll get on their radar that way.

Quote

@ArrowstarAnother suggestion to the KOS feature: if you transpose the data when exporting (so that each line represents a point in time instead of a column), it would be possible to make the script work by reading a line at a time. This would likely reduce memory usage, but most importantly, would cut the long loading time to zero

Yes, that's true.  It's not a bad suggestion actually.  I don't think I'll change it for the v1.6.7 release since I really do want to get it out the door in the next few days, but I can look into the change afterwards.

31 minutes ago, vitorboschi said:

@ArrowstarHow hard would it be to implement the CSV exporter as a plugin instead of being embedded into the application? I'm asking because it looks to me that it would be a great example plugin (that people can learn from in order to make their own) and also enable really easy customization.

I suspect it wouldn't be hard at all.  However, that would put the functionality in an unintuitive spot that would be hard to find and would likely never get used, so I'd prefer not to move it.  I probably could include it, or something similar to it, as an example plugin, though.

As far as customization goes, I actually do rely on the fixed format of the CSV file for the kOS script, so I'm afraid that's not an option.  However, if you want to produce a custom CSV file, remember that Graphical Analysis is capable of spitting out CSV files along with the plotting capabilities.  You can certainly try that!

[vitorboschi]

31 minutes ago, Arrowstar said:

Yes, that's true.  It's not a bad suggestion actually.  I don't think I'll change it for the v1.6.7 release since I really do want to get it out the door in the next few days, but I can look into the change afterwards.

Awesome! I have just reworked the script side of the thing to work that way (worked like a charm) and made a launch from Kerbin using it. Here are my stats:

Expected orbit / Actual orbit:

SMA:  6993.698km /  7077.637 km

ECC: 0.9248807 / 0.92720

INC: 179.8792 deg / 179.844 deg

RAAN: 57.00031 deg / 30.664 deg

AOP: 184.3414 deg / 154.729 deg

 

[Arrowstar]

11 minutes ago, vitorboschi said:

Awesome! I have just reworked the script side of the thing to work that way (worked like a charm) and made a launch from Kerbin using it. Here are my stats:

Expected orbit / Actual orbit:

SMA:  6993.698km /  7077.637 km

ECC: 0.9248807 / 0.92720

INC: 179.8792 deg / 179.844 deg

RAAN: 57.00031 deg / 30.664 deg

AOP: 184.3414 deg / 154.729 deg

 

Well, it's not actually as bad as I was thinking it was going to be, but clearly it's fairly far off.  This is why real rockets use closed loop guidance for orbit insertion and don't just run open loop steering the whole way to orbit.

Quote

I have just reworked the script side of the thing to work that way (worked like a charm)

Would you mind sharing the updated script with me?  If you've already done it and don't mind me just using it after the v1.6.7 release, I may just go that route...

Edited January 6, 2021 by Arrowstar

[vitorboschi]

49 minutes ago, Arrowstar said:

Well, it's not actually as bad as I was thinking it was going to be, but clearly it's fairly far off.  This is why real rockets use closed loop guidance for orbit insertion and don't just run open loop steering the whole way to orbit.

Yeah, but still way better than I could do myself

Do you know some keywords I can search for, if I ever try to write a closed loop guidance control?

 

51 minutes ago, Arrowstar said:

Would you mind sharing the updated script with me?  If you've already done it and don't mind me just using it after the v1.6.7 release, I may just go that route...

Sure thing: https://www.dropbox.com/s/x9i5mao7cx333i8/execlvdcontrolt.ks?dl=0

I have used the csvtool application (available on Linux) to transpose the generated CSV and test it.

 

1 hour ago, Arrowstar said:

As far as customization goes, I actually do rely on the fixed format of the CSV file for the kOS script, so I'm afraid that's not an option.  However, if you want to produce a custom CSV file, remember that Graphical Analysis is capable of spitting out CSV files along with the plotting capabilities.  You can certainly try that!

Yes, customization would require changes in the kOS script too, but that part is already easily changeable. I know I can generate data from the GA tool, but I was thinking in a slightly more advanced workflow, like, for example, generating a few lines at the beginning of the file with the expected state after each event, and only after that putting the throttle/attitude data points. That would allow me to display how much the ship is deviating from the plan, and maybe add some sort of closed loop guidance to the mix

[KC_073]

1 hour ago, vitorboschi said:

Yeah, but still way better than I could do myself

Do you know some keywords I can search for, if I ever try to write a closed loop guidance control?

 

 Something like this https://ksp-kos.github.io/KOS/tutorials/pidloops.html ?

[vitorboschi]

23 minutes ago, KC_073 said:

 Something like this https://ksp-kos.github.io/KOS/tutorials/pidloops.html ?

Not really. A PID is just a small part of the problem. What I meant by closed loop is a guidance controller that will try to achieve a given orbit instead of blindly following the calculated attitude/throttle over time

[Arrowstar]

Just now, vitorboschi said:

Not really. A PID is just a small part of the problem. What I meant by closed loop is a guidance controller that will try to achieve a given orbit instead of blindly following the calculated attitude/throttle over time

Look for Powered Explicit Guidance, PEG.  A modified version of PEG was flown on Shuttle so it's pretty good all around.

[KC_073]

2 minutes ago, vitorboschi said:

Not really. A PID is just a small part of the problem. What I meant by closed loop is a guidance controller that will try to achieve a given orbit instead of blindly following the calculated attitude/throttle over time

Ah, got it.  This seems relevant -
 

 

Or some related light reading here - https://ntrs.nasa.gov/citations/19970022700

Edited January 6, 2021 by KC_073

[Arrowstar]

Last call for bug reports in v1.6.7 pre-release 13!  Otherwise we're looking at a release tomorrow I think.

[Arrowstar]

Hi everyone!

This afternoon I'm pleased to announce the release of the KSP Trajectory Optimization Tool v1.6.7!  This is a major release that generally adds significant new functionality to Launch Vehicle designer.  It also fixes some bugs in Mission Architect and other parts of the application.

One of the marquee improvements to Launch Vehicle Designer is the ability to export LVD steering and throttle controls to a CSV file which can be read in from a custom kOS script.  You can check out some of the discussion on this topic earlier in this thread, or check out the following demonstration video of a munar lander inserting into a circular orbit from the surface.

Here's the full change log:

• LVD: Implementation of alternators and electric engines.
• LVD: Fix for broken plot background color option.
• LVD: GA now respects event plotting setting when plotting data.
• LVD: Implementation of alternators and electric engines.
• LVD: Fix for broken plot background color option.
• LVD: GA now respects event plotting setting when plotting data.
• MA/LVD: Added option to set number of parallel workers for optimization.
• MA: Fixed bug with having more than one variable item in a variable (initial state).
• MA: LWA can now import target orbit data from KSP.
• MA: Added functionality to set launch site from ground target in Set State (estimate launch).
• LVD: Fixed bug with power sources (wrong matrix size stuff).
• MA: Resolved issue that causes error if an event does not have any states associated with it.
• LVD: Added ability to set positive output step sizes for all active integrators on events.
• LVD: Boosted performance when looking for downward SoI transitions.
• LVD: Can now create event continuity constraints via a context menu accessed by right clicking on the sequential events listbox.
• LVD: Drawing plots should be faster when plotting other celestial bodies.  The slow multiprocessing stuff from a previous pre-release is gone here.
• LVD: Added a feature to output the wall clock run time for each event to the ksptot.log file upon propagation.  See Settings menu.
• LVD: Fixed bug with the time slider sucking up a bunch of CPU time after sliding it around a bunch.
• The missing parentID lines of the SolarSystemBodies.ini file have been added.
• LVD: Added a linear tangent steering model to the available options in LVD.  This is a great way to get an optimal ascent from the surface of a body to space, as the linear tangent steering law is actually derived directly from optimal control theory.  As of now, only "pitch" type angles can use this steering.
  • The linear tangent steering law is: tan(pitch_angle) = a*t + b, where t is time after the steering law is initiated and a and b are constants.
  • There is a new lvd example MAT file that shows how to use it, and best of all, shows how it can be used to get off of the Mun in a single event!
• MA/LVD: Added a flight path angle graphical analysis task and constraint.
• LVD: Fixed bug with Adjust Variable dialog getting a weird axes in the background sometimes.
• LVD: Optimization variables are now sorted by event number before optimization so they appear in order in the optimization UI.
• LVD: Having the Update View Limits option checked in the View Settings now retains the existing view direction, it just updates the axis limits.
• LVD: Added ability to display a semi-transparent atmosphere overlay in the View Settings.
• MA/LVD: Added a new astro calculator to find radius/velocity/FPA from sma/ecc/true anomaly.
• MA: Mission Animator UT time entry field now has a context menu for entering time as date/time. It also attempts string evaluation.
• LVD: Added angle equations to steering and throttle UIs.
• LVD: Users can now set the type of throttle model and steering model in the initial state, as well as their corresponding parameters.
• Celestial bodies can now display a surface texture instead of the color gradient used previously.
• MA/LVD: Added flight path angle graphical analysis tasks and constraints.
• MA: Mission Animator time slider step size is now fixed to warp rate.
• LVD: Steering model UIs now display proper angle names and not just "alpha", "beta", and "gamma."
• LVD: The main LVD window is now resizable.  There is a minimum size limit equal to the current window size, but no limit on the maximum.
• LVD: Resolved TwoBodyPropagator error.
• The issue with radio button strings overrunning their bounds in the main KSPTOT UI on Linux has been resolved.
• LVD: Added a new toolbar button to toggle the camera toolbar on and off.  The camera toolbar can be used to move the physical scene camera around, which often makes for a better viewing experience. 
• 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.
• 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.
• 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.
• LVD: Fixed bug where attitudes would not display in backwards prop segments.
• LVD: Added option to FMINCON otimizer to automatically find optimal step size.
• LVD: Removing an event now removes the variables associated with that event's termination condition and actions.
• LVD: Resolved issue with typo in 2BImpactPointLat name.
• LVD: Resolved issue with empty globals in 2BodyImpactPt calls to findSoITransitions.
• LVD: Fixed issue with finding down SoI transitions not working if eccentricity >= 1.
• MA/LVD: Fixed bug with chunked state log generation skipping last state log entry if there's only one event in SoI.

As usual, the Windows and Linux download links are available in the first post of this thread.  Please let me know if you find any bugs, and I'll work to get them resolved.

Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire.

Happy orbiting!

[vitorboschi]

5 minutes ago, Arrowstar said:

Hi everyone!

This afternoon I'm pleased to announce the release of the KSP Trajectory Optimization Tool v1.6.7!  This is a major release that generally adds significant new functionality to Launch Vehicle designer.  It also fixes some bugs in Mission Architect and other parts of the application.

One of the marquee improvements to Launch Vehicle Designer is the ability to export LVD steering and throttle controls to a CSV file which can be read in from a custom kOS script.  You can check out some of the discussion on this topic earlier in this thread, or check out the following demonstration video of a munar lander inserting into a circular orbit from the surface.

Here's the full change log:

• LVD: Implementation of alternators and electric engines.
• LVD: Fix for broken plot background color option.
• LVD: GA now respects event plotting setting when plotting data.
• LVD: Implementation of alternators and electric engines.
• LVD: Fix for broken plot background color option.
• LVD: GA now respects event plotting setting when plotting data.
• MA/LVD: Added option to set number of parallel workers for optimization.
• MA: Fixed bug with having more than one variable item in a variable (initial state).
• MA: LWA can now import target orbit data from KSP.
• MA: Added functionality to set launch site from ground target in Set State (estimate launch).
• LVD: Fixed bug with power sources (wrong matrix size stuff).
• MA: Resolved issue that causes error if an event does not have any states associated with it.
• LVD: Added ability to set positive output step sizes for all active integrators on events.
• LVD: Boosted performance when looking for downward SoI transitions.
• LVD: Can now create event continuity constraints via a context menu accessed by right clicking on the sequential events listbox.
• LVD: Drawing plots should be faster when plotting other celestial bodies.  The slow multiprocessing stuff from a previous pre-release is gone here.
• LVD: Added a feature to output the wall clock run time for each event to the ksptot.log file upon propagation.  See Settings menu.
• LVD: Fixed bug with the time slider sucking up a bunch of CPU time after sliding it around a bunch.
• The missing parentID lines of the SolarSystemBodies.ini file have been added.
• LVD: Added a linear tangent steering model to the available options in LVD.  This is a great way to get an optimal ascent from the surface of a body to space, as the linear tangent steering law is actually derived directly from optimal control theory.  As of now, only "pitch" type angles can use this steering.
  • The linear tangent steering law is: tan(pitch_angle) = a*t + b, where t is time after the steering law is initiated and a and b are constants.
  • There is a new lvd example MAT file that shows how to use it, and best of all, shows how it can be used to get off of the Mun in a single event!
• MA/LVD: Added a flight path angle graphical analysis task and constraint.
• LVD: Fixed bug with Adjust Variable dialog getting a weird axes in the background sometimes.
• LVD: Optimization variables are now sorted by event number before optimization so they appear in order in the optimization UI.
• LVD: Having the Update View Limits option checked in the View Settings now retains the existing view direction, it just updates the axis limits.
• LVD: Added ability to display a semi-transparent atmosphere overlay in the View Settings.
• MA/LVD: Added a new astro calculator to find radius/velocity/FPA from sma/ecc/true anomaly.
• MA: Mission Animator UT time entry field now has a context menu for entering time as date/time. It also attempts string evaluation.
• LVD: Added angle equations to steering and throttle UIs.
• LVD: Users can now set the type of throttle model and steering model in the initial state, as well as their corresponding parameters.
• Celestial bodies can now display a surface texture instead of the color gradient used previously.
• MA/LVD: Added flight path angle graphical analysis tasks and constraints.
• MA: Mission Animator time slider step size is now fixed to warp rate.
• LVD: Steering model UIs now display proper angle names and not just "alpha", "beta", and "gamma."
• LVD: The main LVD window is now resizable.  There is a minimum size limit equal to the current window size, but no limit on the maximum.
• LVD: Resolved TwoBodyPropagator error.
• The issue with radio button strings overrunning their bounds in the main KSPTOT UI on Linux has been resolved.
• LVD: Added a new toolbar button to toggle the camera toolbar on and off.  The camera toolbar can be used to move the physical scene camera around, which often makes for a better viewing experience. 
• 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.
• 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.
• 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.
• LVD: Fixed bug where attitudes would not display in backwards prop segments.
• LVD: Added option to FMINCON otimizer to automatically find optimal step size.
• LVD: Removing an event now removes the variables associated with that event's termination condition and actions.
• LVD: Resolved issue with typo in 2BImpactPointLat name.
• LVD: Resolved issue with empty globals in 2BodyImpactPt calls to findSoITransitions.
• LVD: Fixed issue with finding down SoI transitions not working if eccentricity >= 1.
• MA/LVD: Fixed bug with chunked state log generation skipping last state log entry if there's only one event in SoI.

As usual, the Windows and Linux download links are available in the first post of this thread.  Please let me know if you find any bugs, and I'll work to get them resolved.

Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire.

Happy orbiting!

Great release! Congratulations @Arrowstar!

[Drew Kerman]

@Arrowstar the latest Kerbal Weather Project update has been made to work with FAR so that the pressure and temperature changes are put into effect. Does my suggestion about manual input for weather data in LVD make sense? I feel this should be more upon the user to handle if they want to deal with it

[RaceToTheMun]

Is there any PDF advance tutorials in the Multi-Flyby Manuever Sequencer?